problem compiling

[odie12]

I get this error in the last version of raspbian

pi@raspberrypi ~/RTLSDR-Airband $ make
as -o rtl_airband_asm.o rtl_airband_asm.s
g++ -O3 -mcpu=arm1176jzf-s -mtune=arm1176jzf-s -march=armv6zk -mfpu=vfp -lrt -lm -lvorbisenc -lmp3lame -lshout -lpthread -lrtlsdr -o rtl_airband rtl_airband.cpp hello_fft/mailbox.c hello_fft/gpu_fft.c hello_fft/gpu_fft_twiddles.c hello_fft/gpu_fft_shaders.c hello_fft/gpu_fft_base.c rtl_airband_asm.s
hello_fft/gpu_fft_base.c:29:22: fatal error: bcm_host.h: No such file or directory
compilation terminated.
makefile:21: recipe for target 'rtl_airband' failed
make: *** [rtl_airband] Error 1

[johnbaker26]

Same issue

[szpajder]

Have you tried this clone:

https://github.com/szpajder/RTLSDR-Airband

?

[odie12]

Hi

With this clone works pefect

---

Atentamente,
Andres Holguin Coral

On Feb 13, 2015, at 14:00, szpajder [email protected] wrote:

Have you tried this clone:

https://github.com/szpajder/RTLSDR-Airband

?

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

[johnbaker26]

Yes thanks. When I compile it it works, but when I run the program it locks up my pi and then does a reboot.
I have an odroid U3 I would rather use. Is it possible to install on one of these?
Thanks

John

Sent from myMail app for Android
Saturday, 14 February 2015, 03:29AM +08:00 from odie12 [email protected]:
Hi
With this clone works pefect

---

Atentamente,
Andres Holguin Coral

On Feb 13, 2015, at 14:00, szpajder [email protected] wrote:

Have you tried this clone:

  https://github.com/szpajder/RTLSDR-Airband

?

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

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

[szpajder]

On Fri, Feb 13, 2015 at 11:48 PM, johnbaker26 [email protected]
wrote:

Yes thanks. When I compile it it works, but when I run the program it
locks up my pi and then does a reboot.

Umm, strange. Does it produce any output on the screen before it locks up?

Which RPi model do you have? Which Raspbian and kernel version?

I have an odroid U3 I would rather use. Is it possible to install on one

of these?

AFAIK, Odroid has a Mali-400 GPU, while RPi uses Broadcom VideoCore, so I
doubt it would run.

This is important, because rtl_airband does FFT on GPU to offload main CPU.

[johnbaker26]

Hi,

It is an RPi 2. I just tried again and it complied! but froze when I
went to start rtl_airband. Here is my config file I"m using.

Ok thanks for the info on the odroid.

On 02/15/2015 12:16 AM, szpajder wrote:

On Fri, Feb 13, 2015 at 11:48 PM, johnbaker26 [email protected]
wrote:

Yes thanks. When I compile it it works, but when I run the program it
locks up my pi and then does a reboot.

Umm, strange. Does it produce any output on the screen before it locks up?

Which RPi model do you have? Which Raspbian and kernel version?

I have an odroid U3 I would rather use. Is it possible to install on one

of these?

AFAIK, Odroid has a Mali-400 GPU, while RPi uses Broadcom VideoCore, so I
doubt it would run.

This is important, because rtl_airband does FFT on GPU to offload main
CPU.

—
Reply to this email directly or view it on GitHub
#10 (comment).

2
0 6 290 119400000 3540
audio-in.liveatc.net 8010 vhhh_twr1 118200000 source ***
audio-in.liveatc.net 8010 vhhh_twr2 118400000 source ***
audio-in.liveatc.net 8010 vhhh_zone 120600000 source ***
audio-in.liveatc.net 8010 vhhh_app_1191 119100000 source ***
audio-in.liveatc.net 8010 vhhh_dir 119500000 source ***
audio-in.liveatc.net 8010 vhhh_app_11935 119350000 source ***
1 3 290 122600000 3680
audio-in.liveatc.net 8010 vhhh_gnd1 121600000 source ***
audio-in.liveatc.net 8010 vhhh_gnd2 122550000 source ***
audio-in.liveatc.net 8010 vhhh_dep 123800000 source ***

[microtony]

Thank you szpajder for the fork.
johnbaker26 I think it may be due to the instruction set difference so the asm optimizations are not working. But I don't have a RPi 2 yet to update it.

[campag]

For me, it doesn't freeze on the Pi-2B, but doesn't run smoothly like on the old B.

The textual waterfall runs at about half the speed, and the demodulated speech is chopped - I'm hearing fragments.

Commenting out the calls to gpu_fft & your arm asm code does not improve the waterfall "flow" rate, so I'm looking elsewhere for the issue.

Edited to add:
@johnbaker, the freeze on the rpi-2 is probably because you have not updated the gpu_fft sources - copy them across from /opt/vc/src/hello_pi/hello_fft in the latest raspbian releases.

[johnbaker26]

OK well if any of you guys get to the bottom of this please let me know.

I can test out any changes you might think will work.

John

On 02/15/2015 11:22 AM, Tony Wong wrote:

Thank you szpajder for the fork.
johnbaker26 I think it may be due to the instruction set difference so
the asm optimizations are not working. But I don't have a RPi 2 yet to
update it.

—
Reply to this email directly or view it on GitHub
#10 (comment).

[campag]

I'd overlooked that there are two optimised assembly routines; the slowdown that I'm seeing on the Pi2 disappears if I comment out the call to samplefft().

Indeed, reverting to the c version of that routine from commit 5c59df... has got it working on the Pi2.

[johnbaker26]

campag,

thanks for your help. When I try to copy the new hello_fft director (after deleting old one) I get this error compiling on the RPi2

root@PapaKilo:/home/pi/RTLSDR-Airband/hello_fft# make
gcc -o hello_fft.bin -lrt -lm -L../lib -L/opt/vc/lib/ -lbcm_host -I/opt/vc/include -I/opt/vc/include/interface/vcos/pthreads -I/opt/vc/include/interface/vmcs_host/linux mailbox.c gpu_fft.c gpu_fft_base.c gpu_fft_twiddles.c gpu_fft_shaders.c hello_fft.c
root@PapaKilo:/home/pi/RTLSDR-Airband/hello_fft# cd ..
root@PapaKilo:/home/pi/RTLSDR-Airband# make
as -o rtl_airband_asm.o rtl_airband_asm.s
g++ -O3 -mcpu=arm1176jzf-s -mtune=arm1176jzf-s -march=armv6zk -mfpu=vfp -lrt -lm -lvorbisenc -lmp3lame -lshout -lpthread -lrtlsdr -o rtl_airband rtl_airband.cpp hello_fft/mailbox.c hello_fft/gpu_fft.c hello_fft/gpu_fft_twiddles.c hello_fft/gpu_fft_shaders.c rtl_airband_asm.s
/tmp/ccWF4uUy.o: In function gpu_fft_prepare(int, int, int, int, GPU_FFT**)': gpu_fft.c:(.text+0x98): undefined reference togpu_fft_alloc(int, unsigned int, GPU_FFT_PTR_)'
gpu_fft.c:(.text+0xbc): undefined reference to gpu_fft_ptr_inc(GPU_FFT_PTR_, int)' gpu_fft.c:(.text+0x104): undefined reference to gpu_fft_ptr_inc(GPU_FFT_PTR*, int)'
gpu_fft.c:(.text+0x134): undefined reference togpu_fft_ptr_inc(GPU_FFT_PTR_, int)' gpu_fft.c:(.text+0x158): undefined reference to gpu_fft_ptr_inc(GPU_FFT_PTR_, int)'
gpu_fft.c:(.text+0x1fc): undefined reference to gpu_fft_ptr_inc(GPU_FFT_PTR*, int)' /tmp/ccWF4uUy.o: In functiongpu_fft_execute(GPU_FFT_)':
gpu_fft.c:(.text+0x2ec): undefined reference to gpu_fft_base_exec(GPU_FFT_BASE_, int)' /tmp/ccWF4uUy.o: In function gpu_fft_release(GPU_FFT*)':
gpu_fft.c:(.text+0x2f0): undefined reference to`gpu_fft_base_release(GPU_FFT_BASE_)'
collect2: error: ld returned 1 exit status
makefile:21: recipe for target 'rtl_airband' failed
make: *_* [rtl_airband] Error 1

[campag]

Looks like you're missing hello_fft/gpu_ fft_base.c - add that to the source files in the makefile.

I'll try to familiarise myself with git and fork szpajders effort and publish my changes added later.

[campag]

OK, I pushed my changes to get it to run on the RPi2. Edit the makefile to compile for RPi1 or RPi2 (default) .

https://github.com/campag/RTLSDR-Airband

[johnbaker26]

campag, Thank you so much! Things are working nicely now on my RPi2

[johnbaker26]

Sorry, but after some further testing, my CPU is running over 100% and the stream cuts in and out.

[campag]

Strange, maybe someone else can confirm, as I have no such issues on the Rpi2-B when compiled with either g++ (4.6 as included in Wheezy) or g++-4.8 (via apt-get).

[johnbaker26]

Ohh shoot, I was compiling with 4.9 Maybe that was the problem? I'll
install 4.8 also and try. Also, I should copy over the hello_fft in
adition to the git clone folder?

On 03/02/2015 06:46 PM, campag wrote:

Strange, maybe someone else can confirm, as I have no such issues on
the Rpi2-B when compiled with either g++ (4.6 as included in Wheezy)
or g++-4.8 (via apt-get).

—
Reply to this email directly or view it on GitHub
#10 (comment).

[campag]

It's no longer necessary to copy across the hello_fft folder as the updated, fixed for RPi2 version, is included in my fork. In fact I've also replaced the optimised shaders from http://maazl.de/project/vc4asm/doc/index.html.

When building with g++-4.8, you should get an executable size of 90993 bytes.

[johnbaker26]

Nope, without a copy of my hello_fft I get this:

root@PapaKilo:/home/pi/test/RTLSDR-Airband# make
as -o rtl_airband_asm.o rtl_airband_asm.s -mfpu=neon-vfpv4 -march=armv7-a
g++ -L/opt/vc/lib/ -lbcm_host -I/opt/vc/include
-I/opt/vc/include/interface/vcos/pthreads
-I/opt/vc/include/interface/vmcs_host/linux -lrt -lm -lvorbisenc
-lmp3lame -lshout -lpthread -lrtlsdr -o rtl_airband -O3 -DRPI2
-mfpu=neon-vfpv4 -march=armv7-a rtl_airband.cpp hello_fft/mailbox.c
hello_fft/gpu_fft.c hello_fft/gpu_fft_base.c
hello_fft/gpu_fft_twiddles.c hello_fft/gpu_fft_shaders.c rtl_airband_asm.s
g++: error: hello_fft/gpu_fft_base.c: No such file or directory
makefile:27: recipe for target 'rtl_airband' failed
make: *** [rtl_airband] Error 1
root@PapaKilo:/home/pi/test/RTLSDR-Airband#

On 03/02/2015 07:02 PM, campag wrote:

It's no longer necessary to copy across the hello_fft folder as the
updated, fixed for RPi2 version, is included in my fork. In fact I've
also replaced the optimised shaders from
http://maazl.de/project/vc4asm/doc/index.html.

When building with g++-4.8, you should get an executable size of 90993
bytes.

—
Reply to this email directly or view it on GitHub
#10 (comment).

[campag]

Sorry, I'd failed to add one source file & few of the shaders for the larger transforms which are now supported. I'm a bit of a noob with git. I've pushed those additions now.

I've just done a fresh git clone & everything compiled fine, g++ 4.6 producing a file of 103676 bytes, g++-4.8 90993 bytes.

[johnbaker26]

Tasks: 87 total, 2 running, 85 sleeping, 0 stopped, 0 zombie
%Cpu(s): 11.3 us, 12.8 sy, 0.0 ni, 75.5 id, 0.0 wa, 0.0 hi, 0.3 si, 0.0 st
KiB Mem: 949472 total, 122980 used, 826492 free, 11688 buffers
KiB Swap: 102396 total, 0 used, 102396 free, 41608 cached

PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND
2255 root 20 0 87848 26m 3248 R 95.1 2.9 1:02.46 rtl_airband
2216 pi 20 0 9272 3064 2488 S 1.3 0.3 0:00.80 sshd

[johnbaker26]

CPU is between 95% and 100%, causing interruptions in the stream.

[campag]

So I assume it now compiled OK & produced binaries with the same sizes I quoted? Anyone else had the same result? All fine here, working just as well as on the previous Pi models:

top - 08:17:13 up 11:55, 2 users, load average: 0.40, 0.34, 0.42
Tasks: 117 total, 1 running, 116 sleeping, 0 stopped, 0 zombie
%Cpu0 : 10.5 us, 0.3 sy, 0.0 ni, 86.7 id, 0.3 wa, 0.0 hi, 2.1 si, 0.0 st
%Cpu1 : 0.0 us, 0.3 sy, 0.0 ni, 99.7 id, 0.0 wa, 0.0 hi, 0.0 si, 0.0 st
%Cpu2 : 4.7 us, 9.0 sy, 0.0 ni, 86.3 id, 0.0 wa, 0.0 hi, 0.0 si, 0.0 st
%Cpu3 : 6.6 us, 12.9 sy, 0.0 ni, 80.5 id, 0.0 wa, 0.0 hi, 0.0 si, 0.0 st
KiB Mem: 754256 total, 249380 used, 504876 free, 31344 buffers
KiB Swap: 102396 total, 0 used, 102396 free, 113016 cached

PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND
3556 root 20 0 65820 15m 3224 S 42.4 2.1 0:12.89 rtl_airband
2407 pi 20 0 207m 13m 5732 S 2.3 1.9 26:30.66 tvheadend
2223 root 20 0 33776 21m 7448 S 1.7 2.9 126:54.61 Xorg
2064 icecast2 20 0 15576 5232 4560 S 0.7 0.7 1:17.11 icecast2
3580 pi 20 0 4680 2488 2084 R 0.7 0.3 0:00.20 top

[szpajder]

I have modified both assembly functions (samplefft and fftwave) to use the new NEON floating point unit in RPi2 instead of old VFP. NEON does not support VFP vector mode computations - all instructions which use it fail on RPi2, the Linux kernel then silently traps the exceptions and emulates FPU in software, which causes horrible performance.

Anybody wanting to give it a try, please pull https://github.com/szpajder/RTLSDR-Airband . It is necessary to choose the right platform during build process - either make rtl_airband_neon (for RPi2) or make rtl_airband_vfp (for RPi1). Please do not modify or replace hello_fft subdirectory. If you encounter any compilation failures (like "gpu_fft_base.c:105:51: error: 'bcm_host_get_sdram_address' was not declared in this scope"), please make sure you have rpi-update'd your system.

RIght now I'm doing three dongles simultaneously - dump1090 + rtl_airband on two dongles, five channels in total, no overclocking - I'm about 53% user CPU (which is only a bit higher than RPi1 had when running rtl_airband on one dongle, instead of two).

[johnbaker26]

Very nice! I will be trying this today! The timing couldn't be better for me. I'll let you know how it works.
Wednesday, 22 April 2015, 04:04AM +08:00 from szpajder [email protected]:

I have modified both assembly functions (samplefft and fftwave) to use the new NEON floating point unit in RPi2 instead of old VFP. NEON does not support VFP vector mode computations - all instructions which use it fail on RPi2, the Linux kernel then silently traps the exceptions and emulates FPU in software, which causes horrible performance.
Anybody wanting to give it a try, please pull  https://github.com/szpajder/RTLSDR-Airband . It is necessary to choose the right platform during build process - either make rtl_airband_neon (for RPi2) or make rtl_airband_vfp (for RPi1). Please do not modify or replace hello_fft subdirectory. If you encounter any compilation failures (like "gpu_fft_base.c:105:51: error: 'bcm_host_get_sdram_address' was not declared in this scope"), please make sure you have rpi-update'd your system.
RIght now I'm doing three dongles simultaneously - dump1090 + rtl_airband on two dongles, five channels in total, no overclocking - I'm about 53% user CPU (which is only a bit higher than RPi1 had when running rtl_airband on one dongle, instead of two).
—
Reply to this email directly or  view it on GitHub .

[microtony]

Awesome! I don't have a RPi2 so I couldn't test it out. I will add a note in my README to refer people to your repo instead.

[szpajder]

If anybody is interested, it is now possible to run rtl_airband under Linux on standard PC hardware as well. Refer to README.md file for details.

Please pull the latest https://github.com/szpajder/RTLSDR-Airband and share your feedback.

[acasadoalonso]

With Raspberry PI 2
I get this error message when compile:

pi@RPi1 ~/airband2 $ make
as -o rtl_airband_asm.o rtl_airband_asm.s
g++ -O3 -mcpu=arm1176jzf-s -mtune=arm1176jzf-s -march=armv6zk -mfpu=vfp -lrt -lm -lvorbisenc -lmp3lame -lshout -lpthread -lrtlsdr -o rtl_airband rtl_airband.cpp hello_fft/mailbox.c hello_fft/gpu_fft.c hello_fft/gpu_fft_twiddles.c hello_fft/gpu_fft_shaders.c rtl_airband_asm.s
/tmp/ccNfq2qG.o: In function gpu_fft_prepare(int, int, int, int, GPU_FFT**)': gpu_fft.c:(.text+0xa0): undefined reference togpu_fft_alloc(int, unsigned int, GPU_FFT_PTR_)'
gpu_fft.c:(.text+0xc4): undefined reference to gpu_fft_ptr_inc(GPU_FFT_PTR_, int)' gpu_fft.c:(.text+0x10c): undefined reference to gpu_fft_ptr_inc(GPU_FFT_PTR*, int)'
gpu_fft.c:(.text+0x138): undefined reference togpu_fft_ptr_inc(GPU_FFT_PTR_, int)' gpu_fft.c:(.text+0x15c): undefined reference to gpu_fft_ptr_inc(GPU_FFT_PTR_, int)'
gpu_fft.c:(.text+0x1f4): undefined reference to gpu_fft_ptr_inc(GPU_FFT_PTR*, int)' /tmp/ccNfq2qG.o: In functiongpu_fft_execute(GPU_FFT_)':
gpu_fft.c:(.text+0x2c4): undefined reference to gpu_fft_base_exec(GPU_FFT_BASE_, int)' /tmp/ccNfq2qG.o: In function gpu_fft_release(GPU_FFT*)':
gpu_fft.c:(.text+0x2c8): undefined reference to`gpu_fft_base_release(GPU_FFT_BASE_)'
collect2: ld returned 1 exit status
makefile:21: recipe for target 'rtl_airband' failed
make: *_* [rtl_airband] Error 1
pi@RPi1 ~/airband2 $

I am using now the campag pull any idea why ???
AC/.

[szpajder]

On Mon, May 18, 2015 at 2:18 PM, acasadoalonso [email protected]
wrote:

With Raspberry PI 2
I get this error message when compile:

pi@RPi1 ~/airband2 $ make
as -o rtl_airband_asm.o rtl_airband_asm.s
g++ -O3 -mcpu=arm1176jzf-s -mtune=arm1176jzf-s -march=armv6zk -mfpu=vfp
-lrt -lm -lvorbisenc -lmp3lame -lshout -lpthread -lrtlsdr -o rtl_airband
rtl_airband.cpp hello_fft/mailbox.c hello_fft/gpu_fft.c
hello_fft/gpu_fft_twiddles.c hello_fft/gpu_fft_shaders.c rtl_airband_asm.s
/tmp/ccNfq2qG.o: In function gpu_fft_prepare(int, int, int, int,
GPU_FFT*)':
gpu_fft.c:(.text+0xa0): undefined reference togpu_fft_alloc(int, unsigned
int, GPU_FFT_PTR)'*

Pull this one: https://github.com/szpajder/RTLSDR-Airband

[acasadoalonso]

I got it, Thank you, it compiles OK now, soon to be tested….

AC/.

On 18 May 2015, at 14:24, szpajder [email protected] wrote:

On Mon, May 18, 2015 at 2:18 PM, acasadoalonso [email protected]
wrote:

With Raspberry PI 2
I get this error message when compile:

pi@RPi1 ~/airband2 $ make
as -o rtl_airband_asm.o rtl_airband_asm.s
g++ -O3 -mcpu=arm1176jzf-s -mtune=arm1176jzf-s -march=armv6zk -mfpu=vfp
-lrt -lm -lvorbisenc -lmp3lame -lshout -lpthread -lrtlsdr -o rtl_airband
rtl_airband.cpp hello_fft/mailbox.c hello_fft/gpu_fft.c
hello_fft/gpu_fft_twiddles.c hello_fft/gpu_fft_shaders.c rtl_airband_asm.s
/tmp/ccNfq2qG.o: In function gpu_fft_prepare(int, int, int, int,
GPU_FFT*)':
gpu_fft.c:(.text+0xa0): undefined reference togpu_fft_alloc(int, unsigned
int, GPU_FFT_PTR)'*

Pull this one: https://github.com/szpajder/RTLSDR-Airband
—
Reply to this email directly or view it on GitHub #10 (comment).

[johnbaker26]

Do you think it might be possible to run it on an odroid U3 as well??

On 04/25/2015 07:08 PM, szpajder wrote:

If anybody is interested, it is now possible to run rtl_airband under
Linux on standard PC hardware as well. Refer to README.md file for
details.

Please pull the latest https://github.com/szpajder/RTLSDR-Airband and
share your feedback.

—
Reply to this email directly or view it on GitHub
#10 (comment).

[szpajder]

On Tue, May 26, 2015 at 5:26 AM, johnbaker26 [email protected]
wrote:

Do you think it might be possible to run it on an odroid U3 as well??

Well, I do not currently have such hardware at hand, but it's a Cortex-A9,
which has NEON onboard, so if you have it, maybe just give the *_neon build
a try and let me know, if it works already?

[johnbaker26]

Thank you, I decided to try again with the RPi2 since you updated your
code. Wow it works great now. 8 feeds from two dongles and CPU about
35%. Very nice!

Do you know of any limitation of running more than two dongles on one
raspberry pi?

On 05/26/2015 07:26 PM, szpajder wrote:

On Tue, May 26, 2015 at 5:26 AM, johnbaker26 [email protected]
wrote:

Do you think it might be possible to run it on an odroid U3 as well??

Well, I do not currently have such hardware at hand, but it's a Cortex-A9,
which has NEON onboard, so if you have it, maybe just give the *_neon
build
a try and let me know, if it works already?

—
Reply to this email directly or view it on GitHub
#10 (comment).

[szpajder]

Do you know of any limitation of running more than two dongles on one
raspberry pi?

There are no hardcoded dongle count limits - neither in rtl_airband nor
rtl-sdr library. I think you can go up to about four, maybe five dongles on
RPi2 - at this stage you will get limited by CPU usage which will cause
stream hiccups.

Another limit is the power - you need a really good USB hub and power
supply to power all this stuff. For example, I'm currently using The PiHut
7-port USB hub with 3A power supply (at least that's what it's written on
it...), RPi2, three dongles, and USB WiFi card. It's all stable, however
the red LED on RPi (indicating "power good") is not lit - so I guess I'm on
the edge right now. I've already trashed two cheap 2A power supplies which
failed after a few months of continuous work. If the current one fails,
I'll probably go for an industrial power supply.

[johnbaker26]

Ohh I know the pi power probs well unfortunately...
I've got a nice 10amp industrial supply, the power pins on the dongles have been cut and directly wired to the power supply so no back power into the pi. Pi is also powered fr on same supply via quality wires.
I
Wednesday, 27 May 2015, 05:45PM +08:00 from szpajder [email protected]:

Do you know of any limitation of running more than two dongles on one
raspberry pi?
There are no hardcoded dongle count limits - neither in rtl_airband nor
rtl-sdr library. I think you can go up to about four, maybe five dongles on
RPi2 - at this stage you will get limited by CPU usage which will cause
stream hiccups.
Another limit is the power - you need a really good USB hub and power
supply to power all this stuff. For example, I'm currently using The PiHut
7-port USB hub with 3A power supply (at least that's what it's written on
it...), RPi2, three dongles, and USB WiFi card. It's all stable, however
the red LED on RPi (indicating "power good") is not lit - so I guess I'm on
the edge right now. I've already trashed two cheap 2A power supplies which
failed after a few months of continuous work. If the current one fails,
I'll probably go for an industrial power supply.
—
Reply to this email directly or  view it on GitHub .

[spotter-ssol]

Hi there!
How to propper config a freq. correction of 85ppm in config file? 85? 8500? 85000?
Thanks!

[johnbaker26]

Hello,

Does anyone have any experience with bleeding over frequencies when
using rtl-airband? I am feeding frequencies to live atc, and the two
tower frequencies here in Hong Kong are 118.2 and 118.4, lots of bleed
coming from either frequency. Any ideas how to limit this?

Thanks!

On 02/15/2015 12:16 AM, szpajder wrote:

On Fri, Feb 13, 2015 at 11:48 PM, johnbaker26 [email protected]
wrote:

Yes thanks. When I compile it it works, but when I run the program it
locks up my pi and then does a reboot.

Umm, strange. Does it produce any output on the screen before it locks up?

Which RPi model do you have? Which Raspbian and kernel version?

I have an odroid U3 I would rather use. Is it possible to install on one

of these?

AFAIK, Odroid has a Mali-400 GPU, while RPi uses Broadcom VideoCore, so I
doubt it would run.

This is important, because rtl_airband does FFT on GPU to offload main
CPU.

—
Reply to this email directly or view it on GitHub
#10 (comment).

[microtony]

Do you have success using other programs such as SDR Sharp / SDR Radio.com?
One thing you can try is to lower the gain. But you won't have much luck if you live closer to a enroute antenna (i.e. NE Lantau, Tai Mo Shan, Tates Cairn, Victoria Peak) than the airport.

[johnbaker26]

Lowering the gain worked very nicely thanks!  I lowered from 290 to 200 and now no more bleed.
http://www.liveatc.net/flisten.php?mount=vhhh_twr1&icao=vhhh
Sunday, 04 October 2015, 05:52PM +08:00 from Tony Wong < [email protected]> :

Do you have success using other programs such as SDR Sharp / SDR Radio.com?
One thing you can try is to lower the gain. But you won't have much luck if you live closer to a enroute antenna (i.e. NE Lantau, Tai Mo Shan, Tates Cairn, Victoria Peak) than the airport.
—
Reply to this email directly or view it on GitHub .