2-bit correction with --fix --fix in dump1090-fa 3.8

This morning i seen in my system (Debian 10), that a new version of Dump1090, the 3.8.0 is ready to be installed on my Pi4 !

I have installed it, and all run as normal for the moment !

I have seen in the changelog that now we can use the 2 bits corrected messages, that’s great, but how do that, where to put the --net-verbatim option ?
I do not understand if i need to use too the --fix option too ?

Thanks for your help !

Yes, i’ve just received the update notification.

It was not only dump1090 but also piaware and piaware-repository

Additional note:

Check your gain settings.
After the update mine was set back to “-10” which is the default on a new installation.

You have this because during installation, you chose not to keep your configuration file, and it has been replaced by the new configuration file offered with this update.

If you are using a package install, then options can be specified in /etc/default/dump1090-fa

To enable 2-bit correction (do you really want this?) include --fix --fix in the options.

By default these 2-bit-corrected messages will not be emitted to any network clients. If you do want to pass them on, then either the client should enable verbatim mode on that connection (this requires changes to the client) or you can pass the --net-verbatim option to turn on verbatim mode for all connections. In verbatim mode, the original uncorrected message is sent to the network - the downstream client is then responsible for applying error correction if desired. So either way, there’s probably some work needed in other software if you want it to handle these messages.

piaware and faup1090 in 3.8.0 are verbatim-mode-aware, so you don’t need to do anything special there - but note that they make a deliberate decision not to use 2-bit corrected messages.

1 Like

Not sure if it’s related but i now have a higher number of positions/sec. Coming close to 60 was not possible before with this number of aircraft visible. I will monitor it.

I had no choice. The update was simply installed without any chance of interaction.
EDIT: I had a choice on my second device. Wonder what went wrong on the first one.

Flightaware updated ok on piaware (pi 2nd)

but for buster 10/piaware it didnt (pi main)
[2020-01-03 10:07 GMT] performing manual update, action: piaware
[2020-01-03 10:07 GMT] *** running command ‘/usr/lib/piaware/helpers/run-apt-get update’ and logging output
[2020-01-03 10:07 GMT] manual update (user-initiated via their flightaware control page) requested by adept server
[2020-01-03 10:07 GMT] skipping action piaware
[2020-01-03 10:07 GMT] run-apt-get(22306): Automatic updates not available for OS raspbian:10 (Raspbian GNU/Linux 10 (buster))
[2020-01-03 10:07 GMT] child process 22306 exited with status EXIT 1
[2020-01-03 10:09 GMT] 409070 msgs recv’d from dump1090-fa (4502 in last 5m); 407835 msgs sent to FlightAware

1 Like

piaware 3.7.2 doesn’t know how to auto-upgrade on buster (note that 3.7.2 on buster isn’t officially supported…), and if you installed the stretch version then a command-line upgrade will upgrade to the 3.8.0~bpo9 stretch version, not the 3.8.0 buster version. You’ll probably want to rerun the package install instructions to pick up the buster repository package (but wait a few days first - the website is not updated for that yet)

edit: try this (instructions are specifically for Buster, don’t do this on Stretch)

wget https://flightaware.com/adsb/piaware/files/packages/pool/piaware/p/piaware-support/piaware-repository_3.8.0_all.deb
sudo dpkg -i piaware-repository_3.8.0_all.deb
sudo apt-get update
sudo apt-get upgrade
1 Like

Hm, that is interesting. Both of my devices are on Buster and the upgrade was working with the two single sudo apt-get commands. No need to trigger a download before.

Sure, but I’m going to guess that now you’re on 3.8.0~bpo9 - the Stretch packages, not the Buster packages. Your repository config will be pointing at the Stretch repository.

That’s perfect for me with yours instructions : thanks ;+))
I have replaced the 3.8.0~bpo9 version with the 3.8.0 for Buster !
In my case that need an apt-get dist-upgrade to complete.

Just to confirm, I updated via apt on buster, and got the backported version.

Why ~bpo9+1 ?

pi@raspberrypi:~ $ uname -a
Linux raspberrypi 4.19.75-v7+ #1270 SMP Tue Sep 24 18:45:11 BST 2019 armv7l GNU/Linux

pi@raspberrypi:~ $ cat /etc/os-release
PRETTY_NAME="Raspbian GNU/Linux 10 (buster)"
pi@raspberrypi:~ $ apt-cache policy piaware
piaware:
  Installed: 3.8.0~bpo9+1
  Candidate: 3.8.0~bpo9+1
  Version table:
 *** 3.8.0~bpo9+1 500
        500 http://flightaware.com/adsb/piaware/files/packages stretch/piaware armhf Packages
        100 /var/lib/dpkg/status

That’s the stretch version (backport to debian 9). See how your policy details say it’s coming from the stretch repo. See posts above.

1 Like

Same here.

But it is working without issues

Did the upgrade but failed nothing running at moment
bit stuck on what to do next

Problem fetching data from dump1090.
AJAX call failed (error: Not Found). Maybe dump1090 is no longer running?
The displayed map data will be out of date.

also running airspy

apt-cache policy piaware
piaware:
Installed: 3.8.0
Candidate: 3.8.0
Version table:
*** 3.8.0 500
500 http://flightaware.com/adsb/piaware/files/packages buster/piaware armhf Packages
100 /var/lib/dpkg/status
3.8.0~bpo9+1 500
500 http://flightaware.com/adsb/piaware/files/packages stretch/piaware armhf Packages

The upgrade went smoothly except the graphs1090 upgrade portion replaced the graphs.js file. There was no option to keep the existing file. (I had a backup.)

Rerun the airspy configuration script, see if that fixes it.

That’s quite unrelated to updating dump1090?

Yes thankyou
all working again