Q1 2017 development status

[daniel]

Dear All,

I wanted to update you on some of our planned firmware releases. We have 5 key features to be rolled-out:

1. Switching-off WiFI/BLE radios and actually reducing the power consumption.
   Status: We have had confirmation from Espressif that this functionality will be released within the IDF by Friday. We will need to integrate it in our firmware thereafter.

2. LoRaWAN nano-Gateway.
   Status: We have been working on this feature and plan to release it by the end of next week.

3. Providing support for frozen code and an easy way compile it.
   Status: Whilst this is a non-core feature (and it's mostly for advanced users), it is low workload and as such we will fit it into our short term schedule. The good thing is that it helps with getting large scripts running on the modules.

4. ULP co-processor.
   Status: Espressif is working on integrating the ULP processor compiler (it’s a tiny 4-bit core) with the rest of the toolchain. We are trying to get some visibility around timelines from them, and we’ll share those with you once we know more.

5. The Sleep Modes.
   Status: For the moment only deep sleep without memory retention is supported by the IDF which is not very useful without the ULP support. Light sleep mode will be added at the same time as ULP support according to Espressif.

Points 4 and 5 can only be resolved by Espressif as they must enable these features in the IDF. Espressif are working hard to progress these points and I hope to have some good news shortly.

Upon completing the first 3 features we will focus our development resources on stabilising the code, fixing bugs and releasing more memory for the application until we reach 96KB.

I want to make it clear that non of our firmware team members has been pulled onto other projects whether that be website or other non-core activities. I have read some claims to that effect on the forum however I can refute it. On the contrary, I am pleased to confirm that additional embedded developers have joined the team. Our focus remains getting our modules to full functional level despite some delays that are out of our control.

Finally, if anyone needs specific support for a particular project then it is best to email us on support@pycom.io.

Cheers,
Daniel

[jmarcelino]

Thank you Daniel. Sounds like some great functionality is coming soon.

On the Deep Sleep topic I think just supporting esp_deep_sleep_enable_timer_wakeup(microseconds) even without the ULP would be useful (though with limitations).

Many IoT tasks are periodic and require no memory retention, e.g . read a sensor every 5 minutes and send result over LoRa.

I did some experiments with it and posted some results on this thread https://forum.pycom.io/topic/556/sleep-experiments/ though I didn't try the wake up stub code.

[crankshaft]

@daniel - why is nobody replying to posts that are reporting issues such as:

1. Guru Mediation Crashes
2. Dying Sockets
3. Unstable Threading / Interrupts
4. Bytecode not Implemented
5. EHOSTUNREACH when acting as a server

It seems pointless reporting these issues on the forum as nobody at pycom seems interested in investigating or even replying ?!

[daniel]

@crankshaft I'm sorry that the lack of replies to this reports makes it look like we don't care. It's certainly not the case. We are aware of all those issues and we are working on them as well as on many other points. I'm happy to look at your specific problems if you email us on support@pycom.io with code examples that help us reproduce it easily. Would that work for you?

Cheers,
Daniel

[daniel]

@crankshaft I believe it is you posting all the issues on Github right now. Thanks for that. We will do our best to sort them out ASAP.

Cheers,
Daniel

[crankshaft]

@daniel - Thanks, but the point is if you are aware of it, why not reply to the post saying acknowledging the fact ?? - in all of the posts I have made reporting these issues, not one person has responded to a single post, not even 1 reply, nothing at all ?!

It feels like I should simply write these issues on a piece of paper and throw it in the bin

[daniel]

Thanks, but the point is if you are aware of it, why not reply to the post saying acknowledging the fact ??

All that I can say is that the whole team has been overloaded with work for the past 2 or 3 weeks. Along with the development plan that we just shared we will concentrate on solving those critical issues that you have been reporting.

Cheers,
Daniel

[crankshaft]

@daniel - I have a suggestion / request that will benefit both PYCOM and your customers, and won't take much effort or time and won't cost anything.

Whenever you release a new version, it often breaks I/O and specifically sensors, and I seem to spend unnecessary time crawling the web searching and converting python libraries to use on PYCOM devices.

Many sensors require bit-banging and changes to firmware can effect timing which will break these I/Os

So can you create an official repository of libraries for the most popular things that are used to test beta versions before they are released and can be used by customers to avoid them reinventing the wheel.

I suggest a folder for sensors such as:

1. DHTXX
2. I2C BMP/BME280
3. HX711
4. SHT21
5. DS1820X
6. SI7021

And another for sockets such as:

1. http server
2. websocket client
3. websocket server
4. mqtt client (which you have)

And another for displays:

1. ssd1306

And then create a file that calls each of these libraries and tests that they work before you release a new firmware.

[daniel]

@crankshaft thanks for the suggestion, it makes a lot of sense. We have started doing that, the repository exists (for more than a month at least ), and we have some of what the things you list already here:

https://github.com/pycom/pycom-libraries/tree/master/examples

We will work on completing it with more sensors and accessories support.

Cheers,
Daniel

[mcook]

@daniel

Hi Daniel,

I apologize if there is another thread that has an update on this.

Can you please refer me to it if one exists already? If not, could you please provide a status?

What I need is for the LoPy to enter deep sleep mode ( < 1 mA and preferably 30 uA) and wake up every 'n' hours, where 'n' is defined by me as an argument to the deep sleep function. I really don't need to preserve state at all. I don't need any sensors to wake me up (so the ULP mode is not really required for me right now). I do need to use the BT and WiFi chipsets when the app wakes up. Then I need the LoPy to re-enter sleep mode.

Do you think the above will be available soon in a new firmware update?

Thanks very much,
Mike

[jmarcelino]

@mcook
Since version 1.6.4.b1 it's possible to call machine.deepsleep(number_of_ms) and the LoPy go into deep sleep in the way you want, however at the moment the current flow is still high (15mA@3.3v last time I checked) but this being investigated

At the moment there's an issue with current not really dropping to just a few uA and we are investigating it.

https://forum.pycom.io/topic/767/new-firmware-release-version-1-6-4-b1