New firmware release 1.4.0.b1

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

[mohpor]

@jmarcelino

That was my question. Just like in Client mode, having no Notify callback in Server mode renders having GATT Server close to useless for me.

@arneme Please read the original question again.

[jmarcelino]

@Wembly
Yes I've seen some WiFi timeouts as well. I suspect the STA mode WiFi power management isn't entirely on point - or maybe it's just doesn't like my "free" wifi router.

(pinging @daniel) I'd suggest letting us disable the automatic power savings on WiFi. Perhaps the WiFi set_mode call can take an extra parameter for both mode (i.e. STA) and power savings setting.

[jmarcelino]

@mohpor
May not be ideal or efficient but for many applications you can emulate the notification system by simply periodically polling the characteristic from your iOS app client which triggers the CHAR_READ_EVENT callback on the Py side.

[mohpor]

@jmarcelino
It's not going to work, because I want to actually read those values, plus, I need to send over large amount of data which I have to package in bundles of 140bytes and write/read them sequentially.

One thing would work though, I could have a totally separate characteristic which have events on write and when I need the data, I can write on/off to trigger updates for the main characteristic. Seems rather counter intuitive but I have to make do :(

Cheers,
M.

[daniel]

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!

This is actually not implemented. We are planning another early week release this Monday or Tuesday and we can have it available by then. I'll add it to the list.

[daniel]

I'd suggest letting us disable the automatic power savings on WiFi. Perhaps the WiFi set_mode call can take an extra parameter for both mode (i.e. STA) and power savings setting.

OK, will add this option. Thanks for the feedback everyone!

[livius]

@daniel
Hi,

is still i2c as software or it is hardware now?
i test now and when i change first bmp180 and then bh1750 it is ok:

bus = I2C(0, I2C.MASTER, baudrate=100000, pins=("P19", "P20"))
time.sleep_ms(1)

from bmp180 import BMP180
bus.scan()
time.sleep_ms(1)
bmp180 = BMP180(bus)
bmp180.oversample_sett = 2
bmp180.baseline = 103825

time.sleep_ms(1)

#bus.scan()
light_adr = bus.scan()[0] 
time.sleep_ms(1)
light_sensor = bh1750fvi.BH1750FVI(bus, addr=light_adr)

time.sleep_ms(1)

but if i change first bh1750 and then bmp180 this cause OSError: I2C bus error under current firmware - on previous all was ok

bus = I2C(0, I2C.MASTER, baudrate=100000, pins=("P19", "P20"))
time.sleep_ms(1)

#bus.scan()
light_adr = bus.scan()[0] 
time.sleep_ms(1)
light_sensor = bh1750fvi.BH1750FVI(bus, addr=light_adr)

time.sleep_ms(1)

from bmp180 import BMP180
bus.scan()
time.sleep_ms(1)
bmp180 = BMP180(bus)
bmp180.oversample_sett = 2
bmp180.baseline = 103825
time.sleep_ms(1)

[daniel]

@livius the I2C implementation is still by software and noting around that has changed on the last releases.

[mohpor]

I know it has been a while since Bluetooth got introduced, and 2 firmware updates since GATT Server was added, but, why can't we add more than one Characteristic to a service?!

To clarify what I mean here it is the GATT Profile Hierarchy:

As you can see, a Service is defined as a collection of Characteristics...
Is there a timing or plan to have proper GATT Server implementation?
The syntax is telling Service.Characteristic while it should be: Service.add_characteristic for example.

Now, to be fair, there is an Open Issue about it on Espressif side of the code:

#280: How to create multiple characteristic on same service(for Bluetooth GATT server)

Update:

The issue is closed now. The solution looks simple.

Cheers,
M.

[daniel]

@mophor thanks for pointing this out. We'll take this into account for the next release.

Cheers,
Daniel

[jasonriedy]

Digging through the code, it appears that advertisement events are tied to GATTs. They should be separate. You see the advertisements without connections.

[jasonriedy]

@jasonriedy Excuse me, connections and not GATTs.

[crankshaft]

@daniel -

Sorry if this appears to be a rant of complaints, but I was expecting much more, and are a little disappointed...

About a month ago, and after reading the specs for the wipy2 and ESP32 vs the ESP8266 which included 14ma with wifi enabled and so many features such as Dual Core, more ram, RTC, BLE, I2C, etc etc, I was so impressed with what was claimed that I purchased a handful of wipy2 and lopy devices from seeedstudio.

I initially got confused thinking that the features and specs were available now and not planned features, and that micropython and pycom's implementation of micropython were one and the same, and could not understand when libraries that were available in the micropython wiki page were not available in my wipy2, now I realise that it is only a much smaller subset of it, and that it is still very much work in progress.

Having now used it for a few weeks and built up some specific libraries, I have come to the conclusion that it is simply not ready for any real production environments yet, and is very much still in the mid beta stages.

The amount of available ram is just too small to do anything that includes anything more than one or 2 libraries, I managed to get the fantastic bosch BMP280 enviro sensor working, and cobbled together a mqtt client, however they cannot work together due to insufficient ram, and so I have to now find an alternative sensor that is easier to decode.

Given the specs, I would have expected that anything that ran on the ESP8266 would also run on the ESP32, and leave more available ram and run faster, but this is very much not the case, and libraries that ran on the older device won't run on the new one due to memory availability.

The power reduction in the latest firmware is really great, however it is still not close to the 14ma advertised and in my measurements swings between 60 and 120ma, probably with an average of 70 or 80 ma, although I have not measured it accurately.

I could further reduce power by using deep sleep, but to do that I need RTC interrupts which are not implemented yet, also I cannot sync the RTC clock as the socket.sendto() is not implemented yet and so although RTC is there, in the real world it is not really usable.

I know that pycomn have tasked espressif with freeing up the memory, and it would be great if this happens, but I struggle to understand how they can increase the available ram by 200% just by optimisation, without crippling the available features ?

Whilst you and your team are doing a really great job in adding new features and functions, it would be good if more effort could be made to concentrate on and make individual features more usable in the real world, and increase the available programmable memory back up to the 98K which I believe was the target, now it is only around 30K and it looks like this will only fall further as new features and functionality is added.

[daniel]

@crankshaft thanks for the direct feedback. We are very much aware that there's a lot to improve everywhere specially around sleep modes, but we can only do as much as the IDF permits. We will reach those current features as it's what the datasheet specifies, it simply needs more work on the firmware. Regarding the memory, we have good news around that. We have been able to release a good amount which has allowed us to increase the MicroPython heap size and also get TLS working again. All this will be available later this week.

Memory optimizations are on their way, and they won't come at the expense of less functionality.

Cheers,
Daniel