Electron - Serious Issue with UBlox AT Communication for retrieving large result sets

Dear Particles,

after a painful process of tracing down the root cause, it looks like the electron is not capable of handling larger result sets from the UBLOX device.

I included a test script that enables the validation of the problem:

Just flash the attached script (no worries, no data traffic is generated).

After flashing use a serial connection and

  1. Turn your modem on - Press ‘1’
  2. Fire a AT command that has a larger result set e.g. issue ‘AT+CLAC’ (lists the available AT commands)

As you can see, the device is not responsive any more …

I really need those commands in order to read out the cell information (AT+CGED).

Maybe I am missing something fundamental, so I would appreciated your and Particles support.

INO Test File:

SYSTEM_MODE(MANUAL);

int callbackAT(int type, const char* buf, int len, char* param){
    return WAIT;
}


void setup()
{
  Serial.begin(9600);
}

void loop()
{
  int i = 0;
  char commandbuffer[100]="";
  String command="";
  char* response;
  // THERE IS SOMETHING ON SERIAL
  if (Serial.available())
  {
    while( Serial.available() && i< 99) {
      commandbuffer[i++] = Serial.read();
    }
    if (commandbuffer[i-1] == '\n') {
      commandbuffer[i-1]='\r';
      commandbuffer[i]= '\n';
      command = (String) commandbuffer;
      Serial.println("String retrieved: " + command);
    // EXECUTE COMMAND
      switch(command[0]) {
        case 'A' :
          // EXECUTE AT - COMMAND
          Serial.println("------ EXECUTING AT COMMAND START ---------");
          if (RESP_OK == Cellular.command(callbackAT, response, 10000, command))
          {
            Serial.println("------ EXECUTING AT COMMAND SUCCESSFUL ----");
          }
          else
          {
            Serial.println("------ EXECUTING AT COMMAND FAILED  -------");
          }

          break;
        case '1' :
          // TURN MODEM ON
          Serial.println("Turn Modem On");
          Cellular.on();
          break;
        case '0' :
          // TURN MODEM OFF
          Serial.println("Turn Modem Off");
          Cellular.off();
          break;

        default :
          Serial.println("Wrong Character Input");
        }
    }
  }
}

The full test script is available here:

Thanks for your support and best regards,
Rainer

Thanks for filing this bug! We’ll try to reproduce on our end and file a GitHub issue if we can confirm it. I’m cc’ing @bdub, one of our embedded systems developers, for transparency.

You are likely just not able to grab all of the URC info out of the callback handler before the timeout occurs, or you get an OK response which will terminate the looping of data in the callback handler. I’ve created some cheater ways to get the data… and have some even better ways to get it, but need to think about the best way to work it into the Cellular.command() API first.

I see you want to get at the COPS=5 command from your other post: Electron AT Commands - Tests & Issues (Cell Location / GSM Tracking)

I run this COPS=5 command in the Electron Troubleshooting app as the last command in the n command. For instructions on how to run this app, check the very bottom of the 0.5.0-rc.1 release: https://github.com/spark/firmware/releases/tag/v0.5.0-rc.1

Source code for this Electron Troubleshooting app is here:

Thanks for taking over … AT+COPS=5 unfortunately doesn’t work for me with the Troubleshooting App (scan incomplete! Power cycle the modem and try again) … and +COPN breaks before successful ending … but anyhow … would be great if a bugfix for this problem would be available soon as I am working under some time constraints … btw. I am mainly interested in AT+CGED=5 … as this doesn’t require to be connected to the network and lists all the cells available in the neighborhood … good luck with testing!

BTW … I don’t think it’s a timeout issue (at least if you relate to the timeout in the cellular.command function) as the result breaks as part of the callback function … ways before the timeout happens …
Furthermore I always captured and printed the UBLOX responses in the callback loop (as part of my longer test script) … there is no OK response in the callback handler if the AT command breaks …

COPS=5 doesn’t always give a response. Are you using the Particle SIM or a 3rd party SIM?

I am using a particle sim. It seems like some commands killing the interface and others don’t … and I don’t think it has something to do with waiting for the network (but I am not quite sure) as with AT+CLAC (which simply reads all the possible AT commands from the chip) it is the same problem … call it once …it usually doesn’t finish … call it twice … the interface is dead …

In addition, I extended my TextScript ( Electron AT Commands - Tests & Issues (Cell Location / GSM Tracking) ) with LoopPoints in the callback handler.

Just turn on the modem with '1’
Enter ‘AT+CCID’ - works as expeted (2 Loops - one for the CCID - one for the OK)'
Enter ‘AT+CLAC’ - readout AT Commands from UBlox Chipset - may end with a 'OK or breaks after some loops
Enter ‘AT+CLAC’ for the second time … breaks usually after the first loop
Enter ‘AT+CCID’ doesn’t return feedback anymore - interface is dead

This behavior indicates an interface problem …
BTW … my cellular chipset is the ‘Ublox Sara G350’ if this matters by any means …