Distance column gone compared to dump1090-ma | and more tech talk, Docker, etc

[Saturnus]

I just launched a second instance of Dump1090, this one being the FlightAware fork. Compared to the older Dump1090-mutability the distance column is missing.

For FlightAware Dump1090 I did not do any configuration, for the older one there was a config.js that seems not to be working with the FA fork. The FA Dump1090 did get auto-detected and added to the account however, so there I just setup the location data.

Did I miss something?

[wiedehopf]

The position needs to be accessible via receiver.json for the distance calculation to work.

For that to happen, the program needs to know the receiver location.
(In config js you only configure an overwrite in the web interface, it’s not used for calculating the distance for whatever reason)

If you are running dump1090-fa and piaware, it should use the location from the stats page.

If you just configured the location on the stats page, just try restarting dump1090-fa, it should pick up the location.

You can configure it in the config file as well:

sudo nano /etc/default/dump1090-fa

Add lat and lon to the decoder options line like in the following example:

DECODER_OPTIONS="--lat 50.1 --lon 10.0 --max-range 360"

Ctrl-o and enter to save, Ctrl-x to exit

Then restart dump1090-fa to apply the settings:

sudo systemctl restart dump1090-fa

[Saturnus]

Thanks for the information.

I am running GitHub - Thom-x/docker-fr24feed-piaware-dump1090: Docker image of dump1090-fa, fr24feed, FlightAware, adsbexchange and Plane Finder. and did not find the file, nor creating it myself worked. Probably due to how the container is programmed. I did found it at /usr/lib/fr24/public_html/config.js which is unchanged from the non-FA version of the container, so I guess I overlooked that. Should have checked that before opening this topic.

So I edited the file, restarted the container and got the distance column now.

I might develop my own Docker container image in the future though, especially for Raspberry Pi, so your information is still useful.

[wiedehopf]

Ah it seems dump1090-fa is invoked by fr24feed in your case.

So editing the config file i described wouldn’t help.
You’d have to use the --lat and --lon arguments in the “Process Arguments” field of the fr24feed settings.

[Saturnus]

Do you have any recommendation on good sites/manuals that explain how the software platforms work and how they work together?

Like what you said the Dump1090 is launched from within FR24, I had no idea.
And like, Dump1090-fa version apparently has FA integrated and is not a local only application, like I think the original Dump1090 was?

I thought it would be difficult for a Docker noob (some Linux experience) to make a container with let’s say Dump1090, FA, FR24, ADSB-Exchange, and maybe more as all-in-one, but now I am starting to think it will be extremely difficult for me.

[wiedehopf]

@Saturnus

Like what you said the Dump1090 is launched from within FR24, I had no idea.

That was just what id deducted from the github.

@Saturnus

Do you have any recommendation on good sites/manuals that explain how the software platforms work and how they work together?

Pretty much all dump1090 just provide beast data on 30005 and some other data formats on other ports.
The -fa variant mainly has a branded webinterface.
It’s also the actively developed variant.

The data output from all variants should be the same in regards to beast data.

Most feeder do the sensible thing and want beast data on port 30005.
FR24 and radarbox have a mode in their feeder where dump1090 is started by the feeder.
But you can change that in the configuration (receiver type: beast tcp, don’t use DVB-T)

For piaware there is even a diagram:
PiAware - dump1090 ADS-B integration with FlightAware - FlightAware

@Saturnus

I thought it would be difficult for a Docker noob (some Linux experience) to make a container with let’s say Dump1090, FA, FR24, ADSB-Exchange, and maybe more as all-in-one, but now I am starting to think it will be extremely difficult for me.

Just start from scratch and not with that strange docker image.
Seems to be weirdly configured.

Why do you even need docker?
The Raspberry Pi works fine and for best reception is likely gonna end up in the attic or somewhere else close to the antenna.

[Saturnus]

Thanks. Still a lot of abracadabra haha, but got some references now.

Docker is really nice when the images and containers are well set-up. The personal files or configs can be saved externally and used as input of containers. The containers hold the programs. So if you mess up something, you just deploy a new container from the image. Or if it turns out that a newer image version does not work as expected, you just restart the old container, based on the older image.

The benefits of Docker are poorly reaped for ADS-B software at this moment, it becomes problematic when image maintainers do not explicitly use version (number) tags. That’s why I am thinking to make one myself. Also like you said, the configuration just looks weird.

In theory it should also be super easy to deploy multi USB receivers on a single system, because you forward the USB device to a container. Just use the original container start command, adjust ip, port and usb device, and go. Then again, I for example don’t understand all the configs yet. Like what will happen if you use the fr24key at the same time in multiple instances, and all that kind of stuff. FA seems to use a smarter way of detecting instances, I am getting a lot of mails from my testing haha.

I tried it by the way, because I have 2 USB receivers. But /dev/bus/usb/001/??? numbers keep changing (using those because I don’t get /dev/ttyXYZ ones) after container starts/restarts/stops. Plus when one instance (container) was up, and the other came online, they both stopped receiving signals from the sky.

This whole thing is pretty annoying. I have a clear vision but getting there is a lot harder than expected due to weird behaviour and difficulty in understanding software.

[obj]

@Saturnus

I tried it by the way, because I have 2 USB receivers. But /dev/bus/usb/001/??? numbers keep changing (using those because I don’t get /dev/ttyXYZ ones) after container starts/restarts/stops.

Set a serial number on each receiver to identify them, and configure by serial number not by device index.

@Saturnus

Plus when one instance (container) was up, and the other came online, they both stopped receiving signals from the sky.

That sounds like a power issue.

[Saturnus]

I have to map each /dev/bus/usb/001/??? device to a Docker container, because when using the --privileged mode, the whole USB bus gets mapped to a container and the other container cannot open the device anymore. I am not sure if this is because of the privileged mode itself or because Dump1090 is locking all suitable devices.

Thus

~# lsusb
Bus 001 Device 004: ID 0bda:2838 Realtek Semiconductor Corp. RTL2838 DVB-T
Bus 001 Device 005: ID 0bda:2832 Realtek Semiconductor Corp. RTL2832U DVB-T

/dev/bus/usb/001/004 goes to container 1.
/dev/bus/usb/001/005 goes to container 2.

But because this, I think, is a hardware pass through, when the container is stopped, the USB device is given back (‘re-attached’) to the host OS, and then the number changes.
Bus 001 Device 006: ID 0bda:2838 Realtek Semiconductor Corp. RTL2838 DVB-T

Then the Docker container argument is also changed. --device=/dev/bus/usb/001/006
Which makes it extremely annoying. Static something needed. PersistentUSBDevices - Domoticz does not work because there is no higher level ‘/dev/ name’ except infrared control or so.

Not enough power, I thought of that. Will have a RPi 3B+ with genuine PSU tomorrow. Currently testing on a RPi 1B.

[wiedehopf]

@Saturnus

Like what will happen if you use the fr24key at the same time in multiple instances

You don’t.
Just go through sudo fr24feed --signup again.
It will assign you a new key for your second station.

@Saturnus

Currently testing on a RPi 1B.

The USB chip is probably not able to handle 2 data streams of the magnitude produced by the dongles.

2.4 MSamples/s with 1 byte per sample.

The USB bus on the RPi 3B+ is able to handle two dongles, but the bandwidth on USB is still pretty bad.

[wiedehopf]

@Saturnus

In theory it should also be super easy to deploy multi USB receivers on a single system, because you forward the USB device to a container.

It’s not really necessary to use containers for that.

Plus when you look at the thread that was just started you’ll understand the configurations better and how the stuff is connected:

Two Independent 1090 Mhz ADS-B Receivers on One Pi (No UAT 978)

[1-Pi-2-Receivers-c] STEP-1: Prepare OS 1.1 - Download and write Raspbian Lite image to microSD card. https://downloads.raspberrypi.org/raspbian_lite_latest 1.2 - Enable SSH After image is written, and while the microSD Card is still in the Laptop/Desktop, open File Explorer (Windows) or Finder (Mac), and open the drive named “boot” . This will open the /boot folder of Raspbian. In this folder create a new text file and rename it ssh 1.3 - Slip microSD card into RPi and power-up. . STE…

You’ll have to understand some bash scripting though and understand the systemd unit files.
But that’s well worth it

[Saturnus]

Thanks, got a second key now.

Alright, will see tomorrow on RPi3. It’s also no problem to use the main receiver on RPi3 and secondary on RPi 1. Automatically solving the ‘2 receivers on 1 system’ problem, but I like a challenge anyways.

I saw the topic and executing it should not be a problem, however, the method in my opinion is a lot of work, lacks scalability, etc. Don’t get me wrong, I believe it will work super nice, but what if someone wants to run let’s say 8 instances, or do lots of experimental testing/programming.

With a well programmed docker image it would literally be 30 seconds of work to deploy a new instance, on top of other mentioned benefits. The road to get there though…

[wiedehopf]

@Saturnus

but what if someone wants to run let’s say 8 instances, or do lots of experimental testing/programming.

It wouldn’t be so hard to automate creating the additional files needed.

@Saturnus

With a well programmed docker image it would literally be 30 seconds of work to deploy a new instance, on top of other mentioned benefits.

Do docker containers have their own IP address?
I’m not really familiar but as you saw the ports dump1090-fa need to be changed to use a second instance.

[Saturnus]

Depending on the configuration, yes.

Let’s say there is a RPi with LAN ip 192.168.1.5 and Docker network 172.1.0.0/16.

Container ports can be mapped to host ports. E.g.:
Contain 1: 127.0.0.1:8080 → 192.168.1.5:8080
Contain 2: 127.0.0.1:8080 → 192.168.1.5:8081
Contain 3: 127.0.0.1:8080 → 192.168.1.5:8082
These are mappings in Docker, no need to change Dump1090 configs.

Also, advertising the Docker network is possible: 172.1.0.0/16 via gateway 192.168.1.5

So then you are be able to reach the Dump1090 pages inside the home network via:
Container 1: 172.1.0.1:8080
Container 2: 172.1.0.2:8080
Container 3: 172.1.0.3:8080

[Saturnus]

Grabbed the other RPi 3B+ because I wanted to test today, before unpacking the second RPi 3B+.

Maybe the USB numbering problem is solved. It is possible that the RPi 1B lost connection with USB devices due to power and load, and therefore the device numbers kept increasing.

Now, there is still a problem. I am trying to show only one USB receiver to each container, yet somehow it seems the container still can see both. Posted at Docker forums: Device USB mapping going wrong, container sees unmapped devices, bug? leak? - General Discussions - Docker Community Forums

Question about Dump1090:
As seen in that topic, both containers can see both receivers, or at least try to, so therefore it is weird that the second one is unable to use the second receiver.
Why is this happening?
My guesses:

1. The successful container sees both receivers and selects the first. Fine. But it also locks/claims the second receiver somehow.
2. The second container fails because it is unable to use the first receiver, and it does not even try the second receiver. (I have found some parameters to force select a second receiver but didn’t got it to work.)
   Or both wrong?

Something really odd is going on.

[wiedehopf]

By default they want to use the dongle with the device id 0.

You can change the config options for one of them to use device id 1.

--device <index|serial>  select device by index or serial number

Are you still using that horrid docker image?

[Saturnus]

Yeah so I tried --device 1 and --device=1 in the fr24feed.ini procargs field, but nope.

You think the Docker image is the problem? Maybe it has something todo with the supervisord packages in it. Will try another one tomorrow.

[wiedehopf]

Maybe it’s just the html in the fr24 directory.
And the dump1090 starts independently.

Which dump1090 was it?

pgrep -l dump1090

For dump1090-fa try modifying /etc/default/dump1090-fa

you can always check
pgrep -a dump1090

to see the command line options in use.

[Saturnus]

It is Dump1090-mutability because GitHub - dmorehouse/docker-raspberrypi-fr24feed-piaware-dump1090-mutability: Docker image for Raspberry PI of Fr24feed, FlightAware and dump1090-mutability. for RPI’s is not updated yet. I was planning on doing that but thinking to skip after today’s madness. Sorry should have made clear I am using that forked repo on the Pi and sometimes test the parent on the desktop (as was the case with the original topic question).

[wiedehopf]

I’m not sure about the config file options for dump1090-mutability.

But you should be able to use
sudo dpkg-reconfigure dump1090-mutability

to change the settings. (unless it’s started by fr24)

take a look at the config file as well
/etc/default/dump1090-mutability