New firmware release 1.4.0.b1

[daniel]

Hello everyone,

On this release we have added the following features:

• WLAN and Bluetooth disabling. See wlan.deinit() and bluetooth.deinit() methods.

• WiFi power save mode. This is enabled by default when in STA (Station) mode. The WiFi radio is disabled automatically when not being used to lower the power consumption. This cannot be done in AP mode because access points need to have their radios ON all the time.

• ```machine.idle()`` method now stops the CPU clock until the next interrupt occurs to preserve power.

• Bluetooth callbacks for the following events:

  • Client connected.
  • Client disconnected.
  • New advertisement received.
  • Characteristic notifications (also known as subscriptions).

• The ```wlan.disconnect()`` bug has been fixed, see: https://github.com/pycom/pycom-micropython/issues/55

• Finally we are now using the remote control peripheral to drive the RGB LED (instead of bit banging).

The new firmware binaries will be available tomorrow (around 10:00 AM CET), on the usual place: https://www.pycom.io/support/supportdownloads/#firmware

I'll notify again when the release is available for download.

Cheers,
Daniel

[jmarcelino]

Wow power savings AND great news for BLE too, can't wait to try this.

What are the chances the RMT code can be expanded to support more than the one LED, i.e. WS2812 strips?

[daniel]

Hello,

The release is live :-), feel free to download it now. Thanks!

https://www.pycom.io/support/supportdownloads/#firmware

Cheers,
Daniel

[borjam]

Great! I´'ve just updated one of my LoPys adn it seems to be working fine.

However, I have a suggestion: It would be much better if wireless interfaces (LoRa, WiFi, Bluetooth, and whatever you add in the future) were in a well known disabled state by default upon power up.

It's a bit clumsy to be required to do this just in order to get stuff running:

from network import WLAN
from network import Bluetooth
wlan = WLAN()
wlan.deinit()
bt = Bluetooth()
bt.deinit()

Moreover, if in the future you add another network interface (like the planned GyPy, it will be mandatory to add proper "deinit()" commands even if not planning to use the new interface, which will hurt upwards compatibility.

What happens when deinit() is called, by the way? Does the call to the intialization methods consume memory that I presume won't be released when calling deinit()?

[borjam]

I mean something like this (I've used the equal sign for the system prompt in order to avoid generating mark-up text formatting)

= import gc
= gc.mem_free()
31856
= from network import WLAN
= from network import Bluetooth
= gc.mem_free()
31536
= wlan=WLAN()
= gc.mem_free()
31376
= bt=Bluetooth()
BTDM CONTROLLER VERSION: 010101
btip start
copy .data from 4000d890 to 3ffae6e0, len 00001830
set .bss 0x0 from 3ffb8000 to 3ffbff70, len 00007f70
BTDM ROM VERSION 0101
BD_ADDR: 24:0A:C4:00:BD:CA
NVDS MAGIC FAILED
RF Init OK with coex
= gc.mem_free()
31152
= wlan.deinit()
= gc.mem_free()
30992
= bt.deinit()
= gc.mem_free()
30832

[jmarcelino]

I'm also a bit stumped by how to turn off wifi.

If try a simple script:

from network import WLAN
import time
import pycom

pycom.heartbeat(False)
wlan = WLAN(mode=WLAN.STA)
wlan.deinit()

while True:
    pycom.rgbled( 0x00ff00)
    time.sleep(0.1)
    pycom.rgbled( 0)
    time.sleep(9.9)

I see no decrease in current at all.

If I remove the wlan.deinit() the new power saving mode kicks in and I do see it switching from about 60mA to 140mA (@3.3V). I can't see how to turn it off. Thanks!

[daniel]

@borjam memory from Bluetooth is not released when is not in use. This is something that we are looking to implement as it is very important.

@jmarcelino we are aware of this and we are checking with Espressif.

[borjam]

Thanks @daniel. Being able to properly disable network interfaces you don't intend to use is really critical.

Not only for power reasons, but in order to avoid conditions in which a "stray" network device with a life of its own (after all both have reasonably complex associated software stacks) can lead to some nefarious behavior due to environmental circumstances.

An example: imagine that you have deployed LoPys as some kind of embedded sensors. You are using LoRa, not WiFi nor Bluetooth. Now, some device with a buggy Bluetooth or WiFi stack moves close, or it doesn't have a buggy implementation but, nevertheless, something happens that triggers a bug in the LoPy's stack. So, the WiFi or Bluetooth goes mad and something Bad™ happens.

Of course it could be an intentional attacker as well.

It would be nice to tell the Espressif guys that "off must be off" and the relevant silicon must be really powered off with no possibility of zombie behavior ;)

[PeterBaugh]

@jmarcelino Out of interest how are you measuring the power consumption of your device?

[constantinos]

Can you give us more explanation for machine.idle and sleep modes?

Thanks

[jmarcelino]

So there's the small caveat that disabled doesn't mean 'turn off' the interface :-) Thanks for the clarification! The STA power savings are very good news though, can save a lot of battery with almost no effort.

By the way I found that if I do:

from network import WLAN
wlan = WLAN(mode=WLAN.STA)

power saving is enabled, but if I use this instead it doesn't:

from network import WLAN
wlan = WLAN()
wl.mode(WLAN.STA)

@PeterBaugh: Just looking at my power supply reading at the moment. I also use a coulomb counter (LTC4150) for consumption over time (without needing to do integration) I'm hoping to do a blog post on this soon.

[daniel]

@jmarcelino

from network import WLAN
wlan = WLAN()
wl.mode(WLAN.STA)

If that's the case that's an issue. We'll check. Thanks!

[crankshaft]

@daniel Been waiting for this, thanks very much, I am looking now at my power supply which definitely shows the current is down, but fluctuating a lot.

But I have a feature request, is it possible to have a machine.sleep(msec) where msec is the number of milliseconds that you want to sleep.

This would be really cool, to be able to put it to REAL sleep without interrupts.

And on the same subject, are the RTC interrupts on the horizon so that we can achieve the above, only with more code ?

[livius]

@daniel
something is wrong

pycom.rgbled(0xff0000)
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
OSError: the requested operation is not possible

>>> os.uname()
(sysname='WiPy', nodename='WiPy', release='1.4.0.b1', version='v1.8.6-398-g4a4a81e on 2017-01-20', machine='WiPy with ESP32')

[daniel]

@livius that's being done on purpose, you need to disable the heartbeat first. You can either have the heartbeat enabled or control the LED manually. What are you trying to do?

Cheers,
Daniel

[jmarcelino]

@livius
I noticed that, but wasn't sure if it's new. You have to disable the heartbeat before using rgbled

pycom.heartbeat(False)
pycom.rgbled(0x007f00) # green

Maybe a little jarring for first time users just trying to blink the led

[livius]

@daniel

i have this file from start(3 month ago)

file "wifi_ap.py"
import pycom
print('wifi_ap')
pycom.heartbeat(0)
pycom.heartbeat(1)
pycom.rgbled(0xff0000)

this worked in all previous version of firmware
now it does not work.
If it should not work previously in that way i can fix this

[jmarcelino]

@livius
Why is the code turning the heartbeat signal off just to turn it on right after?

If you remove the pycom.heartbeat(1) line it should work.

[livius]

@jmarcelino
file 3 month ago and i suppose copy paste from doc or forum
but why i can not change color of led when it is on?

and i disable default blink of led which is after normal boot(firmware blink)

[livius]

but something is wrong try this:

1. 
pycom.heartbeat(0) #disable
pycom.rgbled(0xff0000) #change color - but this also turn it on
pycom.heartbeat(1) # strange this also disable led