Giter Club home page Giter Club logo

readsb's Introduction

Readsb

This is a detached fork of https://github.com/Mictronics/readsb

It's continually under development, expect bugs, segfaults and all the good stuff :)

NO WARRANTY

THIS SOFTWARE IS PROVIDED BY THE COPYRIGHT HOLDERS AND CONTRIBUTORS "AS IS" see the LICENSE file for details

how to install / build

I'd recommend this script to automatically install it:

Or build the package yourself:

sudo apt update
sudo apt install --no-install-recommends --no-install-suggests -y \
    git build-essential debhelper libusb-1.0-0-dev \
    librtlsdr-dev librtlsdr0 pkg-config \
    libncurses-dev zlib1g-dev zlib1g libzstd-dev libzstd1
git clone --depth 20 https://github.com/wiedehopf/readsb.git
cd readsb
export DEB_BUILD_OPTIONS=noddebs
dpkg-buildpackage -b -Prtlsdr -ui -uc -us
sudo dpkg -i ../readsb_*.deb

Or check here for more build instructions and other useful stuff:

aircraft.json format:

json file Readme

Push server support

readsb connects to a listening server.

Sending beast data (beast_out):

--net-connector 192.168.2.22,30004,beast_out

Receiving beast data (beast_in);

--net-connector 192.168.2.28,30005,beast_in

BeastReduce output

Selectively forwards beast messages if the received data hasn't been forwarded in the last 125 ms (or --net-beast-reduce-interval). Data not related to the physical aircraft state are only forwarded every 500 ms (4 * --net-beast-reduce-interval).The messages of this output are normal beast messages and compatible with every program able to receive beast messages.

Debian package

  • Build package with no additional receiver library dependencies: dpkg-buildpackage -b.
  • Build with RTLSDR support: dpkg-buildpackage -b --build-profiles=rtlsdr

Building manually

You can probably just run "make". By default "make" builds with no specific library support. See below. Binaries are built in the source directory; you will need to arrange to install them (and a method for starting them) yourself.

"make RTLSDR=yes" will enable rtl-sdr support and add the dependency on librtlsdr.

On Raspbian 32 bit, mostly rpi2 and older you might want to use this to compile if you're running into CPU issues:

make AIRCRAFT_HASH_BITS=11 RTLSDR=yes OPTIMIZE="-Ofast -mcpu=arm1176jzf-s -mfpu=vfp"

In general if you want to save on CPU cycles, you can try building with these options:

make AIRCRAFT_HASH_BITS=11 RTLSDR=yes OPTIMIZE="-O3 -march=native"

Or even more aggressive but could cause unexpected behaviour:

make AIRCRAFT_HASH_BITS=11 RTLSDR=yes OPTIMIZE="-Ofast -march=native"

The difference of using -Ofast or -O3 over the default of -O2 is likely very minimal. -march=native also usually makes little difference but it might, so it's worth a try.

Configuration

If required, edit /etc/default/readsb to set the service options, device type, network ports etc.

rtl-sdr bias tee

Use this utility independent of readsb: https://github.com/wiedehopf/adsb-wiki/wiki/RTL-Bias-Tee

Global map of aircraft

One of this forks main uses is to be the backend of a global map. For that purpose it's used in conjunction with tar1090 with some extra options to cope with the number of aircraft and also record a history of flight paths: https://github.com/wiedehopf/tar1090#0800-destroy-sd-card

Websites using this software:

Projects that use or have used data generated by this software:

--debug=S: speed check debugging output

For current reference please see the speed_check function.

hex

SQ means same quality (ADS-B vs MLAT and stuff) LQ means lower quality

fail / ok ok means speed check passed (displayed only with cpr-focus)

A means airborne and S means surface.

reliable is my reliability counter every good position increases each aircrafts position reliability, if it gets to zero, speed check is no longer applied and it's allowed to "JUMP", "JUMP" is also allowed if we haven't had a position for 2 minutes.

tD is the trackDifference 170 or 180 means the new position goes in the opposite direction of the ground track broadcast by the aircraft.

then we have actual distance / allowed distance. the allowed distance i tweak depending on the trackDifference high trackDifference makes the allowed distance go slightly negative as i don't want aircraft to jump backwards.

elapsed time

actual / allowed speed (allowed speed based on allowed distance)

old --> new lat, lon -> lat, lon

oh if you want that display: --debug=S you'll have to update, just disabled the MLAT speed check from displayign stuff ... because usually it's not interesting

readsb --help

might be out of date, check the command on a freshly compiled version

Usage: readsb [OPTION...] 
readsb Mode-S/ADSB/TIS Receiver   
Build options: 

 General options:
      --cpr-focus=<hex>      show CPR details for this hex
      --db-file=<file.csv.gz>   Default: "none" (as of writing a compatible
                             file is available here:
                             https://github.com/wiedehopf/tar1090-db/tree/csv)
      --db-file-lt           Write long type to aircraft.json as field desc
      --debug=<flags>        Debug mode (verbose), n: network, P: CPR, S: speed
                             check
      --device-type=<type>   Select SDR type
      --filter-DF=<type>     When displaying decoded ModeS messages on stdout
                             only show this DF type
      --fix                  Enable CRC single-bit error correction (default)
      --forward-mlat         Allow forwarding of received mlat results to
                             output ports
      --freq=<hz>            Set frequency (default: 1090 MHz)
      --gain=<db>            Set gain (default: max gain. Use -10 for
                             auto-gain)
      --gnss                 Show altitudes as GNSS when available
      --heatmap=<interval in seconds>
                             Make Heatmap, each aircraft at most every interval
                             seconds (creates historydir/heatmap.bin and exit
                             after that)
      --heatmap-dir=<dir>    Change the directory where heatmaps are saved
                             (default is in globe history dir)
      --interactive          Interactive mode refreshing data on screen.
                             Implies --throttle
      --interactive-ttl=<sec>   Remove from list if idle for <sec> (default:
                             60)
      --jaero-timeout=<n>    How long in minutes JAERO positions remain valid
                             and on the map in tar1090 (default:33)
      --json-location-accuracy=<n>
                             Accuracy of receiver location in json metadata:
                             0=no location, 1=approximate, 2=exact
      --json-reliable=<n>    Minimum position reliability to put it into json
                             (default: 1, globe options will default set this
                             to 2, disable speed filter: -1, max: 4)
                                   --json-trace-hist-only=1,2,3,8
Don't write recent(1), full(2), either(3) traces
                             to /run, only archive via write-globe-history (8:
                             irregularly write limited traces to run, subject
                             to change)
      --json-trace-interval=<seconds>
                             Interval after which a new position will
                             guaranteed to be written to the trace and the json
                             position output (default: 30)
      --lat=<lat>            Reference/receiver surface latitude
      --leg-focus=<hex>      show leg marking details for this hex
      --lon=<lon>            Reference/receiver surface longitude
      --max-range=<dist>     Absolute maximum range for position decoding (in
                             nm, default: 300)
      --metric               Use metric units
      --mlat                 Display raw messages in Beast ASCII mode
      --modeac               Enable decoding of SSR Modes 3/A & 3/C
      --modeac-auto          Enable Mode A/C if requested by a Beast
                             connection
      --no-fix               Disable CRC single-bit error correction
      --no-fix-df            Disable CRC single-bit error correction on the DF
                             type to produce more DF17 messages (disabling
                             reduces CPU usage)
      --no-interactive       Disable interactive mode, print to stdout
      --onlyaddr             Show only ICAO addresses
      --position-persistence=<n>   Position persistence against outliers
                             (default: 4), incremented by json-reliable minus
                             1
      --preamble-threshold=<40-400>
                             lower threshold --> more CPU usage (default: 58,
                             pi zero / pi 1: 75, hot CPU 42)
      --quiet                Disable output (default)
      --range-outline-hours=<hours>
                             Make the range outline retain data for the last X
                             hours (float, default: 24.0)
      --raw                  Show only messages hex values
      --receiver-focus=<receiverId>
                             only process messages from receiverId
      --show-only=<addr>     Show only messages by given ICAO on stdout
      --snip=<level>         Strip IQ file removing samples < level
      --stats                With --ifile print stats at exit. No other output
      --stats-every=<sec>    Show and reset stats every <sec> seconds
      --stats-range          Collect/show range histogram
      --trace-focus=<hex>    show traceAdd details for this hex
      --write-globe-history=<dir>
                             Extended Globe History
      --write-json=<dir>     Periodically write json output to <dir>
      --write-json-binCraft-only=<n>
                             Use only binary binCraft format for globe files
                             (1), for aircraft.json as well (2)
      --write-json-every=<sec>   Write json output and update API json every
                             sec seconds (default 1)
      --write-json-globe-index   Write specially indexed globe_xxxx.json files
                             (for tar1090)
      --write-json-gzip      Write aircraft.json also as aircraft.json.gz
      --write-prom=<filepath>   Periodically write prometheus output to
                             <filepath>
      --write-receiver-id-json   Write receivers.json
      --write-state=<dir>    Write state to disk to have traces and outline
                             after a restart
                            
      --write-state-only-on-exit   Don't continously update state.

 Network options:
      --net                  Enable networking
      --net-api-port=<port>  TCP API listen port (in contrast to other
                             listeners, only a single port is allowed) (update
                             frequency controlled by write-json-every
                             parameter) (default: 0)
      --net-beast-reduce-filter-alt=<pressure altitude in ft>
                             beast-reduce: remove aircraft which are above
                             altitude
      --net-beast-reduce-filter-dist=<distance in nmi>
                             beast-reduce: remove aircraft which are further
                             than distance from the receiver
      --net-beast-reduce-interval=<seconds>
                             BeastReduce position update interval, longer means
                             less data (default: 0.125, valid range: 0.000 -
                             14.999)
      --net-beast-reduce-out-port=<ports>
                             TCP BeastReduce output listen ports (default: 0)
      --net-bi-port=<ports>  TCP Beast input listen ports  (default: 0)
      --net-bind-address=<ip>   IP address to bind to (default: Any; Use
                             127.0.0.1 for private)
      --net-bo-port=<ports>  TCP Beast output listen ports (default: 0)
      --net-buffer=<n>       TCP buffer size 64Kb * (2^n) (default: n=2, 256Kb)
                            
      --net-connector=<ip,port,protocol>
                             Establish connection, can be specified multiple
                             times (e.g. 127.0.0.1,23004,beast_out) Protocols:
                             beast_out, beast_in, raw_out, raw_in, sbs_in,
                             sbs_in_jaero, sbs_out, sbs_out_jaero, sbs_out_prio 
                             vrs_out, json_out, asterix_out, asterix_in, 
                             gpsd_in (one failover ip/address,port can be specified:
                             primary-address,primary-port,protocol,failover-address,failover-port)
      --net-connector-delay=<seconds>
                             Outbound re-connection delay (default: 30)
      --net-garbage=<ports>  timeout receivers, output messages from timed out
                             receivers as beast on <ports>
      --net-heartbeat=<rate> TCP heartbeat rate in seconds (default: 60 sec; 0
                             to disable)
                                   --net-ingest           primary ingest node
      --net-json-port=<ports>   TCP json position output listen ports, sends
                             one line with a json object containing aircraft
                             details for every position received (default: 0)
      --net-json-port-include-noposition
TCP json position output: include aircraft without
                             position (state is sent for aircraft for every
                             DF11 with CRC if the aircraft hasn't sent a
                             position in the last 10 seconds and interval
                             allowing)
      --net-json-port-interval=<seconds>
                             Set minimum interval between outputs per aircraft
                             for TCP json output, default: 0.0 (every
                             position)
      --net-only             Enable just networking, no RTL device or file
                             used
      --net-receiver-id      forward receiver ID
      --net-ri-port=<ports>  TCP raw input listen ports  (default: 0)
      --net-ro-interval=<rate>   TCP output flush interval in seconds (maximum
                             interval between two network writes of accumulated
                             data)(default: 0.05, valid values 0.005 - 1.0)
      --net-ro-port=<ports>  TCP raw output listen ports (default: 0)
      --net-ro-size=<size>   TCP output flush size (maximum amount of
                             internally buffered data before writing to
                             network) (default: 1200)
      --net-sbs-in-port=<ports>   TCP BaseStation input listen ports (default:
                             0)
      --net-sbs-jaero-in-port=<ports>
                             TCP SBS Jaero input listen ports (default: 0)
      --net-sbs-jaero-port=<ports>
                             TCP SBS Jaero output listen ports (default: 0)
      --net-sbs-port=<ports> TCP BaseStation output listen ports (default: 0)
      --net-sbs-reduce       Apply beast reduce logic and interval to SBS
                             outputs
      --net-ao-port=<ports>  TCP ASTERIX output listen ports (default: 0)
      --net-ai-port=<ports>  TCP ASTERIX input listen ports (default: 0)
      --net-asterix-reduce   Apply beast reduce logic and interval to ASTERIX
                             outputs
      --net-verbatim         Forward messages unchanged
      --net-vrs-interval=<seconds>
                             TCP VRS json output interval (default: 5.0)
      --net-vrs-port=<ports> TCP VRS json output listen ports (default: 0)
      --uuid-file=<path>     path to UUID file

 Modes-S Beast options, use with --device-type modesbeast:
      --beast-baudrate=<baud>   Override Baudrate (default rate 3000000 baud)
      --beast-crc-off        Turn OFF CRC checking
      --beast-df045-on       Turn ON DF0/4/5 filter
      --beast-df1117-on      Turn ON DF11/17-only filter
      --beast-fec-off        Turn OFF forward error correction
      --beast-mlat-off       Turn OFF MLAT time stamps
      --beast-modeac         Turn ON mode A/C
      --beast-serial=<path>  Path to Beast serial device (default
                             /dev/ttyUSB0)

 GNS HULC options, use with --device-type gnshulc:
      --beast-serial=<path>  Path to GNS HULC serial device (default
                             /dev/ttyUSB0)

 ifile-specific options, use with --ifile:
      --ifile=<path>         Read samples from given file ('-' for stdin)
      --iformat=<type>       Set sample format (UC8, SC16, SC16Q11)
      --throttle             Process samples at the original capture speed

 Help options:

  -?, --help                 Give this help list
      --usage                Give a short usage message
  -V, --version              Print program version

readsb's People

Contributors

dennis14e avatar dxmekch avatar ericsesterhennx41 avatar huusky avatar k2fc avatar mikeage avatar palhaland avatar rush0815 avatar tjmullicani avatar wiedehopf avatar

Stargazers

 avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar

Watchers

 avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar

readsb's Issues

GPS to readsb

I followed the following steps.

GPS: u blox vtk172 USB GPS.

  1. Installed gpsd & gpsd-clients
  2. /etc/default/gpsd:
 # Devices gpsd should collect to at boot time.
# They need to be read/writeable, either by user gpsd or the group dialout.
DEVICES=""

# Other options you want to pass to gpsd
GPSD_OPTIONS="/dev/ttyACM0"
# Automatically hot add/remove USB GPS devices via gpsdctl
USBAUTO="true"

`START_DAEMON="true"
  1. Tested gps with xgps and it works.
  2. After adding the --net-connector localhost,2947,gpsd_in to the readsb config, I get lats and long reading 0 when running cgps -s. Only after I stop the readsb.service, do I immediately regain lats and longs on the cgps -s page whcih seems like it then frees up ttyACM0 and the I can regain my coordinates, instead of it reading just 0
    How can I fix this?

Thanks!

readsb with mode-s beast problem

I have a modesbeast board but have problem with readsb
It seems readsb can't set baudrate to 1000000? Test with microcom and same baudrate is normal output beast message.
But if not add --beast-baudrate=1000000 readsb will abnormal exit
Test:
sudo readsb --device-type modesbeast --beast-serial=/dev/ttyUSB1 --beast-baudrate=1000000
Mon Aug 22 02:41:40 2022 CST readsb starting up.
readsb version: wiedehopf git: 365daf3 (committed: Fri Aug 12 02:36:00 2022 0200)
Beast cfsetispeed(/dev/ttyUSB1, 1000000): Invalid argument
Mon Aug 22 02:41:40 2022 CST sdrOpen() failed, exiting!
Mon Aug 22 02:41:40 2022 CST Abnormal exit.
tianyi@BPI-M2:~ $ sudo readsb --device-type modesbeast --beast-serial=/dev/ttyUSB0 --beast-baudrate=1000000
Mon Aug 22 02:41:52 2022 CST readsb starting up.
readsb version: wiedehopf git: 365daf3 (committed: Fri Aug 12 02:36:00 2022 0200)
Beast cfsetispeed(/dev/ttyUSB0, 1000000): Invalid argument
Mon Aug 22 02:41:52 2022 CST sdrOpen() failed, exiting!
Mon Aug 22 02:41:52 2022 CST Abnormal exit.
tianyi@BPI-M2:~ $
tianyi@BPI-M2:~ $ microcom -p /dev/ttyUSB0 -s 1000000
connected to /dev/ttyUSB0
Escape character: Ctrl-
Type the escape character to get to the prompt.
+0000B00000000000000000000000;
+0000B00000000000000000000000;
+0000B00000000000000000000000;
+00FFB00000000000000000000000;
+0000B00000000000000000000000;
+0000B00000000000000000000000;
+00FFB00000000000000000000000;
+00FFB00000000000000000000000;
+0001B00000000000000000000000;
+00FFB00000000000000000000000;
+0000B00000000000000000000000;
+0000B00000000000000000000000;
+0000B00000000000000000000000;
+0000B00000000000000000000000;
+0001B00000000000000000000000;
+0000B00000000000000000000000;
+0001B00000000000000000000000;
+0000B00000000000000000000000;
+0000B00000000000000000000000;
+0000B00000000000000000000000;
+0000B00000000000000000000000;
+0000B00000000000000000000000;
+0000B00000000000000000000000;
+0000B00000000000000000000000;
+0000B00000000000000000000000;
+0000B00000000000000000000000;
+0000B00000000000000000000000;
+00FFB00000000000000000000000;
+00FFB00000000000000000000000;
+0000B00000000000000000000000;
+0001B00000000000000000000000;
+0000B00000000000000000000000;
+0000B00000000000000000000000;
+0001B00000000000000000000000;
+0000B00000000000000000000000;
+0000B00000000000000000000000;
+0000B00000000000000000000000;
+0000B00000000000000000000000;
+00FFB00000000000000000000000;

Enter command. Try 'help' for a list of builtin commands
exiting
tianyi@BPI-M2:~ $ sudo readsb --device-type modesbeast --beast-serial=/dev/ttyUSB0
Mon Aug 22 02:43:54 2022 CST readsb starting up.
readsb version: wiedehopf git: 365daf3 (committed: Fri Aug 12 02:36:00 2022 0200)
Running Mode-S Beast via USB.
<3>FATAL: removeStale() interval 60.1 seconds! Trying for an orderly shutdown as well as possible!
<3> priorityTasksRun didn't run for 60.1 seconds!
<3> removeStale didn't run for 59.1 seconds!
Mon Aug 22 02:44:54 2022 CST Abnormal exit.
tianyi@BPI-M2:~ $
Try stty -F /dev/ttyUSB0 ispeed 1000000 ospeed 1000000
but not work for me.
tianyi@BPI-M2:~ $ lsusb
Bus 001 Device 005: ID 10c4:ea70 Silicon Labs CP2105 Dual UART Bridge
Bus 001 Device 004: ID 0bda:2838 Realtek Semiconductor Corp. RTL2838 DVB-T
Bus 001 Device 003: ID 0424:ec00 Microchip Technology, Inc. (formerly SMSC) SMSC9512/9514 Fast Ethernet Adapter
Bus 001 Device 002: ID 0424:9514 Microchip Technology, Inc. (formerly SMSC) SMC9514 Hub
Bus 001 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub
readsb with RTLSDR is working.

Separate session of readsb to only import api

I want to run a separate session of tar1090 and readsb that only reads FROM an JSON file from https://api.adsb.lol/v2/all

This is to be updated every 30-60 seconds and I would like the data (and possibly tracks) to show on tar1090.

Is this possible? All the reading I can find relates to connecting back to a beast port. This caused me a data loop.

I'm only looking to take a snapshot (as a bot) based on data in the API.

Thanks

GCC unroll is a GCC 8 feature, not a GCC 7 one

It appears GCC 8 introduced _Pragma ("GCC unroll N") not GCC 7.
Ref: https://gcc.gnu.org/gcc-8/changes.html

A new pragma GCC unroll has been implemented in the C family of languages [...]

diff --git a/readsb.h b/readsb.h
index 994abf7..0ca42bc 100644
--- a/readsb.h
+++ b/readsb.h
@@ -357,7 +357,7 @@ typedef enum {
 
 #elif defined(__GNUC__)
 
-#if __GNUC__ >= 7
+#if __GNUC__ > 7
 #define _unroll_8 _Pragma ("GCC unroll 8")
 #define _unroll_16 _Pragma ("GCC unroll 16")
 #define _unroll_32 _Pragma ("GCC unroll 32")

LMK if you need this one-char fix in a PR ๐Ÿ˜†

Many thanks! Hope my next contribution will be a bigger one ๐Ÿ™ˆ

Statistics inconsistency

Hi
I run "readsb --device-type rtlsdr --stats-every=1 --quiet"
to follow the number of valid frames received per seconds but, instead of a value expected to be around 40/s, the counter rise at each step then seems to reset before rising again (see below).
I use version wiedehopf git: a30c9c3 (committed: Wed Apr 20 13:11:02 2022 0200)
Bug or misunderstanding ?

`

218 accepted with correct CRC
398 accepted with correct CRC
588 accepted with correct CRC
785 accepted with correct CRC
979 accepted with correct CRC
1162 accepted with correct CRC
1315 accepted with correct CRC
1501 accepted with correct CRC
394 accepted with correct CRC
537 accepted with correct CRC
720 accepted with correct CRC
868 accepted with correct CRC
1025 accepted with correct CRC
313 accepted with correct CRC
514 accepted with correct CRC
670 accepted with correct CRC
827 accepted with correct CRC
987 accepted with correct CRC
328 accepted with correct CRC
473 accepted with correct CRC
689 accepted with correct CRC
782 accepted with correct CRC
946 accepted with correct CRC
`
Chris

Unknown error height

In recent use I have found that some of the ground data received by the aircraft after landing or preparing to take off will be decoded into the air. It is not continuous but intermittent. I am close to the airport, and the surrounding area is relatively open, may I ask whether this is the decoding problem of readsb or the environment

Couldn't compile on Alpine Linux (musl)

Hi,

currently I get following error message compiling on Alpine Linux:

In file included from readsb.c:54:
readsb.h:357:18: error: missing binary operator before token "("
  357 | #if __GNUC_PREREQ(8,0)
     |                  ^
make: *** [Makefile:117: readsb.o] Error 1

Also see here.

squawk not always read from SBS JAERO inputs

Background: I'm extracting positions from ACARS/HFDL messages and forwarding them to readsb (as embedded in the ultrafeeder and tar1090 containers). I'm trying to differentiate the source of the position (ACARS vs HFDL) by setting the squawk to either 1111 or 3333.

Not every line of the tar1090 aircraft list shows a squawk. There are some 1111, some 3333, and some blank. Not entirely sure if the issue is in readsb or tar1090.

Debian build fails due missing dh-systemd package on Bullseye

As per https://bugs.debian.org/822670, the dh-systemd package has been merged with the main debhelper package since version 9.20160709

For some time, a transitional dh-systemd package existed which simply depended on debhelper. However, this was removed from bullseye.

The fix should be as simple as depending on debhelper (>= 9.20160709), which available on all supported Debian releases and all supported Ubuntu releases except for xenial.

Rsp1a with readsb

Hello is there a way tu use a rsp1a instead of a dongle RTL-SDR ?

If yes how is it possible ?

alternating gain

At a local airport we have an ADS-B receiver, but it is swamped by strong signals. Of course we could reduce the (optimized) gain, but then planes further away will not be received.
I don't know how invasive the gain switching is, but I was wondering if the following would work. When a signal has been received that's too strong (or perhaps simply constantly), the gain is reduced for 1.5 seconds, then switches back to normal gain for 7 seconds, after which it repeats. Maybe these times should be somewhat randomized.
How far to reduce during this 1.5 seconds low-gain window? Well maybe "a lot" (30 dB less? to minimum?) might just work, or perhaps the user could set it.
I was thinking of some gain regulator, and while that works for approaching aircraft that get louder and louder, that doesn't work well for airports where aircraft can startup nearby unexpectedly. So I think a fixed reduced gain would be best.
I chose the times based on this https://aviation.stackexchange.com/questions/78952/what-is-the-broadcast-rate-of-an-ads-b-message .
What do you think about this?

Short documentation of how readsb is utilizing mlat

Hello,
this is more an understanding topic rather than an issue.
I am wondering how readsb is getting mlat information.
I am running readsb with tar1090.
So in tar1090 I can observe that there are several aircrafts tracked using mlat.
If I read directly from the json port of readsb I can see the mlat fields.
Where readsb is getting this information from? For that purpose it would need to talk to different services or talk to different readsb instances in order to do triangulation?
I can not really find this in code but maybe I am also wrong or overseeing this.

Thank you in advance!
Great work

Uncompiled code

There are a couple of ifs that always will evaluate to 0, should these be removed, replaced with a macro, or removed the 0 && so that they are compiled in?

A lot of them are debug (fprintf).

globe_index.c:776:    if (0 && a->addr == TRACE_FOCUS)
globe_index.c-777-        fprintf(stderr, "mw: %.0f, perm: %.0f, count: %d\n",
globe_index.c-778-                ((int64_t) a->trace_next_mw - (int64_t) now) / 1000.0,
--
globe_index.c:843:        if (0 && oldSize != newSize) {
globe_index.c-844-            fprintf(stderr, "%06x size mismatch when replacing aircraft data, aborting!\n", source->addr);
globe_index.c-845-            return -1;
--
globe_index.c:1218:            if (0 && focus) {
globe_index.c-1219-                time_t nowish = state->timestamp/1000;
globe_index.c-1220-                struct tm utc;
--
globe_index.c:1250:            if (0 && focus) {
globe_index.c-1251-                time_t nowish = state->timestamp/1000;
globe_index.c-1252-                struct tm utc;
--
globe_index.c:1286:                    if (0 && focus) {
globe_index.c-1287-                        fprintf(stderr, "k: %d %d %d %d\n", k, (int) (st->baro_alt / _alt_factor), st->baro_alt_valid, st->on_ground);
globe_index.c-1288-                    }
--
globe_index.c:1327:        if (0 && elapsed > 30 * 60 * 1000 && (state->on_ground || !state->baro_alt_valid || (state->baro_alt_valid && state->baro_alt / _alt_factor < max_leg_alt))) {
globe_index.c-1328-            double distance = greatcircle(
globe_index.c-1329-                    (double) state->lat * 1e-6,
--
globe_index.c:1485:    if (0 && ca->reader_count > 1) {
globe_index.c-1486-        fprintf(stderr, "ca->reader_count %d\n", ca->reader_count);
globe_index.c-1487-    }
--
globe_index.c:1713:        if (0 && Modes.verbose) {
globe_index.c-1714-            fprintf(stderr, "%06x deleting %d chunks\n", a->addr, deletedChunks);
globe_index.c-1715-        }
--
globe_index.c:1729:        if (0 && Modes.verbose) {
globe_index.c-1730-            fprintf(stderr, "%s%06x tracePrune a->trace_current: %d\n",
globe_index.c-1731-                    ((a->addr & MODES_NON_ICAO_ADDRESS) ? "." : ". "), a->addr, SFOUR * deleteFs);
--
globe_index.c:2014:        if (0 && lastChunk && memcmp(zstd_magic, lastChunk->compressed, sizeof(zstd_magic)) == 0) {
globe_index.c-2015-            // recompress finished buffer
globe_index.c-2016-            recompressStateChunk(lastChunk, passbuffer);
--
globe_index.c:2043:        if (0 && Modes.json_dir) {
globe_index.c-2044-            char path[1024];
globe_index.c-2045-            snprintf(path, 1024, "%s/tracechunk_samples/%06x", Modes.json_dir, a->addr);
--
globe_index.c:2174:        if (0 && Modes.verbose) {
globe_index.c-2175-            fprintf(stderr, "len %d max %d\n", a->trace_current_len, a->trace_current_max);
globe_index.c-2176-        }
--
json_out.c:1264:        if (0 && (p + 2000) >= end) {
json_out.c-1265-            int used = p - buf;
json_out.c-1266-            alloc *= 2;
--
json_out.c:1609:    if (0 && a->addr == TRACE_FOCUS) {
json_out.c-1610-        fprintf(stderr, "%06x sprintCache: %d points firstRecent starting %d (firstRecentCache starting %d, max %d)\n", a->addr, tb.len - firstRecent, firstRecent, firstRecentCache, Modes.traceCachePoints);
json_out.c-1611-    }
--
json_out.c:1687:        if (0 && state->timestamp < lastTs) {
json_out.c-1688-            fprintf(stderr, "%06x trace timestamps wrong order: %.3f %.3f i: %d k: %d %s\n", a->addr, lastTs / 1000.0, state->timestamp / 1000.0, i, k, stringStart);
json_out.c-1689-        }
--
json_out.c:1786:            if (0 && a->addr == TRACE_FOCUS) {
json_out.c-1787-                fprintf(stderr, "%06x using tCache starting with tCache->firstRecentCache %d stateIndex %d\n", a->addr, tCache->firstRecentCache, start);
json_out.c-1788-            }
--
mode_s.c:1807:    if (0 && mm->cpr_valid && mm->cpr_decoded) {
mode_s.c-1808-        printf("systemTime: %.3fs\n", (mm->sysTimestamp % (5*MINUTES)) / 1000.0);
mode_s.c-1809-        printf("  CPR odd flag:  %s\n",
--
net_io.c:672:    if (0 && Modes.debug_net) {
net_io.c-673-        fprintf(stderr, "serviceListen: %s with SNDBUF %d RCVBUF %d)\n", service->descr,  getSNDBUF(service), getRCVBUF(service));
net_io.c-674-    }
--
net_io.c:1174:    if (0 && Modes.debug_ping)
net_io.c-1175-        fprintf(stderr, "readPing: %d\n", res);
net_io.c-1176-    return res;
--
net_io.c:1184:    if (0 && Modes.debug_ping)
net_io.c-1185-        fprintf(stderr, "readPing: %d\n", res);
net_io.c-1186-    return res;
--
net_io.c:1209:    if (0 && Modes.debug_ping)
net_io.c-1210-        fprintf(stderr, "Sending Ping c: %d\n", ping);
net_io.c-1211-}
--
net_io.c:2502:        if (0 && Modes.debug_ping)
net_io.c-2503-            fprintf(stderr, "Got Ping: %d\n", c->ping);
net_io.c-2504-    } else if (p[0] == '1') {
--
net_io.c:3075:    if (0 && Modes.netIngest && !Modes.debug_no_discard) {
net_io.c-3076-        if (now - c->recentMessagesReset > 1 * SECONDS) {
net_io.c-3077-            c->recentMessagesReset = now;
--
net_io.c:4322:        } else if (0 && !ac) {
net_io.c-4323-            if (mm->addr != HEX_UNKNOWN && !dbGet(mm->addr, Modes.dbIndex))
net_io.c-4324-                displayModesMessage(mm);
--
track.c:169:    if (0 && is_pos && a->addr == Modes.cpr_focus) {
track.c-170-        //fprintf(stderr, "%d %p %p\n", mm->duplicate, d, &a->pos_reliable_valid);
track.c-171-        fprintf(stderr, "%d %s", mm->duplicate, source_string(mm->source));
--
track.c:425:    if (0 && mm->sbs_in && a->addr == Modes.cpr_focus) {
track.c-426-        fprintf(stderr, ".");
track.c-427-    }
--
track.c:443:    if (0 && (a->prev_lat == lat && a->prev_lon == lon) && (Modes.debug_cpr || Modes.debug_speed_check || a->addr == Modes.cpr_focus)) {
track.c-444-        fprintf(stderr, "%06x now - seen_pos %6.3f now - prev_pos_time %6.3f\n",
track.c-445-                a->addr,
--
track.c:780:            if (0 && (a->addr == Modes.cpr_focus || Modes.debug_cpr)) {
track.c-781-                fprintf(stderr, "%06x CPRsurface ref %d refDistance: %4.0f km (%4.0f, %4.0f) allow_ac_rel %d\n", a->addr, ref, refDistance / 1000.0, reflat, reflon, a->surfaceCPR_allow_ac_rel);
track.c-782-            }
--
track.c:963:    if (0 && a->addr == Modes.cpr_focus) {
track.c-964-        showPositionDebug(a, mm, now, 0, 0);
track.c-965-    }
--
track.c:981:        if (0 && (fabs(mm->decoded_lat) >= 90.0 || fabs(mm->decoded_lon) >= 180.0)) {
track.c-982-            fprintf(stderr, "%06x lat,lon out of bounds: %.2f,%.2f source: %s\n", a->addr, mm->decoded_lat, mm->decoded_lon, source_enum_string(mm->source));
track.c-983-        }
--
track.c:1053:        if (0 && a->addr == Modes.cpr_focus) {
track.c-1054-            fprintf(stderr, "%u\n", simpleHash(mm->receiverId));
track.c-1055-        }
--
track.c:1152:        if (0 && a->addr == Modes.trace_focus) {
track.c-1153-            fprintf(stderr, "%5.1fs traceAdd: %06x\n", (now % (600 * SECONDS)) / 1000.0, a->addr);
track.c-1154-        }
--
track.c:1213:    if (0 && a->addr == Modes.cpr_focus) {
track.c-1214-        fprintf(stderr, "%06x: reliability odd: %3.1f even: %3.1f status: %d\n", a->addr, a->pos_reliable_odd, a->pos_reliable_even, posReliable(a));
track.c-1215-    }
--
track.c:1762:        if (0 && a->addr == Modes.trace_focus && abs(delta) > -1) {
track.c-1763-            fprintf(stdout, "Alt check S: %06x: %2d %6d ->%6d, %s->%s, min %.1f kfpm, max %.1f kfpm, actual %.1f kfpm\n",
track.c-1764-                    a->addr, a->alt_reliable, a->baro_alt, alt,
--
track.c:2221:        if (0 && a->addr == Modes.cpr_focus)
track.c-2222-            fprintf(stderr, "E \n");
track.c-2223-    }
--
track.c:2232:        if (0 && a->addr == Modes.cpr_focus)
track.c-2233-            fprintf(stderr, "O \n");
track.c-2234-    }
--
track.c:2395:        if (0 && a->addr == Modes.cpr_focus) {
track.c-2396-            fprintf(stderr, "%06x: age: odd %"PRIu64" even %"PRIu64"\n",
track.c-2397-                    a->addr,
--
track.c:2421:                if (0 && greatcircle(a->mlat_lat, a->mlat_lon, mm->decoded_lat, mm->decoded_lon, 1) > 5000) {
track.c-2422-                    a->mlat_pos_valid.source = SOURCE_INVALID;
track.c-2423-                }
--
track.c:2429:                if (0 && a->pos_reliable_valid.source > SOURCE_MLAT) {
track.c-2430-                    fprintf(stderr, "%06x: %d\n", a->addr, mm->reduce_forward);
track.c-2431-                }
--
track.c:2480:                        if (0 && a->position_valid.last_source > SOURCE_INDIRECT && a->position_valid.source == SOURCE_INVALID) {
track.c-2481-                            mm->decoded_lat = a->lat;
track.c-2482-                            mm->decoded_lon = a->lon;
--
track.c:3612:    if (0 && a->addr == Modes.cpr_focus)
track.c-3613-        fprintf(stderr, "%06x: position_bad %.1f %.1f %u %u\n", a->addr, a->pos_reliable_odd, a->pos_reliable_even, mm->cpr_lat, mm->cpr_lon);
track.c-3614-}
--
track.h:640:    if (0 && Modes.position_persistence > reliable && reliable > 1 && (a->addr & MODES_NON_ICAO_ADDRESS || a->addrtype == ADDR_TISB_ICAO || a->addrtype == ADDR_ADSR_ICAO)) {
track.h-641-        reliable += 1; // require additional reliability for non-icao hex addresses
track.h-642-    }
--
net_io.c:1310:    if (Modes.debug_ping && 0) {
net_io.c-1311-        char uuid[64]; // needs 36 chars and null byte
net_io.c-1312-        sprint_uuid(c->receiverId, c->receiverId2, uuid);

Option '--throttle'

I've ported readsb to Windows and now trying to use it with the --ifile <IQ-file> and --throttle options is rather confusing.

Apart from epoll() and O_BINARY issue with binary data, it was quite easy to port to Windows.
First I generated IQ-data using rtl_sdr -f 1090M -s 2.4M -n 1E8 samples-bin.iq,
and running readsb.exe --device-type ifile --ifile samples-bin.iq shows:

*8d4785c1225c91b81a0820cd3afd;
hex:  4785c1   CRC: 000000 fixed bits: 0 decode: ok
RSSI:     -7.5 dBFS   reduce_forward: 1
Score: 1400
receiverTime:                    52492.08us
utcTime: 05:45:04.359 epoch: 1681883104.359
DF: 17 AA:4785C1 CA:5 ME:225C91B81A0820
 Extended Squitter Aircraft identification and category (4)
  ICAO Address:  4785C1 (adsb_icao)
  Air/Ground:    airborne
  Ident:         WIF8F
  Category:      A2

*a000061e8db00000000000a91648;
hex:  4785c1   CRC: 4785c1 fixed bits: 0 decode: ok
RSSI:     -7.4 dBFS   reduce_forward: 1
Score: 1000
receiverTime:                    57065.08us
utcTime: 05:45:04.363 epoch: 1681883104.363
DF: 20 addr: 4785c1   FS:0 DR:0 UM:0 AC:1566 MB:8DB00000000000
 Comm-B, Altitude Reply
  Comm-B format: BDS4,0 Selected vertical intention
  ICAO Address:  4785C1 (mode_s)
  Air/Ground:    airborne?
  Baro altitude:               8950 ft
  MCP selected altitude:       7008 ft
...

But adding the --throttle as in readsb.exe --throttle --device-type ifile --ifile samples-bin.iq, gives:

SDR type '(null)' not recognized; supported SDR types are:
  rtlsdr
  modesbeast
  gnshulc
  ifile
  none
invoked by: readsb.exe --throttle --device-type ifile --ifile samples-bin.iq

But it runs fine without throttling.

Experimenting with adding it last readsb.exe --device-type ifile --ifile samples-bin.iq --throttle,
takes 45 sec to complete. Makes sense (since a readsb.exe --device-type ifile --ifile samples-bin.iq, takes 10 sec to complete).

Why can't I have the --throttle option first?

BTW. using --interactive --throttle ..., readsb.exe crashes inside interactiveCleanup() since my PD-curses was not started.

UDP

Can UDP or TCP only streams be output?

Thanks

Can't compile on Alpine Linux: missing rawmemchr

When trying to compile readsb on Alpine Linux, I get the following error message:

#10 3.318 cc -DMODES_READSB_VERSION=\""wiedehopf git: b08247d (committed: Tue Jun 14 19:07:04 2022 0200)"\" -D_GNU_SOURCE -D_FORTIFY_SOURCE=2 -fstack-protector-strong -Wformat -Werror=format-security -DENABLE_RTLSDR -std=c11 -g -W -D_DEFAULT_SOURCE -Wall -Werror -fno-common -O2   -Wno-format-truncation -I/usr/include/ -I/usr/include/libusb-1.0  -c net_io.c -o net_io.o     
#10 3.379 net_io.c: In function 'decodeUatMessage':
#10 3.379 net_io.c:2776:17: error: implicit declaration of function 'rawmemchr'; did you mean 'memchr'? [-Werror=implicit-function-declaration]
#10 3.379  2776 |     char *eod = rawmemchr(som, '\0');
#10 3.379       |                 ^~~~~~~~~
#10 3.379       |                 memchr
#10 3.379 net_io.c:2776:17: error: initialization of 'char *' from 'int' makes pointer from integer without a cast [-Werror=int-conversion]
#10 4.328 cc1: all warnings being treated as errors
#10 4.331 make: *** [Makefile:122: net_io.o] Error 1

It looks like rawmemchr is not available under musl libc.
Is it possible to use another function than rawmemchr?

readsb ogn2dump1090

it is possible ?

work readsb with ogn2dump1090 ?
or can you fix it so does readsb work with ogn2

Compile on Alpine Linux -- __bswap_16

net_io.c is using the internal(?) glibc functions __bswap_16 and _32, so it fails compiling on Alpine Linux with

cc -DMODES_READSB_VERSION=\""wiedehopf git: 4f9ce66-dirty (committed: Sun Mar 13 15:55:13 2022 0100)"\" -D_GNU_SOURCE -D_FORTIFY_SOURCE=2 -fstack-protector-strong -Wformat -Werror=format-security -std=c11 -g -W -D_DEFAULT_SOURCE -Wall -Werror -fno-common -O2   -Wno-format-truncation -c net_io.c -o net_io.o
net_io.c: In function 'bam32ToDouble':
net_io.c:2066:32: error: implicit declaration of function '__bswap_32'; did you mean '__bswap32'? [-Werror=implicit-function-declaration]
 2066 |     return (double) ((int32_t) __bswap_32(bam) * 8.38190317153931E-08);
      |                                ^~~~~~~~~~
      |                                __bswap32
net_io.c: In function 'decodeHulcMessage':
net_io.c:2114:15: error: implicit declaration of function '__bswap_16'; did you mean '__bswap16'? [-Werror=implicit-function-declaration]
 2114 |         alt = __bswap_16(hsm.status.altitude);
      |               ^~~~~~~~~~
      |               __bswap16
cc1: all warnings being treated as errors
make: *** [Makefile:112: net_io.o] Error 1

godotengine/godot#25714

[nnn blob data] messages, how to investigate ?

I have created an application that sends SBS TCP JAERO messages. Although most of the time cooperation with readsb is fine,
sometimes the below message worries me that I send invalid SBS messages, or ?
Could not find where these messages are coming from.
Please show me how to dump the blob data in order to fix my application. TIA

Apr 23 04:09:10 cld67.example.net systemd[1]: Started readsb ADS-B receiver.
Apr 23 04:09:11 cld67.example.net readsb[25593]: invoked by: /usr/local/bin/readsb --fix --debug=nGRUXO --quiet --net-only --net-heartbeat 60 --net-ingest --net-receiver-id --heatmap-dir /usr/local/share/tar1090/html/globe_history --heatmap 30 --net-sbs-jaero-in-port=33303 --write-receiver-id-json --jaero-timeout 10 --write-json /run/readsb --json-location-accuracy 1 --db-file /usr/local/share/tar1090/aircraft.csv.gz --db-file-lt
Apr 23 04:09:11 cld67.example.net readsb[25593]: [2024-04-23 04:09:11.000 EEST] readsb starting up.
Apr 23 04:09:11 cld67.example.net readsb[25593]: readsb version: 3.14.1618 compiled on 2024-04-22, 02:14:51 (EET)
Apr 23 04:09:11 cld67.example.net readsb[25593]: 33303: SBS TCP input JAERO port
Apr 23 04:09:11 cld67.example.net readsb[25593]: Database update in progress!
Apr 23 04:09:11 cld67.example.net readsb[25593]: Database update first part took 0.561 seconds!
Apr 23 04:09:12 cld67.example.net readsb[25593]: Database update done! (critical part took 0.002 seconds)
Apr 23 04:09:51 cld67.example.net readsb[25593]: SBS TCP input JAERO connection count: 1
Apr 23 04:18:53 cld67.example.net readsb[25593]: new client: rId 47d664bc-2886-417c-0000-000000000000 host(127.0.0.1), port(51716)
Apr 23 05:41:01 cld67.example.net readsb[25593]: [285B blob data]
Apr 23 05:41:10 cld67.example.net readsb[25593]: [285B blob data]
Apr 23 05:41:38 cld67.example.net readsb[25593]: [284B blob data]
Apr 23 05:42:36 cld67.example.net readsb[25593]: [283B blob data]
Apr 23 05:42:36 cld67.example.net readsb[25593]: [283B blob data]
Apr 23 05:42:42 cld67.example.net readsb[25593]: [284B blob data]
Apr 23 05:43:46 cld67.example.net readsb[25593]: [283B blob data]
Apr 23 05:46:59 cld67.example.net readsb[25593]: [282B blob data]
Apr 23 05:48:03 cld67.example.net readsb[25593]: [282B blob data]
Apr 23 05:48:23 cld67.example.net readsb[25593]: [282B blob data]
Apr 23 05:48:27 cld67.example.net readsb[25593]: [282B blob data]
Apr 23 05:49:07 cld67.example.net readsb[25593]: [284B blob data]
Apr 23 05:50:11 cld67.example.net readsb[25593]: [282B blob data]
Apr 23 05:50:12 cld67.example.net readsb[25593]: [277B blob data]

Flight Aware ProStick receives 0 messages

Problem: I have a Flight Aware ProStick Plus that I cannot get to work. Apologies if this is the wrong place to ask, you can point me somewhere else.

Setup:
-PI Zero 2 W
-Clean fresh Install of Dietpi
-Clean Fresh Install of all of wiedehopf install scripts (readsb, tar1090, timelapse, graphs, auto-gain)

What I have tried:
-Reboot
-Reinstall readsb script
-Wipe SD and reinstall OS from scratch and run all scripts again

What works:
-Switching to a standard RTL-SDR dongle works and planes and messages start flowing immediately upon plugging it in.

What doesn't work:
-Using the exact same setup, antenna, pi, everything - just swapping SDR dongle the FA stick receives absolutely nothing.

Is my hardware bad, or is there something else required to make FA work?

Thank you!

Below is the log output of readsb with the FA stick. It seems to find it and connect correctly:

root@DietPi:~# sudo journalctl --no-page -u readsb
Feb 14 19:37:06 DietPi systemd[1]: Started readsb.service - readsb ADS-B receiver.
Feb 14 19:37:06 DietPi readsb[421]: invoked by: /usr/bin/readsb --device 0 --device-type rtlsdr --gain -10 --ppm 0 --lat 35.155777 --lon -85.316484 --max-range 450 --write-json-every 1 --net --net-heartbeat 60 --net-ro-size 1250 --net-ro-interval 0.05 --net-ri-port 30001 --net-ro-port 30002 --net-sbs-port 30003 --net-bi-port 30004,30104 --net-bo-port 30005 --json-location-accuracy 2 --range-outline-hours 24 --write-json /run/readsb --quiet
Feb 14 19:37:06 DietPi readsb[421]: [2024-02-14 19:37:06.285 GMT] readsb starting up.
Feb 14 19:37:06 DietPi readsb[421]: readsb version: 3.14.1607 wiedehopf git: d2f5725 (committed: Fri Feb 9 15:00:10 2024 0100)
Feb 14 19:37:06 DietPi readsb[421]: Using lat:   35.1558, lon:  -85.3165
Feb 14 19:37:06 DietPi readsb[421]: 30002: Raw TCP output port
Feb 14 19:37:06 DietPi readsb[421]: 30005: Beast TCP output port
Feb 14 19:37:06 DietPi readsb[421]: 30003: SBS TCP output ALL port
Feb 14 19:37:06 DietPi readsb[421]: 30001: Raw TCP input port
Feb 14 19:37:06 DietPi readsb[421]: 30004: Beast TCP input port
Feb 14 19:37:06 DietPi readsb[421]: 30104: Beast TCP input port
Feb 14 19:37:06 DietPi readsb[421]: rtlsdr: using device #0: Generic RTL2832U (Realtek, RTL2832U, SN 00001000)
Feb 14 19:37:06 DietPi readsb[421]: Detached kernel driver
Feb 14 19:37:06 DietPi readsb[421]: Found Rafael Micro R820T tuner
Feb 14 19:37:06 DietPi readsb[421]: rtlsdr: enabling tuner AGC
Feb 14 19:37:07 DietPi readsb[421]: Allocating 16 zero-copy buffers

Crashed with error message "High load: heatmap_and_stuff took 4113 ms!"

I'm running dev-branch and that may explain why there are errors, but I'll report it anyway.

Readsb crashed and this is from journalctl:

Sep 24 16:32:52 Spy readsb[26751]: 30104: Beast TCP input port
Sep 24 21:23:03 Spy readsb[26751]: High load: heatmap_and_stuff took 4113 ms! Suppressing for 30 seconds
Sep 24 21:23:26 Spy readsb[26751]: FATAL: trackPeriodicUpdate() interval 11.1 seconds! Trying for an orderly shutdown as well as possible!
Sep 24 21:23:26 Spy readsb[26751]: lockThreads() probably hung on statsWrite
Sep 24 21:23:28 Spy readsb[26751]: upkeep thread: threadSignalJoin timed out after 2.0 seconds, undefined behaviour may result!
Sep 24 21:23:28 Spy readsb[26751]: saving state .....
Sep 24 21:25:30 Spy readsb[26751]:  .......... done, saved 52 aircraft in 121.898 seconds!
Sep 24 21:25:30 Spy readsb[26751]: FATAL: thread upkeep could not be joined, calling abort()!
Sep 24 21:25:30 Spy systemd[1]: readsb.service: Main process exited, code=killed, status=6/ABRT
Sep 24 21:25:30 Spy systemd[1]: readsb.service: Failed with result 'signal'.
Sep 24 21:26:00 Spy systemd[1]: readsb.service: Service RestartSec=30s expired, scheduling restart.
Sep 24 21:26:00 Spy systemd[1]: readsb.service: Scheduled restart job, restart counter is at 1.
Sep 24 21:26:00 Spy systemd[1]: Stopped readsb ADS-B receiver.
Sep 24 21:26:00 Spy systemd[1]: Started readsb ADS-B receiver.
Sep 24 21:26:00 Spy readsb[10692]: readsb version: wiedehopf git: f06374e (commited: Tue Sep 21 13:34:41 2021 0200)
Sep 24 21:26:00 Spy readsb[10692]: Using lat:   60.9211, lon:   16.6788
Sep 24 21:26:00 Spy readsb[10692]: loading state .....
Sep 24 21:26:00 Spy readsb[10692]:  .......... done, loaded 52 aircraft in 0.006 seconds!
Sep 24 21:26:00 Spy readsb[10692]: aircraft table fill: 0.0
Sep 24 21:26:00 Spy readsb[10692]: actual range outline, read bytes: 144004
Sep 24 21:26:00 Spy readsb[10692]: Database update done!
Sep 24 21:26:00 Spy readsb[10692]: 30002: Raw TCP output port            30005: Beast TCP output port
Sep 24 21:26:00 Spy readsb[10692]: 30003: SBS TCP output ALL port        30004: Beast TCP input port
Sep 24 21:26:00 Spy readsb[10692]: 30104: Beast TCP input port

I'm running with the following arguments:

/usr/bin/readsb --net-only --write-json-every 1 --db-file tar1090 --lat XX.XXXXX --lon YY.YYYYY --max-range 720 --heatmap-dir /var/globe_history --heatmap 30 --write-state=/var/globe_history --write-prom=/usr/share/dump1090-fa/html/data-prom --net --net-heartbeat 60 --net-ro-size 1280 --net-ro-interval 0.05 --net-ri-port 0 --net-ro-port 30002 --net-sbs-port 30003 --net-bi-port 30004,30104 --net-bo-port 30005 --json-location-accuracy 2 --write-json /run/readsb --quiet

Something happened that consumed a lot of CPU (the system has approx 50% CPU usage from airspy_adsb, no other jobs are running besides generating graphs for graphs1090 and some statistical scripts, but they run only once per day and at another time.

SDR type 'bladerf' not recognized

Hello,
I have both PlutoSDR and BladeRF. I wanted to upload your Github code as in the descriptions and run it over SDR. With PlutoSDR your code worked just fine, but not with BladeRF. The reason for this is that the phrase plutosdr appears in the device type selection section, but bladerf does not appear(After doing "dpkg-buildpackage -b --build-profiles=rtlsdr,bladerf,plutosdr".). Would you help me with this topic?
Thank you for your understanding.

sdr device support

it seems to me rtl-sdr devices are supported at moment only , but is saw there are some files for other other devices like pluto-sdr...
so which devices work with readsb at moment and which are planed? i would like to get pluto or sdrplay run. would be happy for some informations.

thx

Option '--bladerf-fpga' is not recognized

Getting the following error when using the command line switch '--bladerf-fpga'.

$ sudo ./readsb --device-type=bladerf --bladerf-fpga=/usr/share/Nuand/bladeRF/adsbxA4.rbf
Error parsing the given command line parameters, check readsb --usage and readsb --help for valid parameters.
invoked by: ./readsb --device-type=bladerf --bladerf-fpga=/usr/share/Nuand/bladeRF/adsbxA4.rbf

This appears to be caused by

readsb/help.h

Line 166 in fc50225

{"bladerf-fpga", 1001, "<path>", 0, "Use alternative FPGA bitstream ('' to disable FPGA load)", 4},

referencing the value 1001 instead of OptBladeFpgaDir.

Double-free in 'convert.c'

Running the convert_benchmark.exe program on Windows, I got a Dr. Watson assert in cleanup_converter() since
AFAICS, the uc8_lookup pointer was already freed.

This little patch fixed it:

--- a/convert.c 2022-06-25 18:49:20
+++ b/convert.c 2023-04-29 10:54:38
@@ -496,5 +496,7 @@
     free(uc8_lookup);
 #if defined(SC16Q11_TABLE_BITS)
     free(sc16q11_lookup);
+    sc16q11_lookup = NULL;
 #endif
+    uc8_lookup = NULL;
 }

BTW1, I've not built with -DSC16Q11_TABLE_BITS. But assume it has the same issue.

BTW2, here are my results on AMD 3.8GHz (with clang-cl):

Benchmarking: SC16Q11, DC   1451.28M samples in 5.000000 seconds
  290.26M samples/second
Benchmarking: SC16Q11, no DC   2352.60M samples in 5.000000 seconds
  470.52M samples/second
Benchmarking: UC8, DC   1157.00M samples in 5.000000 seconds
  231.40M samples/second
Benchmarking: UC8, no DC   8046.42M samples in 5.000000 seconds
  1609.28M samples/second
Benchmarking: SC16, DC   1474.06M samples in 5.000000 seconds
  294.81M samples/second
Benchmarking: SC16, no DC   2413.32M samples in 5.000000 seconds
  482.66M samples/second

Feature request: include ownerOperator + year in aircraft.json

Just wondering if it would be possible (either controlled by the --db-file-lt, if we treated that as just 'detailed registration output', or perhaps another separate flag) for the aircraft.json output to also include the operator + year fields from the DB, if present (ownOp and year)? This would be useful information for me to visualize in a project of mine.

Thanks so much!

bladeRF error after loading bitstream FPGA image

Get the following error when using readsb with a Nuand bladeRF 2.0 micro xA4:

bladeRF: loading FPGA bitstream from /usr/share/Nuand/bladeRF/hostedxA4.rbf
Calibration TIMEOUT (0x16, 0x80)
[ERROR @ host/libraries/libbladeRF/src/board/bladerf2/rfic_host.c:397] _rfic_host_set_sample_rate: ad9361_set_rx_sampling_freq(phy, rate) failed: An unexpected error occurred
[ERROR @ host/libraries/libbladeRF/src/board/bladerf2/bladerf2.c:1131] bladerf2_set_sample_rate: rfic->set_sample_rate(dev, ch, rate) failed: An unexpected error occurred
bladerf_set_sample_rate failed: An unexpected error occurred
[2023-11-17 16:08:09.641 UTC] sdrOpen() failed, exiting!
[2023-11-17 16:08:09.648 UTC] Abnormal exit.

trace.json and history_x.json not being created

Hardware Info

  • Raspberry Pi 3B+ 1GB
  • 0bda:2838 Realtek Semiconductor Corp. RTL2838 DVB-T

Software Info

readsb version

readsb version: 3.14.1595 wiedehopf git: a25f8ea (committed: Fri Nov 11 18:19:32 2022 0100)

Program options

cat /etc/default/readsb
# readsb configuration
# This is sourced by /etc/systemd/system/default.target.wants/readsb.service as
# daemon startup configuration.

RECEIVER_OPTIONS="--device 0 --device-type rtlsdr --gain -10 --ppm 0"
DECODER_OPTIONS="--lat xxx --lon yyy --max-range 450 --write-json-every 1"
NET_OPTIONS="--net --net-heartbeat 60 --net-ro-size 1250 --net-ro-interval 0.05 --net-ri-port 30001 --net-ro-port 30002 --net-sbs-port 30003 --net-bi-port 30004,30104 --net-bo-port 30005"
JSON_OPTIONS="--json-location-accuracy 2 --range-outline-hours 24 --json-trace-interval 1"
OTHER_OPTIONS="--heatmap-dir /run/readsb --heatmap 5 --write-state /run/readsb --write-globe-history /run/readsb"

I installed readsb using the scripted method outlined in the README. fr24feed is reading from the beast output.

Problem

trace.json and history.json are not being written to the /run/readsb directory. History files are being written to /run/tar1090/.

pi@raspberrypi:~ $ ls -l /run/readsb/
total 40
drwxr-xr-x 3 readsb nogroup   60 Dec  4 18:01 2022
-rw-r--r-- 1 readsb nogroup  276 Dec  4 18:44 aircraft.binCraft.zst
-rw-r--r-- 1 readsb nogroup 1611 Dec  4 18:44 aircraft.json
drwxr-xr-x 2 readsb nogroup 3720 Dec  4 18:44 internal_state
-rw-r--r-- 1 readsb nogroup 5803 Dec  4 18:44 outline.json
-rw-r--r-- 1 readsb nogroup  251 Dec  4 18:01 receiver.json
-rw-r--r-- 1 readsb nogroup 5877 Dec  4 18:44 stats.json
-rw-r--r-- 1 readsb nogroup 3128 Dec  4 18:44 stats.prom
-rw-r--r-- 1 readsb nogroup  336 Dec  4 18:44 status.json
-rw-r--r-- 1 readsb nogroup  496 Dec  4 18:44 status.prom

pi@raspberrypi:~ $ ls -l /run/tar1090/
...
-rw-r--r-- 1 tar1090 nogroup  298 Dec  4 18:43 history_1670179396928.json
-rw-r--r-- 1 tar1090 nogroup  298 Dec  4 18:43 history_1670179404939.json
...

Am I missing a configuration option or doing something otherwise incorrect to not be getting these files?

Update piaware package

Hello all,

I built my feeder a while ago and haven't touched it since. The Piaware feeder specifically is very finicky and as of late it has been crashing. The only way I know is that I get the "your feeder is offline" email from FlightAware.

Quick google search shows that others have had issues with PiAware working consistently, so I'm wondering if it will break anything set up by the readsb-install if I update that package manually using apt.

Specifically, these are the relevant updates available from running "apt update":

piaware-repository/unknown 7.2~bpo10+1 all [upgradable from: 6.1] piaware/unknown 7.2~bpo10+1 armhf [upgradable from: 7.1~bpo10+1]

Thoughts?

Edit: I should clarify that I did update the readsb installation using the script. However, the piaware feeder was not updated during that process. When that feeder crashes, it gets stuck at 100% CPU usage and only a reboot fixes it.

Feature Request: Support for Multiple Receivers with Different Frequencies

Title: Enhance Multi-Receiver Capability for Varied Frequencies

Description:
I would like to propose a feature request for readsb to include support for the simultaneous use of multiple receivers, each dedicated to different frequencies. Specifically, this would enable users to employ separate receivers for ADS-B and UAT (Universal Access Transceiver) frequencies concurrently.

Use Case:
Currently, readsb primarily focuses on receiving and decoding signals from ADS-B transponders at a specific frequency. With the growing adoption of UAT for additional aircraft information, it would be highly beneficial to have the capability to use a separate receiver tuned to the UAT frequency concurrently. This enhancement would provide a more comprehensive and versatile solution for users interested in monitoring both ADS-B and UAT transmissions simultaneously.

Requested Features:

  1. Multi-Receiver Configuration: Allow users to configure and use multiple receivers within readsb, with each receiver dedicated to a specific frequency band.

  2. Frequency Specification: Provide options for users to define the frequency for each receiver independently. For example, one receiver for ADS-B at 1090 MHz and another for UAT at a different frequency.

  3. Enhanced Networking Support: Extend networking options to accommodate multiple receivers, allowing users to forward data from different receivers to distinct output ports or protocols.

  4. Configuration Management: Include configuration parameters in the readsb configuration files or command line options to specify the details of each receiver, such as device type, frequency, gain, and network settings.

Benefits:

  • Expanded Coverage: Users can monitor multiple frequency bands simultaneously, expanding coverage and capturing a more comprehensive set of aircraft data.
  • Flexibility: Tailoring each receiver to a specific frequency allows for greater flexibility in adapting readsb to various aviation communication standards.
  • Real-time Monitoring: Improved real-time monitoring capabilities by simultaneously decoding and processing data from different frequency bands.

Note:
This feature request aims to enhance the versatility of readsb by accommodating users with diverse needs in the ADS-B and UAT monitoring space. The ability to utilize multiple receivers with different frequencies would contribute to the software's utility and relevance in evolving aviation communication scenarios.

argp leaks

When using the version / usage / help commands, configSetDefaults() is called before parseCommandLine(...). argp_parse(...) checks for the version / usage / help commands, prints the appropriate output, and then exits without cleaning up the defaults.

$ valgrind --track-origins=yes --show-leak-kinds=all --leak-check=full ./readsb --help
==185857== Memcheck, a memory error detector
==185857== Copyright (C) 2002-2017, and GNU GPL'd, by Julian Seward et al.
==185857== Using Valgrind-3.18.1 and LibVEX; rerun with -h for copyright info
==185857== Command: ./readsb --help
==185857==
.....
==185857== 
==185857== HEAP SUMMARY:
==185857==     in use at exit: 4,080 bytes in 16 blocks
==185857==   total heap usage: 18 allocs, 2 frees, 5,117 bytes allocated
==185857== 
==185857== 2 bytes in 1 blocks are still reachable in loss record 1 of 16
==185857==    at 0x4848899: malloc (in /usr/libexec/valgrind/vgpreload_memcheck-amd64-linux.so)
==185857==    by 0x4B3F58E: strdup (strdup.c:42)
==185857==    by 0x110932: configSetDefaults (readsb.c:124)
==185857==    by 0x110932: main (readsb.c:2532)
==185857== 
==185857== 2 bytes in 1 blocks are still reachable in loss record 2 of 16
==185857==    at 0x4848899: malloc (in /usr/libexec/valgrind/vgpreload_memcheck-amd64-linux.so)
==185857==    by 0x4B3F58E: strdup (strdup.c:42)
==185857==    by 0x110941: configSetDefaults (readsb.c:125)
==185857==    by 0x110941: main (readsb.c:2532)
==185857== 
==185857== 2 bytes in 1 blocks are still reachable in loss record 3 of 16
==185857==    at 0x4848899: malloc (in /usr/libexec/valgrind/vgpreload_memcheck-amd64-linux.so)
==185857==    by 0x4B3F58E: strdup (strdup.c:42)
==185857==    by 0x110950: configSetDefaults (readsb.c:126)
==185857==    by 0x110950: main (readsb.c:2532)
==185857== 
==185857== 2 bytes in 1 blocks are still reachable in loss record 4 of 16
==185857==    at 0x4848899: malloc (in /usr/libexec/valgrind/vgpreload_memcheck-amd64-linux.so)
==185857==    by 0x4B3F58E: strdup (strdup.c:42)
==185857==    by 0x11095F: configSetDefaults (readsb.c:127)
==185857==    by 0x11095F: main (readsb.c:2532)
==185857== 
==185857== 2 bytes in 1 blocks are still reachable in loss record 5 of 16
==185857==    at 0x4848899: malloc (in /usr/libexec/valgrind/vgpreload_memcheck-amd64-linux.so)
==185857==    by 0x4B3F58E: strdup (strdup.c:42)
==185857==    by 0x11096E: configSetDefaults (readsb.c:128)
==185857==    by 0x11096E: main (readsb.c:2532)
==185857== 
==185857== 2 bytes in 1 blocks are still reachable in loss record 6 of 16
==185857==    at 0x4848899: malloc (in /usr/libexec/valgrind/vgpreload_memcheck-amd64-linux.so)
==185857==    by 0x4B3F58E: strdup (strdup.c:42)
==185857==    by 0x11097D: configSetDefaults (readsb.c:129)
==185857==    by 0x11097D: main (readsb.c:2532)
==185857== 
==185857== 2 bytes in 1 blocks are still reachable in loss record 7 of 16
==185857==    at 0x4848899: malloc (in /usr/libexec/valgrind/vgpreload_memcheck-amd64-linux.so)
==185857==    by 0x4B3F58E: strdup (strdup.c:42)
==185857==    by 0x11098C: configSetDefaults (readsb.c:130)
==185857==    by 0x11098C: main (readsb.c:2532)
==185857== 
==185857== 2 bytes in 1 blocks are still reachable in loss record 8 of 16
==185857==    at 0x4848899: malloc (in /usr/libexec/valgrind/vgpreload_memcheck-amd64-linux.so)
==185857==    by 0x4B3F58E: strdup (strdup.c:42)
==185857==    by 0x11099B: configSetDefaults (readsb.c:131)
==185857==    by 0x11099B: main (readsb.c:2532)
==185857== 
==185857== 2 bytes in 1 blocks are still reachable in loss record 9 of 16
==185857==    at 0x4848899: malloc (in /usr/libexec/valgrind/vgpreload_memcheck-amd64-linux.so)
==185857==    by 0x4B3F58E: strdup (strdup.c:42)
==185857==    by 0x1109C5: configSetDefaults (readsb.c:135)
==185857==    by 0x1109C5: main (readsb.c:2532)
==185857== 
==185857== 2 bytes in 1 blocks are still reachable in loss record 10 of 16
==185857==    at 0x4848899: malloc (in /usr/libexec/valgrind/vgpreload_memcheck-amd64-linux.so)
==185857==    by 0x4B3F58E: strdup (strdup.c:42)
==185857==    by 0x1109DF: configSetDefaults (readsb.c:137)
==185857==    by 0x1109DF: main (readsb.c:2532)
==185857== 
==185857== 2 bytes in 1 blocks are still reachable in loss record 11 of 16
==185857==    at 0x4848899: malloc (in /usr/libexec/valgrind/vgpreload_memcheck-amd64-linux.so)
==185857==    by 0x4B3F58E: strdup (strdup.c:42)
==185857==    by 0x1109EE: configSetDefaults (readsb.c:138)
==185857==    by 0x1109EE: main (readsb.c:2532)
==185857== 
==185857== 2 bytes in 1 blocks are still reachable in loss record 12 of 16
==185857==    at 0x4848899: malloc (in /usr/libexec/valgrind/vgpreload_memcheck-amd64-linux.so)
==185857==    by 0x4B3F58E: strdup (strdup.c:42)
==185857==    by 0x1109FD: configSetDefaults (readsb.c:139)
==185857==    by 0x1109FD: main (readsb.c:2532)
==185857== 
==185857== 2 bytes in 1 blocks are still reachable in loss record 13 of 16
==185857==    at 0x4848899: malloc (in /usr/libexec/valgrind/vgpreload_memcheck-amd64-linux.so)
==185857==    by 0x4B3F58E: strdup (strdup.c:42)
==185857==    by 0x110A1A: configSetDefaults (readsb.c:140)
==185857==    by 0x110A1A: main (readsb.c:2532)
==185857== 
==185857== 13 bytes in 1 blocks are still reachable in loss record 14 of 16
==185857==    at 0x4848899: malloc (in /usr/libexec/valgrind/vgpreload_memcheck-amd64-linux.so)
==185857==    by 0x4B3F58E: strdup (strdup.c:42)
==185857==    by 0x14F41F: beastInitConfig (sdr_beast.c:45)
==185857==    by 0x14FC59: sdrInitConfig (sdr.c:126)
==185857==    by 0x110B8D: configSetDefaults (readsb.c:188)
==185857==    by 0x110B8D: main (readsb.c:2532)
==185857== 
==185857== 41 bytes in 1 blocks are still reachable in loss record 15 of 16
==185857==    at 0x4848899: malloc (in /usr/libexec/valgrind/vgpreload_memcheck-amd64-linux.so)
==185857==    by 0x4B3F58E: strdup (strdup.c:42)
==185857==    by 0x110AB1: configSetDefaults (readsb.c:155)
==185857==    by 0x110AB1: main (readsb.c:2532)
==185857== 
==185857== 4,000 bytes in 1 blocks are still reachable in loss record 16 of 16
==185857==    at 0x484DA83: calloc (in /usr/libexec/valgrind/vgpreload_memcheck-amd64-linux.so)
==185857==    by 0x117615: argp_parse (argp.c:98)
==185857==    by 0x1170AA: parseCommandLine (readsb.c:2063)
==185857==    by 0x110D1C: main (readsb.c:2567)
==185857== 
==185857== LEAK SUMMARY:
==185857==    definitely lost: 0 bytes in 0 blocks
==185857==    indirectly lost: 0 bytes in 0 blocks
==185857==      possibly lost: 0 bytes in 0 blocks
==185857==    still reachable: 4,080 bytes in 16 blocks
==185857==         suppressed: 0 bytes in 0 blocks
==185857== 
==185857== For lists of detected and suppressed errors, rerun with: -s
==185857== ERROR SUMMARY: 0 errors from 0 contexts (suppressed: 0 from 0)

The same issue occurs when an unrecognized arg is passed.

$ valgrind --track-origins=yes --show-leak-kinds=all --leak-check=full ./readsb --invalid-arg
==185822== Memcheck, a memory error detector
==185822== Copyright (C) 2002-2017, and GNU GPL'd, by Julian Seward et al.
==185822== Using Valgrind-3.18.1 and LibVEX; rerun with -h for copyright info
==185822== Command: ./readsb --invalid-arg
==185822== 
./readsb: unrecognized option '--invalid-arg'
Try `./readsb --help' or `./readsb --usage' for more information.
Error parsing the given command line parameters, check readsb --usage and readsb --help for valid parameters.
invoked by: ./readsb --invalid-arg
==185822== 
==185822== HEAP SUMMARY:
==185822==     in use at exit: 4,000 bytes in 1 blocks
==185822==   total heap usage: 17 allocs, 16 frees, 4,093 bytes allocated
==185822== 
==185822== 4,000 bytes in 1 blocks are definitely lost in loss record 1 of 1
==185822==    at 0x484DA83: calloc (in /usr/libexec/valgrind/vgpreload_memcheck-amd64-linux.so)
==185822==    by 0x117615: argp_parse (argp.c:98)
==185822==    by 0x1170AA: parseCommandLine (readsb.c:2063)
==185822==    by 0x110D1C: main (readsb.c:2567)
==185822== 
==185822== LEAK SUMMARY:
==185822==    definitely lost: 4,000 bytes in 1 blocks
==185822==    indirectly lost: 0 bytes in 0 blocks
==185822==      possibly lost: 0 bytes in 0 blocks
==185822==    still reachable: 0 bytes in 0 blocks
==185822==         suppressed: 0 bytes in 0 blocks
==185822== 
==185822== For lists of detected and suppressed errors, rerun with: -s
==185822== ERROR SUMMARY: 1 errors from 1 contexts (suppressed: 0 from 0)

How to run readsb without writing json at all to disk?

Hi,
i am running two instances of readsb on the same rpi with different rtl devices.
This works fine but apparently they both try to write json files to the same directory (/run/readsb).
So sometimes one instances seems to to sth. in this directory causing the other one to trigger an error.

Since i dont need this json stuff, is it somehow possible to deactivate this json writing at all?
I am only interested in the received data from my antenna, and readsb is just forwarding the data using beast protocol to another centralized instance.

thanks

selecting rtlsdr by serial number

Hi,

I tried to let readsb select the dongle by serial number by replacing the original string by the string found by dump1090. But this did not work. I tried some variations in syntax, but no dongle found. The original string will find the rtlsdr, but not by serial number.
Do you know the right syntax?

RECEIVER_OPTIONS="--device 0 --device-type rtlsdr --gain -10 --ppm 0" <-- original
RECEIVER_OPTIONS="--sdr driver=rtlsdr,serial=00001090 --gain -10 --ppm 0" <-- from dump1090

Will it work on RISC-V?

Has someone already tried that or perhaps the project creator knows that from the top of their head: will this compile and work on RISC-V CPUs?

My use case is basically building the smallest and the cheapest receiver. I can live with stats and local website radar view disabled (it will just feed to another instance of readsb on a server elsewhere). Some cheap ARM SBCs like old Raspberry Pi Zero come to mind but nowadays a lot of smaller and cheaper RISC-V devices pop up on the market, perhaps those can be used? In that case, do you have any general advice, like e.g. must have more then x MB of RAM or at least x cores, or specific chip manufacturer, etc.?

--write-json causes bus error

I've decided to upgrade some packages on my rpi runniong fr24 feed, etc, and after a day, there was a problem with readsb service. After running from hand, the
/usr/bin/readsb --device-type rtlsdr --write-json /tmp/a causes program to stop (SIGBUS), while
/usr/bin/readsb --device-type rtlsdr seems work fine (but not generating files for tar).

gdb/strace says not much

`[Thread debugging using libthread_db enabled]
Using host libthread_db library "/lib/arm-linux-gnueabihf/libthread_db.so.1".
invoked by: /usr/bin/readsb --device-type rtlsdr --quiet --write-json /run/readsb
[2024-04-23 17:50:21.421 CEST] readsb starting up.
readsb version: 3.14.1621 wiedehopf git: e79d24a (committed: Sat Apr 20 00:06:35 2024 0200)
[New Thread 0xf7be3440 (LWP 3557)]
[New Thread 0xf70d6440 (LWP 3558)]
[New Thread 0xf66ff440 (LWP 3559)]
[New Thread 0xf5efe440 (LWP 3560)]
[New Thread 0xf54ff440 (LWP 3561)]
[New Thread 0xf4cbd440 (LWP 3562)]
[New Thread 0xf44bc440 (LWP 3563)]
[New Thread 0xf38ff440 (LWP 3564)]

Thread 8 "readsb" received signal SIGBUS, Bus error.
[Switching to Thread 0xf44bc440 (LWP 3563)]
0xf7e5a30c in ?? () from /usr/lib/arm-linux-gnueabihf/libzstd.so.1
#0 0xf7e5a30c in ?? () from /usr/lib/arm-linux-gnueabihf/libzstd.so.1
No symbol table info available.
#1 0x00000000 in ?? ()
No symbol table info available.
Backtrace stopped: previous frame identical to this frame (corrupt stack?)`

Tried upgrading from auto scripts, but nothing changed.

getState/ and aircraft.json are created.

Any hints how to debug it (apart of full clean image, reinstall)?

Any way to optimize the "readsb" performance on Raspberry Pi B+

I am running readsb with fr24feeder on Raspberry Pi B+ having below Specs:

processor       : 0
model name      : ARMv6-compatible processor rev 7 (v6l)
BogoMIPS        : 697.95
Features        : half thumb fastmult vfp edsp java tls
CPU implementer : 0x41
CPU architecture: 7
CPU variant     : 0x0
CPU part        : 0xb76
CPU revision    : 7

Hardware        : BCM2835
Revision        : 000e
Serial          : 0000000041f0e806
Model           : Raspberry Pi Model B Rev 2

Kernel version: Linux raspberrypi 5.4.51+ #1333 Mon Aug 10 16:38:02 BST 2020 armv6l GNU/Linux

readsb tag/commit : 5d238a06402a20f4ddc661e7344623ea6475a3a6

readsb options :

RECEIVER_OPTIONS="--device 0 --device-type rtlsdr --gain 30"
DECODER_OPTIONS="--preamble-threshold 0 --lat xxxxxx --lon xxxxxx --max-range 100"
NET_OPTIONS="--net --net-heartbeat 60 --net-ro-size 1250 --net-ro-interval 0.05 --net-ri-port 30001 --net-ro-port 30002 --net-sbs-port 30003 --net-bi-port 30004,30104 --net-bo-port 30005"

I was able to see decoded messages on --net and --interactive modes before. But after upgrading the readsb and raspberry pi kernel I haven't observed any decoded DF17 messages. I assume it is because of the performance.

Is there any way to optimize the readsb to work(decode) on Raspberry Pi B+ efficiently?

Feature Request: preserve outlines.json after restart

Hello:)

I wonder if it's possible to implement an option (e.g. --range-outline-preserve=) to retain the outlines.json (similar to
--write-state=) after a restart of readsb or the device. This would probably make a helpful addition to the existing option
--range-outline-hours= and would prevent that the outlines are reset after a power loss or restart of the device (e.g. to apply updates).

After starting of readsb the dir /run/readsb disappear

Hi i just installed the readsb from the automatically script the /run/readsb directory disappear and the Tar1090 dont see server.
"Problem fetching data from the server:
Seems the decoder / receiver / backend isn't working correctly!"

When i shutdown the readsb then the /run/readsb is there and the Tor1090 show the map witch my location.
Linux Mint 20.03

readsb --device-type rtlsdr --net
readsb version: wiedehopf git:
rtlsdr: using device #0: Terratec Cinergy T Stick RC (Rev.3) (Realtek, RTL2838UHIDIR, SN 00000001)
Found Elonics E4000 tuner
rtlsdr: enabling tuner AGC
Allocating 16 zero-copy buffers
Thx for help

Compile error in function get_seed

Using Alpine 3.18.2

cc -std=c11 -W -D_GNU_SOURCE -D_DEFAULT_SOURCE -Wall -Werror -fno-common -O2 -DMODES_READSB_VERSION=\""3.14.1604 wiedehopf git: 0059b62 (committed: Sun Jun 18 07:12:59 2023 0200)"\" -Wdate-time -D_FORTIFY_SOURCE=2 -fstack-protector-strong -Wformat -Werror=format-security -Wno-format-truncation -DENABLE_RTLSDR -I/usr/include/ -I/usr/include/libusb-1.0 -g  -c util.c -o util.o
util.c: In function 'get_seed':
util.c:215:110: error: cast from pointer to integer of different size [-Werror=pointer-to-int-cast]
  215 |     unsigned int seed = (uint64_t) time.tv_sec ^ (uint64_t) time.tv_nsec ^ (((uint64_t) getpid()) << 16) ^ (((uint64_t) pthread_self()) << 10);
      |                                                                                                              ^
cc1: all warnings being treated as errors
make: *** [Makefile:125: util.o] Error 1

Error in line 101 (readsb-install.sh)

Hi,
yesterday I tried to compile readsb on my proxmox VM under Debian (readsb-install.sh).
I always get an error MSG: Error in line 101 : make "-j${THREADS}" AIRCRAFT_HASH_BITS=16 RTLSDR=yes OPTIMIZE="-O3 -march=native" "$@"

I did it before also under my VM and had to problems at all.

Recommend Projects

  • React photo React

    A declarative, efficient, and flexible JavaScript library for building user interfaces.

  • Vue.js photo Vue.js

    ๐Ÿ–– Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.

  • Typescript photo Typescript

    TypeScript is a superset of JavaScript that compiles to clean JavaScript output.

  • TensorFlow photo TensorFlow

    An Open Source Machine Learning Framework for Everyone

  • Django photo Django

    The Web framework for perfectionists with deadlines.

  • D3 photo D3

    Bring data to life with SVG, Canvas and HTML. ๐Ÿ“Š๐Ÿ“ˆ๐ŸŽ‰

Recommend Topics

  • javascript

    JavaScript (JS) is a lightweight interpreted programming language with first-class functions.

  • web

    Some thing interesting about web. New door for the world.

  • server

    A server is a program made to process requests and deliver data to clients.

  • Machine learning

    Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.

  • Game

    Some thing interesting about game, make everyone happy.

Recommend Org

  • Facebook photo Facebook

    We are working to build community through open source technology. NB: members must have two-factor auth.

  • Microsoft photo Microsoft

    Open source projects and samples from Microsoft.

  • Google photo Google

    Google โค๏ธ Open Source for everyone.

  • D3 photo D3

    Data-Driven Documents codes.