Hello!
My application uses an ATmega2560V talking to a uBlox cellular modem (LARA-R6 series) via UART. Specifically, it's a rotary cell phone. If you're wondering which rotary cell phone, yes, it's the main one that pops up on Google.
Previously I was using an older cell modem series from that manufacturer (the TOBY-R2 series) that did autobauding. These modems take Hayes (AT) commands, and I expose the messages going between the cell modem and the 2560V to a serial console using Erik Nyquist's serial passthrough function. Naturally this is absolutely necessary for debugging:
void serialPassthrough(){
if (Serial.available()) { //Pass anything entered in Serial off to the cell modem
Serial1.write(Serial.read());
}
if (Serial1.available()) { // Pass anything received from the cell modem to the serial console
Serial.write(Serial1.read());
}
}
I couldn't communicate in anything but garbled text with the previous (TOBY) modem at 115200, but found that 57600 worked well and the TOBY's one-shot autobauding picked it right up.
The TOBY series reached EOL and I just switched to the uBlox LARA-R6 series. Mindbogglingly to me, the LARA-R6 slowest supported baud rate is 115,200, and it doesn't have auto baud rate detection. So now I find myself in the same bad situation, with only having garbled text to work with in my serial monitor with Serial1 running at 115200.
Communication directly from the 2560V to the uBlox LARA seems reliable, as I at least know I can send the power-down AT command and have it power down, and one or two other commands produce an expected result, but I can't see any messages the LARA sends back or echoes on Serial.
The 2560V is running at 8MHz, but even at that speed, the datasheet shows that 115200 should be just fine. To be honest, I can't even really imagine a software solution here, but I suppose I'm grasping at straws. The thing that gets to me is, again, that communication to/from the LARA directly from the 2560V seems consistent, but that I'm unable to expose this to my PC serial monitor. I could connect a logic analyzer, but it's an untenable permanent solution.
FWIW, the UART lines from Serial1 to the LARA have to logic shift to 1.8V, which is done via a TXB0108. For the USB bridge off Serial, I'm using an ATmega16U2.
Things I tried:
- Ran Serial (not Serial1) at various baud rates to see if that was bottlenecking the flow somehow. Behavior seems unchanged whether Serial is at 9600, 115200, or 256000.
- Tried sticking chars received from Serial1 in a buffer and printing them to Serial well after the communication. I think I messed this up somehow because it generally just comes out blank (note to self: re-try this after posting this).
- If I type into the serial console to send AT commands manually, the length of the garbled text responses looks consistent with what I'd expect for the commands I'm sending.
- The garbled text is generally consistent. Like, I'm pretty sure ?j5 means "OK". Haha? Uff.
I'm somewhat convinced that the issue is in how the serial passthrough function handles things, despite trying to run both Serial and Serial1 at 115200.
Schematics/layout available, but it seems to me not to be a layout problem.
Any advice?
~Justine