search

bistromath / gr-air-modes

Gnuradio Mode-S/ADS-B radio
This project implements a Mode S receiver for the Gnuradio software-defined radio project. It is designed to receive Mode S transmissions from aircraft and decode them to a human-readable format, including ADS-B information messages such as position and a
GNU General Public License v3.0
438 stars 126 forks source link

Unable to decode frames #72

Closed Ka-zam closed 9 years ago

Ka-zam commented 9 years ago

I have an Ubuntu 14.04 system with GR installed via pybombs. Everything installs clean, including gr-air-modes, of course. However when trying to runI get the following output:

magnus@magnus-VPCF23L1E:~/src/pybombs$ modes_rx -s osmocom -r 2e6 -g 50 linux; GNU C++ version 4.8.2; Boost_105400; UHD_003.009.git-171-g51bc00ee

gr-osmosdr v0.1.4-45-g46e95395 (0.1.5git) gnuradio v3.7.7.1-131-g71ab508d built-in source types: file osmosdr fcd rtl rtl_tcp uhd hackrf bladerf rfspace airspy Using device #0 Realtek RTL2838UHIDIR SN: 00000001 Found Rafael Micro R820T tuner [R82XX] PLL not locked! Exact sample rate is: 2000000.052982 Hz [R82XX] PLL not locked! Gain is 49 Rate is 2000000 Using Volk machine: avx_64_mmx thread[thread-per-block[4]: <block preamble (8)>]: pmt_symbol_to_string: wrong_type : () OOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOO^CO magnus@magnus-VPCF23L1E:~/src/pybombs$

What could be wrong? I tried recompiling in verbose mode but everything just checks out fine. No errors.

bistromath commented 9 years ago

That's a new one, thanks for reporting. I'll check into it.

On Wed, Jun 17, 2015 at 3:52 PM Ka-zam notifications@github.com wrote:

I have an Ubuntu 14.04 system with GR installed via pybombs. Everything installs clean, including gr-air-modes, of course. However when trying to runI get the following output:

magnus@magnus-VPCF23L1E:~/src/pybombs$ modes_rx -s osmocom -r 2e6 -g 50 linux; GNU C++ version 4.8.2; Boost_105400; UHD_003.009.git-171-g51bc00ee

gr-osmosdr v0.1.4-45-g46e95395 (0.1.5git) gnuradio v3.7.7.1-131-g71ab508d built-in source types: file osmosdr fcd rtl rtl_tcp uhd hackrf bladerf rfspace airspy Using device #0 Realtek RTL2838UHIDIR SN: 00000001 Found Rafael Micro R820T tuner [R82XX] PLL not locked! Exact sample rate is: 2000000.052982 Hz [R82XX] PLL not locked! Gain is 49 Rate is 2000000 Using Volk machine: avx_64_mmx thread[thread-per-block[4]: ]: pmt_symbol_to_string: wrong_type : () OOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOO^CO magnus@magnus-VPCF23L1E:~/src/pybombs$

What could be wrong? I tried recompiling in verbose mode but everything just checks out fine. No errors.

— Reply to this email directly or view it on GitHub https://github.com/bistromath/gr-air-modes/issues/72.

jrgifford commented 9 years ago

I'm seeing this as well.

jrgifford commented 9 years ago

Is your machine (by any chance) virtual or physical @Ka-zam ?

Ka-zam commented 9 years ago

Physical machine. It's a Sandybridge i5 laptop with Ubuntu 14.04.2 LTS.

bistromath commented 9 years ago

@jrgifford: please give the output of gnuradio-config-info -v. Are you also using the RTL dongle?

Ka-zam commented 9 years ago

I have an AirSpy as well and tried it. Same problem:

magnus@magnus-VPCF23L1E:~$ modes_rx -g 15 -s osmocom -D airspy=0 -r 2.5e6 linux; GNU C++ version 4.8.2; Boost_105400; UHD_003.009.git-171-g51bc00ee

gr-osmosdr v0.1.4-45-g46e95395 (0.1.5git) gnuradio v3.7.7.1-131-g71ab508d built-in source types: file osmosdr fcd rtl rtl_tcp uhd hackrf bladerf rfspace airspy Using AirSpy NOS v1.0.0-rc5-0-g648c14f 2015-05-20, samplerates: 2.5M 10M Gain is 15 Rate is 2500000 Using Volk machine: avx_64_mmx thread[thread-per-block[4]: <block preamble (8)>]: pmt_symbol_to_string: wrong_type : () OOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOO^Cmagnus@magnus-VPCF23L1E:~$ magnus@magnus-VPCF23L1E:~$

bistromath commented 9 years ago

OK, as I can't reproduce I'm suspecting it's an issue with my use of the Osmo interface. I'll try it with an RTL.

On Thu, Jun 25, 2015 at 10:51 AM Ka-zam notifications@github.com wrote:

I have an AirSpy as well and tried it. Same problem:

magnus@magnus-VPCF23L1E:~$ modes_rx -g 15 -s osmocom -D airspy=0 -r 2.5e6

linux; GNU C++ version 4.8.2; Boost_105400; UHD_003.009.git-171-g51bc00ee

gr-osmosdr v0.1.4-45-g46e95395 (0.1.5git) gnuradio v3.7.7.1-131-g71ab508d built-in source types: file osmosdr fcd rtl rtl_tcp uhd hackrf bladerf rfspace airspy

Using AirSpy NOS v1.0.0-rc5-0-g648c14f 2015-05-20, samplerates: 2.5M 10M Gain is 15 Rate is 2500000

Using Volk machine: avx_64_mmx thread[thread-per-block[4]: ]: pmt_symbol_to_string: wrong_type : ()

OOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOO^Cmagnus@magnus-VPCF23L1E:~$ magnus@magnus-VPCF23L1E:~$

— Reply to this email directly or view it on GitHub https://github.com/bistromath/gr-air-modes/issues/72#issuecomment-115343396 .

Ka-zam commented 9 years ago

Just let me know if you need any commands run or output logs reported.

ckuethe commented 9 years ago

Can also reproduce with hackrf and airspy

kpreid commented 9 years ago

I'm seeing this too. It doesn't just happen with modes_rx but also my own integration of gr-air-modes (and I can reproduce it with a synthesized source, excluding gr-osmosdr entirely). This code used to work and I suspect based on when it manifested near an upgrade that the root cause is something between gr-air-modes and gnuradio.

On Mac OS X 10.10.4, gnuradio and all installed via MacPorts.

bistromath commented 9 years ago

This was an issue with tag processing in the preamble framer and a fix has been pushed to master. Please pull and verify that it works for you. NB: don't forget to use the option -r3.2e6 to set the sample rate for RTL dongles correctly; the default sample rate is 4e6, which RTL dongles do not support.

--n

On Sun, Jul 5, 2015 at 1:53 PM Kevin Reid notifications@github.com wrote:

I'm seeing this too. It doesn't just happen with modes_rx but also my own integration of gr-air-modes https://github.com/kpreid/shinysdr/blob/master/shinysdr/plugins/mode_s/__init__.py (and I can reproduce it with a synthesized source, excluding gr-osmosdr entirely). This code used to work and I suspect based on when it manifested near an upgrade that the root cause is something between gr-air-modes and gnuradio.

On Mac OS X 10.10.4, gnuradio and all installed via MacPorts.

— Reply to this email directly or view it on GitHub https://github.com/bistromath/gr-air-modes/issues/72#issuecomment-118667033 .

Ka-zam commented 9 years ago

Confirmed working.

Be aware that you have to change the recipe file to reference the master branch if you want to build through pybombs.

ckuethe commented 9 years ago

My rtl only goes up to 2.56e6, and it starts getting lossy above 2.4e6. Is it worth asking osmocom for the device's supported sample rates and defaulting to the one closest to 4e6?

max(osmosdr.source().get_sample_rates().values() gr-osmosdr v0.1.4-45-g46e95395 (0.1.5git) gnuradio v3.7.7.1-166-g28f69a54 built-in source types: file osmosdr fcd rtl rtl_tcp uhd hackrf rfspace airspy Using device #0 Realtek RTL2838UHIDIR SN: 00000001 Found Rafael Micro R820T tuner [R82XX] PLL not locked! 2560000.0

On Fri, Jul 10, 2015 at 9:31 AM, bistromath notifications@github.com wrote:

This was an issue with tag processing in the preamble framer and a fix has been pushed to master. Please pull and verify that it works for you. NB: don't forget to use the option -r3.2e6 to set the sample rate for RTL dongles correctly; the default sample rate is 4e6, which RTL dongles do not support.

--n

On Sun, Jul 5, 2015 at 1:53 PM Kevin Reid notifications@github.com wrote:

I'm seeing this too. It doesn't just happen with modes_rx but also my own integration of gr-air-modes < https://github.com/kpreid/shinysdr/blob/master/shinysdr/plugins/mode_s/__init__.py

(and I can reproduce it with a synthesized source, excluding gr-osmosdr entirely). This code used to work and I suspect based on when it manifested near an upgrade that the root cause is something between gr-air-modes and gnuradio.

On Mac OS X 10.10.4, gnuradio and all installed via MacPorts.

— Reply to this email directly or view it on GitHub < https://github.com/bistromath/gr-air-modes/issues/72#issuecomment-118667033

.

— Reply to this email directly or view it on GitHub https://github.com/bistromath/gr-air-modes/issues/72#issuecomment-120452841 .

GDB has a 'break' feature; why doesn't it have 'fix' too?

bistromath commented 9 years ago

Yeah, 2.4e6 is fine. Just don't try 4e6 and expect it to work.

--n

On Fri, Jul 10, 2015 at 1:47 PM ckuethe notifications@github.com wrote:

My rtl only goes up to 2.56e6, and it starts getting lossy above 2.4e6. Is it worth asking osmocom for the device's supported sample rates and defaulting to the one closest to 4e6?

max(osmosdr.source().get_sample_rates().values() gr-osmosdr v0.1.4-45-g46e95395 (0.1.5git) gnuradio v3.7.7.1-166-g28f69a54 built-in source types: file osmosdr fcd rtl rtl_tcp uhd hackrf rfspace airspy Using device #0 Realtek RTL2838UHIDIR SN: 00000001 Found Rafael Micro R820T tuner [R82XX] PLL not locked! 2560000.0

On Fri, Jul 10, 2015 at 9:31 AM, bistromath notifications@github.com wrote:

This was an issue with tag processing in the preamble framer and a fix has been pushed to master. Please pull and verify that it works for you. NB: don't forget to use the option -r3.2e6 to set the sample rate for RTL dongles correctly; the default sample rate is 4e6, which RTL dongles do not support.

--n

On Sun, Jul 5, 2015 at 1:53 PM Kevin Reid notifications@github.com wrote:

I'm seeing this too. It doesn't just happen with modes_rx but also my own integration of gr-air-modes <

https://github.com/kpreid/shinysdr/blob/master/shinysdr/plugins/mode_s/__init__.py

(and I can reproduce it with a synthesized source, excluding gr-osmosdr entirely). This code used to work and I suspect based on when it manifested near an upgrade that the root cause is something between gr-air-modes and gnuradio.

On Mac OS X 10.10.4, gnuradio and all installed via MacPorts.

— Reply to this email directly or view it on GitHub <

https://github.com/bistromath/gr-air-modes/issues/72#issuecomment-118667033

.

— Reply to this email directly or view it on GitHub < https://github.com/bistromath/gr-air-modes/issues/72#issuecomment-120452841

.

GDB has a 'break' feature; why doesn't it have 'fix' too?

— Reply to this email directly or view it on GitHub https://github.com/bistromath/gr-air-modes/issues/72#issuecomment-120518594 .

ckuethe commented 9 years ago

I know I can ask for a particular sample rate; I meant a code change to let modes_rx figure out the best sample rate to use

On Wed, Jul 15, 2015 at 12:59 PM, bistromath notifications@github.com wrote:

Yeah, 2.4e6 is fine. Just don't try 4e6 and expect it to work.

--n

On Fri, Jul 10, 2015 at 1:47 PM ckuethe notifications@github.com wrote:

My rtl only goes up to 2.56e6, and it starts getting lossy above 2.4e6. Is it worth asking osmocom for the device's supported sample rates and defaulting to the one closest to 4e6?

max(osmosdr.source().get_sample_rates().values() gr-osmosdr v0.1.4-45-g46e95395 (0.1.5git) gnuradio v3.7.7.1-166-g28f69a54 built-in source types: file osmosdr fcd rtl rtl_tcp uhd hackrf rfspace airspy Using device #0 Realtek RTL2838UHIDIR SN: 00000001 Found Rafael Micro R820T tuner [R82XX] PLL not locked! 2560000.0

On Fri, Jul 10, 2015 at 9:31 AM, bistromath notifications@github.com wrote:

This was an issue with tag processing in the preamble framer and a fix has been pushed to master. Please pull and verify that it works for you. NB: don't forget to use the option -r3.2e6 to set the sample rate for RTL dongles correctly; the default sample rate is 4e6, which RTL dongles do not support.

--n

On Sun, Jul 5, 2015 at 1:53 PM Kevin Reid notifications@github.com wrote:

I'm seeing this too. It doesn't just happen with modes_rx but also my own integration of gr-air-modes <

https://github.com/kpreid/shinysdr/blob/master/shinysdr/plugins/mode_s/__init__.py

(and I can reproduce it with a synthesized source, excluding gr-osmosdr entirely). This code used to work and I suspect based on when it manifested near an upgrade that the root cause is something between gr-air-modes and gnuradio.

On Mac OS X 10.10.4, gnuradio and all installed via MacPorts.

— Reply to this email directly or view it on GitHub <

https://github.com/bistromath/gr-air-modes/issues/72#issuecomment-118667033

.

— Reply to this email directly or view it on GitHub <

https://github.com/bistromath/gr-air-modes/issues/72#issuecomment-120452841

.

GDB has a 'break' feature; why doesn't it have 'fix' too?

— Reply to this email directly or view it on GitHub < https://github.com/bistromath/gr-air-modes/issues/72#issuecomment-120518594

.

— Reply to this email directly or view it on GitHub https://github.com/bistromath/gr-air-modes/issues/72#issuecomment-121729030 .

GDB has a 'break' feature; why doesn't it have 'fix' too?

Ka-zam commented 9 years ago

I have tried 10e6 and 2.5e6 with my AirSpy and it works as far as live data is concerned but I get no information in the other tabs. So somethings going on there. I will try my RTL as well and report back.

bistromath commented 9 years ago

modes_gui already does intelligently select a sample rate. I'll move that algorithm into modes_rx.

On Wed, Jul 15, 2015, 4:39 PM Ka-zam notifications@github.com wrote:

I have tried 10e6 and 2.5e6 with my AirSpy and it works as far as live data is concerned but I get no information in the other tabs. So somethings going on there. I will try my RTL as well and report back.

— Reply to this email directly or view it on GitHub https://github.com/bistromath/gr-air-modes/issues/72#issuecomment-121740323 .

bistromath commented 9 years ago

Also, you'll only see data in the other tabs for ADS-B reports; live data also shows mode S reports.

On Wed, Jul 15, 2015, 9:01 PM Nick Foster bistromath@gmail.com wrote:

modes_gui already does intelligently select a sample rate. I'll move that algorithm into modes_rx.

On Wed, Jul 15, 2015, 4:39 PM Ka-zam notifications@github.com wrote:

I have tried 10e6 and 2.5e6 with my AirSpy and it works as far as live data is concerned but I get no information in the other tabs. So somethings going on there. I will try my RTL as well and report back.

— Reply to this email directly or view it on GitHub https://github.com/bistromath/gr-air-modes/issues/72#issuecomment-121740323 .

hawkingyy commented 7 years ago

I found it again. I installed ubuntu16.04 on vmware 12, and use apt-get to install gr-air-modes. When I use RTL2838U, the problem as said before appeared again. I have set the sample rate to 3.2e6, but received none. When i set it at other frequency, I just found ooooooooooooooooo again. How to solve this problem please?

ckuethe commented 7 years ago

@hawkingyy you should probably use rtl_test to figure out the maximum sample rate supported by your system. I've never seen an RTL that can do 3.2Msps (not that they don't exist) wtithout dropping samples, and running inside a VM isn't likely to be good for performance either.

hawkingyy commented 7 years ago

@ckuethe I finally got it! Just use apt-get -pruge to remove gr-air-modes which I installed use the same way. Then, git clone the https://github.com/bistromath/gr-air-modes.git and install it with source codes. Note to check the message of cmake, to install depends software which the cmake could not find. In the end, you can make it!