New firmware release v1.17.0.b1 (Completely new LTE class)

[daniel]

Hello,

The highlight is that the LTE class has been completely re-written, the functionality is complete and it also allows to send AT commands directly to the cellular radio. The API has changed a bit, so make sure to check the docs here: https://docs.pycom.io/chapter/firmwareapi/pycom/network/lte/cat-m1.html

Here's the complete change log:

• esp32: New LTE class with comprehensive methods and an option to send AT commands directly. Fix high power consumption issues on the FiPy, GPy and G01 when entering deepsleep.

• esp32: Fix power output problems for the FiPy and LoPy4 on Sigfox.

• esp32: Correct LoRaWAN version number to 1.0.2.

• esp32: Fix antenna selection API for the second generation modules.

  Also add antenna selection option for Bluetooth. See: https://docs.pycom.io/chapter/firmwareapi/pycom/network/bluetooth/#bluetoothinitid0-modebluetoothble-antennanone

• esp32: Fix LoRaWAN ADR behaviour. Enhance lora.stats(). See: https://docs.pycom.io/chapter/firmwareapi/pycom/network/lora.html#lorastats

• esp32: Fix Sigfox lock-up on the SiPy.

• esp32: Erase LoRA NVS area if the LoRaWAN region is different than before.

• esp32: Adding RMT class to machine module

• esp32: Raise specific exception if region in config block is 0xff.

• esp32: Do not return a default region if value in flash is not set (0xff)

• esp32: Take the LoRa region from the config block if not specified.

IMPORTANT: This release requires a a mandatory upgrade of the updater tool.

Cheers,
Daniel

[colinza]

@robert-hh Okay yeah that is a fair point, there is a known bug in this ones firmware with sending RST signals or something. I'll throw it in the bin and try a different one with a FTDI chip.

[robert-hh]

@colinza According to the schematics, the ATMEGA always runs at USBVcc = 5V, which means, it's output levels are 5V. Only the Vcc output pin is affceted by the jumper.
And no, Pycom does not require to use it's board. I'm uses different USB/Serial adapters with a dedicated USB/serial chip for that purpose without any problem. Just adapters based on a CH340G chip do not go up to 921600 Baud. So it still seems like the Atmega software in your adapter is faulty. Maybe one can fix that, but it may not be worth the effort.

[colinza]

@robert-hh The one I have has a jumper for 3.3V which I use. Also as I said it does work completely fine, and I've updated modules with it in the past perfectly, it's only that the new update software seems a bit "too user friendly" by not letting you change the baud rates or know what it's trying to do. As I say, this just seems very short sighted. I don't see why Pycom should require their own special programmer boards to get things done, the AT8U2 adaptors are ubiquitous and TTL serial should respect the standards (or just put a USB connector on the board already like the NodeMCU does...)

[robert-hh]

@colinza It seems that the adapter is the problem. And using it seems strange also for another reason: the Atmega runs at 5V with 5V signal levels. That is beyond the recommended input levels of the ESP32. There is a serial resistor which limits the input current, but still it is out of spec.
Better use an adapter with USB/Serial chip made for purpose, which also can provide 3.3V output levels.

[colinza]

@xykon I'm using a pretty standard Atmega 8u2 based adaptor from DFRobot. The default baudrate the wipy and lopy4 comes up in in programming mode is 115200 and it can connect fine like that, and the old update tool worked fine when I forced it to use that instead of 57600. For whatever reason the baudrate switching has never worked for me, probably it only works on the Pycom programmer boards.

[Xykon]

@colinza said in New firmware release v1.17.0.b1 (Completely new LTE class):

In a previous post I pointed out a simple fix to the Pycom firmware updater to correctly set the serial baud rate to what YOU PYCOM set it to when you ship the module.

With this new updater it's compiled so I can't change it, and the bug is still there.

Why don't you listen?

The firmware updater always connects with an initial baud rate of 115200bps (and this does not depend on the firmware as the esp32 is running the ROM bootloader) and then instructs the esp32 to switch to the baudrate as chosen in the GUI firmware updater: 921600bps when high-speed transfer is selected (which is the default) and otherwise 57600 bps.

It would be extremely odd if your USB / TTL adapter works at 115200 bps but not at 57600 bps (maybe you can provide some more details about your OS and the adapter so I can check if I can replicate this?)

I've actually been planning to increase the "slow" baud rate from 57600 to 115200 as pretty much all computers these days should be able to handle the upload at 115200 bps. You should see a beta announcement for a new firmware updater in the next few days.

[colinza]

In a previous post I pointed out a simple fix to the Pycom firmware updater to correctly set the serial baud rate to what YOU PYCOM set it to when you ship the module.

With this new updater it's compiled so I can't change it, and the bug is still there.

Why don't you listen?

[Colateral]

@livius ahhh.. thanks :)

[livius]

@colateral said in New firmware release v1.17.0.b1 (Completely new LTE class):

RTC_DATA_ATTR

only from source code and custom firmware
not available in python
you can find details here:
https://github.com/pycom/pycom-esp-idf/blob/master/components/esp32/include/esp_attr.h

[Colateral]

@liviue I can not find this RTC_DATA_ATTR in documentation. Can you post an example?

[daniel]

@livius yes, this is part of the roadmap. Expect it in a few weeks.

[livius]

@daniel
Is there possibility to store variables in rtc memory from python code?
This memory survive deep sleep.
This is already avaiable by RTC_DATA_ATTR to declare variable stored in RTC memory.

[bali]

@daniel

Just updated Gpy to new firmware but as soon as i call the LTE class it crashes. Any idea why?

import os
os.uname()
(sysname='GPy', nodename='GPy', release='1.17.0.b1', version='v1.8.6-849-d0dc708 on 2018-02-27', machine='GPy with ESP32')

from network import LTE
lte=LTE()
/Users/danicampora/Code/Espressif/IDF/esp-idf-20180112/components/freertos/./queue.c:718 (xQueueGenericSend)- assert failed!
abort() was called at PC 0x40089fb8 on core 1

[nathanh]

@IOAg @danielm just an update I got my FiPy working on Telstra with your latest firmware. Details posted here: https://forum.pycom.io/topic/2769/telstra-lte-cat-m-working-on-fipy-just

[danielm]

@Xykon
I sent a mail to support@pycom.io as you suggested in this post:
https://forum.pycom.io/topic/2734/new-firmware-release-v1-17-0-b1-completely-new-lte-class/8

[livius]

@daniel
Is there some progress about point 3 from this post? :)
https://forum.pycom.io/post/15420

Encryption: Complete flash encryption will be supported with an AES-256 key stored in the fuse bits of the ESP32. Reading this key from outside of the ESP32 is not possible. In addition, we will add secure boot which writes protect the bootloader area. Both measures will make the firmware flashed to our modules fully secure. Expect this update before end Feb.

[incognico]

@seb said in New firmware release v1.17.0.b1 (Completely new LTE class):

@losi
The links at the top of this page should always point to the latest version:
https://docs.pycom.io/chapter/gettingstarted/installation/firmwaretool.html

What links at the top of this page? Maybe I need some more coffee this morning but I couldn't see a link to this new tool "at the top of this page". A search of the page source doesn't find a link to firmwaretool.html until your post. Even if it is there and I'm being foolish, perhaps a more obvious link to the tool when announcing it would be helpful...?

[nathanh]

@ioag said in New firmware release v1.17.0.b1 (Completely new LTE class):

@daniel no mention of fipy LTE issue with Telstra in Australia. Any chance release includes a fix?

So I still cannot connect to Telstra. However, it is nice to have AT command access which has given some more control and feedback.

From my testing I will setup the APN with the following prior to trying to attach.

AT+CGDCONT=1,"IP","telstra.m2m"

If I then try and check the status with AT+CEREG? I get the result +CEREG:2,0 as you would expect.

When I then try to attach I get the following:

lte.attach()
lte.send_at_cmd('AT+CEREG?')
\r\n+CEREG:2,4\r\n\r\nOK\r\n

So the result of 2,4 is an unknown response (and according to doco, one possible reason can be no coverage). However, according to Telstra's coverage map I am under full coverage. I can confirm on my phone I do get Telstra 4G but whether on not the phone is using band 28 like the device should be, I am unable to determine.

Anyway, still disappointing that a product being sold here and was meant to be certified according to Pycom's website last year (https://pycom.io/state-lte-m/) is still not working. Especially since everything else Pycom has been awesome to work with. At this stage I might start looking at going back to working with the ESP32 direct with a Telit modem.

[IOAg]

@daniel no mention of fipy LTE issue with Telstra in Australia. Any chance release includes a fix?