Technical Topics > Software
Amalgamated DGPS Software
ChrisSmolinski:
DGPS stations transmit the difference between positions indicated by GPS satellite systems and the known fixed position of the station. This allows higher accuracy. DGPS transmissions are 100 or 200 baud and are transmitted on frequencies from 285 kHz to 325 kHz in the longwave band. Hundreds of these stations are operated by the Coast Guard and other agencies around the world, and they can be interesting DX targets. Each station transmits a continuous stream of messages containing correction data for GPS. These messages also contain the station ID code, so they can be used to directly ID the station.
Since SDRs are capable of recording a chunk of the RF spectrum directly to a disk file, I realized that a decoder could be written to demodulate all of the DGPS channels at the same time, at both baud rates. They write this data as a I/Q file, storing the complex representation of a portion of the RF spectrum. A 50 kHz bandwidth is slightly more than enough to cover the entire DGPS band. I set my SDR software up to record overnight, then in the morning I can run the recordings through the software, and see what stations are present.
The software sets up 82 SSB demodulators, two for each of the DGPS channels, one is for decoding 100 baud and the other for 200 baud, that allows me to use a more narrow filter for the 100 baud case. The output of each demodulator goes to a DGPS decoder that looks for valid messages. A message is considered valid if it starts with the correct preamble byte, is of message type 6 or 9 (the most common sent), has a z-count (which is a time code offset from the hour) that is within a few seconds of what it should be, and passes the 6 bit parity word test. This eliminates the vast majority of bad message decodes, although every so often one will sneak through. This is because you can get multiple bit errors on a message that corrupt both the data and parity word in such a way that the parity check still passes. It is still necessary to visually inspect the decodes, and decide if a seemingly amazing DX catch is realistic, or more likely just a bad decode.
Below is a screenshot showing the output of approximately 24 hours of recordings of the DGPS band.
The columns containing the following information:
• Count: the number of decodes of this station.
• ID: ID number of the station, stations transmit either the ID or one of the reference IDs.
• RefID1: The first reference ID of the station.
• RefID2: The second reference ID of the station.
• kHz: Frequency.
• Baud: The baud rate, 100 or 200.
• City: Station Location.
• Country: Station Location.
• Lat: Station latitude.
• Lon: Station longitude.
• km: The distance to the station from your location.
• deg: The bearing to the station from your location.
Most likely the Wiarton and Angleton decodes are corrupted messages, as the frequencies they use are both dominated by strong semi local signals.
Another way to look at the decoded data is with this graph, that shows the times that messages were received from each station
You can see the various times stations were decoded. There are cases where a single decode was received (just a thin line), which was possibly a garbled message. But there are also cases for DX stations where several messages in a row were received (a thicker line). It is quite improbable that many messages were garbled in a row, with exactly the necessary bit errors to change the ID of the station, but also preserve the parity word check.
It is interesting to observe how two stations on a given frequency will alternate reception, as one fades out and the other fades in.
A very preliminary beta version of this program, Amalgamated DGPS, is available for download for those who wish to try it. It is only for Mac OS X, and requires I/Q recording files made in either the RF Space or Perseus format (and note that I have only tested with the former, the latter should work, but you never know). While there is no Windows version available at present, I may have one available shortly, so stay tuned!
http://www.blackcatsystems.com/software/dgps_decoding_software_sdr.html
Also another article about this software here: http://www.radiohobbyist.org/blog/?p=1907
ChrisSmolinski:
I've updated this app with a new version, 0.2.0, which adds a bunch of features, including the ability to decode from regular WAVE audio files, if you do not have an SDR. The app can decode from multiple DGPS channels in the same WAVE file, as many as fit in the bandwidth. So if, for example, your radio is tuned to 300 kHz USB with a bandwidth of 6 kHz, then 301 to 305 kHz fit inside and will be decoded. You could of course tune to say 299.5 kHz and squeeze in another channel. Or make the bandwidth wider. Or both!
The graph window now shows a red graph at the top, which indicates the total number of messages per minute being decoded. It can be handy as a rough guide as to how well band conditions are.
I have also added support for a few other formats of SDR recordings, Studio1, ELAD, and Sdr-Radio, in addition to SdrDx / RF Space and Perseus formats. Note that I do not have all of these programs, so testing was done with files provided by others. I think it is all working correctly, but you never know.
It is still Mac only, but the changes to this version (which is close to a complete re-write) move me closer to being able to release a Windows version. It can be downloaded here http://www.blackcatsystems.com/software/dgps_decoding_software_sdr.html
ChrisSmolinski:
Version 0.3.0 for Mac OS X has been released. This version adds live decoding from an audio input. It also adds a window of UNID stations (those that were received but the ID does not match any known ID/frequency/baud rate combinations). There's also the usual bug fixes.
Live decoding of audio was the last major feature that needs to be added. So now the task of making a Windows version can begin.
Version 0.3.0 can be downloaded here http://www.blackcatsystems.com/software/dgps_decoding_software_sdr.html
redhat:
So is the software smart enough to triangulate your receive location based on receive timing, et al, or do you tell it where you are?
+-RH
ChrisSmolinski:
--- Quote from: redhat on September 17, 2016, 0520 UTC ---So is the software smart enough to triangulate your receive location based on receive timing, et al, or do you tell it where you are?
+-RH
--- End quote ---
You have to tell it where you are located. I'm not sure that the transmissions are synchronized to UTC time, allowing for triangulation based on the time delay.
Navigation
[0] Message Index
[#] Next page
Go to full version