Nice real world example of figuring out an unknown interface. There are plenty of different electrical interfaces for transmitting serial data, and they often use the same physical connector, so you definitely have to know what the device is outputting. For reverse-engineering an unknown device, you often will need a scope. If you're lucky, you'll be facing an interface that is documented, like RS-232, RS-422, or RS-485. If you're unlucky, you need to rely on experience, knowledge and familiarity like OP did. Only once you have the electrical signal figured out, you can move on to baud, word length, stop bits, parity, and so on, and then decoding the actual data.
RS-232 defines the levels, the different signals, and the physical connectors. However, baud rate, parity, stop bits, and the like are at a "level" above RS-232, and so outside its scope.
We also have to bear in mind that the computer industry often uses "RS-232" in reference to something that uses neither the connector nor the signaling levels defined by RS-232, something we have IBM to thank for.
Egregious rent seeking grifters at TIA demanding $165 per half-assed scanned copy[1] of a near 3-decade-old document that they couldn't even be bothered to properly OCR, and somehow IBM gets to shoulder the blame for the interoperability clusterfuck that ensued as everyone and their mother was profiting off their innovation?
Yet another fine example showing why standards should be at least readable to everyone for free, eh?
The general public at large already pays huge amounts of money to various standardization organizations, be it ISO, IEC, DIN, UL, whatever. The resulting works should be public domain, similar to patents.
See, you called it “asynchronous serial protocol” there. But one can certainly think of asynchronous serial protocols that are outside those bounds.
The Wikipedia article [0] calls this category “asynchronous start-stop signaling” but has no source.
I guess the best term is “UART protocol”, despite the limited size of the “universe”, since it’s really just a de facto convention established by decades of chips called “UARTs”.
For years the most common use for “serial” would be dialup internet and computer mice (among other peripherals), neither of which would have been primarily ASCII.
Not sure what you have in mind by “usually” ASCII, but it’s not the layer that serial links operate at, they’re just a dumb pipe.
RS422 and RS485 use the same differential signalling IIRC. The difference between two lines (>some mV <some mV) is what encodes zero or one. There's some allowed voltage range defined from ground but it's not that level that encodes the signal, it's the difference. Running a differential signal over a twisted pair reduces the noise.
In RS232, to contrast, the voltage defines the values, +/- 12V is also common and I think you can go pretty low while still meeting the standard.
ASCII is orthogonal, you can send anything over the serial link.
EDIT: apparently 3V-15V are the defined voltage levels (-3V - -15V) and drivers should tolerate up to +/-25V.
Big difference between RS422 and RS485 is the drivers for RS485 are required to survive a minus 7 volt difference between the two grounds.
Old R422 drivers would smoke if you got more than 7 tenths of a volt difference. Which would happen if you had a open ground. Or lighting hit. Or some big motor turned on. We had an RS422 based system with 50 units on one pair. One of them was holding the line. Coworker unplugged each one till he found it. And half of them didn't work after that.
I hope GPS receivers have addressed this rollover problem. Not that we will be using GPS receivers made now necessarily over 150 years from now. Garmin GPS 95 was made in 1995. Because it uses the older 10-bit week counter then it causes the device to display incorrect dates after the counter resets every 1024 weeks. Newer GPS systems with the 13-bit week counter don't have this problem because they can count weeks for a much longer period (157 years) before needing to reset.
I am guessing when GPS was originally designed the designers didn’t anticipate that the 10 but counter would be an issue and/or proliferation of these consumer devices.
Since they could control their own equipment, maybe they thought the LNAV 10 bit counter was fine.
> I am guessing when GPS was originally designed the designers didn’t anticipate that the 10 but counter would be an issue and/or proliferation of these consumer devices.
Or maybe they just assumed that some other source of information could disambiguate the week number.
For example:
1. The week rollover interval is almost co-prime with the number of weeks per year. If the user is given a way to override just the current day-of-month, the full current date and time can probably be disambiguated to within a ~255-year window. If the user is given a way to override just the current year, the current date and time can be exactly calculated.
2. A receiver with non-volatile storage can keep track of the last week number it has seen. If the week number at the next power-up is less than the previous value, it is likely that at least one week rollover has occurred. If the receiver is powered on at least once every few years, this would be a fairly reliable way to count the number of rollovers.
3. (NV storage again) Leap seconds are added at a rate of roughly 10 per 1024 weeks. If the number of leap seconds suddenly jumps, that may be a sign that a large amount of time has passed. This might be used to augment #2 to estimate the number of rollovers that have occurred. There are some reliability concerns here, as the earth seems to be slowing somewhat.
4. (NV storage again) GPS satellites do not (as far as I know) really have enough fuel to change which orbital plane (of the ~6) they are in. If the set of PRN-plane assignments do not match the assignments from last power-up, it is likely that large amount of time has passed (because it means that some satellites were retired and others launched).
All in all, it's a relatively minor problem. Most receivers just hard-code a minimum date in software and assume that they are within 20 years of that. Most of the time, nobody cares.
It's possible to brick some GPS units by sending them faked signals that advance the time until the next rollover. Then they're permanently stuck in the next epoch, far in the future.
Fun trivia, the Unix epoch rolls over in January of 2038, but the next GPS WNRO happens in Novermber of that same year. So some systems, if you hiccup the epoch past that, may immediately suffer Y2038 problems.
I ran into this a few years ago with a cots GNSS product. Their datasheet said it supported 232, 422, maybe 485. But they didn't say how to select any of them and when I probed, it was I think 422. It was certainly 0-3v. Not wanting to send -15V to a standard digital logic chip, I contacted the manufacturer. Weeks of going back and forth with their sales team on the phone and email. They insisted that was 232 because the 3v is within some range. Eventually they let me talk to an engineer who within seconds said "it'll auto detect from the negative voltage." It did and we closed off that task. Easily the most frustrating manufacturer interaction I've ever had. They could've just put that in the datasheet.
This takes me back to one of my first hacker projects. We were going on a family road trip and I had found an old marine GPS receiver. The manual it came with showed a special cable for RS232, but I didn't have it and so drilled a hole in the side to solder wires to the back of the connector. Then there was some desktop program where you could plot your position on top of downloaded openstreetmaps maps. This was around the time where smartphones with maps existed, but nobody I knew had one. I think you could also get GPS receivers from Sparkfun, but they were expensive and I was a kid with no money. Good times.
The GPS 95 supported NMEA 0180, 0182, and 0183 up to version 1.5 originally. The GPS 95 XL revision increased the support up to NMEA 0183 version 2.0. With four proprietary extensions, of course. The specimen in the blog post was software updated to the GPS 95 XL firmware at some point.
The NMEA organization published version 4.30 of the 0183 standard in December 2023. I dumped the firmware of the (software upgraded) GPS 95, it might be a cool project to replace the proprietary extensions with standard sentences from later revisions.
As for NMEA 2000, it's a completely different beast: a binary protocol sent in frames over a CAN bus. But as evidenced by NMEA continuing to update the 0183 standard, some industry is still using it.
This takes me back to the days of ordering a custom injection molded 4 pin connector for a Garmin III+ or IV, back in the days when you wouldn't just 3D print one and throw in a few pin connectors.
Nice! I just found my TFT color Garmin GPS yesterday that I was looking for during the pandemic but have now forgotten what project I was going to use it for. Maybe I should take it out caching for old times sake.
I used to cache a ton; but, have only found a handful a year (outside of an annual guys trip with caching friends that has become more about chasing states where we’ve found caches (49 for me; just missing AK)) and hitting breweries.
My unit predates GPS units having street maps, but assuming your TFT version does, I believe there are exporters from Open Street Maps that might be cool to try out?
