NOAA ARGOS TX

Problem statement

I need to find a transmitter that I know is in a certain locale for validating the PROJECT DESERT TORTOISE a subset of the NOAA_POES_TIP_Demodulation DCS-2 Doppler shift models. I also want to figure out the time base encoding contained inside of the DCS packets, which I assumed were 100ms but the numbers aren't quite adding up. Also, who doesn't want to decode a new and exciting signal?!

To be useful, we need to decode the bits of the transmitter to find the 4-byte ID that we will use to find the data in the satellite downlink data.

ARGOS Description

ARGOS transmitters are environmental monitors that uplink data to the NOAA POES spacecraft. They broadcast preserved carrier manchester encoded BPSK on 401.650Mhz. The bitrate is 400bps and the symbol rate is 800bps and the payload is up to 48 bytes. The repetition rate is around a minute, but can be more or less. Their location is calculated by using the recorded doppler shifts, and the orbit of the satellite. This is often a lower power alternative to GPS, though they could transmit GPS coordinates as their payload as well. Ocean sensors, floats, wave height monitors, arctic sea ice monitors, and wildlife tracking collars are some examples.

Local Transmitter

I wasn't able to hear anything using a vertically polarized 2m whip antenna, but my cross polarized turn-style antenna (most likely due to the filtering effect of the phasing and matching lines) was able to hear a single ARGOS transmitter within range, with a repetition rate of 50 seconds. Since I know that this transmitter must be somewhere in the Phoenix, AZ area, it is a good model transmitter to use when validating doppler shift models.

Decoding

I wrote a quick GNUradio script, which isn't perfect (the PLL won't lock to the carrier with such short bursts, for example), but it does spit out mostly synchronized bits -- enough to put through a bit slicer.

Bit slicing reveals the following, which is still manchester coded:
000110111111101110000011111110001000000011101010110101010100100100101101010110001001001000101010101010101010101010101010101010101010101010101010101010101

Since 10 is a 1 and 01 is a 0, and two 1's or 0's in a row mark a bit boundary, we can either manually... or we could re-use some code from the downlink decoder that already used this encoding ;) File:DecodeBitsyncedArgosData.m

Our script will spit out the following, which is grouped into chunks that look right but are just guesses:
0000000 00000001 11010000 11110000 01001100 01010010 11111111 11111111 11111111 11111111

Which could also be the inverse, since we don't really know what the sync word is and have no way to judge polarity.
1111111 11111110 00101111 00001111 10110011 10101101 00000000 00000000 00000000 00000000

What is ID? what is sync word? What is payload? There are many ways to find out, but the best way I could think of was to search for three bytes at a time within the satellite downlink data, since it should contain the ID and the payload.

Bingo. '11111011001110101101000000000000' match found (ID 165 in dataset 8; ID 50,257,378 in dataset 5)
ID 50 from NOAA-18 recording: 22.8853 D6 01 0B E3 C8 08 FB 3A D0 00 00 00 00 81 96 18 (first 6 and last 3 bytes added by the spacecraft)

Using the satellite data to frame our packet, we can now conclusively say that this transmitter is transmitting the following bits.

11111111 11100010 11110000 - 11111011 00111010 11010000 00000000 00000000 00000000 0000
Preamble   Sync     Sync        ID       ID      ID        ID      Data     Data   Data

Which decodes to
Preamble: String of ~16 0x0 or 0xF
Sync Word: E2 F0 TXID: FB 3A D0 00
Data: 00 00 0

Conclusions

This TXID shows up in nearly every data set that I have, and appears to be a strong transmitter. It should be a good data verification source! The TXID appears to transmit nothing at all, which could mean it is simply meant to be tracked and really doesn't contain any data payload, or there could be events that trigger status words to appear (low battery, etc) though I have yet to observe this behavior.

Results of Doppler Match

Results are shown below, the plotted points represent the solutions from two passes 20 minutes apart (NOAA15 and NOAA18). The distantly spaced models uses the 3 DOF model which assume a doppler scaling of 1.0 (just trust the raw frequency data) whereas the more closely spaced data uses the 4 DOF model that solves for slight calibration errors of the spacecraft. Both models solve for frequency offsets of the transmitter.

Todo

• DONE!! Figure out the location of this transmitter using radio direction finding techniques while being respectful of the science and careful not to invade on private property (this includes the transmitter as well as its surroundings) in order to get more exact tuning of the doppler shift geolocation model.
• DONE!! Run the doppler model and plot the results.
• Finish https://github.com/nebarnix/Project-Desert-Tortoise SO THE WORLD CAN JOIN IN THE FUN