Amalgamated DGPS decodes the entire DGPS band (285-325 kHz) from SDR recordings. This posting is a collection of tips and suggestions for using it. If you have suggestions/questions feel free to post them as a reply to this message. In order to keep them tidy, replies may be deleted after they have been acted on.
Program page and download links:
http://www.blackcatsystems.com/software/dgps_decoding_software_sdr.htmlThe program page also contains instructions for using it. Please read them
While the program can decode live audio, the main purpose is to decode the entire band at once, so as to not miss any brief openings.
Note that not all makes/models of SDRs/software are supported! Check the page to see which ones are. You may need to experiment with the settings of your SDR program to produce files that can be processed. I do not have every SDR/program in the universe. If yours is not listed, and you can provide me with (1) sample I/Q recording files and (2) information about the format of the files, I can try to add support. Or better yet, give me one of those SDRs
The general workflow is to set your SDR software to record overnight, I like to start an hour or two before local sunset, and run an hour or two past sunrise. You can obviously run all day if you wish.
Set your SDR to record as close to the entire band as possible, it is only 40 kHz wide, so a 50 kHz bandwidth is ideal, centered at 305 kHz. Don't record wider than necessary, that creates larger files that take longer to process.
SDR programs generally let you specify the maximum recording file length, I find 1 GB works nicely. They will continuously record up to that limit, then start a new file when the limit is reached. So over the course of the night, you will get several files.
You have two options for processing. You can wait until you are done recording and then process all your files at once. Or you can process files as they finish. While you can do that manually, Amalgamated DGPS has an option to monitor a directory on your computer. When it sees a new file appear, it watches the length. Once a certain amount of time has passed without the length changing, it assumes the file is done, and begins to process it. To do this:
1) Choose "Select I/Q File Directory" from the File menu. Pick the directory your SDR recording files are written to. This only needs to be done once, the program will remember it.
2) Start your SDR software and start recording I/Q files.
3) Choose "Monitor I/Q File Directory" from the File menu. Amalgamated DGPS will ask you to specify the file that saved decodes will be written to.
Don't store this file in the same directory as your I/Q Files!Amalgamated DGPS will now monitor this directory, looking for new files. When they are finished, it will process them, when it is done processing each file, it will save the decodes. That way you don't lose them if it crashes.
There is an option in the Preferences called File Wait Time. It is the number of seconds that the length of a file must not change for it to be considered finished. I set it to 12 seconds, you may need a longer time period, especially if you are using a network drive for I/Q files.
As the program runs, it will continuously update the list of received stations, showing how many messages from each, how far away each is, etc. You can double click on a station to get another window, showing the received timestamps for that station. This can be useful, see below.
Amalgamated DGPS Preferences:There's several other things in the preferences you should set, or think about setting. I am not going to discuss all of them here, as some are, or should be, obvious.
Your location. Remember, north latitudes are positive, south are negative. East longitudes are positive, west are negative.
Max zCount Error: DGPS messages have a zCount, which is a truncated number of seconds past the hour. Amalgamated DGPS uses this is a check for corrupted messages. Due to computer clocks being slightly off, processing delays, etc. it will never be exactly correct. So a certain error is allowed. You can change this. I find 10 seconds works well. You could try smaller numbers, at the risk of maybe losing some decodes. You can experiment, keep reducing the number until your decode rate drops, then raise it a little as a safety factor.
zCount Offset: The zCount time is UTC time, which does not have leap seconds. So there is always a difference - that is the value of this field. It is currently 24. It will become 25 the next time there is a UTC leap second.
Check 0.5 kHz channels if you want the program to check them for transmissions. This doubles the processing time of a file. If you live Europe you must check it, or you will miss half the stations. If you live in the USA and want to catch DX from Europe, check it. Teh only reason not to check it is if you don't want to possibly catch some great DX. But then why are you a DXer?
The Just message types 6 and 9 box tells the program to only look for these types of DGPS messages. They account for the vast majority of messages transmitted. You can leave it unchecked, but might get more false decodes.
The Step Fields: These are used to tell Amalgamated DGPS to try making slight adjustments to the tuned frequency, in case the station, or more likely your SDR, is slightly off frequency. As each file is processed, the tuned frequency is adjusted. First with an offset at the minus step limit, then incremented by the step size, up to the plus limit. An example may help illustrate:
I use values of -10 to 10 Hz in 2 Hz steps. That means that each file is processed first with the tuned frequency set 10 Hz low (-10 Hz). Then -8 Hz, -6 Hz... all the way to +10 Hz. So a total of 11 difference tuned frequencies (-10, -8, -6, -4, -2, 0, 2, 4, 6, 8, 10). Experimentation has shown that this helps detect very weak signals that may be slightly off frequency. At the expense of taking longer to process. You can start by leaving all the fields zeros, and nothing special will be done. Then if you want experiment with values. I like to have a "test I/Q file" for this. A file with a known brief appearance of a tough to catch DX target at a certain time in the file. See if you can produce additional decodes at nearby times. Again, you can just leave these values at the default if you do not want to use this feature.
Note: The Windows version has a bug with the step feature that can cause duplicate decodes! This is being fixed now.
Why do I get so many obviously bogus decodes???This is a common question by new users. Why do I see decodes from Japan or China, 10,000+ km away, at noon, when it is impossible to get reception. Obviously the program is broken! No, it's not.
Let me start with explaining how Amalgamated DGPS works. Each I/Q recording file is demodulated many times, once for each DGPS channel. Just as though you had your radio tuned in SSB mode. It looks for valid DGPS messages, that is, messages with the correct header, data, and a valid checkum. The message data contains the ID of the station sending it. When it gets what appears to be a valid message, the station ID is checked against a table of known DGPS stations. If there is a station on that frequency, at that baud rate (100 or 200 baud) sending that ID, and the zCount is within the allowed error, and it is the right message type, it is counted as a valid decode and added to the display list. There's actually three possible IDs for each station, the station ID, and one of two reference IDs. I do not think there is any agreement as to which is sent, so the software checks against all three. If one matches, it passes.
Unfortunately, the checksum algorithm used is far from perfect. It is possible to get several bit errors, and still pass the checksum test. You might also still pass the zCount error check. If you zap enough bits, it might appear to be from another station on that frequency.
Now, this processing is being done very often. How often? Well, it varies with several factors like the sample rate, but more than 6,000 times per second. Per channel being monitored. With all the channels and baud rates, there are 164 virtual channels. So the program is, in total, looking for a valid message about one million times per second. Over the course of a 12 hour recording session, about 42 billion times. That is why even though the chances of just the right bit errors to produce a message from another station are extremely low, it is still bound to happen a few times. It's like buying 42 billion lottery tickets. Some of them will be winners.
This means that it is necessary to critically look at some of decodes. If you have thousands or even hundreds of decodes from a station, it is probably valid - with one exception. There are some cases where two DGPS stations on the same channel use the same ID. That means that Amalgamated DGPS has no way of knowing which station is being received. For example, Okha India and Wisconsin Point WI. You need to decide for yourself which station was being received, and ignore the other.
What about when you have 5 or 10 decodes? Is it valid? Again... it depends. This is where I like to double click on the station to get the timestamps. If they are at impossible times, or scattered all over, they are probably not valid. Especially if you have a strong DGPS station on the same frequency.
Here are some supposed decodes from Egypt:
Tuesday, February 13, 2018 23:09:06
Wednesday, February 14, 2018 03:08:14
Wednesday, February 14, 2018 05:14:54
Wednesday, February 14, 2018 05:21:04
Wednesday, February 14, 2018 05:38:09
Wednesday, February 14, 2018 07:36:26
Wednesday, February 14, 2018 07:44:02
I do not consider them valid. It's daylight in Egypt when all but the first two are received here.
Here's some from Wales:
Tuesday, February 13, 2018 05:17:27
Tuesday, February 13, 2018 05:20:17
Tuesday, February 13, 2018 05:20:25
Tuesday, February 13, 2018 05:20:31
Tuesday, February 13, 2018 05:20:59
Tuesday, February 13, 2018 05:22:59
Tuesday, February 13, 2018 05:23:07
Tuesday, February 13, 2018 05:23:45
Notice how they are closely spaced in time. I think these are valid. There was a brief opening, as is common on the DGPS band.
Here's a station from England:
Tuesday, February 13, 2018 04:15:15
Tuesday, February 13, 2018 04:15:26
Tuesday, February 13, 2018 04:15:50
It's a good DX catch for me, 5,748 km away. Only three decodes. But in the span of less than a minute. Again, one of those very brief openings. I think it's real. Again, it is a judgement call on your part as to which decodes to accept or reject. Consider their spacing in time, and propagation. Is the catch
possible? Are other stations from the same area being received at about the same time? If so, there's a better chance it is real. What are overall propagation conditions like? As I write this, we have had several nights of exceptional, amazing conditions. While normally I don't get more than one station from Europe, last night I had dozen. That makes me believe more of the decodes, especially considering the other factors.
Several of us post our DGPS decodes here each day. Feel free to join us!
Topic: Tips for using Amalgamated DGPS (Read 5042 times)