discuss-gnuradio
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Discuss-gnuradio] Help about using gr-air-modes


From: Ralph A. Schmid, dk5ras
Subject: Re: [Discuss-gnuradio] Help about using gr-air-modes
Date: Mon, 27 Jan 2014 11:35:33 +0100

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: address@hidden [mailto:address@hidden 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 <address@hidden> 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:

{{{

address@hidden:~/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 <address@hidden> wrote:

On Mon, Jan 27, 2014 at 12:23 AM, Cheng Chi <address@hidden> 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 <address@hidden> wrote:

On Sun, Jan 26, 2014 at 11:48 PM, Cheng Chi <address@hidden> 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
address@hidden
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

 


_______________________________________________
Discuss-gnuradio mailing list
address@hidden
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

 

 


_______________________________________________
Discuss-gnuradio mailing list
address@hidden
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

 

 


reply via email to

[Prev in Thread] Current Thread [Next in Thread]