New firmware release 1.4.0.b1

Wembly

I have seen in later releases that I get a lot of these:

W (196498) wifi: post pm rx bcn failed
W (196498) wifi: post pm rx bcn failed
W (196498) wifi: post pm rx bcn failed
W (196498) wifi: post pm rx bcn failed
W (196498) wifi: post pm rx bcn failed
W (196498) wifi: post pm rx bcn failed
W (196498) wifi: post pm rx bcn failed
W (196498) wifi: post pm rx bcn failed
W (196498) wifi: post pm rx bcn failed

I have no idea why, I cannot recall that I got them before.
They seem to be harmful since my sockets are being dropped after a while. Also, when they arrive the hw seem to stall for many seconds.

jmarcelino

@mohpor
Yes thats is correct, the notification events are for the Py boards working as a GATT client only.

What are you trying to achieve by having a notification callback as GATT server? Servers usually just send a notification if a characteristic was updated (this isn't implemented yet)

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)

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:

powered via VIN
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 !

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

jmarcelino

@livius
This is how I understand it:

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.
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

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

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)

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

@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
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

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

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')

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 ?

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!

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.

constantinos

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

Thanks

PeterBaugh

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

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 ;)

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.

Explore Pybytes | Official Documentation | Report a Firmware Bug/Issue | GitHub

New firmware release 1.4.0.b1

UPDATE:

UPDATE 2:

Pycom on Twitter