New firmware release 1.4.0.b1

[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

[jmarcelino]

@livius
This is how I understand it:

1. heartbeat is a special function associated to the led and needs exclusive access. If it's active (set to 1 or True) you can't override it and the led will just blink periodically in blue.

2. rgbled doesn't just change the colour, it sets the led immediately to the colour you give it. If the colour is anything other than 0 (black) it turns the led on. To turn it off do pycom.rgbled(0)

[livius]

and also problem with i2c
previous code run without any problem but now i got:

I (8388) wifi: connected with livius, channel 9
WLAN connection to the router succeeded!
Traceback (most recent call last):
  File "boot.py", line 16, in <module>
  File "wifi_sta_router.py", line 65, in <module>
  File "bmp180.py", line 48, in __init__
OSError: I2C bus error

was something changed also in i2c?

@jmarcelino
i can also understand this in that way but what is then purpose about parameter

pycom.heartbeat(1)
pycom.heartbeat(0)

i can disable it and enable back with the same color as previous?
but pycom.heartbeat(1) also disable it when it was enabled
i suppose that this work as toggle instead on/off

@daniel
also i see that when i send file - size 3201 bytes throught wifi
it is somehow broken inside - it is transmitted as 3201 but some lines are wrong when i download it back throught wifi
e.g.
oryginal file

		ileTemp180=0
	if (prevCisnienie180!=cisnienie180):
		prevCisnienie180=cisnienie180
		s.send('{"U":"' + UID + 'C180' + '", "V":[[' + str(cisnienie180)+','+str(ileCisnienie180) +']]}\n')
		ileCisnienie180=0

	time.sleep(1)

and after download back:

		ileTemp180=0
	if (pr180) +']]}\n')
		ileCisnienie180=0

	time.sleep(1)

UPDATE
i see that problem with i2c was only because this crash(trash) in file not i2c itself (i suppose)
when i send this file e.g. 20 times (always successfully)
then it was eventually as should be and code work ok also in newest firmware
12 sensors read data throught i2c, one wire, digital and ADC and send it back throught wifi to service on computer and back to database :)

And now i have question - how many times we can write to flash?
What is the write cycle life of that flash?

UPDATE 2
I supposed that it all was fixed
but after fresh start on early morning it bring me back same error about i2c

WLAN connection to the router succeeded!
Traceback (most recent call last):
  File "boot.py", line 16, in <module>
  File "wifi_sta_router.py", line 65, in <module>
  File "bmp180.py", line 48, in __init__
OSError: I2C bus error

[crankshaft]

OK, just discovered something....

If I power the WIPY2 via expansion board / USB then it boots, but if I power it by VIN and GND it does not.

I have proved that it appears to be firmware related by performing the same test on another board that has factory firmware.

Can someone else verify this ?

Update 1

Is there a circuit diagram for the expansion board, I can't seem to find one ??

If I remove the expansion board jupmers for TX and RX and power it via USB, it does not boot, same as powering with VIN, I now suspect that the new firmware may not be pulling the TX/RX lines high during boot, or something is waiting for these lines to be pulled up.

Update 2
OK, If I hold P0 high, then the board will boot when:

1. powered via VIN
2. powered via USB but the TX jumper is removed.

So my guess is that the firmware is not doing a soft-pullup on this pin during bootup ??

Update 3
After more study, I believe that this issue is caused when calling the serial console in the boot.py file, the system tries to initialise the serial console and if the line is not high then it just waits forever until it is.

So not really a bug !

[mohpor]

@daniel

Thanks for the updates.

The Bluetooth.CLIENT_CONNECTED and Bluetooth.CLIENT_DISCONNECTED are working as expected. but I just can't work the Bluetooth.CHAR_NOTIFY_EVENT! It simply won't call the callback function.

I'm developing my own test app for iOS and when I try to subscribe to the characteristic I have defined, I get an update from my peripheral manager that indicates the characteristic is not subscribed for notification! Meaning the BLE characteristic has rejected the subscription. Could you provide us with a working example of the event callback to work on? Am I missing something here?

Here is how I'm defining the callback:

def char_subscribed(chr):
    print("Char Subscribed: %r" % chr)

chr1_cb = chr1.callback(trigger = Bluetooth.CHAR_NOTIFY_EVENT,  handler = char_subscribed)

P.S.: If I substitute CAHR_NOTIFY_EVENT with CHAR_READ_EVENT the callback is called when I try to read.

UPDATE:

As I was browsing through the newly available source code of the MicroPython for pycom boards (Thanks a lot), I have noticed that the Notify event is for the BLE Client mode only (?!) am I right? it says MOD_BT_GATTC_NOTIFY_EVT which from GATTC part I'm guessing it is for GATT Client only! Could someone confirm my findings?

UPDATE 2:

Using other utilities leads to same results: If you try to subscribe, it simply fails to subscribe.

Tools I tried: LightBlue (iOS and macOS)