UART stutters on startup

The SparqEE CELLv1.0 device.
User avatar
donjohnii
Site Admin
Posts: 686
Joined: Tue Jul 30, 2013 2:19 pm

Re: UART stutters on startup

Postby donjohnii » Sat Apr 22, 2017 2:53 am

Miq1 wrote:
donjohnii wrote:5 Status lines:
AR (input) - Module (CELLv1.0) checks if AP is asleep
MR (output) - Module sleep status... If it's asleep, this will be lit
AWM (input) -
MWA (output)- Module (CELLv1.0) wakes up AP (Client)
MP (output) - Module Poweron indication

Now we seem to be getting further: all three MWA, MP and MR(!) lines are on HIGH level. I would not bother about MWA and MP, but MR? So it looks like the module is in sleep state after power on - but why?

Next, if I pull AWM to LOW, MR stays HIGH - what??? Even if I apply my workaround procedure and get the communication running, MR still remains on HIGH. The only thing I can imagine is that the Cell only checks the AWM line infrequently or at startup only to terminate sleep state.

I will change my wiring to connect both AR and AWM to GND, so supposedly the Cell should never feel tempted to enter sleep state.


I'm not sure this one is a big deal. That particular status light could potentially just not work... I recall sending a bug report to ZTE about it one of the status lights. The other post is much more relevant to your situation.

User avatar
donjohnii
Site Admin
Posts: 686
Joined: Tue Jul 30, 2013 2:19 pm

Re: UART stutters on startup

Postby donjohnii » Sat Apr 22, 2017 2:55 am

Miq1 wrote:
donjohnii wrote:Great debug steps... so it's not sleeping. It's getting caught somewhere in the switchover.

Have you setup a simple echo device - write from the Arduino IDE through Serial0, print to CELLv1.0, echo results to Serial1? I'm not sure about your code, but getting consistency on an earlier, simple codebase and moving up from there is the way to go.

That is exactly what I am doing to debug, the main loop() consists of a few statements only, most of it inactive unless I type in special characters:

Code: Select all

void loop()
{
  static int bauds[] = { 9600, 19200, 38400, 57600, 115200, 0 };
  static uint8_t myBaud = 1;
  static long t0 = millis()+10000;
  char myChar;
 
  if(Serial.available())
  {
    myChar = (char)Serial.read();
    if(myChar=='&')
    {
      myBaud++;
      if(!bauds[myBaud]) myBaud = 0;
       CellOne.begin(bauds[myBaud]);
    }
    else if(myChar=='#') CellOne.write(0x1a);
    else if(myChar=='!') CellOneReset();
    else CellOne.print(myChar);
  }
  while(CellOne.available())
  {
    myChar = (char)CellOne.read();
    Serial.print(myChar);
  }
  if(millis()>t0)
  {
    CellOne.print("ATE1\r");
    t0 = millis() + 10000;
  }
}




Default baud is 115200, that's faster than your 38400 and is default for the module

Anytime you're dealing with clocks you have to look at the spec sheet of the MCU to figure out what offsets the baud rate has and every baud rate has a different offset based on the crystal/clock being used - it's very possible there is a positive skew on one device and a negative one on the other which causes a funny condition in some cases. I'm not saying that's the problem here, but it's possible and I've seen this type of issue in other systems.

What are you trying to do in your code... are you jumping around bauds when an & hits? That doesn't seem like a good idea... baud rates are much more finiky than you're making it out to be in this example. Hardcode in config and never change type of idea. And I've definitely seen on the cellular module if you switch up bauds incorrectly you will crash it.

Your code isn't bad, but there are some changes that should happen... move the configuration items out of the loop so you're not redeclaring continuously, make the while an if so it processes charaters from the CellOne and Serial ports more equally. This is also because the Arduinos conduct themselves in a strange way on some of the devices - for example, getting stuck in the while loop within the main loop could potentially impact the clock due to sharing of clock resources... and there is an ISR for the Serial inputs that should probably be utilzied as well instead of the main look, but that's more a preference I guess.

Miq1 wrote:
donjohnii wrote:
Miq1 wrote:I can confirm the odd "send ATE1 9-12 times on 19200, then switch to 38400" method works almost every time I try it. So the Cell seems to be listening in general, but I somehow do not get the data right.


I'm a little confused by this statement... you said it works almost every time. So what is the problem then? Not getting the "OK" after switching the baud?

No, the baud switch is just a way to get the Cell's attention. I do not get any reaction on the "ATE1" commands with the right baud rate of 38400, unless I will apply the awkward method. As I wrote: I know the "ATE1"s at 19200 baud make no sense at all, but as I observed the Cell to work at least after having seen 8-10 of those and a subsequent switch to 38400 baud on the Arduino side I chose to dig further into that.

donjohnii wrote:I'd suggest not switching the baud as a quick test/fix... you're not going to be able to utilize the additional baud rate on an Arduino anyhow. And if your program runs fine without switching, that could point to a clock inconsistency/offset between the two devices. Depending on what clock sources both devices are using, different baud rates act and line up differently with eachother.

Can you explain what you have in mind with that? I understand the bit with the clock differences, although I would assume that two UARTs running at the same nominal baud rate should be able to compensate for minor differences anyway.

But what do you mean with "you're not going to be able to utilize the additional baud rate on an Arduino anyhow"?



Baud switch should NOT be used to get the attention... probably will crash it more than anything else I've seen.

I'm not sure why you're using 38400... default is 115200 and should be kept there if possible.

Not using the additional baud - on the arduino you can't process fast enough to utilize the extra baud rate i.e. speed i.e. bandwidth. With a PPP connection on a RasPi you can but not on the Aruino... the AT commands just aren't fast enough.

User avatar
donjohnii
Site Admin
Posts: 686
Joined: Tue Jul 30, 2013 2:19 pm

Re: UART stutters on startup

Postby donjohnii » Sat Apr 22, 2017 3:00 am

You should really check out the code on the Arduino page:
http://www.sparqee.com/portfolio/sparqee-shielda/

Here's the talk to the Arduino code... there are a lot of reasons it's structured the way it is... hardware clock, ISR routines, minimizing time spent in each process, etc.


Code: Select all

#include <SoftwareSerial.h>
#include "shieldA_lib.h"


//-----------------------------------------------------------------------------
// SETUP ----------------------------------------------------------------------
//-----------------------------------------------------------------------------

void setup() {
  mySerial.begin(115200);
  mySerial.println("");
 
  cmd_setup();                     //set-up shield GPIO
  cmd_power();                     //power on
 
  debug_print( "MAIN:", LEVEL_INFO );
}


//-----------------------------------------------------------------------------
// LOOP -----------------------------------------------------------------------
//-----------------------------------------------------------------------------

void loop() {
  if (mySerial.available()) {
    char myChar = (char)mySerial.read();
    Serial.print(myChar);
  }
}

void serialEvent() {
  while (Serial.available()) {
    char inChar = (char)Serial.read();
    mySerial.print(inChar);
  }
}



Once this is working, building on top of it is an incremental process with regression testing along the way to get to your solution in a step-by-step manner.

Miq1
Posts: 22
Joined: Mon Oct 17, 2016 10:58 pm

Re: UART stutters on startup

Postby Miq1 » Sat Apr 22, 2017 7:46 am

donjohnii wrote:I'm not sure this one is a big deal. That particular status light could potentially just not work... I recall sending a bug report to ZTE about it one of the status lights. The other post is much more relevant to your situation.

Thanks for looking after it. You were right, changing the wiring did not change a thing, but please see my next response on your further posts.

Miq1
Posts: 22
Joined: Mon Oct 17, 2016 10:58 pm

Re: UART stutters on startup

Postby Miq1 » Sat Apr 22, 2017 8:01 am

A quick result ahead: 115200 baud works indeed.

donjohnii wrote:Default baud is 115200, that's faster than your 38400 and is default for the module

Yes, of course. The reason I tried using lower baud rates is the number of things the Arduino will have to do while receiving data. If I got a couple of milliseconds between looks into the UART buffer that would make my life easier. Thus I would like to slow down the Cell a bit :)

donjohnii wrote:Anytime you're dealing with clocks you have to look at the spec sheet of the MCU to figure out what offsets the baud rate has and every baud rate has a different offset based on the crystal/clock being used - it's very possible there is a positive skew on one device and a negative one on the other which causes a funny condition in some cases. I'm not saying that's the problem here, but it's possible and I've seen this type of issue in other systems.

Live and learn... I never encountered such thing before.

donjohnii wrote:What are you trying to do in your code... are you jumping around bauds when an & hits? That doesn't seem like a good idea... baud rates are much more finiky than you're making it out to be in this example. Hardcode in config and never change type of idea. And I've definitely seen on the cellular module if you switch up bauds incorrectly you will crash it.

That was done for test purposes only, I wanted to be able to switch rates without having to re-compile and upload the sketch again.

donjohnii wrote:Your code isn't bad, but there are some changes that should happen... move the configuration items out of the loop so you're not redeclaring continuously, make the while an if so it processes charaters from the CellOne and Serial ports more equally. This is also because the Arduinos conduct themselves in a strange way on some of the devices - for example, getting stuck in the while loop within the main loop could potentially impact the clock due to sharing of clock resources... and there is an ISR for the Serial inputs that should probably be utilzied as well instead of the main look, but that's more a preference I guess.

The variable declarations are "static", so they will be executed only once on startup (so I learned my C++). The read from Serial will be much slower than the data coming in from the Cell, since I used the Serial input only to type AT commands, that's why there is an if and the read from the Cell has a while loop. I am using a MKR1000 Arduino, so both serial interfaces are hardware based with their own respective 64 character buffer, so I thought that would be sufficient to catch all input on both lines.

One more reply to your next post coming :)

Miq1
Posts: 22
Joined: Mon Oct 17, 2016 10:58 pm

Re: UART stutters on startup

Postby Miq1 » Sat Apr 22, 2017 8:11 am

donjohnii wrote:You should really check out the code on the Arduino page:
http://www.sparqee.com/portfolio/sparqee-shielda/

Here's the talk to the Arduino code... there are a lot of reasons it's structured the way it is... hardware clock, ISR routines, minimizing time spent in each process, etc.


Code: Select all

#include <SoftwareSerial.h>
#include "shieldA_lib.h"


//-----------------------------------------------------------------------------
// SETUP ----------------------------------------------------------------------
//-----------------------------------------------------------------------------

void setup() {
  mySerial.begin(115200);
  mySerial.println("");
 
  cmd_setup();                     //set-up shield GPIO
  cmd_power();                     //power on
 
  debug_print( "MAIN:", LEVEL_INFO );
}


//-----------------------------------------------------------------------------
// LOOP -----------------------------------------------------------------------
//-----------------------------------------------------------------------------

void loop() {
  if (mySerial.available()) {
    char myChar = (char)mySerial.read();
    Serial.print(myChar);
  }
}

void serialEvent() {
  while (Serial.available()) {
    char inChar = (char)Serial.read();
    mySerial.print(inChar);
  }
}



Once this is working, building on top of it is an incremental process with regression testing along the way to get to your solution in a step-by-step manner.

Thanks for the hint. I did that at 115200 and got it running. I noticed, though, that I cannot do much else than just receive and send the data to the Serial monitor; any other activities on the Arduino will finally lead to buffer overflows and lost data coming from the Cell.

That could mean I will have to buffer all data from the Cell in a temporary buffer before being able to work on these. As you know SRAM is a sparse resource on Arduinos (I got 32KB), so that might bring me into a different kind of troubles. I expect to receive data packets of up to 2KB in a row in my application. Well, time to think again.

Thanks for your help for now. I rather had the Cell running at a different speed but as it seems that obviously does not work well. Perhaps you could mention that anywhere so that other Arduino developers will not run into the same trap like I did?

Miq1
Posts: 22
Joined: Mon Oct 17, 2016 10:58 pm

Re: UART stutters on startup

Postby Miq1 » Sat Apr 22, 2017 9:32 am

Looks like there may be another issue - based on the things you said, I wrote a simple copy sketch that takes everything coming from the Cell into a 8KB buffer. For test reasons I used the "AT+COPN" command that generates quite some data. But I noticed data gaps in the output, that cannot result from the copy routine (faulty spots marked manually in the list by me):

Code: Select all

at+copn

+COPN: "00101","Test PLMN 1-1"
+COPN: "00102","Test PLMN 1-2"
+COPN: "00201","Test PLMN 2-1"
+COPN: "20201","GR COSMOTE"
+COPN: "20201","GR COSMOTE"
+COPN: "20205","vodafone GR"
+COPN: "20210","TIM GR"
+COPN: "20404","vodafone NL"
+COPN: "20404","vodafone NL"
+COPN: "20408","NL KPN"
+COPN: "20408","NL KPN"
+COPN: "20412","NL Telfort"
+COPN: "20416","T-Mobile NL"
+COPN: "20416","T-Mobile NL"
+COPN: "20420","Orange NL"
+COPN: "20601","BEL PROXIMUS"
+COPN: "20601","BEL PROXIMUS"
+COPN: "20610","B Mobistar"
+COPN: "20610","B mobistar"
+COPN: "20610","B mobistar"
+COPN: "20620","BASE"
+COPN: "20620","BASE"
+COPN: "20801","Orange F"
+COPN: "20801","Orange F"
+COPN: "20802","F - Contact"
+COPN: "20802","F - Contact"
+COPN: "20810","F SFR"
+COPN: "20810","F SFR"
+COPN: "20810","F SFR"
+COPN: "20813","F - Contact"
+COPN: "20813","F - Contact"
+COPN: "20820","F-Bouygues Telecom"
+COPN: "20820","F-Bouygues Telecom"
+COPN: "20888","F - Contact"
+COPN: "20888","F - Contact"
+COPN: "21210","Monaco"
+COPN: "21303","STA-MOBILAND"
+COPN: "21401","vodafone ES"
+COPN: "21401","vodafone ES"
+COPN: "21403","Orange"
+COPN: "21403","Orange"
+COPN: "21403","Orange"
+COPN: "21404","Yoigo"
+COPN: "21407","movistar"
+COPN: "21407","movistar"
+COPN: "21601","H pannon 3G"
+COPN: "21601","H pannon"
+COPN: "21601","H pannon"
+COPN: "21630","T-Mobile H"
+COPN: "21630","T-Mobile H"
+COPN: "21670","vodafone HU"
+COPN: "21670","vodafone HU"
+COPN: "21803","HT ERONET"
+COPN: "21805","m:tel"
+COPN: "21805","m:tel"
+COPN: "21890","BIH BH Mobile"
+COPN: "21890","BIH BH Mobile"
+COPN: "21901","T-Mobile HR"
+COPN: "21902","HR TELE2  HR 21902"
+COPN: "21910","HR VIP"
+COPN: "22001","Telenor SRB"
+COPN: "22001","Telenor SRB"
+COPN: "22002","ProMonte"
+COPN: "22002","ProMonte"
+COPN: "22003","YUMTS  YUG03"
+COPN: "22003","YUG 03"
+COPN: "22003","YUG 03"
+COPN: "22004","T-Mobile CG"
+COPN: "22005","Vip SRB"
+COPN: "22005","Vip SRB"
+COPN: "22005","Vip SRB"
+COPN: "22201","I TIM"
+COPN: "22201","I TIM"
+COPN: "22210","vodafone IT"
+COPN: "22210","vodafone IT"
+COPN: "22288","I WIND"
+COPN: "22288","I WIND"
+COPN: "22299","3 ITA"
+COPN: "22601","RO Vodafone RO"
+COPN: "22601","RO Vodafone RO"
+COPN: "22603","RO COSMOTE"
+COPN: "22603","RO COSMOTE"
+COPN: "22605","RO Digi.Mobil"
+COPN: "22610","RO ORANGE"
+COPN: "22610","RO ORANGE"
+COPN: "22801","Swisscom"
+COPN: "22801","Swisscom"
+COPN: "22801","Swisscom"
+COPN: "22802","Sunrise"
+COPN: "22802","Sunrise"
+COPN: "22803","orange CH"
+COPN: "22807","In&Phone"
+COPN: "22808","CHE  Tele2 Switzerland"
+COPN: "23001","T-Mobile CZ"
+COPN: "23001","T-Mobile CZ"
+COPN: "23002","O2 - CZ"
+COPN: "23002","O2 - CZ"
+COPN: "23003","Vodafone CZ"
+COPN: "23003","Vodafone CZ"
+COPN: "23101","Orange SK"
+COPN: "23101","Orange SK"
+COPN: "23102","T-Mobile SK"
+COPN: "23102","T-Mobile SK"
+COPN: "23102","T-Mobile SK"
+COPN: "23106","O2 - SK"
+COPN: "23106","O2 - SK"
+COPN: "23201","A1"
+COPN: "23201","A1"
+COPN: "23201","A1"
+COPN: "23203","T-Mobile Austria"
+COPN: "23203","T-Mobile Austria"
+COPN: "23203","T-Mobile Austria"
+COPN: "23205","Orange AT"
+COPN: "23205","Orange AT"
+COPN: "23207","tele - ring"
+COPN: "23207","tele - ring"
+COPN: "23207","tele - ring"
+COPN: "23210","3 AT"
+COPN: "23212","Orange AT"
+COPN: "23212","Orange AT"
+COPN: "23401","UK01"
+COPN: "23403","Airtel-Vodafone"
+COPN: "23403","Airtel-Vodafone"
+COPN: "23407","Cable&Wireless UK"
+COPN: "23409","PMN UK"
+COPN: "23410","O2 - UK"
+COPN: "23410","O2 - UK"
+COPN: "23410","O2 - UK"
+COPN: "23415","vodafone UK"
+COPN: "23415","vodafone UK"
+COPN: "23416","Opal UK"
+COPN: "23419","PMN UK"
+COPN: "23420","3 UK"
+COPN: "23430","T-Mobile UK"
+COPN: "23431","T-Mobile UK"
+COPN: "23432","T-Mobile UK"
+COPN: "23433","Orange"
+COPN: "23450","JT-Wave"
+COPN: "23450","JT-Wave"
+COPN: "23450","JT-Wave"
+COPN: "23450","JT-Wave"
+COPN: ","RUS DTC" <-------------------------------------- here is something wrong
+COPN: "25012","RUS 12"
+COPN: "25012","Far East  RUS 12  250 12"
+COPN: "25012","Far East  RUS 12  250 12"
+COPN: "25013","RUS Kuban-GSM"
+COPN: "25013","RUS Kuban-GSM"
+COPN: "25015","RUS15  RUS SMARTS"
+COPN: "25016","RUS16 250 16"
+COPN: "25016","RUS16 250 16"
+COPN: "25017","Utel"
+COPN: "25017","Utel"
+COPN: "25019","RUS INDIGO"
+COPN: "25020","RUSSIA VOTEK MOBILE"
+COPN: "25020","TELE2"
+COPN: "25028","RUS Beeline"
+COPN: "25035","MOTIV"
+COPN: "25037","KODOTEL"
+COPN: "25039","Utel"
+COPN: "25039","Utel"
+COPN: "25099","Beeline"
+COPN: "25099","Beeline"
+COPN: "25501","MTS UKR"
+COPN: "25501","MTS UKR"
+COPN: "25502"+COPN: "311180","AT&T" <----------------------- here again
+COPN: "311180","AT&T"
+COPN: "311190","USAC1ECI"
+COPN: "311210","FARMERS"
+COPN: "311210","FARMERS"
+COPN: "311240","USACWCI"
+COPN: "311250","USA i CAN"
+COPN: "311260","SLO Cellular"
+COPN: "311310","Lamar Cellular"
+COPN: "311311","USANCW"
+COPN: "311330","BTW"
+COPN: "311360","Stelera Wireless"
+COPN: "311370","GCI"
+COPN: "311500","MOSAIC"
+COPN: "311530","USANCW"
+COPN: "330110","PR Claro"
+COPN: "330110","PR Claro"
+COPN: "33211","Blue Sky"
+COPN: "332011","Blue Sky"
+COPN: "334003","movistar"
+COPN: "33420","Telcel GSM"
+COPN: "334020","Telcel GSM"
+COPN: "33805","DIGICEL"
+COPN: "33805","DIGICEL"
+COPl" <------------------------------------------------- and again
+COPN: "405802","Aircel"
+COPN: "405803","Aircel"
+COPN: "405804","Aircel"
+COPN: "405805","Aircel"
+COPN: "405806","Aircel"
+COPN: "405807","Aircel"
+COPN: "405808","Aircel"
+COPN: "405809","Aircel"
+COPN: "405810","Aircel"
+COPN: "405811","Aircel"
+COPN: "405812","Aircel"
+COPN: "405813","IN UNITECH"
+COPN: "405814","IN UNITECH"
+COPN: "405815","IN UNITECH"
+COPN: "405816","IN UNITECH"
+COPN: "405817","IN UNITECH"
+COPN: "405818","IN UNITECH"
+COPN: "405819","IN UNITECH"
+COPN: "405820","IN UNITECH"
+COPN: "405821","IN UNITECH"
+COPN: "405822","IN UNITECH"
+COPN: "405844","Unitech Wireless IN"
+COPN: "405845","IDEA"
+COPN: "40584UB" <----------------------------------- as well here
+COPN: "52505","STARHUB-SGP"
+COPN: "52507","SGP Call Zone"
+COPN: "52802","BRU-bmobile"
+COPN: "52811","BRU-DSTCom"
+COPN: "53001","vodafone NZ"
+COPN: "53005","Telecom NZ"
+COPN: "53005","Telecom NZ"
+COPN: "53024","2degrees"
+COPN: "53024","2degrees"
+COPN: "53701","PNGBMobile"
+COPN: "53730","Digicel PNG"
+COPN: "53901","U-CALL"
+COPN: "53988","Digicel  Tonga"
+COPN: "54001","SI BREEZE"
+COPN: "54101","VUT SMILE"
+COPN: "54105","DIGICEL"
+COPN: "54201","FJ VODAFONE"
+COPN: "54411","Blue Sky"
+COPN: "544011","Blue Sky"
+COPN: "544110","Blue Sky Communications"
+COPN: "544544","Blue Sky Communications"
+COPN: "54509","KL-Frigate"
VILNET" <------------------------------ here
+COPN: "73601","NUEVATEL"
+COPN: "736001","NUEVATEL"
+COPN: "73602","EMOVIL"
+COPN: "736002","EMOVIL"
+COPN: "73603","Telecel⸮Bolivia⸮GSM"
+COPN: "73801","DIGICEL"
+COPN: "73802","GUY CLNK PLS"
+COPN: "74000","movistar"
+COPN: "74001","PORTA GSM"
+COPN: "74401","HOLA PARAGUAY"
+COPN: "744001","HOLA PARAGUAY"
+COPN: "744002","CLARO PY"
+COPN: "74404","Telecel GSM"
+COPN: "74405","PY Personal"
+COPN: "744005","PY Personal"
+COPN: "74602","SR.TELESUR.GSM"
+COPN: "74602","SR.TELESUR.GSM"
+COPN: "74603","DIGICEL"
+COPN: "74603","DIGICEL"
+COPN: "74604","UNIQA"
+COPN: "74807","MOVISTAR"
+COPN: "748007","MOVISTAR"
+COPN: "748010","CLARO URUGUAY"
+COPN: "75001","C&W FLK"
+COPN: "79502","TM CELL"
+COPN: "79502","TM CELL"
+COPN: "90105","Thuraya"
+COPN: "90106","Thuraya"
+COPN: "90112","MCP Maritime Com"
+COPN: "90114","AeroMobile"
+COPN: "90115","OnAir"
+COPN: "90117","Navitas"
+COPN: "90118","cellular at SEA"
+COPN: "901018","cellular at SEA"
+COPN: "90121","Seanet"
+COPN: "00011","INX Inmarsat"

OK


The first error is close to 4000 characters from the beginning, where the buffer has still another 4KB space left. Could it be the Cell itself has a buffer overrun here? I may not have spotted all errors at first glance, though.

The code I am using here is as follows:

Code: Select all

const unsigned int CBsize = 8000;
char CellBuf[CBsize];
const char *CBlimit = CellBuf + CBsize - 2;
char *CellPtr = CellBuf;
long idle = millis();

void loop()
{
  if(Serial.available())
  {
    char myChar = (char)Serial.read();
    CellOne.print(myChar);
    idle = millis() + 5000;
  }
  while (CellOne.available())
  {
    *CellPtr++ = (char)CellOne.read();
    if(CellPtr>CBlimit) break;
  }
  if(CellPtr>CellBuf && idle<millis())
  {
    *CellPtr = 0;
    CellPtr = CellBuf;
    Serial.print(CellBuf);
  }
}

User avatar
donjohnii
Site Admin
Posts: 686
Joined: Tue Jul 30, 2013 2:19 pm

Re: UART stutters on startup

Postby donjohnii » Sat Apr 22, 2017 2:14 pm

Thanks for your help for now. I rather had the Cell running at a different speed but as it seems that obviously does not work well. Perhaps you could mention that anywhere so that other Arduino developers will not run into the same trap like I did?


I did also notice that in talking with you. It was a little surprising that note wasn't already available - the default baud and note on switching it. Will add. Thanks.

User avatar
donjohnii
Site Admin
Posts: 686
Joined: Tue Jul 30, 2013 2:19 pm

Re: UART stutters on startup

Postby donjohnii » Sat Apr 22, 2017 2:27 pm

Here's where you're going to get into issues with the Arduino...

I've tested extensively on the Arduino and RasPi. The arduino, when dealing with too much data or too quick of data, will start to miss... just like any system that doesn't have enough speed/buffer support... that's just inherent in the HW and something you have to work with. The misses you show are consistent with the Arduino not being able to service the buffer quick enough. It is possible that I didn't test a ton of data with this simple script like you're doing... <suggestion that I did test when running into this issue in next paragraph>

BUT there's also - anytime your printing for debug purposes, it's going to run your system slower and eat-up CPU. So something I've done in the past with the Arduino - push your debug to a buffer and only print periodically to see if it's actually a problem with your arduino/cell connection vs. just a debug issue because of the printing cost/time, which it could definitely be.

I don't know what you meant by - you brought the baud down so you'd have a few milliseconds between reads. I may be confused about your statement, or I may not, but a higher baud rate gives you more BW. The HW buffers you're using will take care of processing the characters but they'll overrun if not serviced quick enough. Maybe you mean that as an individual character is coming across, before the ISR is tripped, you'll have more time to do other stuff with a lower baud rate... I know this makes some sense, but it sounds jenky for some reason... I'll have to think about this one. I wouldn't rely on this type of build, but who knows, could work.

I would suggest to push your input to a buffer so the HW buffer wouldn't overflow for the UART. That being said, you have to make sure your application code doesn't overrun your underlying buffer length. In this way, there wouldn't be a forceful exercise to print out to empty the buffer but a quicker opportunity to cache the data in a local buffer then take the time to print it later, which is the most time intense exercise.

Miq1
Posts: 22
Joined: Mon Oct 17, 2016 10:58 pm

Re: UART stutters on startup

Postby Miq1 » Sun Apr 23, 2017 3:25 am

Thanks again for your thoughts. I did some more experiments in the meantime and am afraid it may be out of my capabilities to compensate for the issues. I modified my code to put an additional '|' into the buffer whenever I will enter the read loop upon "CellOne.available()" being true. The loop does not much more than to copy the incoming data into a buffer, any output is delayed to 5 seconds after I entered the respective AT command:

Code: Select all

long idle = millis();

void loop()
{
  if(Serial.available())
  {
    char myChar = (char)Serial.read();
    CellOne.print(myChar);
    idle = millis() + 5000;
  }
  if(CellOne.available())
  {
    *CellPtr++ = '|';
    do
    {
      *CellPtr++ = (char)CellOne.read();
    } while (CellOne.available() && CellPtr<CBlimit);
  }
  if(CellPtr>CBlimit || (CellPtr>CellBuf && idle<millis()))
  {
    *CellPtr = 0;
    CellPtr = CellBuf;
    Serial.print(CellBuf);
  }
}


With that code I can see that the loop is left after any single character - the data seems to be slow enough to not fill more of the internal 64 byte UART buffer. But at the point where the first data fault in the output of AT+COPN was visible, the pattern changes dramatically:

Code: Select all

|+|C|O|P|N|:| |"|2|3|4|5|0|"|,|"|J|T|-|W|a|v|e|"||
|+|C|O|P|N: ","RUS DTC"
+COPN: "25012","RUS 12"
+COPN: "25012","Far Ea25|0|2|0|"|,|"|R|U|S|S|I|A| |V|O|T|E|K| |M|O|B|I|L|E|"||
|+|C|O|P|N|:| |"|2|5|0|2|0|"|,|"|T|E|L|E|2|"|
|


The number of characters read in in a row here is 63 - a full HW buffer - and several more seem to be missing before and after that string.

Since nothing can have changed my program while it ran, there must be something running in the background of the Arduino eating up too much cycles.

A quick calculation: 115200 baud is approximately 11KB per second, give or take a few. The MKR1000 runs at 48MHz, ARM instructions taking mostly 1, some up to 4 cycles. Let us assume 2 on average, so we get 24 million instructions per second. So we have around 2.200 instructions available per byte of incoming data. That is quite a number, so what happens there in the background consuming that many instructions that the 64 byte buffer can be overrun?


Return to “CELLv1.0”

Who is online

Users browsing this forum: No registered users and 1 guest