Oh! Of course. Yes, that's why I wanted to see the complete output --
timestamps are not kept in the saved samples. You'll only get timestamps if
you are viewing live data.
--n
On Wed, Jan 29, 2014 at 2:24 AM, Cheng Chi <ch000...@e.ntu.edu.sg> wrote:
> Hi Nick,
>
> Thanks for your explanation :)
>
> Today I have collected some data using the same setup, USRP N210 with
> GPSDO + WBX. The collection is done at the rooftop with open sky.
> Gain: 20
> Sampling Rate: 10M
> Center Frequency: 1090M
> Data format: complex float (Use GNUradio Companion for collecting data. I
> think this should be the same as using uhd_rx_cfile?)
>
> As shown below, the decoded data seems correct, but the timestamp
> information is still quite strange. Is it because the modes_rx program
> can't timestamp packets for saved data? Do you have any suggestion about
> how to identify the Mode S packet from the raw data? (I've tried using the
> preamble to cross correlate with the received data, but no success so far.)
>
>
> command line:
> {{{
> modes_rx -s ADSB_10M_JAN29_float_4.dat -r 10000000
> }}}
>
> output:
> {{{
> (-55 0.00000000) Type 0 (short A-A surveillance) from 8a0301 at 2450ft
> (Vertical TCAS resolution only)
> (-52 0.00000000) Type 20 TCAS report from 76ce4e: (no handler for TTI=0)
> at 14200ft
> (-55 0.00000000) Type 0 (short A-A surveillance) from 8a0301 at 2450ft
> (Vertical TCAS resolution only)
> (-56 0.00000000) Type 0 (short A-A surveillance) from 76cf27 at 8600ft
> (Vertical TCAS resolution only)
> (-50 0.00000000) Type 17 BDS0,9-1 (track report) from 461eac with velocity
> 191kt heading 23 VS 64
> (-57 0.00000000) Type 17 BDS0,5 (position report) from 8a01ba at
> (0.985511, 103.824021) at 5375ft
> (-56 0.00000000) Type 20 TCAS report from 75029c: (no handler for TTI=0)
> at 38025ft
> (-54 0.00000000) Type 0 (short A-A surveillance) from 75029c at 38025ft
> (speed 300-600kt)
> (-60 0.00000000) Type 0 (short A-A surveillance) from abee7c at 7100ft
> (Vertical TCAS resolution only)
> (-46 0.00000000) Type 0 (short A-A surveillance) from 750279 at 9100ft
> (Vertical TCAS resolution only)
> (-58 0.00000000) Type 0 (short A-A surveillance) from 8a1f1a at 2400ft
> (Vertical TCAS resolution only)
> (-55 0.00000000) Type 0 (short A-A surveillance) from 8a03c2 at 8075ft
> (Vertical TCAS resolution only)
> (-45 0.00000000) Type 0 (short A-A surveillance) from ae075d at 1100ft
> (Vertical TCAS resolution only)
> (-50 0.00000000) Type 0 (short A-A surveillance) from 4b1906 at 10100ft
> (Vertical TCAS resolution only)
> (-54 0.00000000) Type 20 TCAS report from 76cd88: (no handler for TTI=0)
> at 4100ft
> (-51 0.00000000) Type 0 (short A-A surveillance) from 4b1906 at 10100ft
> (Vertical TCAS resolution only)
> (-44 0.00000000) Type 11 (all call reply) from 8a01ba in reply to
> interrogator 0 with capability level 6
> (-52 0.00000000) Type 17 BDS0,5 (position report) from 76ce4e at
> (1.148118, 104.249078) at 14225ft
> (-55 0.00000000) Type 20 TCAS report from 76cd88: (no handler for TTI=0)
> at 4100ft
> (-58 0.00000000) Type 0 (short A-A surveillance) from 8a0301 at 2450ft
> (Vertical TCAS resolution only)
> (-56 0.00000000) Type 0 (short A-A surveillance) from 732f06 at 3700ft
> (Vertical TCAS resolution only)
> (-51 0.00000000) Type 0 (short A-A surveillance) from 7501fd at 33000ft
> (Vertical TCAS resolution only)
> (-53 0.00000000) Type 0 (short A-A surveillance) from 76cd88 at 4100ft
> (Vertical TCAS resolution only)
> (-55 0.00000000) Type 21 link capability report from 76cd88: ACS: 0x10080,
> BCS: 0xf600, ECS: 0x0, continues 0 ident 9c
> (-51 0.00000000) Type 0 (short A-A surveillance) from 76ce4e at 14225ft
> (speed 300-600kt)
> (-45 0.00000000) Type 0 (short A-A surveillance) from ae075d at 1100ft
> (Vertical TCAS resolution only)
> (-56 0.00000000) Type 0 (short A-A surveillance) from 8a0301 at 2450ft
> (Vertical TCAS resolution only)
> (-57 0.00000000) Type 0 (short A-A surveillance) from 76cf27 at 8600ft
> (Vertical TCAS resolution only)
> (-54 0.00000000) Type 17 BDS0,5 (position report) from 76cd88 at
> (0.876299, 103.944397) at 4100ft
> (-52 0.00000000) Type 0 (short A-A surveillance) from 76ce4e at 14225ft
> (Vertical TCAS resolution only)
> (-50 0.00000000) Type 11 (all call reply) from 461eac in reply to
> interrogator 0 with capability level 6
> }}}
>
> Best regards,
> Cheng Chi
>
>
>
> On Tue, Jan 28, 2014 at 1:58 AM, Nick Foster <bistrom...@gmail.com> wrote:
>
>> Haven't used bladeRF, but I have used other LMS6002D-based radios with
>> gr-air-modes, with some success. The problem is Mode S has a weak CRC and
>> is thus vulnerable to spurious packets. That said, in practice spurious
>> replies should be under 1% of your total. Experiment with gain and
>> threshold settings -- your feedback should be nonunique ICAO numbers; in
>> other words you're looking for multiple replies from the same aircraft. The
>> "get_dupes.py" script in apps/ will take the output generated by
>> gr-air-modes and parse it to tell you how many actual aircraft you've heard.
>>
>> --n
>>
>>
>> On Mon, Jan 27, 2014 at 2:35 AM, Ralph A. Schmid, dk5ras <
>> ra...@schmid.xxx> wrote:
>>
>>> When having no clue about the data I should expect - how can I find out
>>> about the real data, and how can I see what is decoded noise? I am using
>>> the bladeRF, and to me most data looks wrong, too :)
>>>
>>>
>>>
>>> Ralph-
>>>
>>>
>>>
>>> *From:* discuss-gnuradio-bounces+ralph=schmid....@gnu.org [mailto:
>>> discuss-gnuradio-bounces+ralph=schmid....@gnu.org] *On Behalf Of *Nick
>>> Foster
>>> *Sent:* Monday, January 27, 2014 9:43 AM
>>> *To:* Cheng Chi
>>> *Cc:* GNURadio Discussion List
>>> *Subject:* Re: [Discuss-gnuradio] Help about using gr-air-modes
>>>
>>>
>>>
>>> The reason you're seeing lots of false packets is the use of a zero
>>> threshold. Leave the -T 0 part out of the command line. Your other settings
>>> are fine, although if you're indoors you probably aren't going to see much
>>> data at all.
>>>
>>>
>>>
>>> I'll look into the timestamp issue and see if I can replicate it here.
>>>
>>>
>>>
>>> --n
>>>
>>>
>>>
>>> On Mon, Jan 27, 2014 at 12:40 AM, Cheng Chi <ch000...@e.ntu.edu.sg>
>>> wrote:
>>>
>>> Hi Nick,
>>>
>>>
>>>
>>> The command line:
>>>
>>> {{{
>>>
>>> modes_rx -T 0 -r 10000000 -s packet_float.dat
>>>
>>> }}}
>>>
>>>
>>>
>>> The setup:
>>>
>>> USRP + WBX + VERT900 Antenna, gain is set at 19 when recording the data.
>>>
>>>
>>>
>>>
>>>
>>> The output:
>>>
>>> {{{
>>>
>>> usrp@ubuntu:~/gr-air-modes/apps$ modes_rx -T 0 -r 10000000 -s
>>> packet_float.dat
>>>
>>> Using file source packet_float.dat
>>>
>>> Rate is 10000000
>>>
>>> Using Volk machine: avx_32_mmx_orc
>>>
>>> (41 0.00000000) Type 0 (short A-A surveillance) from 8b11e3 at 43825ft
>>> (speed <75kt)
>>>
>>> (31 0.00000000) Type 0 (short A-A surveillance) from 76ce83 at 19000ft
>>> (Vertical TCAS resolution only)
>>>
>>> (38 0.00000000) Type 0 (short A-A surveillance) from 7805dd at 3025ft
>>> (Vertical TCAS resolution only)
>>>
>>> (26 0.00000000) Type 4 (short surveillance altitude reply) from 53dd8d
>>> at -1000ft (SPI)
>>>
>>> (25 0.00000000) No handler for message type 24 from d9a7dd
>>>
>>> (27 0.00000000) Type 0 (short A-A surveillance) from ee5e77 at 44475ft
>>> (Vertical TCAS resolution only)
>>>
>>> (26 0.00000000) Type 0 (short A-A surveillance) from e2683e at 33850ft
>>> (speed 1200-2400kt)
>>>
>>> (38 0.00000000) Type 0 (short A-A surveillance) from 7805dd at 3025ft
>>> (Vertical TCAS resolution only)
>>>
>>> (26 0.00000000) No handler for message type 24 from df163e
>>>
>>> (26 0.00000000) No handler for message type 24 from 4dd8f4
>>>
>>> (22 0.00000000) Type 0 (short A-A surveillance) from 3b8ec9 at 59100ft
>>> (speed 75-150kt)
>>>
>>> (26 0.00000000) Type 0 (short A-A surveillance) from 9f6f91 at 18450ft
>>> (speed 1200-2400kt)
>>>
>>> (28 0.00000000) No handler for message type 24 from c4b50b
>>>
>>> (31 0.00000000) Type 11 (all call reply) from 76ce83 in reply to
>>> interrogator 0 with capability level 6
>>>
>>> (31 0.00000000) Type 21 link capability report from 75008f: ACS:
>>> 0x10680, BCS: 0xf600, ECS: 0x0, continues 0 ident 564
>>>
>>> (23 0.00000000) No handler for message type 24 from 38f620
>>>
>>> (26 0.00000000) No handler for message type 24 from d7a547
>>>
>>> (29 0.00000000) Type 11 (all call reply) from 76aa6b in reply to
>>> interrogator 0 with capability level 6
>>>
>>> (26 0.00000000) Type 5 (short surveillance ident reply) from b49331 with
>>> ident 7150 (aircraft is on the ground)
>>>
>>> (29 0.00000000) Type 5 (short surveillance ident reply) from 8f6b6a with
>>> ident 7610 (SPI ALERT)
>>>
>>> (39 0.00000000) Type 4 (short surveillance altitude reply) from a69223
>>> at 32975ft (AIRBORNE ALERT)
>>>
>>> (25 0.00000000) Type 4 (short surveillance altitude reply) from acc9e9
>>> at 53700ft (aircraft is on the ground)
>>>
>>> (33 0.00000000) Type 0 (short A-A surveillance) from 8a01d4 at 18750ft
>>> (speed 300-600kt)
>>>
>>> (32 0.00000000) Type 0 (short A-A surveillance) from 8a01d4 at 18750ft
>>> (speed 300-600kt)
>>>
>>> (28 0.00000000) Type 0 (short A-A surveillance) from 601589 at 46725ft
>>> (TCAS resolution inhibited)
>>>
>>> (27 0.00000000) Type 5 (short surveillance ident reply) from 4ba262 with
>>> ident 2520 (SPI)
>>>
>>> (24 0.00000000) Type 21 link capability report from fba5fc: ACS:
>>> 0x250aa, BCS: 0xe638, ECS: 0xa2, continues 6 ident 68
>>>
>>> (25 0.00000000) Type 5 (short surveillance ident reply) from fbc939 with
>>> ident 3620 (SPI ALERT)
>>>
>>> (24 0.00000000) Type 0 (short A-A surveillance) from 7e5086 at 111200ft
>>> (speed 150-300kt)
>>>
>>> (24 0.00000000) No handler for message type 24 from 10b1ec
>>>
>>> (25 0.00000000) No handler for message type 24 from 1aba1c
>>>
>>> (24 0.00000000) Type 0 (short A-A surveillance) from 9d7554 at 10800ft
>>> (speed 2400-4800kt)
>>>
>>> (23 0.00000000) Type 5 (short surveillance ident reply) from 9da024 with
>>> ident 3540 (GROUND ALERT)
>>>
>>> (27 0.00000000) No handler for message type 24 from 9f8569
>>>
>>> (24 0.00000000) No handler for message type 24 from 5da41f
>>>
>>> (25 0.00000000) Type 0 (short A-A surveillance) from ae194c at 48875ft
>>> (speed 600-1200kt)
>>>
>>> (23 0.00000000) No handler for message type 24 from 11099d
>>>
>>> (30 0.00000000) Type 20 TCAS report from 76aa6b: (no handler for TTI=0)
>>> at 11450ft
>>>
>>> (23 0.00000000) No handler for message type 24 from b7a19e
>>>
>>> (28 0.00000000) Type 20 link capability report from ef7118: ACS:
>>> 0x55278, BCS: 0x954d, ECS: 0xb1, continues 14 at 51300ft
>>>
>>> (24 0.00000000) Type 0 (short A-A surveillance) from 7f4d04 at 13475ft
>>> (speed 75-150kt)
>>>
>>> (32 0.00000000) Type 17 BDS0,9-1 (track report) from 8a01d4 with
>>> velocity 406kt heading 150 VS 1984
>>>
>>> (28 0.00000000) Type 21 link capability report from 8992dc: ACS:
>>> 0x100c0, BCS: 0xe600, ECS: 0x0, continues 0 ident 9a0
>>>
>>> (37 0.00000000) Type 20 TCAS report from 7805dd: (no handler for TTI=0)
>>> at 3000ft
>>>
>>> (27 0.00000000) Type 0 (short A-A surveillance) from dc2ed9 at 45900ft
>>> (speed 600-1200kt)
>>>
>>> (23 0.00000000) Type 4 (short surveillance altitude reply) from 2443b0
>>> at 59800ft (GROUND ALERT)
>>>
>>> (24 0.00000000) Type 4 (short surveillance altitude reply) from 3b1fc3
>>> at 3200ft (SPI)
>>>
>>> (21 0.00000000) Type 21 link capability report from d5ca0e: ACS: 0xda21,
>>> BCS: 0xc923, ECS: 0xee, continues 8 ident 123e
>>>
>>> (22 0.00000000) Type 5 (short surveillance ident reply) from 5ad8b4 with
>>> ident 728 (GROUND ALERT)
>>>
>>> (37 0.00000000) Type 17 BDS0,9-1 (track report) from 7805dd with
>>> velocity 218kt heading 238 VS -1664
>>>
>>> }}}
>>>
>>>
>>>
>>> Best regards,
>>>
>>> Cheng Chi
>>>
>>>
>>>
>>> On Mon, Jan 27, 2014 at 4:28 PM, Nick Foster <bistrom...@gmail.com>
>>> wrote:
>>>
>>> On Mon, Jan 27, 2014 at 12:23 AM, Cheng Chi <ch000...@e.ntu.edu.sg>
>>> wrote:
>>>
>>> Hi Nick,
>>>
>>>
>>>
>>> Thanks for your quick reply!
>>>
>>>
>>>
>>> I have to use a 10M sampling rate in my case, but due to computer
>>> constrain, modes_rx will cause overflow when used directly with -r
>>> 10000000. I gauss it's because it's sampling data in float? I am using a
>>> GPSDO with USRP.
>>>
>>>
>>>
>>> So I record data in short at 10M sampling rate, convert from short to
>>> float and then input to modes_rx. The output looks like this:
>>>
>>> {{{
>>>
>>> (27 0.00000000) Type 0 (short A-A surveillance) from dc2ed9 at 45900ft
>>> (speed 600-1200kt)
>>>
>>> (23 0.00000000) Type 4 (short surveillance altitude reply) from 2443b0
>>> at 59800ft (GROUND ALERT)
>>>
>>> (24 0.00000000) Type 4 (short surveillance altitude reply) from 3b1fc3
>>> at 3200ft (SPI)
>>>
>>> (21 0.00000000) Type 21 link capability report from d5ca0e: ACS: 0xda21,
>>> BCS: 0xc923, ECS: 0xee, continues 8 ident 123e
>>>
>>> (22 0.00000000) Type 5 (short surveillance ident reply) from 5ad8b4 with
>>> ident 728 (GROUND ALERT)
>>>
>>> (37 0.00000000) Type 17 BDS0,9-1 (track report) from 7805dd with
>>> velocity 218kt heading 238 VS -1664
>>>
>>> }}}
>>>
>>>
>>>
>>> The timestamp are all zeros.
>>>
>>>
>>>
>>> This appears to be a bug. Can you paste the entire output of
>>> gr-air-modes?
>>>
>>>
>>>
>>> I'm also concerned by the data you've shown. There is only one real
>>> reply in the above data -- the last one. The others are all spurious
>>> replies. Can you tell me the command line you're using as well as the
>>> equipment setup -- daughterboard, antenna, etc.?
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>> Another question is that if I use modes_rx, how to save the sampled
>>> complex baseband signal? Is the data saved somewhere that I've missed?
>>>
>>>
>>>
>>> This is not something modes_rx is designed to do. I suggest instead that
>>> you record samples to disk using uhd_rx_cfile, and then run modes_rx on the
>>> saved file using --source=<filename>.
>>>
>>>
>>>
>>> --n
>>>
>>>
>>>
>>>
>>>
>>> Best regards,
>>>
>>> Cheng Chi
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>> On Mon, Jan 27, 2014 at 3:57 PM, Nick Foster <bistrom...@gmail.com>
>>> wrote:
>>>
>>> On Sun, Jan 26, 2014 at 11:48 PM, Cheng Chi <ch000...@e.ntu.edu.sg>
>>> wrote:
>>>
>>> Hi,
>>>
>>> I am using gr-air-modes for decoding the air plane signal with USRP.
>>> I've successfully used the "modes_rx" and "modes_gui" for decoding the
>>> mode-S packets.
>>>
>>> However, it seems that the modes_rx or modes_gui can't provide the
>>> timestamp of the mode-S packets being decoded. Is there any option that I
>>> can set to timestamp the mode-S packet? The reason I want this timestamp
>>> function is that I want to know the decoded packet data correspond to which
>>> part of the raw data (complex baseband data samples).
>>>
>>>
>>>
>>> If you're using a USRP, you should be getting a timestamp. It's the
>>> second number printed, as in the following:
>>>
>>> (-14 *1.29258827811*) Type 0 (short A-A surveillance) from ab2984 at
>>> 3000ft
>>>
>>>
>>>
>>> If you are using a GPSDO with your USRP, the printed time will be in UTC
>>> seconds. Otherwise, it will be in seconds since the application started
>>> running.
>>>
>>>
>>>
>>> --n
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>> Thank you for any help you can provide in this situation.
>>>
>>> I found that there's a file called "air_modes_preamble.cc" seems to
>>> provide the timestamp function. Does anyone know how to use this file
>>> separately?
>>>
>>>
>>>
>>> Best regards,
>>>
>>> Cheng Chi
>>>
>>>
>>>
>>> _______________________________________________
>>> Discuss-gnuradio mailing list
>>> Discuss-gnuradio@gnu.org
>>> https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
>>>
>>>
>>>
>>>
>>> _______________________________________________
>>> Discuss-gnuradio mailing list
>>> Discuss-gnuradio@gnu.org
>>> https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
>>>
>>>
>>>
>>>
>>>
>>>
>>> _______________________________________________
>>> Discuss-gnuradio mailing list
>>> Discuss-gnuradio@gnu.org
>>> https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
>>>
>>>
>>>
>>>
>>>
>>
>>
>> _______________________________________________
>> Discuss-gnuradio mailing list
>> Discuss-gnuradio@gnu.org
>> https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
>>
>>
>
_______________________________________________
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
