Normally, I’d just edit the previous post when it’s the same day,. but this has a lot to unpack.
I pinged a few fellow nerds who I know are prone to tinkering in order to look for some thoughts on what was going on.
KE0FF, ever the controller guy asked if it was really TTL or RS232… and also thought the baud rate might have been wrong, but noted that the framing seemed ok. I assured him that the baud rate was right, because I set it to 9600 baud multiple times. He suggested I go out and get a fancy USB based scope that could look at protocols to see if there was something deeper going on. He recalled that RS232 generally appears to be +5V with negative going logic, whereas TTL sits at 0 and swings high.
The alarm bells stated ringing. I have a Hantek 2D72 in my desk. popped it out and started some probing.
Well, looky there.
- I tapped the GPS output – it came out as TTL (5V at idle, swinging negative)
- I tapped the port A output – it same out as RS-232-esque (0V idle, swinging positive)
I wired up a TTL<–>RS232 chip that I had on a shelf, and got the right levels… but in zooming output he packets were too short. something more was going on.
I zoomed in and started looking at the timing of the first bit in the packet (because it was convenient). Well… that’s odd… it came out to ~26 uS in length. 1/T gave me somewhere on the order of 36k. So off to excel to dump in some common baud rates to see what the bit width would look like (I made some mistakes on specific data rates, but I was close enough to draw some conclusions).
| Baud | 1/T (sec) | 1/T (usec) |
| 115200 | 8.68056E-06 | 8.68055556 |
| 37600 | 2.65957E-05 | 26.5957447 |
| 56600 | 1.76678E-05 | 17.6678445 |
| 19200 | 5.20833E-05 | 52.0833333 |
| 9600 | 0.000104167 | 104.166667 |
| 4800 | 0.000208333 | 208.333333 |
| 1200 | 0.000833333 | 833.333333 |
Now, I’ve been using 2 things for monitoring the serial output of A. One, a BLE module that I’ve been watching from my desktop computer. Problem is, it’s set for 9600. IF I’m not at 9600, it’s not going to work right. The other is an Arduino lashed to just leverage the programming lines.
By lashing the RESET line on the Arduino Uno (and others) to ground, the Arduino microcontroller is forced into a reset state, where it is not actually operating, but the reprogramming lines from the USB to Serial (TTL) circuit are active. In this case, you would use the “TX” line (normally tied to the chip) as the Receive line, and vice versa (so wire TNC TX to Arduino TX, and TNC RX to Arduino RX).
Can’t recall where I read this – but it works well.
This makes the Arduino IDE Serial monitor work as a serial monitor for the components of the TNC (GPS, TNC, etc.). You can even change the baud rate to make sure things are set up correctly.
So now that my MAX232 chip was changing levels, I needed to look into baud rate… In the Arduino IDE, I selected 38700, and I IMMEDIATELY saw $GPRMC messages pop up. So I had a couple issues going on here.
I pulled up the BLE interface and started sending CTRL+C to stop traffic, and sent ABAUD 9600. While I never saw anything useful on the BLE terminal, I DID see the bitwidth change.
Then something weird happened. The MAX232 chip started getting HOT… it got so hot that when I flicked the board with my fingernail to see if something was just messed up, the MAX232 chip popped off the board entirely. oops. Well… how was I going to fix this?? I started looking at new MAX232 boards.. then I realized – I had the answer from yesterday – PATCH.
PATCH 005FFF0100 // out of the box, I had problems...
PATCH 005FFF0106 // obviously this one didn't work.
PATCH 005FFF0102 // This inverted the transmit line.
Once I changed the transmit line, the oscilloscope trace looked perfect – but even at 38700, I was getting trash on the screen. I was worried I had more problems. For grins, I again started messing with the Arduino IDE baud rates, and when I set it to 19200, I started getting good data again. It seems that the TNC changed to a completely different baud rate – and I don’t know why. This isn’t even one I’ve programmed or sent an ABAUD command to.
It seems I have a good start on the solution – now I need to talk to Argent and find out what I can possibly do to hard code that baud rate. That, and getting a BLE module I can connect to my iPhone. What I DID do was force the BLE module (AT09) to 19200 baud – and all of a sudden I’m getting NMEA data on my desktop via bluetooth! I’m that much closer to APRS.FI working.
After some reconfiguring (it took about 2 hours to apply windows updates, which slowed me down), it turns out I had auto baud selected on the OT3m configuration tool. I turned that off and reset the BLE module to 9600, and everything seems to be playing nicely for the moment. RTFM, truly. That one’s on me.
Now.. I’m trying to send commands via bluetooth and getting a lack of response – all it’s doing it sending my command back to me. I can at least get the CMD prompt with a CTRL+C.
Next steps? well… figuring out how the A port is supposed to respond to(might need a different terminal), and then getting a new BLE module, so I can actually talk to the system from an iPhone or iPad (and specifically APRS.FI). I suppose I could switch to android and try APRSdriod…
