Originally posted by milair
View Post
Announcement
Collapse
No announcement yet.
Raspberry Pi type B + DVB-T Dongle to feed FR24
Collapse
X
-
Originally posted by peterhr View PostI have a Draytek Vigor ADSL router - it's done there in the firewall config.T-EGMC14 -- RTL2832U / R820T+ Raspberry Pi + Dump1090 with home made 8 element colinear 12m above ground level.
Comment
-
Dump 1090 has the following parameters
Code:pi@raspberrypi ~/dump1090 $ ./dump1090 --help ----------------------------------------------------------------------------- | dump1090 ModeS Receiver Ver : 1.07.1908.13 | ----------------------------------------------------------------------------- --device-index <index> Select RTL device (default: 0) --gain <db> Set gain (default: max gain. Use -100 for auto-gain) --enable-agc Enable the Automatic Gain Control (default: off) --freq <hz> Set frequency (default: 1090 Mhz) --ifile <filename> Read data from file (use '-' for stdin) --interactive Interactive mode refreshing data on screen --interactive-rows <num> Max number of rows in interactive mode (default: 15) --interactive-ttl <sec> Remove from list if idle for <sec> (default: 60) --interactive-rtl1090 Display flight table in RTL1090 format --raw Show only messages hex values --net Enable networking --modeac Enable decoding of SSR Modes 3/A & 3/C --net-beast TCP raw output in Beast binary format --net-only Enable just networking, no RTL device or file used --net-http-port <port> HTTP server port (default: 8080) --net-ri-port <port> TCP raw input listen port (default: 30001) --net-ro-port <port> TCP raw output listen port (default: 30002) --net-sbs-port <port> TCP BaseStation output listen port (default: 30003) --net-bi-port <port> TCP Beast input listen port (default: 30004) --net-bo-port <port> TCP Beast output listen port (default: 30005) --net-ro-size <size> TCP raw output minimum size (default: 0) --net-ro-rate <rate> TCP raw output memory flush rate (default: 0) --lat <latitude> Reference/receiver latitide for surface posn (opt) --lon <longitude> Reference/receiver longitude for surface posn (opt) --fix Enable single-bits error correction using CRC --no-fix Disable single-bits error correction using CRC --no-crc-check Disable messages with broken CRC (discouraged) --phase-enhance Enable phase enhancement --aggressive More CPU for more messages (two bits fixes, ...) --mlat display raw messages in Beast ascii mode --stats With --ifile print stats at exit. No other output --onlyaddr Show only ICAO addresses (testing purposes) --metric Use metric units (meters, km/h, ...) --snip <level> Strip IQ file removing samples < level --debug <flags> Debug mode (verbose), see README for details --quiet Disable output to stdout. Use for daemon applications --ppm <error> Set receiver error in parts per million (default 0) --help Show this help Debug mode flags: d = Log frames decoded with errors D = Log frames decoded with zero errors c = Log frames with bad CRC C = Log frames with good CRC p = Log frames with bad preamble n = Log network debugging info j = Log frames to frames.js, loadable by debug.html pi@raspberrypi ~/dump1090 $
... we can use that to change the http page to one of the other ports that is easy to open on the superhub.
Comment
-
Thanks, I'm following now .. interesting to note the ppm <error> setting as I know I had to change this when using one of these to receive Airband, may try it out as the settings are still in the SDR Radio software.
I've had enough for this weekend, I've just backed up the SD card and put the RPi back online, so if I do bu**er up anything I can easily get it back anyway.
I presume that you need to stop dump1090 before changing the flags ?T-EGMC14 -- RTL2832U / R820T+ Raspberry Pi + Dump1090 with home made 8 element colinear 12m above ground level.
Comment
-
Originally posted by milair View PostThanks, I'm following now .. interesting to note the ppm <error> setting as I know I had to change this when using one of these to receive Airband, may try it out as the settings are still in the SDR Radio software.
I've had enough for this weekend, I've just backed up the SD card and put the RPi back online, so if I do bu**er up anything I can easily get it back anyway.
I presume that you need to stop dump1090 before changing the flags ?
Sent from my GT-P5110 using Tapatalk
Comment
-
I entered this but nothing changed and still outputs on 8080? Am I missing something (remember I know nothing about Linux)
pi@raspberrypi ~/dump1090 $ ./dump1090 --net-http-port 40000 --net-sbs-port 30003 --quiet > /dev/null &T-EGMC14 -- RTL2832U / R820T+ Raspberry Pi + Dump1090 with home made 8 element colinear 12m above ground level.
Comment
-
Originally posted by milair View PostI entered this but nothing changed and still outputs on 8080? Am I missing something (remember I know nothing about Linux)
pi@raspberrypi ~/dump1090 $ ./dump1090 --net-http-port 40000 --net-sbs-port 30003 --quiet > /dev/null &
BTW. There's nothing special about Linux, al lot of this stuff can be done in windows in CMD scripts (only there the operating system is far heavier)
Comment
-
Just came across this a article 'Hardening your pi' (not tried anything - so can't answer questions)
When I had traded in my Microsoft box for a Linux box, I wanted it to look and behave like the large $100K Unix boxes I had had the pleasure...
Note: this is about making it more reliable, not security against hackers.Last edited by peterhr; 2013-12-14, 08:33.
Comment
-
Hi Peter / all,
Last night, I came upon an interesting problem. I ran the apt-get update / upgrade on my Pi, and when I rebooted it after the latest update, dump1090 refused to run. There seemed to be a driver conflict for the rtl28xx DVB-T stick. The error I got was something like this:
Using device 0: ezcap USB 2.0 DVB-T/DAB/FM dongle
Kernel driver is active, or device is claimed by second instance of librtlsdr.
In the first case, please either detach or blacklist the kernel module
(dvb_usb_rtl28xxu), or enable automatic detaching at compile time.
usb_claim_interface error -6
Failed to open rtlsdr device #0
Some research told me that apparently this is caused by a conflict with the DVB-T kernel modules provided by the Linux kernel. There were two sugested remedies:
1) Blacklist the kernel modules using modprobe.d. You need to create a file /etc/modprobe.d/librtlsdr-blacklist.conf and put the following in it: "blacklist dvb_usb_rtl28xxu" (Without the quotes). I tried this, and it didn't work - same error.
2) Option 2 - enable detaching the kernel module at compile time, when you build the rtl-sdr driver. This feature is disabled by default in the CMakeLists.txt file (for those interested, the changelog is here: http://ftp-master.metadata.debian.or....README.Debian
To enable it when building with cmake, you need the option: cmake ../ -DDETACH_KERNEL_DRIVER=ON
So the relevant section in your HowTo doc would become:
cd rtl-sdr
mkdir build
cd build
cmake ../ -DDETACH_KERNEL_DRIVER=ON -DINSTALL_UDEV_RULES=ON
make
sudo make install
sudo ldconfig
I did this and it worked after a reboot. Everything is back online now. I have now removed the blacklist file I had placed in /etc/modprobe.d/ when trying out option one, and it works even without that, so obviously all I needed to do was to enable the DDETACH_KERNEL_DRIVER=ON flag and rebuild the rtl-sdr driver source. You don't need to delete the existing rtl-sdr stuff - just rebuild it over the existing install if you have it already.
Just wanted to share this for everyone's benefit, in case anyone runs into this particular problem. Yet another reason to keep a spare SD card fully configured with your last working build, in case it dies on you and you're particularly concered about downtime of your radar :-)
Best
JayantT-VABB7 | RTL dongle + Raspberry Pi + dump1090 + Bulgarian 5dBi collinear
Comment
-
Originally posted by Jayant View PostHi Peter / all,
Last night, I came upon an interesting problem. I ran the apt-get update / upgrade on my Pi, and when I rebooted it after the latest update, dump1090 refused to run. There seemed to be a driver conflict for the rtl28xx DVB-T stick. The error I got was something like this:
Using device 0: ezcap USB 2.0 DVB-T/DAB/FM dongle
Kernel driver is active, or device is claimed by second instance of librtlsdr.
In the first case, please either detach or blacklist the kernel module
(dvb_usb_rtl28xxu), or enable automatic detaching at compile time.
usb_claim_interface error -6
Failed to open rtlsdr device #0
Some research told me that apparently this is caused by a conflict with the DVB-T kernel modules provided by the Linux kernel. There were two sugested remedies:
1) Blacklist the kernel modules using modprobe.d. You need to create a file /etc/modprobe.d/librtlsdr-blacklist.conf and put the following in it: "blacklist dvb_usb_rtl28xxu" (Without the quotes). I tried this, and it didn't work - same error.
2) Option 2 - enable detaching the kernel module at compile time, when you build the rtl-sdr driver. This feature is disabled by default in the CMakeLists.txt file (for those interested, the changelog is here: http://ftp-master.metadata.debian.or....README.Debian
To enable it when building with cmake, you need the option: cmake ../ -DDETACH_KERNEL_DRIVER=ON
So the relevant section in your HowTo doc would become:
cd rtl-sdr
mkdir build
cd build
cmake ../ -DDETACH_KERNEL_DRIVER=ON -DINSTALL_UDEV_RULES=ON
make
sudo make install
sudo ldconfig
I did this and it worked after a reboot. Everything is back online now. I have now removed the blacklist file I had placed in /etc/modprobe.d/ when trying out option one, and it works even without that, so obviously all I needed to do was to enable the DDETACH_KERNEL_DRIVER=ON flag and rebuild the rtl-sdr driver source. You don't need to delete the existing rtl-sdr stuff - just rebuild it over the existing install if you have it already.
Just wanted to share this for everyone's benefit, in case anyone runs into this particular problem. Yet another reason to keep a spare SD card fully configured with your last working build, in case it dies on you and you're particularly concered about downtime of your radar :-)
Best
Jayant
[docs on google drive updated]Last edited by peterhr; 2013-12-14, 18:29.
Comment
-
Hey guys.
A few days back my SD card died and unfortunately I've lost all my scripts.
In a few days I've managed to install back everything but I have problems with my feed. It crashes at least once/day.
I have a feeling that fr24feed_arm-le_233s is the cause of my problems. Did someone encounter problems with it? Is there a better version somewhere to be found?
Comment
-
233s works for me without problem, but I do assume that dump1090 / fr24feed may prove unreliable (I have no basis for thinking this) but I do restart the two programs every 6 hours or so using the scripts in the doc at post #8 in this thread.
My pi runs unattended for weeks at a time.
Sent from my GT-P5110 using Tapatalk
Comment
-
Just want to say a personal thanks to you all and peterhr for the step-by-step guide to setting up my pi. I've managed to do it in about an hour without any experience of Linux!
I'm now feeding successfully to fr24 and no longer have to use my power hungry laptop!
Pete
Comment
Comment