New firmware release 1.0.0.b1

[daniel]

@pwest

Will we get the ability to read BLE beacon advertisements w/that rev?

Yes, you will be able to read the data from the advertisements.

[daniel]

@brotherdust @RSK thanks for the feedback. We will release the source code to github over the weekend.

[daniel]

@jasonriedy right now the scan function only provides a list of the devices advertising in the neighborhood, so it makes sense to see only one entry in your tests. The next step (and it's what we will release soon) is to subscribe to a given device and get each of the advertisements messages that it sends.

Cheers,
Daniel

[daniel]

@jasonriedy and @jmarcelino I think you both have very good ideas around what the BLE API should look like. I'd love to hear your suggestions around that. We have also been looking and bluepy for inspiration.

Cheers,
Daniel

[DVE]

Reinstalling the installer app every time is a bit annoying. Is it possible to have a direct link to a firmware file on the web site? Or at least please make OTA-version, that does not require install.

PS: I've updated the last firmware, machine.freq() is 160MHz now instead of 80. Magic :)

[jasonriedy]

@daniel Ah, but the Pi3 sees many devices advertising in the neighborhood.

[jasonriedy]

@daniel They're hive sensors from Broodminder. The sensor pipes up every few seconds, but we likely only need the measurements every 10-15 minutes. Assuming that dropping to low power / standby during that time can be made to work... Otherwise might just gather all the data but only send it every longish time. The actual processing is minimal. We just need to re-arrange the bytes into a packet to send of to TTN.

[mohpor]

@daniel
I suggest you take a look at CurieBLE's API as well (https://www.arduino.cc/en/Reference/CurieBLE). It's related to Intel's IoT enabled MCU you can find on Arduino/Genuino 101.
I have used it for a BLE project and it did the job quite beautifully.

[brotherdust]

@jasonriedy
I've been keeping an eye on the implementation status of the ULP coprocesssor functions in the upstream espressif-idf repository. Espressif has been making progress on it, but it doesn't seem like it's ready yet. Pycom did mention they updated their downstream idf repo, which means the ULP functions are present in C; but I didn't see any mention of ULP functions for MicroPython yet. Likely we will see it in them in the near future.

For those interested, I'd strongly suggest occasionally reviewing the commit log on the upstream espressif-idf. It's pretty fun to watch!

https://github.com/espressif/esp-idf/commits/master

[jmarcelino]

@daniel
The cb (CoreBluetooth) module in Pythonista could give some inspiration as well

http://omz-software.com/pythonista/docs/ios/cb.html

[brotherdust]

One thought that occurs to me: what are other MP boards doing for BT (the BBC:micro comes to mind)? Isn't it more pythonic to not reinvent the wheel?

[jmarcelino]

@brotherdust said in New firmware release 1.0.0.b1:

One thought that occurs to me: what are other MP boards doing for BT (the BBC:micro comes to mind)? Isn't it more pythonic to not reinvent the wheel?

The particular Nordic part used in the micro:bit didn't have enough RAM (16K) to run both MicroPython and the BLE stack so they never implemented it.

They only support wired (!) networking and a simple proprietary radio protocol from Nordic.

So here we have a chance to be true pioneers.

[pipomolo]

@daniel Hi Daniel, i have just tried to upgrade my 3 LoPy recently received, with the latest firmware here, and after installing the PyMaker (which works with the actual version of the LoPy) and then trying with the PyCom firmware Updade software, on an iMac, connected with USB cable (and selecting the /dev/cu.Bluetooth-Incoming-Port for Serial), i face the sameproblem. Failed.
It seems there is an issue with the serial / USB driver ?
I have tried with a MacBookPro also, and i face the same issue.
I use the same interface and cable to program my Arduino without issues.
i have tried also to change the speed (9600, 19200) in the .py file related, but no luck.

thanks for pointing me to a relevant doc or tool.

[mohpor]

@pipomolo I have faced the same issue last week. My problem was related to installed FTDI drivers. Have you tried to install FTDI drivers on your mac? if so, you need to remove one of them and leave just one acting driver live.

You can find more info on related FTDI driver's page info: http://www.ftdichip.com/Drivers/D2XX.htm

[mohpor]

@daniel
In this release note you have mentioned WiFi and BLE Coexistence, I have tried a very simple REPL script to check if that's true and I'm sorry to say I have found it's not!
I have tried importing BLE first like this:

from network import Bluetooth
ble = Bluetooth()
# Heartbeat LED turns constant blue.
ble.scan()
# outputs a few bluetooth devices in 10 secs
from network import WLAN
wifi = WLAN(mode = WLAN.STA)
wifi.scan()
# REPL won't give back the control and it never finishes the task

This is a little different if the order was reversed:

from network import WLAN
wifi = WLAN(mode = WLAN.STA)
wifi.scan()
# Outputs list of WiFi devices very fast
from network import Bluetooth
ble = Bluetooth()
ble.scan()
# Outputs a list of BLE devices in 10 seconds.
wifi.scan()
# Won't return the control in ever.

So, in essence, yeah, there is no co existence, even for the simple scan functionality! This means if Bluetooth is imported, WLAN won't work. I have tested the Scan functionality for both but that's bad enough for my scenario.
Any comments?

Update:

It seems vital to mention that from the looks of it, instantiating Bluetooth overwrites memory like this:

from network import Bluetooh()
ble = 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: ..:..:..:..:..:..

is that a right assessment?

[robert-hh]

Hello Daniel, this is a big improvement. Would you mind to update the github repository, such that I can enable support of .mpy files?
Robert

[bmarkus]

With each firmware update we get less and less free RAM. Now it is only 51k. During KickStarter campaign I got the impression to get much more free RAM. Seems that new features eat up memory. Does it mean that at the end of the road with working LoRa stack, BT and so on there will be no RAM available, or RAM availablity limits the introduction of new or missing features? Hope it is not the case.

Would appreciate an explanation how RAM is used by the system.

[jmarcelino]

@bmarkus
This is a common question with the ESP32 - see the long discussion at http://esp32.com/viewtopic.php?f=2&t=44&start=10

ESP32 specs list RAM as one big block (400KB! 540KB!) however that's not really all available to applications - at least not in a simple way.

The ESP-IDF (the "core" SDK of the ESP32) is also not currently optimised for memory. From that thread the "official answer" is:

We indeed will be working on minimizing esp-idf RAM usage at a certain ? point in time; for now, we think it's more important to get all features in first.

Once the ESP-IDF reaches feature stability and they start look into memory improvements I'd expect those savings will translate into *Py environment as well

[jasonriedy]

@robert-hh @daniel If we end using LoPy for a project / class, it'd be great to have students build the whole thing, even if just once. Many had never installed an OS before working with a Pi.

[daniel]

@mohpor

Hi Mophor, we'll check this issue immediately and if there's a problem when performing a WiFi scan after a BLE scan then we'll fix it. Coexistence is happening for sure, you can check it by enabling BLE and doing the scan from telnet when being connected to the LoPy in AP mode.

The memory being overwritten is OK, that portion of memory is already reserved for BLE usage.

Cheers,
Daniel