New Stable Firmware Release v1.18.2

[rcolistete]

Useful info, the firmware v1.18.2 is available for manual download :
https://github.com/pycom/pycom-micropython-sigfox/releases

[Steve Williams]

@rcolistete I'll give this a go, but where can I get a copy of 1.18.1.r7 from just in case my projects' code doesn't want to play with the new version? Just naturally cautious.. :-) Are all the changes documented?

[combaindeft]

@steve-williams said in New Stable Firmware Release v1.18.2:

@rcolistete I'll give this a go, but where can I get a copy of 1.18.1.r7 from just in case my projects' code doesn't want to play with the new version? Just naturally cautious.. :-) Are all the changes documented?

https://docs.pycom.io/advance/downgrade.html

[combaindeft]

@iwahdan said in New Stable Firmware Release v1.18.2:

Added API to Get/set DNS servers.

How do you do this?

[Steve Williams]

@combaindeft Thanks.. not always easy for a newbie to find all the info.. :-)

[johanbrichau]

@combaindeft I had the same question... so I dug up the code changes and figured it out:

usocket.dnsserver(0,'8.8.8.8')
usocket.dnsserver(1,'4.4.4.4')
usocket.dnsserver()
('8.8.8.8', '4.4.4.4')

This is especially useful on NB-IoT networks as it seems the DNS server config is not given by the mobile network. This is really cool. I can remove the hacks to deal with DNS querying in my code.

(source: https://github.com/pycom/pycom-micropython-sigfox/commit/c7efa88baaf8d5cba1a985e737789590b75f5d2f#diff-5f8707a5f826155a6bac3647155b8173)

[combaindeft]

@johanbrichau said in New Stable Firmware Release v1.18.2:

This is especially useful on NB-IoT networks as it seems the DNS server config is not given by the mobile network.

Yes! it is! 😇

And Yeah, The Teleoperators didn't design it with DNS-support in mind .... put they left it "Open" ... and put all of the task on the platform supplier ... to implement a function like this ... to define our own DNS-server.

I will test it out on our Operators network, see if we finally can resolve domain names 🙃

[combaindeft]

@johanbrichau

And yes! ... one now hasz DNSz'y via LTE-NB1 (NB-IOT) 👍🏻

[Martinnn]

Is the documentation already updated? I'm interested in MQTT and Wifi particularly.

[Paul Thornton]

@martinnn No not yet. MQTT docs likely wont see much change. changes are bugfix not a change to functionality as far as I am aware. Will confirm re Wifi.

[Martinnn]

@paul-thornton I saw that the wifi RSSI readout (I am interested in) works on rc 1.20 only, not 1.18. Any comments on when to use rc 1.12 vs. stable 1.18? If you need the new features, try rc, else stick with stable? Although few changes seem to affect the wipy.

[Paul Thornton]

@martinnn said in New Stable Firmware Release v1.18.2:

@paul-thornton I saw that the wifi RSSI readout (I am interested in) works on rc 1.20 only, not 1.18. Any comments on when to use rc 1.12 vs. stable 1.18? If you need the new features, try rc, else stick with stable? Although few changes seem to affect the wipy.

You have the correct idea. If you absolutely need features only available in the RC builds then feel free to give them ago. We still offer as much support as we can but there may be bugs/crashes.

If you dont. Stick to the stable builds. they should have most of the bugs ironed out.

[mfallavol]

I'm getting somewhat regular crashes with this firmware. The crash begins with:

assertion "netconn_alloc: undefined netconn_type" failed: file "/Users/iwahdan/e
sp/pycom-esp-idf/components/lwip/api/api_msg.c", line 696, function: netconn_alloc
abort() was called at PC 0x401450b7 on core 1

I've seen it a few times already today.

[Paul Thornton]

@mfallavol said in New Stable Firmware Release v1.18.2:

I'm getting somewhat regular crashes with this firmware. The crash begins with:

assertion "netconn_alloc: undefined netconn_type" failed: file "/Users/iwahdan/e
sp/pycom-esp-idf/components/lwip/api/api_msg.c", line 696, function: netconn_alloc
abort() was called at PC 0x401450b7 on core 1

I've seen it a few times already today.

Hello @mfallavol, Thanks for the report. Any idea what the board happened to be doing at the time?

[mfallavol]

@paul-thornton
Sorry Paul, I never saw your reply until today. Unfortunately our load is pretty complicated; we have one thread for each I2C bus we configure (1 or 2 depending on the system) and two threads doing socket communication (one for outgoing and one watching for incoming). We're keeping track of resets and will monitor the systems. If it doesn't improve with later firmware releases then I'll have to look at debugging the crash. Do you have instructions on how to go about that?

-- Mike