TDOA with Iridium Signals? A first rough test shows unexpected results using iridium-extractor. #211
Comments
|
That sounds unexpected to me. We will have to do some more investigation to give a better answer. |
|
I noticed during the your talk (with Schneider) at CCC (https://media.ccc.de/v/38c3-investigating-the-iridium-satellite-network) you mentioned that the USRP seems to not timestamp packets accurately and there's a delay. I've never noticed this in my work with USRP B200s and 300 series devices. But if there's a delay and it's not consistent, this could be an issue. I'm going to do some more measurements today to make sure that the timing between the devices is identical (again with a common external GPS-locked 10Mhz and PPS feeding both of my USRPs.)
If there's some test you want me to run, let me know!
|
|
The delay we mentioned in the talk should be deterministic (dependent on sample rate). The delay should be similar to what is known for the N210: http://ianbuckley.net/N210-rx-dsp-delay.txt I am not an expert on this, but I suspect, running a test with a generated reference signal into a splitter with two usrp's could test this issue. |
|
Honestly an average of ~300 ns is not bad. We only determine the timestamp based on 12 symbols from the unique word and each symbol of these is 40 us long. I believe we'd need to correlate against more symbols to get more accurate. That certainly is doable with reasonable effort. So far we simply were not in a position where this made sense. TDOAing transmitters obviously would be an application of course. |
|
Thank you very much for your answers. We ran a test with my own 1GHz signal generated in the lab, and time measurements on a pair of USRPs from the same antenna (split) on the same 10MHz clock and PPS sent through distribution amps. Timing was within 1 sample between them, but I didn't measure if there was a delay between when the signal should have been received at the antenna and the timing of the signal pulse via the rx_time data and sample counting. Based on your comments I will try to simply dump a longer sample at key burst-detection times and cross-corellate between the two devices. I have another question: I presume, with my Tallisman Iridium antenna sitting on our roof....
....that we're receiving multiple satellites simutaneously in the pager part of the band (where the new proprietary timing data is, too?) but in the "voice and data" area, we are only going to be receiving from whatever satellite's spotbeam is beaming down to us at any one time. Is that correct? Also, do you know what the extent of the spot beams are? (How much area do they cover). If we were to do practical TDOA using these signals as "Signals of Opportunity" (and not decoding any of the proprietary data), I'd presume we'd have to look only at the "pager" part so we can get multiple receivers in multiple locations looking at the same satellites because we're not going to be able to see multiple satellites in voice/data band at same time, and the range of the voice/data band is limited to the size of the "spot" |
I wanted to see if you can do TDOA with Iridium signals using iridium-extractor.
I noticed in the source code if you're using a USRP with a PPS clock, iridium-extractor will use the rx_time + samples to make the time based on a calculation from sample count. I figured this would give consistent timing of a received burst.
So I set up a quick experiment: I took two genuine Ettus B-200s, both driven off the same GPSDO 10Mhz and PPS., with the timing signals split from a proper 10 MHz distribution amp, etc. There's a Tallisman Iridium antenna on the roof of our building and we split the signals with a proper splitter to both of the USRP B200s.
I have two computers with the exact same versions of everything running iridium-extractor. I wrote a script to compare the "time" field in the third field from each of the captures in the RAW: file, only looking at "100%" decodes. I expected to see identical times on each of them. (I'm also ignoring "179" length decodes, and making sure all the bits match, too, before comparing the time.)
Here's the end of a recent run. As you can see it's not a conisitant lag, and sometimes packets are ahead and behind, ranging from 100 microseconds to 1000 microseconds. The average time difference at the end of this run was 296 microseconds (0.000296 seconds).
Any ideas as to what's happening? I was hoping these would line up, and then I'd move on to doing sub-sample timing but I need to get the gross time measurements to be much closer/consistent before I can hope to get reliable results with separate receivers in separate locations.
You'll notice in the numbers below that they are a full second + change apart. This is because iridium-extractor will start on the next PPS, so if I don't start the software at the same time, they will be some integral number of seconds apart. So I subracted out the difference related to different start time of the run before comparing received burst times.
[...]
The text was updated successfully, but these errors were encountered: