How to set up a feeder on Windows 10/11 using Windows Subsystem for Linux

[bimmerdriver]

This will be great. Waiting for you to get it working and share

I have created a batch file "Start-WSL.bat" and saved it on Desktop.
When I want to start wsl, I right-click it and choose "run as administrator"
This batch file not only starts wsl, but also attaches the DVB-T Dongle to wsl.

The contents of this batch file are as follows:

wsl
powershell -Command "& {usbipd bind --hardware-id 0bda:2838; usbipd attach --wsl --hardware-id 0bda:2838}"

LATER EDIT (March 23, 2024):
I found that the comands given above for the batch file do NOT work reliably. Sometimes the DVB-T will be attached, and sometime NOT attached. I have now completely changed the code and it seems to work reliably. The revised code for batch file "Start-WSL.bat" is given below:

start wsl
timeout 2
usbipd bind --hardware-id 0bda:2838
usbipd attach --wsl --hardware-id 0bda:2838
exit​

Please note that if you want to log the stderr & stdout when batch file is run, then use following code in the batch file. You have to give log file's location. I have used C:\Users\abcd\Documents\wsl-log.txt

start wsl
timeout 2
usbipd bind --hardware-id 0bda:2838 > C:\Users\abcd\Documents\wsl-log.txt 2>&1
usbipd attach --wsl --hardware-id 0bda:2838 >> C:\Users\abcd\Documents\wsl-log.txt 2>&1
exit​

The contents of log file are as follows:

usbipd: info: Device with hardware-id '0bda:2838' found at busid '1-14'.
usbipd: info: Device with busid '1-14' was already shared.
usbipd: info: Device with hardware-id '0bda:2838' found at busid '1-14'.
usbipd: info: Using WSL distribution 'Ubuntu' to attach; the device will be available in all WSL 2 distributions.
usbipd: info: Using IP address 172.19.80.1 to reach the host.

​

The cmd window opened by running the batch file as administrator


wsl-started-by-batch-file.png

Unless you change the port the USB SDR is plugged into, you only need to bind it once. Once you bind it, it stays binded, even if you remove and reinsert it. Also, the bind command requires administrator rights. You can execute a command on windows from inside WSL2, but I don't recall if there is a way to execute a command requiring administrator rights.

The problem of using usbipd-win is that WSL2 must be booted and the network must be running in order to attach a USB device. This requires the network-online.target to have been reached by systemd. As soon as this target has been reached, systemd starts other services, including dump1090-XX, which require the USB to be attached, so the window of opportunity to execut the attach command is very short.

I'm working on a service that starts after network-online.target and completes before dump1090-fa starts. My intention is for the service to support start (attach), stop (detach) and restart (detach, attach). I'm testing it and I will post the files as soon as possible. This service will require manual installation and manual configuration.

This has taken a while because I'm busy, when I started, I didn't know anything about systemd and the last shell script I wrote was a tcsh script on a Digital AlphaStation running Digital UNIX. Now I know enough about systemd to be dangerous.

I noticed you used hardware-id. I used busid. I just did a test and verified that hardware-id doesn't change, even if you change the port. That's better than busid, so I will put it on the to-do list to change to hardware-id.

There doesn't seem to be a version of linux-tools for the version of linux being used by WSL2, so I'm executing the usbipd commands on Windows from inside WSL2.

More later...

[bimmerdriver]

@kkomarica

FR24 has said that:

(1) MLAT is allowed only if in fr24feed settings, you select "receiver =dvbt". This means dump1090-mutability will be installed, and you will have to remove dup1090-fa or readsb if you have it already installed.

(2) If you are feeding other sites as well from your receiver, then you should disable mlat in fr24feed settings.

I'm feeding to flightradar24 and flightaware. FA is using my receiver for MLAT, but not FR24.

UPDATE: Further to what abcd567 said, I do not have MLAT enabled in the fr24feed settings.

[kkomarica]

I made some changes to my setup so that I managed to get MLAT running. Using advice in some old post by abcd567 I switched to beast-tcp and port 30005 ... thanks!

sudo fr24feed-status
 * FR24 Feeder/Decoder Process: running
 * FR24 Stats Timestamp: 2024-03-24 16:33:04
 * FR24 Link: connected [UDP]
 * FR24 Radar: T-LDZA47
 * FR24 Tracked AC: 29
 * Receiver: connected (742187 MSGS/15 SYNC)
 * FR24 MLAT: ok [UDP]
 * FR24 MLAT AC seen: 28​

Another thing that I wanted to ask (and I am doing it here, not to start a new thread) ...
is the very good performance for ADS-B reception of the default china dvb-t antenna known and reported already?

I am talking about the small magnetic antenna (mcx connector) that you get with most of the cheapest dvb-t sdr sticks:

Hd8028d4eb3b74a988bec8d4539738b70t.jpg?width=898&height=898&hash=1796.webp

[abcd567]

@kkomarica

Check fr24feed-status after few days, and you will find mlat not running.

The small whip antenna supplied with dvbt is just a starter. You cannot get very good performance from it. To get very good performance you will meed a commercial antenna and a dongle with builtin amplifier+filter. If you have strong RF interference from nesrby mobile/cell phone tower or tv tower, then you will need to add an external filter also.

[kkomarica]

abcd567 just to get back to you. one week after, mlat is still running. I'm going to stick with this settings for now.

[abcd567]

@kkomarica
Good news. I will now change my settings from avr-tcp 30002 to beast-tcp 30005 and see how mlat behaves

[bimmerdriver]

I've been working on a systemd service to automatically attach the receiver after booting, before dump1090-fa is started, to prevent failed startup.

I finally have something that's ready to release. The code is below. Even if you're not familiar with systemd, it's fairly self-explanatory how it works.

The service, called usbipd-win is started by systemd after the network is online and before dump1090-fa starts.

To install it, follow the instructions in the comments.

# USBIPD-WIN Service for Ubuntu 22.04 systemd
# Attach USB SDR after the network is online and before dump1090-fa starts
# Requires github.com/dorssel/usbipd-win to be installed on WSL host
#
# Installation Instructions
#
# NOTE: Replace <VID:PID> with actual VID:PID
#
# In Windows Administrator Command Prompt:
# usbipd list
# usbipd bind --hardware-id VID:PID
#
# In WSL Bash shell:
# sudo cp ./usbipd-win.service /etc/systemd/system
# sudo systemctl daemon-reload
# sudo systemctl enable usbipd-win
#
# After installation, use the following commands to start, stop, restart or status
# sudo systemctl start usbipd-win
# sudo systemctl stop usbipd-win
# sudo systemctl restart usbipd-win
# sudo systemctl status usbipd-win
#
# NOTE: If after executing systemctl stop usbipd-win or systemctl restart usbipd-win, the
# Bash window is defocussed, click the mouse in the window to bring it back into focus.​

[Unit]
Description=USBIPD-WIN Attach USB SDR before dump1090-fa starts
Wants=network-online.target
After=network-online.target
Before=dump1090-fa.service

[Service]
Type=oneshot
RemainAfterExit=yes
ExecStart=bash -c "/mnt/c/'Program Files'/usbipd-win//usbipd.exe attach --wsl --hardware-id VID:PID"
ExecStop=bash -c "/mnt/c/'Program Files'/usbipd-win//usbipd.exe detach --hardware-id VID:PID; sleep 1"

[Install]
WantedBy=default.target​

While I was testing this service, I looked at how other related services are being started. I noticed that piaware was configured to start after dump1090-fa, but fr24feed was not. I also noticed that fr24feed has the obnoxious behaviour of trying to install dump1090. I wasn't happy with either of these issues, so I fixed them.

Below is revised code for fr24feed. The changes are commented. It installs the same way as usbipd-win.

[Unit]
Description=Flightradar24 Decoder & Feeder
After=network-online.target

# The following lines have been added to cause this service to have the same
# prerequisites and start order as piaware.service.
Wants=network-online.target
After=dump1090-fa.service time-sync.target

[Service]
Type=simple
Restart=always
LimitCORE=infinity
# The following line has been commented out because it's not
# best practice to install a service from inside a service.#
#ExecStartPre=-/usr/lib/fr24/install_dump1090.sh
ExecStartPre=-/usr/lib/fr24/unregister_kernel_modules.sh
ExecStartPre=-/usr/lib/fr24/create_missing_directories.sh
ExecStartPre=/usr/bin/fr24feed --validate-config --config-file=/etc/fr24feed.ini
ExecStart=/usr/bin/fr24feed
User=fr24
Group=fr24
PermissionsStartOnly=true
StandardOutput=journal
StandardError=journal

[Install]
WantedBy=multi-user.target​

If you install these services, usbipd-win will start first, then dump1090-fa, then finally fr24feed and piaware will start at the same time.

Special thanks to abcd567 for testing.

[abcd567]

Great! Well done bimmerdriver

Thumb-31x34.jpgThumb-31x34.jpgThumb-31x34.jpg

[bimmerdriver]

It's been a while since I've posted. I've been running fr24feed and piaware on WSL for almost a year and a half. According to the stats on flightaware, piaware has been running continuously for 451 days. That's a bit generous, because it ignores a few minor outages, but probably in excess of 99% of the outages are a result of scheduled or unscheduled Windows updates on the host computer and power outages. Were it not for those, the actual uptime would have been almost 100% over that time. Based on this experience, there is no doubt that WSL is a viable alternative to an rpi. I have a dedicated user account on the computer where I leave WSL running and another account from which I use the computer for other purposes, mainly vpn / bittorrent and monitoring other headless computers. The computer has an AMD A8-7800 processor and 16 MB of RAM, nothing flashy or fast.

I'm still running Ubuntu 22.04, but I plan to switch over to 24.04, which I will document when I get around to it.

The one big thing that I did, which I haven't reported to this point, is that I found a solution to the ntp synchronization problems I that I encountered in the beginning. It's widely known that fr24feed doesn't use ntp properly, but that isn't what was causing the problems. The problems were caused by the underlying computer having a very poor realtime clock, which caused not only Windows to not be time synchronized, but also WSL. This was also causing problems with piaware, in particular, MLAT.

The fix was to synchronize system time on the host computer in Windows with ntp, using the standard Windows Time Service. When I did that I was able to get ntp working properly in WSL. The process follows. I will describe the Windows part, then the WSL part.

Step 1. Configure Internet Time (NTP) options in Windows 10 Use this to configure the host to use NTP. I recommend selecting pool.ntp.org as the ntp server, because that is what the fr24feed software uses. (It has been debated elsewhere that flightradar24 should have a vendor-specific pool, but that's beyond my influence.)

Step 2. Configuring systems for high accuracy Use this to configure the host to maintain a high accuracy system time. After you configure your host as described, it will reset the clock every 64 seconds, so there will be very little drift, even if the hardware clock in the host has a lot of drift.

You can verify it's working by using the following command:

C:\WINDOWS\system32>w32tm /query /status /verbose
Leap Indicator: 0(no warning)
Stratum: 4 (secondary reference - syncd by (S)NTP)
Precision: -23 (119.209ns per tick)
Root Delay: 0.0347216s
Root Dispersion: 0.1137837s
ReferenceId: 0xA29FC87B (source IP: 162.159.200.123)
Last Successful Sync Time: 4/1/2025 12:50:43 PM
Source: pool.ntp.org,0x9
Poll Interval: 6 (64s)

Phase Offset: 0.0000000s
ClockRate: 0.0156251s
State Machine: 2 (Sync)
Time Source Flags: 0 (None)
Server Role: 0 (None)
Last Sync Error: 0 (The command completed successfully.)
Time since Last Good Sync Time: 2.6077185s

If you run this command repeatedly, the longest time since Last Good Sync Time will be 64 seconds.

Here are a couple of other useful references:

Windows Time service tools and settings This is only one part of a larger discussion about Windows Time Service. It's all interesting.

Configuring w32time As NTP Client This is only one part of a larger discussion about Windows Time Service. It's all interesting.

That takes care of the host computer. Now you have to configure the WSL2 guest to also use ntp. That will be in the next post.

[bimmerdriver]

You can either install an ntp client or use the built-in systemd-timesyncd.service. I chose the latter.

PART 1

First, verify that the service is operating:

Show current settings:

$ timedatectl
Local time: Thu 2017-09-21 16:08:56 CEST
Universal time: Thu 2017-09-21 14:08:56 UTC
RTC time: Thu 2017-09-21 14:08:56
Time zone: Europe/Warsaw (CEST, +0200)
System clock synchronized: yes
NTP service: active
RTC in local TZ: no

If NTP service is not active, then activate it:

Enable network time synchronization:

$ timedatectl set-ntp true

Now, check if systemd-timesync.service is enabled:

$ systemctl status systemd-timesyncd.service

If not, enable it and recheck:

systemctl enable systemd-timesyncd
systemctl start systemd-timesyncd
systemctl status systemd-timesyncd.service​

It's possible you will get an error, because some services may have been configured to not operate under WSL. If this is the case, you will see this error:

Network Time Synchronization was skipped because of a failed condition check (ConditionVirtualization=!container).

The fix is to override ConditionVirtualization=!container.

Here is an explanation of how to do it: Can't override a systemd unit's ConditionVirtualization on Archlinux on Distrod on WSL. Refer to the answer, which involves creating override.conf.

You may need to re-enable the service.

After that, you should see something like this:

$ systemctl status systemd-timesyncd
● systemd-timesyncd.service - Network Time Synchronization
Loaded: loaded (/lib/systemd/system/systemd-timesyncd.service; enabled; vendor preset: enabled)
Drop-In: /etc/systemd/system/systemd-timesyncd.service.d
└─override.conf
/usr/lib/systemd/system/systemd-timesyncd.service.d
└─wsl.conf
Active: active (running) since Fri 2025-05-16 14:23:42 PDT; 1 week 6 days ago
Docs: man:systemd-timesyncd.service(8)
Main PID: 183 (systemd-timesyn)
Status: "Initial synchronization to time server w.x.y.z:123 (ntp.ubuntu.com)."
Tasks: 4 (limit: 8887)
Memory: 2.8M
CGroup: /system.slice/systemd-timesyncd.service

Note, the file wsl.conf is what was preventing the service from starting:

[Unit]
ConditionVirtualization=
ConditionVirtualization=|!container
ConditionVirtualization=|wsl

override.conf undoes what wsl.conf dis:

[Unit]
ConditionVirtualization=
ConditionVirtualization=wsl

I had to do this on Ubuntu 22.04, but not on 24.04.

Continues in the next post...

[bimmerdriver]

PART 2

Finally, by default, ntp.ubuntu.com is used. I changed it to pool.ntp.org, which is what flightradar24 uses.

To change the default ntp server, edit /etc/systemd/timesyncd.conf as follows:

[Time]
NTP=pool.ntp.org
#FallbackNTP=ntp.ubuntu.com
#RootDistanceMaxSec=5
#PollIntervalMinSec=16
#PollIntervalMaxSec=2048

Finally, restart systemd-timesyncd

systemctl enable systemd-timesyncd
systemctl start systemd-timesyncd

You should see something like this:

$ systemctl status systemd-timesyncd
● systemd-timesyncd.service - Network Time Synchronization
Loaded: loaded (/lib/systemd/system/systemd-timesyncd.service; enabled; vendor preset: enabled)
Drop-In: /etc/systemd/system/systemd-timesyncd.service.d
└─override.conf
/usr/lib/systemd/system/systemd-timesyncd.service.d
└─wsl.conf
Active: active (running) since Fri 2025-05-16 14:23:42 PDT; 1 week 6 days ago
Docs: man:systemd-timesyncd.service(8)
Main PID: 183 (systemd-timesyn)
Status: "Initial synchronization to time server w.x.y.z:123 (pool.ntp.org)."
Tasks: 4 (limit: 8887)
Memory: 2.8M
CGroup: /system.slice/systemd-timesyncd.service

If you didn't have to put in the override, it will look like this:

$ systemctl status systemd-timesyncd
● systemd-timesyncd.service - Network Time Synchronization
Loaded: loaded (/usr/lib/systemd/system/systemd-timesyncd.service; enabled; preset: enabled)
Drop-In: /usr/lib/systemd/system/systemd-timesyncd.service.d
└─wsl.conf
Active: active (running) since Fri 2025-05-16 14:31:21 PDT; 1 week 6 days ago
Docs: man:systemd-timesyncd.service(8)
Main PID: 155 (systemd-timesyn)
Status: "Contacted time server w.x.y.z:123 (pool.ntp.org)."
Tasks: 4 (limit: 8887)
Memory: 2.8M ()
CGroup: /system.slice/systemd-timesyncd.service
└─155 /usr/lib/systemd/systemd-timesyncd

Now, you can make sure it's working:

$ timedatectl timesync-status --monitor
Server: 69.164.213.136 (pool.ntp.org)
Poll interval: 4min 16s (min: 32s; max 34min 8s)
Leap: normal
Version: 4
Stratum: 2
Reference: 2FBBAE33
Precision: 1us (-24)
Root distance: 35.330ms (max: 5s)
Offset: -144.222ms
Delay: 69.398ms
Jitter: 27.131ms
Packet count: 17737
Frequency: +19.146ppm

After all of that, the fr24feed log should look something like this:

Apr 01 12:51:39 kaveri fr24feed[2314409]: [time][i]Synchronizing time via NTP
Apr 01 12:51:39 kaveri fr24feed[2314409]: [time][i]Time synchronized correctly, offset -0.181 seconds, drift -0.000 seconds/minute
Apr 01 12:51:48 kaveri fr24feed[2314409]: [feed][n]ping 1
Apr 01 12:51:48 kaveri fr24feed[2314409]: [feed][i]sent 3,0 AC
Apr 01 12:51:48 kaveri fr24feed[2314409]: [feed][n]syncing stream result: 1
...
Apr 01 13:11:40 kaveri fr24feed[2314409]: [time][i]Synchronizing time via NTP
Apr 01 13:11:40 kaveri fr24feed[2314409]: [time][i]Time synchronized correctly, offset -0.144 seconds, drift +0.000 seconds/minute
Apr 01 13:11:55 kaveri fr24feed[2314409]: [feed][n]ping 1
Apr 01 13:11:56 kaveri fr24feed[2314409]: [feed][i]sent 5,0 AC
Apr 01 13:11:57 kaveri fr24feed[2314409]: [feed][n]syncing stream result: 1

The software tries to synchronize the time every 10 minutes and you can see from the above examples that the time is only drifting a small amount.

[Oblivian]

Each time you edit a mass post its flagged as spam

I've had to approve it 3-4x now. Please try get em right first time.

[bimmerdriver]

Each time you edit a mass post its flagged as spam

I've had to approve it 3-4x now. Please try get em right first time.

I hope it's not necessary for me to say that I didn't intentionally post with typos. Regardless, the board should not flag an edit of a post as spam. It's broken. I also got numerous instances of this error message, which is utterly useless.

image.png

[Oblivian]

That is post too large/long generally

It trips up the way they use it through CloudFlare

Don't get me started on how badly implemented it is. None wants to configure it properly and still using the original custom modified v3 Configs