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

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

[dbrgn]

@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?

[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