New firmware release version v1.7.9.b3 (LoRaWAN ABP bug fixed)

[daniel]

Hello,

A new firmware release is out. The version is v1.7.9.b3. Here's the change log:

• esp32: Add function to Bluetooth class to get a list of all received advertisements.

• esp32: Use active mode for BLE scans.

• esp32: Increase the size of the LoRa data queue from 2 to 3.

• esp32: Add WiFi on boot API.

• esp32: Add recvfrom method to LoRa sockets returning: (data, port).

• esp32: Fix bug on LoRaWAN battery level reporting. Thanks for @bmarkus for the detailed bug report!

• esp32: Fix bug with SNR value reported by lora.stats() being incorrect. Thanks to @bmarkus for the detailed bug report!

• esp32: Fix bug that prevent reception of LoRaWAN packets sent to port 3-223. Thanks to @bmarkus for the detailed bug report!

• esp32: Allow to specify the initial DR for the LoRaWAN join request.

• esp32: Use the us since epoch as part of the initial seed for the random number generator.

• esp32: Allow to include more than 1 service in the BLE advertisement.

• esp32: Improve LoRaWAN NVS handling.

• esp32: Revert change in os.stat() that would report the time as a long int.

In order to get the new firmware it, please user the updater tool that can be downloaded from here: https://www.pycom.io/downloads/

Cheers,
Daniel

[jmarcelino]

@daniel
Why the change to active BLE scans? I'm not sure this will improve scans for users with many BLE devices.

I'll have a look at what is being used to retrieve a list of all advertisers as I have another method of getting them.

By the way there seems to be some problem with LoRaWAN on this version: https://forum.pycom.io/topic/1647/lorawan-apb-not-working-anymore-with-new-firmware/

[daniel]

@jmarcelino thanks for pointing me to the ABP issue.
We have seen in our tests that using passive scans sometimes fails to detect some BLE devices. Espressif uses active scans in their examples too.
Let me know what other method you have for retrieving the list of advertisers :-)

[daniel]

Just released 1.7.9.b3 which solves the ABP issue. Apologies for this bug, we'll investigate why it was not picked up by our automatic tests.

[littlebat]

@daniel

"The difference between active and passive scan is that active scans requests a SCAN_RESPONSE packet from the advertiser. This is done by sending a SCAN_REQUEST packet after an advertisements has been detected."

So I'm not sure how active scanning could affect the number of devices seen. It is more likely that the missing devices was due to the BT RX losing bug recently fixed in esp-idf.

[chumelnicu]

@daniel Hi Daniel , could you tell me if in this moment APB bug is solved , or i should waiting for *.b3 firmware version?

Thx!

[chumelnicu]

@daniel Is still *.b2

[daniel]

@chumelnicu what do you mean? are you using the updater and still getting 1.7.9.b2 as the latest version? I have just tried with all the modules and they all get updated to 1.7.9.b3. Could you please clarify? Thanks...

[chumelnicu]

@chumelnicu I talking about what is posted here "New firmware release version v1.7.9.b2" . I did not try yet to upgrade , that is the reason for i have asking 3 hours ago id APB bug is fixed.

Thank you for info and ill try to update the new firmware !!!

[bmarkus]

recvfrom() returns a strange port number when no data received:

Otherwise it is OK, correct port number returned when data received. 0 or -1 would be better, but it is cosmetic, doesn't influence usability of the method.

[daniel]

@bmarkus thanks. This should fix it:

https://github.com/pycom/pycom-micropython-sigfox/commit/87df833936741675caa96e7ffcb8ba846e2ab4b9

[dbrgn]

Nice update!

@daniel said in New firmware release version v1.7.9.b3 (LoRaWAN ABP bug fixed):

esp32: Add recvfrom method to LoRa sockets returning: (data, port).

Is it still possible to receive downlinks on any socket, no matter which port it's bound to? If yes, is it planned to change that in the future?

esp32: Add WiFi on boot API.

That sounds interesting. Where can I find more information about that?

esp32: Improve LoRaWAN NVS handling.

Does that entail any user-facing change?

[jmarcelino]

@dbrgn said in New firmware release version v1.7.9.b3 (LoRaWAN ABP bug fixed):

Is it still possible to receive downlinks on any socket, no matter which port it's bound to?

socket.bind() - perhaps confusingly - sets the uplink port (i.e. port set in packets you send)

There is no method to bind the socket to a downlink port, I guess you should filter out based on the port returned from recvfrom

esp32: Add WiFi on boot API.

See pycom.wifi_on_boot([enable])

I would like to know if when wifi_on_boot is disabled does the module still run the power hungry RF calibration step (causing those current spikes at boot). I will test this over the weekend.

[bmarkus]

Tested following LoRaWAN fixes:

• snr in lora.stats()
• downlink to port 2-223
• reporting MAC Battery Level
• recvfrom()

These work fine, thank you Daniel and team.

[daniel]

@bmarkus excellent, thanks for the feedback :-)

[redimo]

How does one get that List returned? And whats the format on it?

[livius]

@redimo
about what list are you talking about?

[daniel]

@redimo do you mean bluetooth.get_advertisements() (https://docs.pycom.io/chapter/firmwareapi/pycom/network/bluetooth/)?

The elements in the list has the same format as the named tuple returned by bluetooth.get_adv()

[ozeta]

@daniel said in New firmware release version v1.7.9.b3 (LoRaWAN ABP bug fixed):

esp32: Add WiFi on boot API.

can you explain this?

[daniel]

@ozeta have a look here: https://docs.pycom.io/chapter/firmwareapi/pycom/pycom.html it allows to disable/enable the behaviour that configures the WLAN in Access Point mode right after boot. This reduces the boot time and current consumption when WiFi is not needed.