Hi,
I’m building a device that occasionally transmits position data wirelessly to a remote location. Power conservation is paramount and the transmitter’s transmit buffer size is limited so I am using a microcontroller to scan the serial NMEA output of the GPS module and pick out only the GGA string to transmit to the receiving station.
My problem is that I cannot interpret the data that I am seeing on the serial port. To simplify things I have set the GPS to output only the RMC/RMB string. At the beginning of a string I should see the binary version of ASCII $ followed by two proprietary characters (probably GP) and then RM something,. For Example:
$GPRMC,
The constants in this part of the string should be $xxRMx,.
The binary representation of $ is 010 0100 (MSB on the left) but I can not find this in the begging of the string anywhere presuming highs are a 1s and lows are a 0s.
I am viewing the NMEA output on the scope and the beginning of the string looks like this:
Interpreting the highs and lows as 1s and zeros the beginning of the string looks like:
111011011010001110101111101010110110101010100110101101
11101011100101101011111010111001...
I cannot find a match for the characters by inverting the 1s and 0s either or if I try LSB first or MSB first. I have also looked for the R around where the third character should be in the string with no luck.
My theory now is that I am miss-interpreting how a serial port encodes 1s and 0s.
Any suggestions?
Thanks in advance,
L6E
I’m building a device that occasionally transmits position data wirelessly to a remote location. Power conservation is paramount and the transmitter’s transmit buffer size is limited so I am using a microcontroller to scan the serial NMEA output of the GPS module and pick out only the GGA string to transmit to the receiving station.
My problem is that I cannot interpret the data that I am seeing on the serial port. To simplify things I have set the GPS to output only the RMC/RMB string. At the beginning of a string I should see the binary version of ASCII $ followed by two proprietary characters (probably GP) and then RM something,. For Example:
$GPRMC,
The constants in this part of the string should be $xxRMx,.
The binary representation of $ is 010 0100 (MSB on the left) but I can not find this in the begging of the string anywhere presuming highs are a 1s and lows are a 0s.
I am viewing the NMEA output on the scope and the beginning of the string looks like this:
Interpreting the highs and lows as 1s and zeros the beginning of the string looks like:
111011011010001110101111101010110110101010100110101101
11101011100101101011111010111001...
I cannot find a match for the characters by inverting the 1s and 0s either or if I try LSB first or MSB first. I have also looked for the R around where the third character should be in the string with no luck.
My theory now is that I am miss-interpreting how a serial port encodes 1s and 0s.
Any suggestions?
Thanks in advance,
L6E
Have you verified, with an ASCII capture program on a computer, exactly what the GPS module is outputing? Something as simple as HyperTerminal (on a Windows system) would allow you to see and capture exactly what's coming out of the GPS module.
There are also a number of GPS utilities that will capture the NMEA sentences for you to see. But they don't do a raw capture. Using something like HyperTerminal will let you see all the characters on the serial port, not just the NMEA sentences.
...ken...
There are also a number of GPS utilities that will capture the NMEA sentences for you to see. But they don't do a raw capture. Using something like HyperTerminal will let you see all the characters on the serial port, not just the NMEA sentences.
...ken...
Hi Ken, thanks for responding. Yes, I've ported the NMEA from this GPS directly into Streets and Trips and it runs just fine so the data is valid. This is why I think it is the way I'm trying interpret the serial data.
Problem solved!! The ASCII characters are represented by 8 bit bytes but they each have a 0 start bit in front and a 1 stop bit behind making them a 10 bit word. Everything matches up now. FYI the words are output LSB first.
That only took 4 hours.
Oh well, at least I found Laptop GPS World in the process!
Cheers,
L6E
That only took 4 hours.
Oh well, at least I found Laptop GPS World in the process!
Cheers,
L6E
Hi L6E,
I'm glad you got it figured out.
Just for future reference, checking the data with Streets&Trips or any other navigation program would be as useless for your purposes as using one of the many utilities that capture the NMEA sentences. In all of those cases the only thing you learn is that the NMEA sentences themselves are valid. It's not a bad place to start, just as a quick sanity check to ensure the GPS module is functioning correctly. But it doesn't tell you nearly enough to work at the level you are.
In order to determine exactly what is coming out of the serial port (at a character data level), you need to capture all the characters because there may be other characters in the data stream that act similar to the start/stop bits in the ASCII bit stream. The only way to determine this is to do a raw capture of the entire data stream to see what else is in it. .... Very much like using the scope to examine the serial data at the electrical level and discovering that there are control bits embedded in there.
I apologize that I did not mention start/stop bits to you. I assumed - based on the approach you are taking - that you already knew the construction of an ASCII character. Just for future reference, there are a number of possible combinations, depending on what the serial port is set to.
You have encountered the most common serial port setting: 8-n-1. That's eight data bits, no parity and one stop bit (there is always a start bit) for a total of ten bits or, more correctly, ten Baud times.
There are quite a few other possible combinations. You can have odd or even parity, or none. You can have either seven or eight data bits. You can have one or more stop "bits".
The stop bit really isn't a bit at all. It's a stop period, e.g. a period of time that can be arbitrarily long but cannot be shorter than a specified amount, usually one or two bit times. As an aside, this is how asynchronous communication lines stay "synced". The receiver is able to stop capturing bits when it reaches the first stop period and simply wait until it sees the next start bit come along. The amount of time it waits for the next start bit is irrelevant ... the beauty of asynch communications. As long as the sender honours the minimum stop period they negotiated when setting up the line, it's virtually impossible to get out of synch. The receiver simply re-syncs on the next start bit.
So, you could have encountered 7-E-2, or seven data bits, even parity and two stop bits (minimum of two bit times before the next start bit). Or a variety of other combinations.
All of this - the number of data and framing bits, the parity, the "endianness" (order of the data bits, starting with LSB or MSB) )and the transmission speed (Baud) of the line must be pre-agreed by the communicating parties (e.g. the GPS module and the computer's serial port). It's all defined in excruciating detail in the EIA RS-232 spec. It's a great read if you are having difficulty getting to sleep.
...ken...
I'm glad you got it figured out.
Just for future reference, checking the data with Streets&Trips or any other navigation program would be as useless for your purposes as using one of the many utilities that capture the NMEA sentences. In all of those cases the only thing you learn is that the NMEA sentences themselves are valid. It's not a bad place to start, just as a quick sanity check to ensure the GPS module is functioning correctly. But it doesn't tell you nearly enough to work at the level you are.
In order to determine exactly what is coming out of the serial port (at a character data level), you need to capture all the characters because there may be other characters in the data stream that act similar to the start/stop bits in the ASCII bit stream. The only way to determine this is to do a raw capture of the entire data stream to see what else is in it. .... Very much like using the scope to examine the serial data at the electrical level and discovering that there are control bits embedded in there.
I apologize that I did not mention start/stop bits to you. I assumed - based on the approach you are taking - that you already knew the construction of an ASCII character. Just for future reference, there are a number of possible combinations, depending on what the serial port is set to.
You have encountered the most common serial port setting: 8-n-1. That's eight data bits, no parity and one stop bit (there is always a start bit) for a total of ten bits or, more correctly, ten Baud times.
There are quite a few other possible combinations. You can have odd or even parity, or none. You can have either seven or eight data bits. You can have one or more stop "bits".
The stop bit really isn't a bit at all. It's a stop period, e.g. a period of time that can be arbitrarily long but cannot be shorter than a specified amount, usually one or two bit times. As an aside, this is how asynchronous communication lines stay "synced". The receiver is able to stop capturing bits when it reaches the first stop period and simply wait until it sees the next start bit come along. The amount of time it waits for the next start bit is irrelevant ... the beauty of asynch communications. As long as the sender honours the minimum stop period they negotiated when setting up the line, it's virtually impossible to get out of synch. The receiver simply re-syncs on the next start bit.
So, you could have encountered 7-E-2, or seven data bits, even parity and two stop bits (minimum of two bit times before the next start bit). Or a variety of other combinations.
All of this - the number of data and framing bits, the parity, the "endianness" (order of the data bits, starting with LSB or MSB) )and the transmission speed (Baud) of the line must be pre-agreed by the communicating parties (e.g. the GPS module and the computer's serial port). It's all defined in excruciating detail in the EIA RS-232 spec. It's a great read if you are having difficulty getting to sleep.
...ken...
Thanks for the additional information Ken. Will probably be diving into EIA RS-232 since I have quite a bit more interfacing stages to do with this project. GPS to PIC, PIC to burst transmitter, burst receiver to PIC, PIC to laptop with Streets and Trips installed. So far I have GPS to oscilloscope nailed!
Cheers,
L6E
Cheers,
L6E
If you need to get into RS232 some more, you might also want to take a quick peek at EIA 422.
Any hints you can share with us about what you're trying to accomplish?
...ken...
Any hints you can share with us about what you're trying to accomplish?
...ken...
Knowing that there are other formats available from a COM port may just confuse the issue. As far as I know, changing the COM port settings makes no difference whatsoever to the data format received from the GPS. It will be 8N1 regardless of what you set the port for.
Terry
Terry
He's hacking that stuff, Terry. He's working with a GPS "module", not necessarily a GPS. At the level he's working he may have the ability to change the setting on the GPS module. If he's not aware that there are other possibilities in the serial settings he's going to have the very devil of a time trying to troubleshoot the problem if he ever accidentally changes the serial settings on the GPS module, just as he was left scratching his head at what he was seeing on the scope before he learned about the start/stop bits.
If nothing else, he needs to understand it at that level to make sure he gets the PIC programmed properly and can troubleshoot if he doesn't. An example is the stop "bit". When programming the transmit side of a serial port function it's critical to understand that the stop "bit" really is not a bit but a time period that has to equal or exceed whatever the receiver is expecting. And when programming the receive side it's useful to understand that the time - in Bauds or bit periods - between characters isn't relevant. You just resync on the start bit.
I just figured it's easiest to let him know about other possibilities and where to find the details. He can decide how much he needs to know about them as he proceeds.
...ken...
If nothing else, he needs to understand it at that level to make sure he gets the PIC programmed properly and can troubleshoot if he doesn't. An example is the stop "bit". When programming the transmit side of a serial port function it's critical to understand that the stop "bit" really is not a bit but a time period that has to equal or exceed whatever the receiver is expecting. And when programming the receive side it's useful to understand that the time - in Bauds or bit periods - between characters isn't relevant. You just resync on the start bit.
I just figured it's easiest to let him know about other possibilities and where to find the details. He can decide how much he needs to know about them as he proceeds.
...ken...
Hi Ken, no problem. Its a tracking collar design for watching the progress of deer fawns after they are released by a wildlife rescue organization.
The collars sport an electronic release that can be activated remotely or will release automatically after 3 weeks. The collar wakes up for 2 hours every day to get a new position fix and to listen for a position request and other commands.
The idea is that if the fawn is moving around for 3 weeks then we know the herd that it was adopted out to is nursing it.
The challenge is that the fawns can weigh as little as 8 pounds so the collar has to be very small.
There is no cellular coverage in the area so for communication I am implementing Laird 4790 transceivers.
The collars sport an electronic release that can be activated remotely or will release automatically after 3 weeks. The collar wakes up for 2 hours every day to get a new position fix and to listen for a position request and other commands.
The idea is that if the fawn is moving around for 3 weeks then we know the herd that it was adopted out to is nursing it.
The challenge is that the fawns can weigh as little as 8 pounds so the collar has to be very small.
There is no cellular coverage in the area so for communication I am implementing Laird 4790 transceivers.
That's an interesting application. You should consider commercializing it and selling it through Toys 'R Us. My wife would buy a couple for our twenty-month old twin grandsons.
...ken...
...ken...