Adding demodulator for ARGOS 4 PTT-VLD-A4 (A4-SS-TER-SP-0079-CNES) #12
Conversation
There's no need to invert the data. FindSyncWords automatically checks for the sync word and its inverse.
|
Question: won't normalizing based on the whole file break audio or are you just doing that for recordings? It might also break the code if there are large interference spikes - you probably wouldn't want to attenuate your file based on some blips? |
|
Ah, yes, excellent point! Because I'm right next to the transmitter, the issue I had was that the "dead air" before the data packet was really quiet. I found that if I let the code calculate the normalization factor based on just the first chunk, then the data was massively over-amplified. But you're right - of course - spikes in the data would throw that off. I guess what is needed is something 'clever' that gets around both issues. Maybe some kind of "best n out of m rolling window" type of thing? |
|
Question: Do your updates break backwards support or does it augment existing ARGOS transmitters? |
| @@ -65,40 +65,40 @@ int FindSyncWords(unsigned char *bitStreamIn, double *bitStreamInTime, unsigned | |||
| byte = 0; | |||
| bitIdx = 0; | |||
| frameByteIdx++; | |||
| if(frameByteIdx > 8) | |||
| if(frameByteIdx > 24) | |||
There was a problem hiding this comment.
Remind me what this change does ?
There was a problem hiding this comment.
Ah, yes. It took me a while to find where the longer ARGOS 4 VLD Long messages were being truncated - and its there. That change just lets 24 bytes of data through instead of 8. Actually I think we only need 18 bytes, not 24. It might be nice to add the expected message length as an arg?
There was a problem hiding this comment.
yeah, good call. The best way would be to detect the end of the packet.... not so easy though!!
Is there a payload length byte we could read in to make a guess on??
There was a problem hiding this comment.
Yes, indeed:
The sync is 24 bits: 0xAC5353
The two bits after that define the length. If they are 0b00 then the total number of encoded data bits after that is 68. If the two length bits are 0b11 then 3*68 encoded data bits follow.
Note: this is only true for ARGOS 4 VLD. The other PTT formats use quite different length fields.
There was a problem hiding this comment.
Ah, but... The encoding process reduces the 68 bits down to 45. So, the true answer, in terms of how many bits to process, is:
- 0b00 indicates that 45 bits follow
- 0b11 indicates that 3*45 bits follow
| - In the Recording settings: | ||
| - Select Audio | ||
| - Deselect Baseband (the sample rate is _really_ high!) | ||
| - Run the program and enjoy your bits =3 |
There is a normalizing AGC already after the PLL in the loop (the PLL doesn't care about amplitude anyway, just phase), it should take care of what you are talking about, but could be changed to attack faster? NormalizingAGC(dataStreamReal, nSamples, normFactor, DSP_AGC_ATCK_RATE*(2.0M_PI/Fs), DSP_AGC_DCY_RATE(2.0*M_PI/Fs)); BTW the max gain is set to 5000 in the function, but there is NO minimum gain (below 1 is attenuation for signals above 1) |
Hi Jasper,
I just wanted to say a big thank you for sharing Project Desert Tortoise. I've been using it to decode data from a new ARGOS beacon I'm developing.
By way of thanks, this PR adds support for ARGOS 4 PTT-VLD-A4 (A4-SS-TER-SP-0079-CNES). The Very Low Data rate (200bps) and encoding scheme allows a gain of 5 to 6 dB compared to previous ARGOS beacons (PMT/PTT-A2 and PTT/PMT-A3).
The ARGOS4VLDdemod folder includes a wav file of a packet captured using SDR# and a cheap 820T2 SDR dongle.
Thanks again and very best wishes,
Paul