New Firmware Release Candidate v1.20.0

[iwahdan]

@danielm ok, i’ll Run your code tomorrow on our NB-IoT emulator in the office to try to see where is the problem

[reidfo]

This code seems to be running okay on a FIPY, with the exception of rtc.ntp_sync(). As was noticed a while back in [this thread]](https://forum.pycom.io/topic/1414/i-swore-i-had-rtc-ntp_sync-working-on-my-lopy-and-now-i-can-t-get-it-working-at-all/2), after a soft reset (i.e. after uploading code from Pymakr) the RTC won't sync. I added a check for this and machine.reset() to my code, but it still won't sync after that. I have to physically hit the reset button on the FIPY before the clock will sync again.

[danielm]

@iwahdan
OK, are you able to simulate deteriorating radio conditions/packet loss? In my opinion it is necessary to perform tests in conditions which are close to limits of modulation/modem capabilities.

Some LTE-related questions:

1. Does current NB-IoT firmware for Sequans modem support all Coverage Extension modes?
2. If so, how exactly is the switch between EC0, EC1 and EC2 performed?
3. What are the EC mode switch thresholds for the Sequans modem? The algorithm should be based on RSRP value, or am I wrong?
4. Is it necessary to trigger re-attach from application code in case of EC mode change?

[danielm]

@reidfo
As an alternative to built-in NTP sync implementation you may use this simple code:

NTP_QUERY = bytearray(48)
NTP_QUERY[0] = 0x1b				
addr = socket.getaddrinfo(<NTP_SERVER>, 123)[0][-1]
s = socket.socket(socket.AF_INET, socket.SOCK_DGRAM)
s.settimeout(3) #optional
res = s.sendto(NTP_QUERY, addr)
msg = s.recv(48)
s.close()
val = struct.unpack("!I", msg[40:44])[0] - 2208988800 # 70 years difference between NTP and Pycom epoch
tm = time.localtime(val)
self.rtc.init(tm)

Don't forget to implement handling of socket exceptions.

[crumble]

@iwahdan

Why shall we wait for all the inits? Waiting seems not to be a reliable method for the pytrack. We need methods to check if a module is ready or wait for a init signal.

#main.py
[... a lot of includes of internal and *mpy modules ...]

_startup_ticks = utime.ticks_ms()

[... do some init stuff like WiFi and NTP ...]

_wait_init = 3000 - utime.ticks_diff(utime.ticks_ms(),  _startup_ticks)
if _wait_init > 0:
    print('waiting')
    utime.sleep_ms(_wait_init)
print(_wait_init)

#time.sleep(1)
py = Pytrack()
print('done init pytrack')

will fail somtimes if wait time is 2000ms. Even 3000ms is to short. Sometimes t fails like usualy with i2c errors, once it never returned from Pytrack()

I give now 4500ms a try. It will be hard to trust the settings.

[crumble]

How can I check the type of the file system.
I flashed the firmware under Win10 with update tool 1.15.2.b1

The last update of 1.19.0.b_ on a Lopy with LIttleFS setting showed me on boot up that LittleFS is used. Now it shows me FatFS.

I tried a second upgrade with reformat checkbox set and it is still showing:

Autoconnect: Found a PyCom board on USB
Autoconnect: Connecting on COM3...
Initializing filesystem as FatFS!

[reidfo]

@crumble While I don't know about the first issue, I have seen the second. For me, on MacOS, it seems like I saw the option for LittleFS in the updater (or maybe I'm imagining it) but now I don't. To get LittleFS I have compiled the firmware myself.

[panda]

@reidfo Same here for the Windows updater. LittleFS option is there, but it does not work.

That issue aside, Writing to files I now get an unexpected error at random times:

ASSERT_PARAM(2051 0), in llc_util.c at line 289

[panda]

Actually that error is not related to writing a file. I am not sure what is causing it. It does not appear to happen in direct response to any particular user scripts/code, but in safe mode it is not an issue.

[combaindeft]

@iwahdan

Hi,

I'm still having DNS Resolve issues with this release too

https://forum.pycom.io/topic/4055/nb-iot-in-hungary/3
https://forum.pycom.io/topic/4021/usocket-getaddrinfo-issues

[iwahdan]

Hello All ,

I've released a new version of Release candidate v1.20.0.rc1 having the following updates:

Improvments

• Exposed Keyboard Interrupts Control to Micropython

Bug Fixes

• Fixed DeepSleep high current Consumption when LTE is not Initialized
• Increased Delay before initialising RGB color to not Have RGB turn green at startup

Link to release on GitHub https://github.com/pycom/pycom-micropython-sigfox/releases/tag/v1.20.0.rc1

you can also download this Firmware via Firmware updater using development as firmware type.

[danielm]

@iwahdan
Did you test deep sleep current levels also on G01?

[iwahdan]

@danielm yes, with same results as GpY

[robert-hh]

@iwahdan Very good. Thanks. I will try it this evening.

[serafimsaudade]

@iwahdan
But when I try format to littleFS. It don't work.

[Paul Thornton]

@serafimsaudade HI. Can you give us any more details on the issue your having. do you get any error messages?

[Xykon]

@serafimsaudade said in New Firmware Release Candidate v1.20.0.rc0:

But when I try format to littleFS. It don't work.

Please try the following:

import pycom
pycom.bootmgr(fs_type=pycom.LittleFS, reset=True)

This will update the configuration to use LittleFS instead of FatFS. The board will reset automatically.

Similarly you can switch back to FatFS:

import pycom
pycom.bootmgr(fs_type=pycom.FAT, reset=True)

Note: When switching between LittleFS and FatFS, the flash file system will be re-formatted thus erasing all content.

[serafimsaudade]

@paul-thornton

When using the Pycom Upgrade software for linux. When I chose LittleFS, the pycom finish the upgrade and start with FatFs

[serafimsaudade]

@xykon

Tks, that works :)

[serafimsaudade]

Now I'm having another problem :/.
When I call rtc.ntp_sync(pool.ntp.org) func the rtc get the correct time and date but the rtc.synced() never return True.

Using the 1.19.0.b5 fw this problem disappear.