New Firmware Release Candidate v1.20.0

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

[robert-hh]

@iwahdan The Exposed Keyboard Interrupts Control to Micropython does not work. Reason:
The API changes the persistent flags, but the code in machuart.c and telnet.c looks at the non-persistent flags. IMHO, these non-persistent flags are not required, because it is a user script which modifies the flags and can set it back. At the REPL loop in pyexec.c, these flags are anyhow reset to the default state, once REPL gets control again. So better use the mechanism of the initial PR.

[iwahdan]

Hello @robert-hh, sorry I misunderstood your initial PR, somehow I thought there was a need to control keyboard interrupts in normal REPL, which why I had to do these modifications for it to work.
I agree with you, your PR is then sufficient and no further modifications needed, will correct this shortly

[EinarJ]

@iwahdan Why is PSM and eDRX not used when running deinit(dettach=False)?

[danielm]

@einarj
I did not perform any tests with those features yet but I think you must set requested mode and related timers by AT commands, e.g.:

Power Saving Mode Setting:
+CPSMS=[<mode>[,<Requested_Periodic-RAU>[,<Requested_GPRSREADYtimer>[,<Requested_PeriodicTAU>[,<Requested_Active-Time>]]]]]

[EinarJ]

@danielm I've tried, but it doesn't seem to have any effect. I can see it's being disabled by default in the LTE init, so I've set the command manually after that. The PSM should,in theory, cause the LTE modem go into PSM mode right after the data is sent, but that doesn't seem to happen. Maybe it's becsuse the the flag for going into PSM is not being passes to the modem. But, PSM is useless if you don't cannot setup eDRX. The modem gives me an error if I try the setting specified in the AT-command specs. Do you know if the vendor has implemented these features into the FW?

[danielm]

@einarj
There are some eDRX-related commands as well:

• eDRX Read Dynamic Parameters: +CEDRXRDP
• eDRX Setting: +CEDRXS
• Specific eDRX Settings: +SQNEDRX

I have no idea if PSM/eDRX commands are implemented and working as expected because I did not test them yet.

@iwahdan @Paul-Thornton
In my opinion Pycom should provide statement regarding readiness of PSM/eDRX features implemented in the modem's firmware because without these features it is not possible to develop battery-powered solutions with reasonable long battery life-time which is the main purpose of NB-IoT.
There should also be tutorial available in the documentation because of importance of these features.

[Xykon]

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

@iwahdan @Paul-Thornton
In my opinion Pycom should provide statement regarding readiness of PSM/eDRX features implemented in the modem's firmware because without these features it is not possible to develop battery-powered solutions with reasonable long battery life-time which is the main purpose of NB-IoT.
There should also be tutorial available in the documentation because of importance of these features.

I will try to post more details about PSM/eDRX as soon as possible. Generally the standard 3GPP AT commands should be used using lte.send_at_command(). However in order to tell the modem to go into PSM/eDRX mode, lte.deinit(dettach=False) should be called. The wrong spelling of dettach aside, the modem checks the state of the flow control pins to see if it is OK to go into low power mode. The deinit command releases the flow control pins thus allowing the modem to go into the configured sleep mode.

In regards to the release candidate, after uploading v1.20.0.rc2 earlier today, which includes the latest Sequans firmware updater and Pybytes scripts, I have realised an error was made in pycom_config.h that causes the fs_type flag to be stored at an incorrect position. This is also the reason why the setting from the firmware updater is ignored. I have already uploaded a correction to the release-candidate branch as I had issues updating the perviously used v1.20.0.rc0 branch. I will upload a new version shortly but wanted to give people a heads-up to check the file system type in the firmware updater when updating. This should only affect people who used the commands I posted above to manually switch the fs_type with the pycom_bootmgr command.