search

u-blox / ubxlib

Portable C libraries which provide APIs to build applications with u-blox products and services. Delivered as add-on to existing microcontroller and RTOS SDKs.
Apache License 2.0
287 stars 82 forks source link

ESP32 Demo #253

Open monkeytronics opened 2 weeks ago

monkeytronics commented 2 weeks ago

Hi guys,

Background I have a custom board with ESP32 and SARA-R422S and I'm trying to bring it to life. I'm working from the mqtt_client example. My goal is to communicate to thingstream over MQTT_SN. We are building a new product here. There isn't a lot to say about the hardware. It has a ThingStream SIM card in place and it has previously been able to connect and send messages using M-Center (?). So, I believe it's sound in terms of the hardware.

Progress The ESP32 application is building and running OK. uDeviceOpen( ) succeeds. But it is unable to complete uNetworkInterfaceUp( ).

Questions

  1. I have tried setting 1) .pApn = NULL and 2) .pApn = "tsiot". Neither case succeeds, but the behaviour is significantly different in each of these cases. I've attached the system logs for each of these cases. Hopefully, they will shed some light on what's missing?! I'm not up to speed with the AT level operation of this system, I confess.

mqtt-connect-pApn-NULL.txt mqtt-connect-pApn-tsiot.txt

  1. Reading around the repo, I noticed in the esp-idf/README.md, there are some instructions to include PPP Level Integration. I am uncertain whether that is a requirement or not. But I bring it up as the sdk config options required are not present in the menuconfig - possibly because I haven't defined U_CFG_PPP_ENABLE. So, just checking - I'm fine here - I don't need to worry?

There may be a few steps I'm missing, and gaps in my knowledge (apologies). But maybe by getting my application running, we might identify areas of the docs which could be expanded to accomodate less expert devs (dum-dums) like myself!

RobMeades commented 2 weeks ago

Hi there, and sorry you're having trouble with this. There are, of course, no dum-dum questions, just ill-documented code :-).

Looking at your logs I think you may have a HW issue. From your "tsiot" log (and yes, specifying tsiot as the APN is a requirement for a module connected with a Thingstream SIM to successfully register with the network):

image

At about the time the module is powering-up its transmitter to register with the cellular network, you will see the "null" byte (highlighted in red above) being emitted by the module on the AT interface and, after that, the AT commands sent to the module by ubxlib are all echoed immediately back by the module. The very first thing ubxlib does is switch off echo of AT commands from the module (AT echo is fine when a human is typing but is actively unnecessary and annoying for a machine talking to an AT interface); you'll see ATE0 is one of the first commands in the log.

If AT command echo has magically come back on again, that can only be because the module has rebooted, and the moment it rebooted was the moment the [00] appeared in the log, roughly the time the module would be transmitting to access the network.

Peak transmit power requirements for a cellular module are high, and have a sharp rise time: we're talking something like half an amp immediately. Section 1.5.1 of the SARA-R422 System Integration manual is the place to look for more details.

Why this doesn't happen with M-Center I couldn't say, but it is definitely happening.

Interestingly, your "NULL" log shows the same problem, this time likely not associated with transmission to the cellular network, which shouldn't be happening about then, and the mysterious text "power up", which is not something printed out by ubxlib, appears at about the same time:

image

And I've just noticed the same text appears in the previous log. Did you set "power up" as a greeting message (see uCellCfgSetGreeting(), or you might have done this directly when working via M-Center) to be emitted by the module maybe? If so that backs up the theory that you have a HW issue, if not it might be a clue as to something else that's involved?

there are some instructions to include PPP Level Integration

Not a requirement, this is entirely up to you, it will depend whether you want to use the native IP stack and clients in the ESP-IDF world or not. If you're going to communicate with Thingstream over MQTT-SN then I guess you would not need to use the IP stack/clients of the ESP-IDF world.

monkeytronics commented 2 weeks ago

Aha!

Yes, I do vaguely remember having to address an issue when working on M Centre. From memory: I think it was a timeout (?) causing the module to reboot? So we put the power up log in to catch that... It's not in the ESP32 firmware, so must have put it into the SARA module somehow... But no memory how we did that! I was working on that months back - it's taken quite a while to get the hardware up and running. Does that make any sense?

I was following the SODAQ guide (for R412) and programming the SARA module up with a 'pass through' application. Part of my issue is that I've been thinking of the SARA module as hardware - when it's actually a full embedded system in it's own right. So, it seems that there is probably a huge step I've glossed over - in how that system is brought up, configured and necessarily, a stage where I explicitly double check that every setting by reading back so we know exactly what state the system is in before blindly starting to shove commands and messages into it!

Is there a mechanism within ubxlib where we could poll any and every possible config register in the SARA R422S module to make it reveal all of it's secrets? And then correct any incorrect settings?

And lastly, is the SARA R422S designed to be operated as a peripheral? In which case, I assume there must be a prescribed firmware that it should come preprogrammed with? In a production flow, how does that normally work I wonder?

RobMeades commented 2 weeks ago

It's not in the ESP32 firmware, so must have put it into the SARA module somehow...

Probably best you take a moment to do a factory reset on the SARA-R4: either call uCellCfgFactoryReset(devHandle. 0, 0) followed by uCellPwrReboot(devHandle, NULL), or do it through M-Center if you prefer.

I've been thinking of the SARA module as hardware - when it's actually a full embedded system in it's own right

Yes: SARA-R4 likely has far more RAM/flash/processors and lines of code in it then the embedded MCU that is driving it.

where I explicitly double check that every setting by reading back so we know exactly what state the system is in

No need for that, ubxlib assumes no previous settings in the module, it is designed to work with a "fresh" module and, at least for the purpose of ubxlib, it stores nothing whatsoever in the NVRAM of the module. Only things that you chose to store, like a greeting message, ever get stored in the module.

Is there a mechanism within ubxlib where we could poll any and every possible config register in the SARA R422S

No, SARA-R422 is far more complex than that. Every ubxlib API that can perform a set has a get so you can always read anything that you set back again.

And lastly, is the SARA R422S designed to be operated as a peripheral? In which case, I assume there must be a prescribed firmware that it should come preprogrammed with? In a production flow, how does that normally work I wonder?

Yes, that is what it is, a peripheral, it only does what you tell it to do. All our modules are preprogrammed with FW certified by the operators to work on their cellular network. You would not normally change it but there may be occasional (every year or so) maintenance updates which can be found on our website.