New firmware release 1.4.0.b1

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

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

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

[mohpor]

@jmarcelino
I'm not sure what your question is about, but, there is a valid pattern involving here.
Acting as a server (GATT), you can start updating a characteristic's value IF the client subscribes to its notification which is extremely essential to GATT Servers, otherwise, you are updating a characteristic when no one's even interested in it!

[jmarcelino]

@mohpor
Yes that would be useful but this is a CHAR_NOTIFY_EVENT notification, where the Py board, acting as a GATT client, subscribes to a characteristic and for some reason (usually when the value was updated) the GATT server wishes to notify the Py board.

As far as I know the Py acting as a GATT server cannot send notifications yet, so at the moment - to me at least - there seems to be no useful purpose for a "subscribed" callback.

[arneme]

@mohpor You probably have to make sure that the server side is actually sending notifications. I think this is usually done by writing to a specific register on the server service (look it up in the documentation for the sending device).