tar1090 doesn't seem to connect to readsb

[tracing-home]

I did a fresh install following the instructions in "Raspbian Lite: ADS B receiver".

The tar1090 interface works nicely, but there are no planes in the map and the log area on the right.

The problem in short: Planes are seen, but they don't reach tar1090. I realize this is similar to #273, but this is a fresh install, no config files modified.

I don't know how the planes are accessed by tar1090, but looking here, there are none. Just the message counter increments:

cat  /run/readsb/aircraft.json 

{ "now" : 1703084628.890,
  "messages" : 12,
  "aircraft" : [
  ]
}

Wondering if the receiver (RTL-SDR v4) worked I stopped the readsb service and ran readsb directly.

sudo systemctl stop readsb
readsb --device-type rtlsdr

*8b0cd719bddaa3db8ed4e3eda484;
hex:  0cd719   CRC: 381323 fixed bits: 1 decode: ok
RSSI:    -24.2 dBFS   reduce_forward: 1
Score: 700
receiverTime:                  9099566.75us
utcTime: 14:28:05.539 epoch: 1703082485.539
DF: 17 AA:0CD719 CA:3 ME:BDDAA3DB8ED4E3
 Extended Squitter Unknown (23/5)
  ICAO Address:  0CD719 (adsb_icao)

I get a fairly constant stream of airplanes that are seen, see the example

Running interactive, there are again no planes shown. The header comes up and unaligned status messages is all I see

readsb --device-type rtlsdr --interactive

Starting the readsb service again and looking at the logs, I see no problem:

sudo systemctl start readsb
sudo journalctl --no-pager -u readsb

Dec 20 15:24:12 raspberrypi readsb[702625]: [2023-12-20 15:24:12.640 CET] readsb starting up.
Dec 20 15:24:12 raspberrypi readsb[702625]: readsb version: 3.14.1606 wiedehopf git: 9114b2c (committed: Fri Jul 28 22:19:15 2023 0200)
Dec 20 15:24:12 raspberrypi readsb[702625]: Using lat:   53.0752, lon:    8.8078
Dec 20 15:24:12 raspberrypi readsb[702625]: 30002: Raw TCP output port
Dec 20 15:24:12 raspberrypi readsb[702625]: 30005: Beast TCP output port
Dec 20 15:24:12 raspberrypi readsb[702625]: 30003: SBS TCP output ALL port
Dec 20 15:24:12 raspberrypi readsb[702625]: 30001: Raw TCP input port
Dec 20 15:24:12 raspberrypi readsb[702625]: 30004: Beast TCP input port
Dec 20 15:24:12 raspberrypi readsb[702625]: 30104: Beast TCP input port
Dec 20 15:24:12 raspberrypi readsb[702625]: rtlsdr: using device #0: Generic RTL2832U OEM (RTLSDRBlog, Blog V4, SN 00000001)
Dec 20 15:24:12 raspberrypi readsb[702625]: Detached kernel driver
Dec 20 15:24:13 raspberrypi readsb[702625]: Found Rafael Micro R828D tuner
Dec 20 15:24:13 raspberrypi readsb[702625]: rtlsdr: tuner gain set to 43.9 dB
Dec 20 15:24:13 raspberrypi readsb[702625]: [R82XX] PLL not locked!
Dec 20 15:24:13 raspberrypi readsb[702625]: [R82XX] PLL not locked!
Dec 20 15:24:13 raspberrypi readsb[702625]: Allocating 16 zero-copy buffers

[wiedehopf]

Change gain go 55 in /etc/default/readsb and restart service. After that it should be identical to your command running it from the command line.

[wiedehopf]

If there is no data in /run/readsb/aircraft.json that means readsb just isn't receiving anything, not tar1090 not getting the data from readsb.

[tracing-home]

I did change the gain to 55 and tried other values as well.

There seems to be something else though. In aircraft.json, the messages counter is going up, but there are no entries for any aircraft generated by readsb. This is when I run readsb as a service or in the terminal. I am not sure about the discrepancy between the counter and "missing" airplanes.

cat /run/readsb/aircraft.json  

{ "now" : 1707385850.507,
 "messages" : 1169,
 "aircraft" : [
 ]
}

If I run from the command line with,

readsb --device-type rtlsdr --gain 49.6 --write-json=/home/martin

the resulting aircraft.json looks the same: message counter going up, but no aircraft entries. The gain value has no influence in this context. In the terminal airplanes are listed.

[wiedehopf]

I get a fairly constant stream of airplanes that are seen, see the example

I think you're just not getting good reception or it's just noise making the message counter go up.

Can you give me a sample of raw message output to confirm? (readsb --device-type rtlsdr --interactive ) Post a link to a pastebin or similar website with the messages.

[tracing-home]

Using --interactive, I get no planes listed at all.

I did a couple test runs with --stats and different antenna and cable setups. This one: 140 mm dipol, vertical, outside. 80cm antenna lead, rtl-sdr plugged into raspberry 3+

Attached is the output from the terminal (readsb --stats --device-type rtlsdr --gain 49.6)

8 valid planes seem to be there (in file)

Looking at the stats at the bottom of the file:

  -20.4 dBFS noise power
  -28.4 dBFS mean signal power
  -27.9 dBFS peak signal power

Noise is higher than the signal, that ratio remains about the same with gain levels or setups

I guess those numbers are bad too?

  14091434 Mode-S message preambles received
    10340016 with bad message format or invalid CRC
    3751410 with unrecognized ICAO address

I always seem to get a bit over 70% "bad format" errors. But maybe that is normal...

In some other post on flightradar24.com (2020) you mentioned running pihole on the same raspberry can be an issue. I am doing that. Is that still an issue? I don't notice obvious glitches. However I am seeing that the raspberry has a problem (re)booting with the rtl-sdr stick inserted.

planes-recorded-eigene.txt

[wiedehopf]

Your reception is just bad (proven by what the run you posted). Why that is i can't say.

The software is working as intended.

[wiedehopf]

Just to explain some more ... You received 8 messages in 7 minutes, even receiving only ONE airplane would mean multiple messages per second. Even bad reception of ONE airplane would be one message every couple seconds (already very bad reception).

Aircraft you "heard" are probably noise. Even if they're not they would be hard to distinguish from such, that's why there is a requirement of a DF11 or DF17 message without CRC correction being received. All your messages required CRC correction.

[tracing-home]

Thank you for your explanation in any case!

[wiedehopf]

Most likely you're using a completely unsuitable antenna. Or coax. Or there is massive interference.

[RundesBalli]

Most likely you're using a completely unsuitable antenna. Or coax. Or there is massive interference.

Or cable broke, or its mostly unshielded cable, or a massive LTE antenna nearby without filtering the adsb signal, or, or, or.

[tracing-home]

You guys make me smile :) Or a mixture of all of the above...

Certainly, all options need checking. I do recall, in my first attempts to receive the ADSB signals, I actually go a reception and it showed in tar1090... But here in Bremen there are not a lot of planes anyway. At that point the raspi and rtl-sdr were in a plastic box only wifi connected on the balcony far away from other computers...

Time to try things. Thanks

[wiedehopf]

To be honest it should be fairly simple ... 6.9 cm of wire (can be paper clip) sticking out of the SDR with the SDR facing straight up should give you 50 nmi reception pretty easily.

If you want you can describe you signal path and we can give some educated guesses for improvement.

[tracing-home]

I have tried this setup and variations:

The Raspberry is in a aluminum case, standing upright (USB at the top), after bootup insert RTL-SDR v4 (else no booting), paperclip wire 69mm length inserted. I used sandpaper to clean the wire, a rubberband to create sideways tension, ensuring better contact. The whole setup is connected via Wifi on the balcony. Horizontally, I am on the same level as other houses, about 50 m away. There are tall trees (no leaves), so not ideal. I can send pictures, if it helps.

Whatever variations I try (different than power supply, use MicroSD instead of SSD, powerbank instead of power supply), the noise is always about 3-5 dBFS higher than the signal. In one measurement series I had a single dataset without CRC error, else, always one bit is fixed. I see several unlikely CRC values like "CRC: 020000", noise I guess.

A last run using a power bank, and the dipole I bought with the SDR (50cm cable, ohm meter check shows no breakage, overall span 158mm) the signal is a little stronger than the noise (-24.6 noise, -24.1 signal), but the ratio bad messages to preables received (8154432/11118180) is still about 73%

I am beginning to wonder, if the SDR is dodgy. Or a filter or LNA is needed? Could you/someone show me a sample of "good" stats?

I have attached the last terminal output and stats

Final run with powerbank and dipole antenna.txt

[wiedehopf]

Which RPi is it? It should really boot with SDR in it

[wiedehopf]

root@raspberrypi ~ # readsb --no-interactive --device-type rtlsdr --stats --gain 38 > readsb_sample_run_messages 2>&1
root@raspberrypi ~ # cat readsb_sample_run_messages | nc termbin.com 9999                                            

Let it run for 3 seconds. This is with an antenna optimized for ACARS reception around 130 MHz.

https://termbin.com/7nhw

This would seem to be with an LNA but an LNA doesn't make that big a difference.

[tracing-home]

I'm using a Raspberry 3B+

Actually if I run it with a powerbank, it will boot with the SDR inserted. The Raspi original power supply maybe is an issue. I tried a different 5V/3A one that works better.

Here are some 3 or 4 seconds, is that really long enough? No "planes" in there. https://termbin.com/vaby (Thanks for the pasting link. I didn't know that. )

Thanks for your log. The signal/noise separation is clearly higher than here.

Just for the sake of it: My installation were only your two scripts: readsb and tar1090. That seemed right to me.

[wiedehopf]

So .. the v4 needs a newer driver but that's a raspbian thing ... not sure how up to date that is.

But without driver support i'd just expect it to not work, not work but not have signal.

Have you tried the SDR with SDR# in windows or some other scanner to listen to FM radio / airband? It really looks like a bad SDR to me.

[tracing-home]

Problem solved!

I left the readsb and and tar1090 installation untouched. Following the instructions on https://www.rtl-sdr.com/V4/, I first removed all drivers then installed them as instructed.

Running readsb in the terminal (service deactivated) I get a rapid stream of data coming in. No crc errors, and signal to noise ratio is like yours. tar1090 shows some planes on the map.

I'll leave it running a while and see what happens

Now I am wondering how readsd and the drivers interact. Does readsd install the non-v4 drivers?

[wiedehopf]

It installs the drivers provided by the operating system.

[tracing-home]

ok... then I see my problem. When I installed the drivers first, the readsb installation probably replaced them? Can that be?

[wiedehopf]

It installs the driver package yeah ... that could be it.

[wiedehopf]

I'll have to change my script i guess ... though it would be nice for raspbian just to have the driver

[tracing-home]

Of course pi-os should have the driver. But maybe that is not so easy (I have no deep knowledge): on the installation page are instructions to blacklist the Blacklist the DVB-T TV drivers. So there is some theoretical hardware conflict.

I guess for your script the issue is, to discover which hardware is plugged in.

For the moment, a good workaround seems to be: install readsb, then tar1090, and lastly the rtl-sdr v4 drivers

[wiedehopf]

The blacklisting is irrelevant and hasn't been an issue for a long time.

No my script could determine if custom rtl-sdr drivers are installed and then not install the package.

[wiedehopf]

If you would use the Alternative Debian Package Installation Method listed in the v4 howto, the issue might not have occured as the dependency would be satisfied. Anyhow i'll have to test a bit i guess.

[tracing-home]

I'll give that alternate method a try tomorrow. I'll let you know. Thanks for looking into this and thanks for your support.

[wiedehopf]

It might not work even with the alternate method ... i'm not quite sure how to test for this to be honest.

librtlsdr-dev librtlsdr0 The dev library is required to compile readsb, the 2nd one is required to run it.

Yeah this is a bit unfortunate. I guess i should keep it in mind. It's a bit disappointing that the old driver appears to work with the new hardware, that's bad design.

I guess i should put a note on the wiki... because i'm not sure how to fix this except always compiling the driver as well which i don't want to do.

[tracing-home]

I agree about the bad design thing. The problem is one of sequence, I guess. The old driver was developed before the v4 dongle existed and now probably doesn't recognize, or check for a new, unknown dongle version. The old driver would need an update to block the v4 dongle.

Compiling drivers, which I had to do, has really disappeared from user land.

If you could put a note for the v4 users with the workaround, that might help. I'll think about sending an email to rtl-sdr.

[wiedehopf]

Not sure what rtl-sdr can do ... getting an updated package into debian just takes time.