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
301 stars 90 forks source link

Testing lte-cfg example with ESP32 Feather and Sparkfun LTE shield #41

Closed Paryavi closed 1 year ago

Paryavi commented 2 years ago

Hi there,

In our prototyping with SARAR410 modules, we have very good progress in soldering these boards, but I am still having issues with the software. So going back to the basics, I am running your lte-cfg example on ESP-IDF 4.2, using ESP32 feather board connected to Sparkfun shield(as a break-out board for SARA R410M_02B-01) with a hologram Simcard. ESP32 is connected to SARA shield Serial port with four pins; GND, V_REF(3.3 from ESP32 reaches Sparkfun shield level shifter), and of course RX and TX pins.

The ESP-IDF prompt, for example 9 (lte-cfg) starts printing; U_CELL: initialising with enable power pin not connected, PWR_ON pin not connected and VInt pin not connected. AT ... And In the end, the errors I get in the prompt terminal are;

Added network with handle -7. This module does not support setting an MNO profile. unable to read bandmask! Bringing up the network... Unable to bring up the network! Done. D:/UBLOX/ubxlib/example/cell/lte_cfg/lte_cfg_main.c:455:exampleCellLteCfg:FAIL:Function [example]. Expression Evaluated To FALSE Test ran in 6645ms

I am not sure why it is not able to read bandmask or MNO profile is not supported on R410M_02B.

My simcard, hologram, is MNO agnostic but reading about MNO settings in AT command datasheet for the United States, I set the MNO to 2 or 5 for AT&T and TMobile respectively and APN to "phone" or "hologram" or a few other values mentioned for Tmobile in u_cell_apn_db.h like "fast.tmobile.com" , but I get the same error. Any suggestions?

Things I modify in ubxlib library files;

define MY_MNO_PROFILE 2 //i.e. AT&T, I tried 0 and 5 too define U_CFG_TEST_CELL_MODULE_TYPE U_CELL_MODULE_TYPE_SARA_R410M_02B ifdef U_CFG_TEST_CELL_MODULE_TYPE static const uNetworkConfigurationCell_t gConfigCell = {U_NETWORK_TYPE_CELL, U_CFG_TEST_CELL_MODULE_TYPE, NULL, / SIM pin / "phone", /* APN: NULL to accept default. 240,

define U_CFG_APP_CELL_UART 1 define U_CFG_APP_PIN_CELL_TXD 17 define U_CFG_APP_PIN_CELL_RXD 16

Btw, in the Hologram Dashboard website, sometimes it says the Simcard was connected so the late connection is probably related to MNO, RAT, and CATM1 settings... Also, my goal is to send camera photos with this board, so I need to set it to CAT_M1 instead of NB_IOT, right? I will try this @RobMeades comment that might accelerate the connection if it is delayed by NB_IOT; https://github.com/u-blox/ubxlib/issues/25#issuecomment-894184775

Thanks, Mohsen

RobMeades commented 2 years ago

Hi @Paryavi: from what you've pasted in above we haven't even got to any bi-directional AT interface activity yet, we should re-check the basics.

From what I can see you do not have the PWR_ON pin of the module connected to the ESP32; as far as I am aware SARA-R410M-02B can only be powered up by that pin being toggled for the correct time period by the ubxlib code so I don't believe the module is on...?

image

ubxlib knows all about the correct toggle time etc. for SARA-R4 modules, but for it to be able to power the module up that PWR_ON pin must be connected to the MCU, SARA-R410M-02B does not just power on when power is applied to the VCC pins (unless you're pressing a switch somewhere manually to toggle the PWR_ON pin by hand?).

The other thing is that you should make sure that the module's RTS line is grounded, otherwise it will float to "not-asserted" and the module will assume that the MCU's serial port is not ready to accept its data and it won't send anything back even when it does receive an AT command.

Paryavi commented 2 years ago

Aloha Rob,

Yes RTS is grounded in Sparkfun shield.

For Power_ON: At first, To have Open Drain, I was using a transistor on Sparkfun level shifter; https://www.sparkfun.com/products/12009 Connecting the Gate to MCU GPIO and its drain to Sparkfun shield power_On pin; and source to ground. I need to double-check and implement that again. In code, I need to have Power_ON from MCU as inverting in ESP IDF, so I guess I need to use flags for that, or define inverting flag in the lte-cfg example. https://github.com/u-blox/ubxlib/tree/master/port/platform/esp-idf/mcu/esp32/runner Yes, sometimes I was pushing the Sparkfun Power-On button manually and it was booting up but no bi-directional AT activity yet.

It was a mystery to me how they turn the module on without connecting the Power_ON signal to Arduino in their design, now I see they sneakily(in PCB eagle file) connected the Power_ON signal from Power_ON hardware switch to Arduino D5, D6; https://cdn.sparkfun.com/assets/a/c/b/1/0/lte_cat_m1_shield_sara-r4_schematic.pdf https://github.com/sparkfun/SparkFun_LTE_Shield_Arduino_Library/blob/master/examples/00_Register_Operator/00_Register_Operator.ino

Thanks

RobMeades commented 2 years ago

Thanks for confirming that RTS is grounded. With your Saleae probe what you could now do is have it connected to PWR_ON and VINT (closest to the module), plus the TXD and RXD lines (probably closest to the module again) then capture a trace of, say 15 seconds around the time of powering on and we should be able to see what's going on.

Paryavi commented 2 years ago

Sure, will do.

I have a question, Looking at the Sparkfun LTE shield schematic, as I said they directly connected Arduino pin D5 to module PWR_ON pin, so it looks like I do not need an Open-Drain-transistor between an ESP MCU pin and the module PWR_ON pin, right? As PWR_ON pin has 200 KOhm pull-up resistor. So can I directly connect an ESP32 feather GPIO pin(which ranges from 0 to 3.3 Volts) to the SaRA module Power_ON pin? Normally without connecting anything to PWR_ON, when I connect Lipo to LTE shield, PWR_ON is 0.8 V.

RobMeades commented 2 years ago

I'm no HW expert but in our test farm, wired together by a SW engineer (me), I do connect an ESP32 pin directly to the PWR_ON pin of the module, no inverting, no level shifting; the code will set the drive of the MCU pin that is connected to PWR_ON as open drain in this case and it seems to work, at least to a SW engineer's standards ;-).

Paryavi commented 2 years ago

Thanks Rob, I directly connected MCU GPIO 19 to PWR_ON, and it boots up! Blue LED on Sparkfun shield blinks and after it prints in IDF terminal; U_CELL_PWR, I measure V_Int signal in the shield toggles from 0 to 1.8 V for a few seconds, then goes to zero, AT commands still print, and with second print of U_CELL_PWR it goes from 0 to 1.8 V again for 20 to 30 seconds and then goes back to zero as long as I remember then we have Unable to bring up the network printed;

More detail: Running exampleCellLteCfg... I (8336) uart: queue free spaces: 20 U_CELL: initialising with enable power pin not connected, PWR_ON pin 19 (0x13) (and is toggled from 1 to 0) and VInt pin not connected. I (8356) gpio: GPIO[19]| InputEn: 0| OutputEn: 1| OpenDrain: 1| Pullup: 1| Pulldown: 0| Intr:0 AT AT... Added network with handle -7. This module does not support setting an MNO profile. unable to read bandmask! Bringing up the network... Unable to bring up the network! Done. D:/UBLOX/ubxlib/example/cell/lte_cfg/lte_cfg_main.c:455:exampleCellLteCfg:FAIL:Function [example]. Expression Evaluated To FALSE Test ran in 21293ms

I switched MNO back from # define MY_MNO_PROFILE 2 to # define MY_MNO_PROFILE U_CELL_TEST_CFG_MNO_PROFILE and APN back to "hologram".

I mean I have not set U_CELL_TEST_CFG_MNO_PROFILE should I put a value there?

Before or after that I see a connection on hologram sim; Hologram Dash

Btw, Shield LED randomly blinks blue (in several minutes intervals) even after lte-cfg example prints are done in IDF terminal! Probably because it scans through a big NB-1 or 2G RATs list for finding the right frequency.... Now I start working on Salea 15 sec capture accordingly.

RobMeades commented 2 years ago

Very good, we're getting a bit closer. That Saleae trace should, hopefully, tell us a lot.

Paryavi commented 2 years ago

Recording when IDF prints the U_CELL_PWR:powering on, example 9 of ubxlib; idf.py -p COM5 -D TEST_COMPONENTS="ubxlib_runner" flash monitor Feather_SARA Zoom on the first 15 seconds of the same session; Feather_SARA20secZoom V_INT provides the 1.8 Volt on the TX/RX level shifter of Sparkfun shield(TXB0104), not sure why it goes to zero after 20 seconds. When it toggles to zero, I assume the AT commands of MCU TX won't reach the module probably(I was not able to clip TXD or RXD on the module side yet). The code and MCU pin settings; u_cfg_app_platform_specific .txt lte_cfg_main.txt

RobMeades commented 2 years ago

Good traces, interesting.

In the trace I can see that the PWR_ON toggle is correct, VINT rises as expected and that there is a 6 second wait before the TXD activity, which is the ubxlib code sending AT to the module to see if it is awake, but there is never any response from the module.

The suspicious thing, of course, is that VINT starts glitching, even before that attempt is made, at around 5 seconds. If VINT really is going low then that's very bad, the module is not running properly; the most likely cause is that the module is not getting sufficient current to sustain itself and hence VCC is drooping below the required level. It is quite likely that at around 5 seconds the module is powering up its radio to talk to the network so there could be a surge of 1 Amp or more at that time. What is the source of power to the Sparkfun shield? You likely need more than USB, unless this is USB 3, and even then USB 3 may not be capable of delivering the peaks required in time. Anyway, let's check this: could you attach a Saleae probe to the module's VCC line (as close to the module as possible) and try again?

One thing, just to double-double-double check (sorry if I've asked this before and apologies in advance when I forget and ask it again!): can you confirm that the TXD output from the MCU is connected to the TXD input of the module, and the RXD input of the MCU to the RXD output of the module, i.e. they are not "crossed over", it is TXD->TXD and RXD->RXD? Just that it's a mistake many people (me included) make.

Paryavi commented 2 years ago

Thanks, Rob, yes it was weird VINT going low. I was using a 2000 mAh 3.7V Lipo battery with 4 volts voltage remaining on it. I always check the serial pins connection between MCU and module, but thanks for reminding!

Today I hooked up a Power supply with 1.2A 4.2V settings at the battery inlet and it looks like the problem is not the power supply. 20220317_114717

Feather_SARA_Power_Supply Zoom on first 30 seconds; Feather_SARA_Power_Supply_Zoom

I define MY_MNO_PROFILE as 2 . On the hologram dashboard, it says you are connected to AT&T. Also as far as I remember with connecting Arduino Uno instead of ESP32 to Sparkfun shield, I was using MNO as AT&T which is 2 here; https://github.com/sparkfun/SparkFun_LTE_Shield_Arduino_Library/blob/master/src/SparkFun_LTE_Shield_Arduino_Library.h#L69 And APN I used was "hologram". So I connected to the network more than ten times today but I do not receive Serial response from the module. I changed the antenna, MNO and APN dozen of times, same problem. https://github.com/u-blox/ubxlib/blob/master/cell/src/u_cell_apn_db.h#L161

The code sends AT commands for less than a minute and then gives up, and after a while, I see in the Hologram dashboard website that my simcard is connected. Sparkfun guide says it might take up to 3 minutes to connect to a network in the USA. How can we disable NB-IOT in lte-cfg code?

I think it will be great if you had a more simple IDF example to just connect to a network(with CATM1) and registering the board on the network, something like the following; https://github.com/sparkfun/SparkFun_LTE_Shield_Arduino_Library/blob/master/examples/00_Register_Operator/00_Register_Operator.ino

As you know, We've soldered a few integrated boards(with ESP32 and SARA components), I have not tested lte-cfg IDF codes on them, as you know I was using socket.ino code where one of them was reporting a simcard failure serial reply back from the module, I will run the lte-cfg code on that and see how it responds.

RobMeades commented 2 years ago

In these traces, the ones with the power supply used, VINT is definitely behaving properly, so that's good (though the LiPo you describe should have been quite sufficient). PWR_ON is now other way up though; have you gone back to using the inverter?

Anyway, from what you say, and from what VINT says, the module is on but we never, ever, get ANY serial data back from it, ever. Nothing you set in the code, nothing to do with MNO profile or APN, is going to make the slightest difference because the ubxlib code can only communicate with the module via the AT interface. Until we see AT->OK, either in your Saleae trace or in your printf()'ed trace, we have a much more fundamental problem than network configuration.

One of the following must be true:

  1. the TXD pin you are using on the ESP32 (which I gather is 17) is not connected to the TXD pin of the module,
  2. there is something wrong in the level shifting of the TXD pin so that it is not at 1.8V-logic at the module, or not the right way up, or something,
  3. the RXD pin from the module is not connected to the pin you are using for RXD on the ESP32 (which I gather is 16),
  4. the level shifting on the RXD pin is somehow going wrong and it does not sense 1.8V-logic from the module correctly,
  5. the RTS pin of the module is not grounded properly somehow.

To eliminate some of these, would it be possible to probe all of these pins right up close to the module, or at least on the module-side of the level shifter?

Paryavi commented 2 years ago

Thanks, Rob, I checked the connections, they are fine, the level shifter also works fine, unfortunately with Sparkfun level shifter, I do not have wiggle room to clip both TXD and RXD module pins, but holding the clipper on TXD I got the following; Feather_SARA_Power_Supply_Zoom_TXD MCU As long as V_INT's 1.8 volts is provided to the level shifter, it fetches TXD signal from MCU and shifts it to the module side as seen in the trace, also holding the clipper of Saleaa probe, I get stable 1.8 volts on module RXD pin. I am not sure why V_INT toggles to zero. RTS is grounded by SparkFun already(there is a jumper on the back side of the board for it); https://learn.sparkfun.com/tutorials/lte-cat-m1nb-iot-shield-hookup-guide#USB-interface

Paryavi commented 2 years ago

A quick question, I want to test lte-cfg IDF example on our integrated camera board too, but I have some signals inverted.

In the documentation; https://github.com/u-blox/ubxlib/tree/master/port/platform/esp-idf/mcu/esp32#sdk-usage Where should I set an environment variable for inverting pins?

For example, to invert the PWR_ON pin, Should I add the following flag and where? set U_FLAGS=-DMY_FLAG -DU_CELL_PWR_ON_PIN_INVERTED

RobMeades commented 2 years ago

This is getting a bit difficult to follow: assuming TXD is all good and you say that you get "stable 1.8V" on the RXD line but in the posts on this thread I've not seen any indication yet that you are receiving any actual data back from the module on the RXD pin; can you, in the Saleae application, attach a serial analyzer to the TXD and RXD lines so that it displays the data, and confirm that you are receiving responses to AT commands from the module at your MCU?

On the compilation flag, how you pass that into the build will depend on how you are building the code. If you are using arduino-cli you would pass the build options "--build-property "compiler.c.extra_flags=-Dblah"" and "--build-property "compiler.cpp.extra_flags=-Dblah"" to the "compile" command, but you will need to check exactly how this is done for whatever build mechanism you are using.

Paryavi commented 2 years ago

Hi Rob, happy to tell you I was able to run u-blox Arduino code directly from Arduino IDE;

+CGREG=2 OK AT+CEREG=2 ...U_CELL_NET: user-specified APN is "hologram". AT+CGDCONT=1,"IP","hologram" ...

I implemented the cell enable power inversion I needed with pin definitions, and for Power-ON and Reset-N pins actually we don't need inversion and we're going to remove these extra transistors. So I skipped Arduino CLI and inversion steps and the code runs on ESP board for my Sparkfun R410 LTE shield and today on the R42M8S EVKR4 board I purchased recently. last month I also modified Sparkfun u-blox codes to work on ESP32; https://github.com/sparkfun/SparkFun_LTE_Shield_Arduino_Library/tree/master/src

I have a question; For our integration boards, we have UART0 connected to the module, when I was using Sparkfun codes I moved debug pins to other UARTs;

define SerialMonitor Serial2 //uses UARTS 2 pins for Serial monitor (pins 16 and 17 of ESP32)

define LTEShieldSerial Serial //uses UARTS 0 pins for Serial monitor, as I wanted because in my board UART0 is connected to the module. A relevant video; https://www.youtube.com/watch?v=GwShqW39jlE&t=1s

So how can I have similar functionality for printf in the u-blox Arduino code example? I skimmed through u_port_uart.c and h a bit. I tried fclose(stdout) in the setup and loop but it wipes out everything. Also, I tried something like the following at the beginning of the code but the compiler says printf sometimes has more than one argument.

define DEBUG 1

if DEBUG == 1

define printf(x) printf(x)

else

define printf(x) //right, if debug is 0 then this code converts printf to be nothing!

endif

Thanks, MoZen

RobMeades commented 2 years ago

Woohoo! Well DONE! Great that you have it working.

As to your question about debug output, all that ubxlib does is to call the ESP-IDF printf() function, so wherever the output from the ESP-IDF library function printf() is directed to by Arduino is where it will come out. If you were using ESP-IDF standalone then it would be possible to redirect this but I believe that under Arduino a pre-compiled ESP-IDF library is used and so the destination for stdout is, I think, fixed, but I might be wrong.

To switch all debug output from ubxlib off then you would set the conditional compilation flag U_CFG_ENABLE_LOGGING=0 into the build.

Paryavi commented 2 years ago

Thank you Rob for all your advice, it most probably was a faulty UART on my ESP32-feather, since when I used a different ESP32, ESP32 DEVKit-V1, it started working! Thanks for the info about the debug output too, we might use a different UART for communicating with the module then.

Since I have the EVKR4 board, my next goal is to read GPS data from R422M8S, TXD_GNSS pin, pin 47 of the module(19 on J301). On our prototype board, we have connected this pin to our ESP32 MCU. Which u-blox gnss example do you recommend I look into? Some examples assume external GPS modules compared to R422M8S which has a GNSS chip inside. Here is a picture of ESP32, level shifter, and EVKR4; 20220413_163112

RobMeades commented 2 years ago

Hmm, so your EVK is doubly-endowed with GNSS chips: one inside the SARA-R422M8S chip and one separately on the EVK itself. The ubxlib code supports both but, in the above diagram, you have connected to a pin of the SARA-R422M8S thar is a kind of weird half-way house I didn't even know it had: GNSS output only, no input (i.e. no corresponding GNSS RXD line).

The simplest thing to do is to entirely ignore that pin: the ubxlib code will just talk to the GNSS chip inside the SARA-R422M8S module via AT+UBX AT commands. All you need to do is to say there's an M8 GNSS chip present and set the transport type to U_GNSS_TRANSPORT_AT as described in this example but, actually, it is MUCH easier if you follow this example: this uses the u-blox Cell Locate service which will employ the GNSS signal if it is present (i.e. you get the GNSS accuracy) or, if GNSS is not available for some reason, it will give you an approximate fix based on cell towers. The radius of position number well let you know what accuracy has been achieved.

If you really what to use that GNSS_TXD pin then it is possible that the cellular module configures the internal GNSS chip to leave NMEA messages on in the GNSS chip output stream and you can parse these yourself by tapping into that pin and bringing in your own NMEA parsing library but (a) it might not and (b) this is not something that ubxlib will do for you, you'll need to figure it out yourself I'm afraid.

Paryavi commented 2 years ago

Hi Rob and ublox friends! Congrats on the new code release(V1.0), I realized Arduino code is also updated so I gave it a shot today. With the first encounter, I got the following compilation error, unfortunately;

sketch_jul18c:89:1: error: 'uDeviceCfgCell_t' has no non-static data member named 'pPin' }; ^ C:\Users\myuser\Documents\Arduino\sketch_jul18c\sketch_jul18c.ino: In function 'void loop()': sketch_jul18c:277:27: error: too few arguments to function 'int32_t uDeviceClose(uDeviceHandle_t, bool)' uDeviceClose(devHandle); ^ In file included from C:\Users\myuser\Documents\Arduino\libraries\ubxlib\src/ubxlib.h:69, from C:\Users\myuser\Documents\Arduino\sketch_jul18c\sketch_jul18c.ino:23: C:\Users\myuser\Documents\Arduino\libraries\ubxlib\src/u_device.h:324:9: note: declared here int32_t uDeviceClose(uDeviceHandle_t devHandle, bool powerOff); ^~~~ exit status 1 'uDeviceCfgCell_t' has no non-static data member named 'pPin'

I did not change 'pPin' as I do not use SIM pin in my application. Any comments on how to fix it?

Regards, MoZen

RobMeades commented 2 years ago

Hi MoZen: yes, apologies, noticed that myself yesterday, looks as though Arduino-CLI isn't rebuilding the main application file for this example for some reason in our test system and so we hadn't spotted this. Will post a fix later today.

Paryavi commented 2 years ago

Thanks for quick reply, now I am using ESP32S3 for our camera board application, (we needed more GPIOs) so I tried rolling back to the previous ublox release like 0.10? after compile error you mentioned. but in the Previous release of this socket code, the code was compiling for the esp32 older chip version(like if I select esp32 dev module in board selection of IDE, which is for ESP32 wroom chip we had previously), but as I have updated the chip to ESP32 S3 physically (now I select their ESP32 S3 Dev board in Arduino IDE), and the compiler(for the Previous release of this socket code(v 0.10)) suggested I change the UART_SCLK_REF_TICK to UART_SCLK_RTC in u_port_uart.c, so I changed and it compiled, but in my UART instead of seeing prints like fox jumped on lazy cat I see jibberish unreadable signs at 115200 baudrate, but it connects to the network (blue LED shows connection also Hologram dashboard cloud) as I previously initialized the S3 R410 with Sparkfun LTE codes, so I lost my serial prints somehow!

Paryavi commented 2 years ago

Btw, as you know I wanna send a camera shot to our website using our ublox modem. When I bypass the modem and use WiFi instead, I can do it successfully with an HTTP client, do we have a kinda gsm client in your API?

I need to modify the code a bit, probably changing uSockWrite(sock, message, txSize).

Please let me know if you find problems with this approach or if I should use a different one like AT+UHTTPC=0,4,"/Post""result.txt","postdata.txt",1 So I am after HTTP Posts actually.

Best Regards, MoZen

RobMeades commented 2 years ago

With the first encounter, I got the following compilation error, unfortunately...

This should now be fixed in https://github.com/u-blox/ubxlib/commit/91f84b5b03e01f4b6191ba56aabf9ea1b1600dae.

RobMeades commented 2 years ago

Let me know if you still have problems with your ESP32S3 chip after updating to head-rev ubxliib.

On your need to do HTTP posts, there are a few possibilities. The most obvious one, as you've described above, is just to open a TCP socket on port 80 [or whatever the HTTP port is] of your destination HTTP server machine and send it, using uSockWrite(), a buffer on that socket, one in which you have placed a well-formed HTTP post request.

You might also use some sort of HTTP client code off the web to form the HTTP messages for you, but if all you're ever doing is a post request to a single place that might be overkill, knitting it by hand may be simpler and more obvious.

We will be adding HTTP client support to ubxlib, which will use the HTTP client inside the u-blox cellular/Wifi modules, but that is probably several months away yet.

Paryavi commented 2 years ago

Thank you, I downloaded the new fixes and it upload the code to S3 chip, but serial monitor of Arduino IDE only shows AT commands and I do not get any print from modem, I use uart zero for serial print and modem connection.

_CELL: initialising with enable power pin not connected, PWR_ON pin 35 (0x23) (and is toggled from 1 to 0) and VInt pin not connected. AT AT AT AT AT AT AT AT AT AT U_CELL_PWR: powering on. AT AT Unable to add network, error 1070492948! Network is not available! 1 Tests 1 Failures 0 Ignored CORRUPT HEAP: Bad head at 0x3fce5824. Expected 0xabba1234 got 0x3fce0014

assert failed: multi_heap_free multi_heap_poisoning.c:253 (head != NULL)

Backtrace:0x40377696:0x3fce29b00x4037a449:0x3fce29d0 0x4037fe75:0x3fce29f0 0x4037fae7:0x3fce2b20 0x40377965:0x3fce2b40 0x4037fea5:0x3fce2b60 0x42007bd7:0x3fce2b80 0x42008c74:0x3fce2bb0 0x42001f68:0x3fce2bd0 0x420020cd:0x3fce2bf0 0x42001ede:0x3fce2c10 0x42001d6b:0x3fce2c30 0x4200e721:0x3fce2ce0

ELF file SHA256: 0000000000000000

Rebooting...

RobMeades commented 2 years ago

Odd; nothing concerning the UARTs etc. has been changed in 1.0.0 aside from including the baud-rate in the configuration structure, which I guess you must be populating if you are running the example. Have you definitely applied all the changes you require for your particular HW setup into the updated code?

If you are sure everything is configured correctly, can I suggest we have a video call to go through your setup, etc., maybe do some live debugging? Just that at this stage we usually get into a several weeks-long exchange through this issues mechanism and we could maybe resolve what's going on much more quickly. Steps would be:

  1. Verify that all of the pins (UART TXD, UART RXD, UART RTS, UART CTS, ENABLE_POWER, PWR_ON, VINT) are correct for your HW.
  2. Verify that the baud rate is being set correctly in the cellular device configuration structure (should be 115200).
  3. Verify that the UART HW block is being set correctly for both the cellular device and for your logging output.
  4. Connect Saleae probe to the pins listed in (1) to verify, physically, the levels on the pins and the exchange of UART data.

I can be available in an evening UK time to do this.

Paryavi commented 2 years ago

Aloha Rob,

The odd crash after AT commands is probably because we realized yesterday that with our new S3 design, we used a few GPIOs occupied by and dedicated to PSRAM! so we sent out a new PCB order today to fix that. Yes, I am sure I configured pins connecting the modem to the microcontroller correctly.

Baud rate is 115200, I did not change it in code I mean.

I use UART 0, but I do not set logging output usually, ublox previously was showing the serial prints automatically, but I added Serial.begin(115200) too; at the beginning of the setup loop, still no output. I printed a test sentence below it, it shows that in the serial print terminal.

TX RX Dplus and Dminus Thanks for offering to meet, I think since we are going to solder a new board with PSRAM fixes very soon, let's meet after my new tests, I might have fewer board issues that time!

Thanks

Paryavi commented 2 years ago

Ok, in new sockets Arduino code, there is a baud rate setting: U_CELL_UART_BAUD_RATE is set to 115200 in u_cell.h; define U_CELL_UART_BAUD_RATE 115200 I need to put some solder on smd jumper solder on the wire leading to our micro USB from D+/D- of the modem, this was also added to our new design which I missed!

.transportType = U_DEVICE_TRANSPORT_TYPE_UART, .transportCfg = { .cfgUart = { .uart = U_CFG_APP_CELL_UART, .baudRate = U_CELL_UART_BAUD_RATE,

Paryavi commented 2 years ago

Hi Rob,

The problem was as I mentioned before, we connected ublox LTE Power_ON pin to ESP32 S3 GPIO35 which is occupied with PSRAM! so I disabled PSRAM in Arduino IDE setting for my other board(our R422M8S board), and I have ublox serial prints, attached file! So as seen, it correctly sets the hologram Access point that I have set, but then it gets stuck, I am suspicious that it is because I cant set MNO with your code, how can I add MNO to your Arduino code? It is a piece of cake in Sparkfun LTE code;

Please take a look at line 69 in their source code and line 53 of their Arduino code; The source code for defining MNO as AT&T: https://github.com/sparkfun/SparkFun_LTE_Shield_Arduino_Library/blob/master/src/SparkFun_LTE_Shield_Arduino_Library.h#L69

The arduino code for setting AT&T; https://github.com/sparkfun/SparkFun_LTE_Shield_Arduino_Library/blob/master/examples/00_Register_Operator/00_Register_Operator.ino#L53

My Serial Print is attached. I assume R422 gets stuck as I can't set MNO in your Arduino code. I will try to figure it out, but as we are buying 250 R422 boards very soon to assemble and deploy the camera boards, I need to make it work asap. I can upload Sparkfun code to set network to AT&T first then use your code, but it is not an scalable approach so if you add that to your Arduino code that would be great. I was not 100% sure getting stuck is because of not setting MNO, that's why I have attached the modem report...

R422 Prints.txt

Thanks, MoZen

RobMeades commented 2 years ago

Haven't read your recent posts properly yet but, on setting the MNO profile you just call uCellCfgSetMnoProfile().

Paryavi commented 2 years ago

I added the MNO to the sockets code and uploaded it to our R422 camera board.

My modification to sockets code is minimal, just enable the modem at the beginning of setup using our P_channel MOSFET: pinMode(CELL_ENABLE_POWER, OUTPUT); digitalWrite(CELL_ENABLE_POWER, LOW); .... //MNO Added Assuming AT&T MNO is 2 // NETWORK configuration for cellular int32_t mnoProfile = 2;
int32_t uCellCfgSetMnoProfile(uDeviceHandle_t cellHandle, int32_t mnoProfile);

static const uNetworkCfgCell_t gNetworkCfg = { .type = U_NETWORK_TYPE_CELL, .pApn = "hologram", / APN: NULL to accept default. If using a Thingstream SIM enter "tsiot" here / .timeoutSeconds = 240 / Connection timeout in seconds / }; ....

I get this now:

OK U_CELL_NET: user-specified APN is "hologram". AT+CGDCONT=1,"IP","hologram" AT+CGDCONT=1,"IP","hologram"

OK U_CELL_NET: setting automatic network selection mode... AT+COPS? AT+COPS?

SARA-R422M8S-00B-00

ERROR

+COPS: 0

OK AT+CFUN=1 AT+CFUN=1

OK AT+CREG? AT+CREG?

+CREG: 2,0

OK 0: NReg AT+CGREG? AT+CGREG?

+CGREG: 2,4

OK 0: Search

+CREG: 5,"8504","07A19B0F",7

+CEREG: 5,"8504","7A19B0F",7,,,, 7: RegR 7: RegR AT+COPS=3,0 AT+COPS=3,0

OK AT+COPS? AT+COPS?

+COPS: 0,0,"AT&T",7

OK AT+CGATT? AT+CGATT?

ERROR

+CGATT: 1

OK

ERROR AT+CGATT? AT+CGATT?

+CGATT: 1

OK AT+CGACT? AT+CGACT?

ERROR

+CGACT: 1,1

OK AT+CGACT=1,1 AT+CGACT=1,1

OK AT+CGACT? AT+CGACT?

+CGACT: 1,1

OK AT+UPSD=0,0,0 AT+UPSD=0,0,0

OK AT+UPSD=0,100,1 AT+UPSD=0,100,1

OK U_CELL_NET: connected after 25 second(s). Looking up server address... U_CELL_SOCK: looking up IP address of "ubxlib.it-sgn.u-blox.com". AT+CGDCONT? AT+CGDCONT?

+CGDCONT: 1,"IP","hologram","100.69.155.137",0,0,0

OK AT+UDNSRN=0,"ubxlib.it-sgn.u-blox.com" AT+UDNSRN=0,"ubxlib.it-sgn.u-blox.com"

+UDNSRN: "185.215.195.136"

OK U_CELL_SOCK: found it at "185.215.195.136". Address is: IPV4 185.215.195.136 Creating socket... AT+USOCR=6 AT+USOCR=6

ERROR

+USOCR: 0

OK AT+USOER AT+USOER

+USOER: 65

OK U_SOCK: underlying socket layer could not create socket (errno 105). Unable to connect to server! Closing socket... 1 Tests 1 Failures 0 Ignored R422 After adding MNO.txt Sockets.ino for R422 with MNO.txt

RobMeades commented 2 years ago

Hi MoZen: definitely progress but there's something very weird indeed going on. Taking a segment of the AT trace above and adding my annotations prefixed by <<<:

U_CELL_NET: user-specified APN is "hologram".
AT+CGDCONT=1,"IP","hologram"
AT+CGDCONT=1,"IP","hologram"    <<< The out-going AT command is being echoed back to us by the module;
                                <<< I checked the full log and that shows clearly that we have sent ATE0 
                                <<< to switch echo off, as we always do, so the only way this can happen
                                <<< is if the modem has reset underneath us (which would cause it to
                                <<< forget that we had sent it ATE0).
OK
U_CELL_NET: setting automatic network selection mode...
AT+COPS?
AT+COPS?
SARA-R422M8S-00B-00             <<< This is bizarre!  It is the response to the command ATI, which we haven't sent!
ERROR                           <<< This is also bizarre - an ERROR response might be possible here but we
+COPS: 0                        <<< have an error response followed by the expected response to AT+COPS? (+COPS: 0);
                                <<< this should not be possible.
OK

It is almost like there are two modules and/or two hosts talking down the same bit of serial pipe at the same time.

A reason for the module resetting might be to do with the power circuitry; this could be checked by hooking up your Saleae probe to the module's VINT output line and having it trigger on a negative edge, which would tell us if the module ever loses power.

One point on the MNO profile thing, having looked at your attached code: in putting the call to uCellCfgSetMnoProfile() where you have it is not actually being called, you have effectively added an additional prototype of that function to your C code. To call a function in C you need to put it inside another function somewhere in the call-tree beneath main(), which in the Arduino case would be in the call-tree beneath setup() or loop(). It also needs to be somewhere after we have powered the device up, because setting the MNO profile means talking to the module. For instance, your setup() function might become this:

void setup() {
    //Serial.begin(115200);
    pinMode(CELL_ENABLE_POWER, OUTPUT);
    digitalWrite(CELL_ENABLE_POWER, LOW);
    delay(5000);
    printf("Hi MoZen! \n");

    int32_t returnCode;
    // Initialise the APIs we will need
    uPortInit();
    uDeviceInit();

    // Open the device.  Once this function has returned a
    // non-negative value then the transport is powered-up,
    // can be configured etc. but is not yet connected.
    returnCode = uDeviceOpen(&gDeviceCfg, &devHandle);
    if (returnCode >= 0) {
        // Set the MNO profile
        returnCode = uCellCfgSetMnoProfile(devHandle, 2);
        if (returnCode >= 0) {
            printf("Added network with handle %d.\n", devHandle);
            // Bring up the network layer, i.e. connect it so that
            // after this point it may be used to transfer data.
            printf("Bringing up the network...\n");
            errorCode = uNetworkInterfaceUp(devHandle, U_NETWORK_TYPE_CELL,
                                            &gNetworkCfg);
        } else {
            printf("Unable to set MNO profile, error %d!\n", returnCode);
        }
    } else {
        printf("Unable to add network, error %d!\n", returnCode);
    }

    // An errorCode of zero indicates success
}
RobMeades commented 2 years ago

One other thing you might do is to set a greeting message, which the module would send out when it [re]boots, then you may see it visually in the log; you would do this with a call to uCellCfgSetGreeting(). So, putting everything together, your setup() code might become:

void setup() {
    //Serial.begin(115200);
    pinMode(CELL_ENABLE_POWER, OUTPUT);
    digitalWrite(CELL_ENABLE_POWER, LOW);
    delay(5000);
    printf("Hi MoZen! \n");

    int32_t returnCode;
    // Initialise the APIs we will need
    uPortInit();
    uDeviceInit();

    // Open the device.  Once this function has returned a
    // non-negative value then the transport is powered-up,
    // can be configured etc. but is not yet connected.
    returnCode = uDeviceOpen(&gDeviceCfg, &devHandle);
    if (returnCode >= 0) {
        // Set a greeting message so that we can see when the module
        // has booted; not bothering to check the return code here
        // as this is non-critical
        uCellCfgSetGreeting(devHandle, "Module has booted");
        // Set the MNO profile
        returnCode = uCellCfgSetMnoProfile(devHandle, 2);
        if (returnCode >= 0) {
            printf("Added network with handle %d.\n", devHandle);
            // Bring up the network layer, i.e. connect it so that
            // after this point it may be used to transfer data.
            printf("Bringing up the network...\n");
            errorCode = uNetworkInterfaceUp(devHandle, U_NETWORK_TYPE_CELL,
                                            &gNetworkCfg);
        } else {
            printf("Unable to set MNO profile, error %d!\n", returnCode);
        }
    } else {
        printf("Unable to add network, error %d!\n", returnCode);
    }

    // An errorCode of zero indicates success
}
Paryavi commented 2 years ago

Thanks, Rob, not sure why I did such mistake with the function call, I will read a chapter about it this weekend to refresh my C coding! Anyway, the device boots perfectly after uploading the new setup code, but can't find MNO (AT&T) as follows.

BTW, I am curious why Sparkfun code for MNO setting, also adds MNO-keys, also why do they add 2 to the MNO command string length? Source: https://github.com/sparkfun/SparkFun_LTE_Shield_Arduino_Library/blob/master/src/SparkFun_LTE_Shield_Arduino_Library.cpp#L1658

Hi MoZen! //I think I should remove this, haha! U_CELL: initialising with enable power pin not connected, PWR_ON pin 35 (0x23) (and is toggled from 1 to 0) and VInt pin not connected.

AT AT AT ... // By ... I mean repeated AT prints! U_CELL_PWR: powering on. AT ... AT

Module has booted AT AT AT

OK ATE0 ATE0 AT

OK ATE0

OK

OK

OK AT+CMEE=2 AT+CMEE=2

OK AT+UDCONF=1,0 AT+UDCONF=1,0

OK ATI9 ATI9

00.12,A00.00

OK AT&C1 AT&C1

OK AT&D0 AT&D0

OK AT+UCGED=2 AT+UCGED=2

OK AT&K0 AT&K0

OK AT+UPSV=4 AT+UPSV=4

OK AT+UPSMR=1 AT+UPSMR=1

OK AT+CPSMS? AT+CPSMS?

+CPSMS:0,,,"01100000","00000000"

OK AT+CEDRXS? AT+CEDRXS?

+CEDRXS:

OK AT+CFUN=4 AT+CFUN=4

OK AT+CSGT=1,"Module has booted" AT+CSGT=1,"Module has booted"

OK AT+UMNOPROF=2 AT+UMNOPROF=2

+CME ERROR: Operation not supported

U_CELL_CFG: unable to set MNO profile to 2. Unable to set MNO profile, error -10! Network is not available! 1 Tests 1 Failures 0 Ignored

SARA-R422M8S-00B-00

NO CARRIER

Paryavi commented 2 years ago

It looks like in SParkfun code they first check if APN is set correctly; https://github.com/sparkfun/SparkFun_LTE_Shield_Arduino_Library/blob/master/examples/00_Register_Operator/00_Register_Operator.ino#L119 https://github.com/sparkfun/SparkFun_LTE_Shield_Arduino_Library/blob/master/src/SparkFun_LTE_Shield_Arduino_Library.cpp#L677 Then scan for operator after setting the APN for up to 3 minutes; https://github.com/sparkfun/SparkFun_LTE_Shield_Arduino_Library/blob/master/examples/00_Register_Operator/00_Register_Operator.ino#L130

lte.getOperators

https://github.com/sparkfun/SparkFun_LTE_Shield_Arduino_Library/blob/master/src/SparkFun_LTE_Shield_Arduino_Library.cpp#L832 So should we set APN first too? Because I am using "hologram" simcard.

RobMeades commented 2 years ago

Not sure I understand: you are already setting the APN, I saw it in your code...?

Paryavi commented 2 years ago

It is not setting APN after rebooting with this new setup code from these prints, the AT commands are much shorter now, right? You are right, I am also not sure why it does not show hologram APN anymore in the code like before: Yesterday I had these prints: OK U_CELL_NET: user-specified APN is "hologram". AT+CGDCONT=1,"IP","hologram" AT+CGDCONT=1,"IP","hologram"

OK U_CELL_NET: setting automatic network selection mode... AT+COPS? AT+COPS?

SARA-R422M8S-00B-00

But Today's prints attached are a bit different.

new prints.txt the new code: newcode.txt

RobMeades commented 2 years ago

Looking at your most recent AT log, though, that is utterly bizarre, I just can't square it with reality. The module is sent ATE0, which switches echo off, and yet you are still getting echoes of the sent AT commands. Then towards the end SARA-R422M8S-00B-00 is emitted without any prompting.

On the MNO profile, I've checked the AT manual for SARA-R4 and it says (chapter 7.26.3) the allowed values for SARA-R422M8S are:

SARA-R422 / SARA-R422M8S / SARA-R422S - 1, 19, 31, 46, 90 (factory-programmed value), 100, 201

...which is why it is telling you that 2 is not allowed. I wouldn't worry about this, MNO profile is a kind of "meta setting" thing that tunes the module for some operators but it is by no means a requirement, anything you can set with the MNOPROF at command can be set with individual AT commands if they are really required.

RobMeades commented 2 years ago

It's not setting the APN because it hasn't go to the bit where the APN is relevant; it would set it if it got there.

Now you're also getting NO CARRIER appearing in the log, which is very strange indeed, like something is asking for a circuit switched connection, not something any ubxlib code will ever do. It's not possible that the USB interface of the SARA-R422M8S module is also connected to something, e.g. a PC, is it, which might be trying to access it as a modem?

Paryavi commented 2 years ago

Sorry the logs you saw was for when I connected FTDI programmer Receive pin to ESP32 TX line, now I have connected FTDI receive pin to RX pin of ESP32, so the log is as follows; Btw. the log is seen on Serial terminal of Arduino as FTDI is connected to COM3 of my PC. Here is the picture of the setup: S3R422

Module has booted AT

OK AT

OK ATE0

OK

OK

OK

OK

OK

00.12,A00.00

OK

OK

OK

OK

OK

OK

OK

+CPSMS:0,,,"01100000","00000000"

OK

+CEDRXS:

OK

OK

OK

+CME ERROR: Operation not supported

SARA-R422M8S-00B-00

NO CARRIER

RobMeades commented 2 years ago

OK, so now we don't have the out-going AT commands at all, which makes it a bit difficult to tell where we are in the process. However it matches the log above in that the +CME ERROR: Operation not supported is being sent by the module because of the attempt to set the MNO profile to 2, which SARA-R422M8S does not support (I'd just take this out, it is only an optimisation, things will work perfectly well without it), then there's the mysterious "NO CARRIER", back from the module, which makes no sense to me because we would never ask for a circuit-switched connection.

RobMeades commented 2 years ago

To summarise, take out the MNO Profile setting, 'cos the one you want (2) is not supported by SARA-R422M8s, and the code I gave to you won't proceed unless that works, then the last two things in the log of stuff received back from the module:

SARA-R422M8S-00B-00

NO CARRIER

...don't make a great deal of sense to me: we didn't ask for either of these things, I can't see why the module would ever send them.

Paryavi commented 2 years ago

Yes we don't have outgoing AT commands because as I said I am now connecting the red wire in the picture(RXI of FTDI cable which goes to COM3 of PC) to RX pin of ESP32, which is RX0 of the board and connected to RXD pin of the module.

Ok I will remove the MNO profile setting, thanks for your time. I have an R410 board too, will test this code on that(if I get serial prints on that board).

RobMeades commented 2 years ago

Understood: I'm sure you've got this in hand but, obviously, having printf()-style trace output from the MCU, which is where the ubxlib code will copy the AT exchanges to for tracing purposes, is essential for your development in general, otherwise you're not going to be able to see what is going on to debug anything.

Let me know how it goes: still happy to have a call to help if you think that will make things happen faster.

Paryavi commented 2 years ago

Ok, I did not get prints from R410 modem loading new code(like before that I did not have modem prints), and it was weirdly showing network connections (probably because on R410 I loaded sparkfun code previously) Ok back to R422 again, I commented setting MNO line and uploaded same code to R422. //returnCode = uCellCfgSetMnoProfile(devHandle, 2);

So setup code looks like; // can be configured etc. but is not yet connected. returnCode = uDeviceOpen(&gDeviceCfg, &devHandle); if (returnCode >= 0) { // Set a greeting message so that we can see when the module // has booted; not bothering to check the return code here // as this is non-critical uCellCfgSetGreeting(devHandle, "Module has booted"); // Set the MNO profile //returnCode = uCellCfgSetMnoProfile(devHandle, 2); if (returnCode >= 0) { printf("Added network with handle %d.\n", devHandle); // Bring up the network layer, i.e. connect it so that

        So I commented MNO return code so the following returnCode if statement might not make sense right?

And it connects to AT&T after 27 seconds as module report below but it has another error; underlying socket layer could not create socket (errno 105). Btw, all these prints are from USB port.

CREG: 2,2

OK

+CREG: 5,"8504","07A19B0F",7

+CEREG: 5,"8504","7A19B0F",7,,,, 0: Search 7: RegR 7: RegR AT+COPS=3,0

OK AT+COPS?

+COPS: 0,0,"AT&T",7

OK AT+CGATT?

ERROR

+CGATT: 1

OK

ERROR AT+CGATT?

+CGATT: 1

OK AT+CGACT?

ERROR

+CGACT: 1,1

OK AT+CGACT=1,1

OK AT+CGACT?

+CGACT: 1,1

OK AT+UPSD=0,0,0

OK AT+UPSD=0,100,1

OK U_CELL_NET: connected after 27 second(s). Looking up server address... U_CELL_SOCK: looking up IP address of "ubxlib.it-sgn.u-blox.com". AT+CGDCONT?

+CGDCONT: 1,"IP","hologram","100.69.155.137",0,0,0

OK AT+UDNSRN=0,"ubxlib.it-sgn.u-blox.com"

+UDNSRN: "185.215.195.136"

OK U_CELL_SOCK: found it at "185.215.195.136". Address is: IPV4 185.215.195.136 Creating socket... AT+USOCR=6

ERROR

+USOCR: 0

OK AT+USOER

+USOER: 65

OK U_SOCK: underlying socket layer could not create socket (errno 105). Unable to connect to server! Closing socket... 1 Tests 1 Failures 0 Ignored

Paryavi commented 2 years ago

I resurrected another R410 board that had a defective camera for testing your new MNO code and surprisingly it has serial prints again, it connects to the network and sets the MNO but still, I got a socket issue, I guess in the sockets part it is looking at ublox and hologram server at the same time? I will replace ublox with hologram server and see what is the difference, but before that I have attached the Serial report below. R410 prints.txt

Paryavi commented 2 years ago

I changed ublox server and port to the hologram server and port provided in Sparkfun code, but still error number 105! https://github.com/u-blox/ubxlib/blob/master/common/sock/api/u_sock_errno.h#L145 Probably because we have PSRAM issues on the current dev board. We are rerouting a few wires to fix the memory issue(error 105) on this version of our development board!

+COPS: 0,0,"AT&T Hologram",7

OK AT+CGATT? AT+CGATT?

ERROR

+CGATT: 1

OK

ERROR AT+CGATT? AT+CGATT?

+CGATT: 1

OK AT+CGACT? AT+CGACT?

ERROR

+CGACT: 1,1

OK AT+CGACT=1,1 AT+CGACT=1,1

ERROR AT+CGACT? AT+CGACT?

+CGACT: 1,1

OK U_CELL_NET: connected after 5 second(s). Looking up server address... U_CELL_SOCK: looking up IP address of "cloudsocket.hologram.io". AT+CGDCONT? AT+CGDCONT?

+CGDCONT: 1,"IP","hologram","100.69.155.137",0,0,0,0

OK AT+UDNSRN=0,"cloudsocket.hologram.io" AT+UDNSRN=0,"cloudsocket.hologram.io"

+UDNSRN: "3.210.32.221", "34.233.146.107"

OK U_CELL_SOCK: found it at "3.210.32.221". Address is: IPV4 3.210.32.221 Creating socket... AT+USOCR=6 AT+USOCR=6

ERROR AT+USOER AT+USOER

+USOCR: 0

OK U_SOCK: underlying socket layer could not create socket (errno 105). Unable to connect to server! Closing socket... 1 Tests 1 Failures 0 Ignored

+USOER: 65

Paryavi commented 2 years ago

So we cut the tracks to IO 35 and 36 of ESP32 which should be reserved for PSRAM which previously were connected to Power_ON and RESET of the modem, I am suspicious this (using PSRAM pins) caused error 105, buffer error. So we cut the tracks and now Power_ON is connected to GPIO 3 of R410 and R422 boards, We are going to solder new boards without using GPIOs occupied by PSRAM soon: Now it is # define U_CFG_APP_PIN_CELL_PWR_ON 3 and I have enabled PSRAM now, but still, I get error 105, attached. your MNO code works on R410: R410 Report.txt I commented it for R422: R422 report.txt

My ESP32-Arduino release is 2.0.4 which is based on ESP-IDF V4.4.2; https://github.com/espressif/arduino-esp32/releases

RobMeades commented 2 years ago

One thing to make sure of is that the module's USB port must NOT be connected to anything. If the module detects that its USB port is connected to something it will only respond to AT commands over its USB port and will ignore AT commands coming over the UART from your MCU.

The other thing is to make sure of that you set the correct module type when switching between modules: you must use U_CELL_MODULE_TYPE_SARA_R422 for SARA-R422 and U_CELL_MODULE_TYPE_SARA_R410M_02B for SARA-R410M-02B; the way the cellular connection is made available to the internal IP stack on the module is different for the two cases so SARA-R422 will not set up an IP connection correctly if you tell the ubxlib code that you've got a SARA-R410 module and vice-versa. Looking at your SARA-R422 AT log above there are a couple of things I would expect to see (AT+UPSD commands) that do not appear so it might well be that the module type was not set correctly, at least on that run.

Paryavi commented 2 years ago

Thanks Rob, I was commenting out module type in Arduino, now I created a separate Arduino file for R422, attached. Now it has AT+UPSD command, but still I get error #105. Also I commented setting MNO code like this, not sure if it works properly as I commented returnCode and I still check if statement for R422 board!

.... returnCode = uDeviceOpen(&gDeviceCfg, &devHandle); if (returnCode >= 0) { // Set a greeting message so that we can see when the module // has booted; not bothering to check the return code here // as this is non-critical uCellCfgSetGreeting(devHandle, "Module has booted"); // Set the MNO profile //returnCode = uCellCfgSetMnoProfile(devHandle, 2); if (returnCode >= 0) { printf("Added network with handle %d.\n", devHandle); .... R422 with rerouted pins.txt Arduino code; Arduni code for R422.txt

Btw I think probably ublox library does not support ESP32-S3 yet. Because ublox build is based on ESP-IDF 4.3.2 which does not support ESP32 S3 boards so would you please update the build to IDF 4.4? Thanks