Problems with the UBLOX's connectivity

[Victor Lucio]

I was trying to connect my cellphone tu the ublox modulo for sends at commands from my cell, in the main program of the micro I've the next lines for turn on the ublox module:

nrf_gpio_cfg_output(UBLOX_RST_PIN);//activar buffer del modem
nrf_gpio_cfg_output(UBLOX_PWR_PIN);//activar buffer del modem

uart_init();
nrf_gpio_pin_set(UBLOX_RST_PIN);
nrf_gpio_pin_set(UBLOX_PWR_PIN);

nrf_gpio_pin_clear(UBLOX_RST_PIN);
nrf_delay_ms(200);
nrf_gpio_pin_set(UBLOX_RST_PIN);
nrf_delay_ms(200);
nrf_gpio_pin_clear(UBLOX_PWR_PIN);
nrf_delay_ms(200);
nrf_gpio_pin_set(UBLOX_PWR_PIN);

The error happens after nrf_"gpio_pin_clear(UBLOX_PWR_PIN);",  but that meant that the module did not respond to the at commands and sometimes it's not connect. . For this reason I tried in several ways to solve it and the only thing that works for me is that in the main program I only put the lines until before the delay that I mentioned that I was wrong, in this way to turn on the oblox module for cellular connectivity I must pressed the key.

Now, when I run the program and load it into the terminal, everything goes well until the key is pressed, it shows me the error and the module is restarted(This is where the error occurs and in my boron the RGB LED lights up implying that the entire micro is being completely restarted.), but the connectivity is correct. If I press the button again, other error does not occur and the module doesn't restarted. In other words, the error only happens the first time I press the key.

The new error is this:

[NRF_ERROR_DATA_SIZE] in APP_ERROR_HANDLER(p_event->data.error_communication);

In this line

case APP_UART_COMMUNICATION_ERROR:
APP_ERROR_HANDLER(p_event->data.error_communication);
break;

[Denis Rustak]

There are a couple of things on how the power pin for this device needs to be driven. Most cell data modules treat the power pin as if it were a user-activated button like what you find on a cell phone -- push-and-release to turn on, push-and-release to turn off. 

The SARA-R410M is like that (but particularly bad to be honest).  On startup, you should have the reset line and the power pins high (actually, open drain but the Boron has open drain drivers so you can use normal outputs).  If coming from a clean/cold start, the R410M will be off.  Give it a second or two and then drive the power pin low for *3 seconds*, then bring it back high.  That should power the modem on and in the next second or two it should respond to AT commands.

To power it off, repeat the process of driving the power pin low for 3 seconds, then back high/open.  This will turn it off.

This gets funky if you reset the processor without power cycling as the modem will still be on and the power-on sequence now turns it *off*.  There are different ways to take handle this problem.  The Particle Boron has a sense input that detects if the module is already powered up (p0.02 IIRC but check).  If you read it and it's high, you know you can skip the power-on sequence.

Once power-on works, you'll still bump into a few issues getting the Boron to work. 

The first is that when you power the device on and off, it will generate bad data on the UART lines which cause framing errors for the NRF.  The NRF app_uart library does not handle these well.  Initializing the uart after power up can help here, as can a call to uart_unit, but the newer serial libraries are a better choice and have nice buffers to boot.  

Also, the R410M does not support handshaking but still needs the RTS line grounded so you have to configure the port with HWFC disabled and then ground RTS yourself. Because of this, buffer overflows are something you need to address at the application level.  This isn't a big deal if you avoid using the USODL mode and stick to USORD calls when you need to get data.

Finally, the R410M needs to have the DTR pin grounded for it to send URC's to the processor (such as USOCL !).  The folks at Particle decided not to do that (wut?) so getting notifications of things like disconnections, new data and the like are needlessly challenging.  They also ship older firmware in their modems (units bought 2 months ago have firmware from Feb 2018) so upgrading them isn't a bad idea if you're looking for reliability.

Sorry for the length of this; I wrote it in bouts and it turned into a blog post!