New firmware release version v1.7.9.b3 (LoRaWAN ABP bug fixed)
-
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
-
-
@dbrgn WiFi can always be enabled afterwards. The wifi on boot API only affects the behaviour during start up. If you call that specific sequence nothing will happen (calling WLAN() without params just returns the object).
Cheers,
Daniel
-
@daniel What happens if you call
wlan = WLAN(); wlan.deinit()when wifi on boot is disabled? Nothing, right? Or does the constructor call allocate / initialize some resources again?
-
@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.
-
@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?
-
@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()
-
@redimo
about what list are you talking about?
-
How does one get that List returned? And whats the format on it?
-
@bmarkus excellent, thanks for the feedback :-)
-
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.
-
@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.
-
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?
-
@bmarkus thanks. This should fix it:
https://github.com/pycom/pycom-micropython-sigfox/commit/87df833936741675caa96e7ffcb8ba846e2ab4b9
-
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.
-
@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 !!!
-
@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...
-
@daniel Is still *.b2
-
@daniel Hi Daniel , could you tell me if in this moment APB bug is solved , or i should waiting for *.b3 firmware version?
Thx!
-
"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.
-
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.
