On Mon, Jan 27, 2014 at 12:23 AM, Cheng Chi <[email protected]> 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 <[email protected]> wrote:
>
>> On Sun, Jan 26, 2014 at 11:48 PM, Cheng Chi <[email protected]>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
>>> [email protected]
>>> https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
>>>
>>>
>>
>> _______________________________________________
>> Discuss-gnuradio mailing list
>> [email protected]
>> https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
>>
>>
>
_______________________________________________
Discuss-gnuradio mailing list
[email protected]
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
