New firmware release 1.4.0.b1

[mohpor]

@sakis
I'm well aware of the Github repo's existence but I guess the burden is on you guys to direct issues (and manage them to some extent) from here to there and make others engage the proper way. I will be submitting my issues there from now on.

Cheers,
M.

[sakis]

@mohpor

Hi,

We have an internal issue tracker but it's not exposed to the public. Public issues are available on GitHub, and they are updated (open/closed) as expected.

I agree that we should use GitHub more instead of the forum, especially for tagging and prioritising issues, but that's already happening (admittedly on a smaller scale than it should).

[mohpor]

@daniel

Hi,

just like @crankshaft, I have expressed my concerns on the state of things on firmware side before (hardware specs vs price is phenomenal, no doubt about it). A few weeks has passed and I regret expressing them the way I wrote them, in my defense, I was really frustrated by the fact that I couldn't do anything in the meantime, now, the firmware is getting closer to finish (very very far away at the moment, but big steps every week).
The reason I'm writing here again is that, as a veteran Software Developer, I can see the reason behind these frustrations: Issue Tracking, or the lack thereof. This forum is a great tool to discuss things, but when it comes to tracking or submitting an issue, it is not the right tool. If you provide a proper Issue Tracking service, be that your Github repo's Issues section or something as comprehensive as Jira, we would have a better understanding of what's missing, what is working, the progress, the plan ahead and many many more advantages that I'm sure you are aware of.
To see how important it is to provide a better Issue Tracking tool just read every Firmware update Announcement's comments! It's like a lot of issues being submitted to the post! This is not right @daniel.

Good news on Memory would make my week! I'm running into memory related issues left and right and I'm just hoping to optimize my code to get where I'm heading.

More power to you all,
Cheers,
M.

[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

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

[jasonriedy]

@jasonriedy Excuse me, connections and not GATTs.

[jasonriedy]

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

[daniel]

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

Cheers,
Daniel

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

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

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

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!

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

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

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

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

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

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

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

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