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

[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