I’ve been doing a LOT of troubleshooting and trying to figure this thing out.
Ordered a new breadboard (old one had some shorted lines), and a bunch of wires.
Ordered the Adafruit BLE UART friend to replace the HC05 and alleged AT09 (turns out, it identifies as an HC05, so I think it was a fake).
Nothing.
So let’s break down where I’m at with all this:
I never got a good “SNOOP” operation with the GPS connected. This means there was something going on with the TNC. I tried multiple settings, and got nowhere.
In digging into the documentation for the TNC, I noted that it was reportedly “configurable for either RS-232 OR TTL”. OK – but I could not find ANYWHERE where this was truly documented. Then I stumbled on this line in the web documentation:
At this point, I had nothing to lose, so I tried it – as soon as the device rebooted, the green LED started pulsing once per second, and I started seeing valid GPS packets on the USB line when connected through PuTTY. It would seem that I fixed something – I got excited, thinking the project was almost wrapped up. Not quite – I put a monitor on port A (GPS was on port B), and was getting the same inverted nonsense I had gotten before when trying to decode the GPS data.
I emailed Argent about it, and asked a few questions about the patch command… I learned a bit about the command from Scott Miller. It turns out that the command is modifying address 005FFF. It is sending 0106, which tells the firmware that we’re sending ONE byte (01) and setting it to value 06.
Based on the bits, the following options for this value exist:
- 00 – non-inverted TX/RX
- 02 – invert RX only
- 04 – invert TX only
- 06 – invert both RX and TX.
02 and 06 both resulted in good GPS data being received, but I’ve not gotten good data on the passthrough.
This is the data I get on the passthrough, while getting a good GPS fix now, when both input and output are inverted (this is similar to what I got on the USB terminal before inverting things):
And when I invert ONLY the receive, this is what I get on the output (with refreshes or clear screens quite frequently):
In the first case, I can enter “CTRL+C” on some terminal interfaces (across a BLE link to my computer, still no dice with phone), and it will stop the system from doing data passthrough (proper operation), but I get no actual CMD prompt or responses.
I might try using a 2N3904 as a simple inverter to see if I can get something useable. I asked Scott about inverting only one of the ports, and he said it was all or nothing – the serial boot loader and other back-end things for that TNC design were pretty much locked in place. It would take a new chipset to really move on to that level.
I’ve considered that maybe my GPS and BLE and Serial terminal devices were NOT all TTL – but I’ve done direct connections, bypassing the TNC and showed that they all talk nice to one-another, so that’s probably not the issue at this point.
I’ve also set everything to 9600bd, simply because that matches the GPS native data rate.
More to come, I’m not done with this project yet….