Closed Ka-zam closed 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.
I'm seeing this as well.
Is your machine (by any chance) virtual or physical @Ka-zam ?
Physical machine. It's a Sandybridge i5 laptop with Ubuntu 14.04.2 LTS.
@jrgifford: please give the output of gnuradio-config-info -v. Are you also using the RTL dongle?
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:~$
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 .
Just let me know if you need any commands run or output logs reported.
Can also reproduce with hackrf and airspy
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.
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 .
Confirmed working.
Be aware that you have to change the recipe file to reference the master branch if you want to build through pybombs.
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?
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 .
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?
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.
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 .
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 .
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?
@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.
@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!
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.