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
