UART stutters on startup

[Miq1]

[I am hoping I will not get permanently banned again, as it has happened twice before... ]

I am using the Cell with an Arduino MKR1000, connected to hardware Serial2. As soon as the UART communication starts working, all is fine, but the initial startup has an issue.

After resetting/powering the Arduino, a 100ms LOW signal is put to PO. Hence the Cell restarts and is able to establish a 3G connection, as I can see from the LED.

But serial communications on the UART is possible only once in a while - it may work immediately after power up, may take several seconds to minutes to finally get up or never start at all. I see all three schemes repeatedly, with the comms failing more often.

Serial speed was set to Auto (+ZBITRATE=1, then +ZBITRATE=S), with the Arduino communicating at 9600 baud at the moment.

It is not reliable enough for me to use, so what would you suggest doing?

[donjohnii]

Typically I would go through a loop to not use a product until consistent communication was established... so something like:

flag_go=false
1. Check if ate1 returns 'ok', if so flag_go=true, if not flag_go=false
2. check for 'ok' and wait 10sec interval for 120sec total, if good flag_go=true, if not flag_go=false
3. if previous check failed, reset connection and restart check

Unless the HW is busted, which isn't your problem, the above look should establish a consistent connection. It's a very common scenario with interconnecting and working with HW that the connection takes a couple tries and there needs to be a retry and wait mechanism in order to establish a consistent connection.

[u063096]

What time to wait for the connection would you suggest then? I currently have a loop iterating through the baud rates and sending AT only, then wait for the OK, but that seemingly works only once in a while. I could not find a pattern yet as when the communication will establish or not.

[donjohnii]

I wouldnt suggest changing the baud as that will cause errors too. Stick with a 1m-3m loop on reset.

If you are having these type of consistent issues, it's not common. You probably have a bad modem or driving with a bad baud.

[Miq1]

[donjohnii]

This suggestion is probably not awesome, but I would stick with the default baud rate. If you've changed the baud rate but are still seeing the original, then either it's not initializing soon enough or it's potentially getting misaligned somehow due to the baud rate issue. So utilizing the default baud would eliminate that issue.

It does seem like there's some type of overflow situation or even a sleep situation that is causing the modem to not come back.

Someone else is currently asking about sleep/hang and your issue could be similar. To eliminate potential causes, I'd suggest to do 2 things at this point - use the default baud and check the sleep status using the below information:

There are a couple of things to try to debug based on the 5 status I/O lines. If you look at the datasheet, the 5 lines are for:

2 Main Lines
PRN - reset's the board
PO - controls on/off functionality

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

I don't use these status lines much, but it's possible I have them connected in a certain way in my tests that I cause it to stay on. So I would suggest that you provide:
-AR 0V to tell the module that the the client is available
-AWM 0V to tell the module to wakeup if it is sleeping

Then check the status lights of:
-MR to make sure it's dark (LED off) indicating it's awake
-MWA should be lit (LED on) to indicate that the module is telling the AP to be awake
-MP should always be lit (LED on) indicating power to the module

[Miq1]

Thanks for the advice. I already tested with AR and/or AWM set to GND unfortunately with no different results. Remains the check of the info lines; I will need a multimeter or osc to check tomorrow, as the Cell is on a PCB already and not easily rewired.

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.

[donjohnii]

[Miq1]

[Miq1]