(Resolved) - [PiAware][Ubuntu][amd64] Local clock source is unstable

Hi all,

I have moved my ADSB setup from a RPi4 to an Ubuntu 22.04 LTS on Promox on HP Proliant DL360 and the USB plugged into the back of the server and pass-thru to the VM.

I followed the instructions found here.

I have setup the local timezone of my VM to match where I am, however, I see the MLAT is now colored orange and reports that “Local clock source is unstable”.

Any suggestions on how to fix this?

This is likely why. USB timing is likely being interfered with by the VM. MLAT relies on accurately timestamping the incoming USB packets, and this is done in software. If there is any jitter introduced by the virtual machine, that will cause those time stamps to be inaccurate and therefore not make sense to the server.

Unfortunately, don’t run in a virtual machine is the usual answer unless there is a way to configure it to give more direct access to the USB ports that means the data arrives smoothly.

Understand, however, due to RPi shortages, I had to pull this one out for another project. Is there a way to check/measure the timing for incoming USB packets/jitter to check if this is the actual reason?

Why not install Ubuntu directly on Hard Drive of HP Proliant DL360 as dual boot? Alternatively, if possible, get rid of existing OS of HP Proliant DL360 and install Ubuntu or Debian.

Couple of months ago, I purchased a used Thin Client HP520 with on-board 16 GB SSD for $48. It came with Windows10 pre-installed.

As I had already faced mlat issue on VM on Windows PC, I did not go for VM. I replaced HP520’s Windows10 by Debian11 amd64. Then installed dump1090-fa and piaware on it. With this arrangement MLAT works perfect.

The reason I am using Proxmox as hypervisor is because I have other services and VMs running on that hardware. Looks like the only way to resolve this issue is to use a physical machine and have either Debian or Ubuntu installed on it to run PiAware.

Thanks.

You’ll probably need something quite low level to do that. Maybe something like wireshark can do it. That might suffer from the same issue if you run it within the virtual machine though. Perhaps capturing the traffic on the host machine and within the VM simultaneously and comparing the two would be possible, but I don’t know how you’d go about it or how reliable it would be.

The timestamps are applied to the decoded messages rather than the actual USB packets - the problem is that the decoding and time stamping takes place after the USB transfer, so the decoder can’t actually tell if there is any jitter.

rtl_test can act as a crude test (run it at 2.4MHz)

For a more comprehensive test … well, that’s what the mlat server is already doing, looking at message arrival times to see if they’re consistent with what other receivers are seeing. If you’re seeing “clock unstable” then the server thinks your timing is inconsistent.

Since you are using Proxmox, containers provide a more direct link to the hardware than VMs.

I had the same problem with a VM in Proxmox.

I managed to get a CT running with Piaware in May 2022 following various threads on the internet for FR24 in a Proxmox CT (abcd 567 contributed to one). That seemed to avoid the timing errors but I lost that install with a hard disk corruption.

Did not have chance to try to set it up again until December 2022 but could not get it working. I thought my notes were comprehensive but apparently not :face_with_raised_eyebrow: .

Having spent a lot of time trying to understand the passthrough of a RTL2838 dongle to a CT, eventually got it working two days ago. Not sure if Proxmox changed things since last year (more strict?) but there seemed to be omissions from my notes and the internet threads. Anyway Piaware seems to be working ok for now in the CT.

Too soon to know if this is going to work long-term, and I want to reinstall on another machine to ensure my notes are now correct - already had to revisit and modify after rebooting!

There are some Docker installs of Piaware on the internet - did not try those but they may offer the same “closer to the bare metal” than a VM.

That’s great. Would love to get a hold of your notes to see how you did it with containers/CT.

My original starting points were these two threads:

Based on these, somehow I got RTL2838 passthrough working in early 2022 but no luck at all near Christmas.

Someone else might jump in with their own recipe that works - certainly feels like casting spells.

Anyway the threads might give you a clue as to what is involved. Essentially passing through the hardware to the container and also permissions for use in the container, with very specific rules for those that need to match one-to one with the host. Others are transformed to different uid/gid.

To keep the container lightweight, I use the “Core” container from Turnkey Linux which is based on Debian 11.

I’m running this on an HP T630 thin client. This is the next version up from what abcd567 mentioned (cheaper prices in the UK). But rather than use bare metal, I want to be able to dump this in the loft and upgrade Piaware remotely. Just create and test a CT with the latest Piaware. Getting too old to be changing out SD cards in a Pi up a ladder. Hence the reason my working Piaware on a Pi is still stuck on a very old version (v4.0?). Your DL360 has much more horsepower so should not even notice the new CT.

I have another T630 destined for Kodi but will test Piaware from scratch over the next few days. Problem is changes need to be made to both host and container, so although I can easily backup the CT to retain or revert from latest changes, the host needs to be reinstalled to revert to original state

Well I’m glad I checked my method. Found that i could leave out all the complicated stuff that took me ages to figure out.

Basically it just needs the USB port to be passed through. No need for the /dev/dvb/adapter0 that adds the complication.

So create a container on Proxmox using your distro of choice.

Plug in the RTL2838 stick. and use lsusb to discover the port it uses ls -al to check ownership

root@pveLXC:~# lsusb
Bus 002 Device 002: ID 0bda:2838 Realtek Semiconductor Corp. RTL2838 DVB-T

root@pveLXC:~# ls -al /dev/bus/usb/002
crw-rw-r-- 1 root root 189, 129 Jan 21 17:43 002

Create an sdr-rules file and add the following rules. Apply the new rule.

root@pveLXC:~# nano /etc/udev/rules.d/rtlsdr.rules

SUBSYSTEMS==“usb”, ATTRS{idVendor}==“0bda”, ATTRS{idProduct}==“2838”, ENV{ID_SOFTWARE_RADIO}=“1”, MODE=“0666”, GROUP=“plugdev”

root@pveLXC:~# udevadm control --reload-rules && udevadm trigger

Recheck the USB port for the RTL2838 stick - it should now include “plugdev” in its ownership/

root@pveLXC:~# ls -al /dev/bus/usb/002
crw-rw-rw- 1 root plugdev 189, 129 Jan 21 18:31 002

On the host, edit the container config file and add two lines at the end.

root@pveLXC:~# nano /etc/pve/lxc/.conf

lxc.cgroup2.devices.allow: c 189: rwm*
lxc.mount.entry: /dev/bus/usb dev/bus/usb none bind,optional,create=dir

Start the container.

Check that the USB port with the RTL2838 stick has been passed through:

root@pveLXC:~# ls -al /dev/bus/usb/002
crw-rw-rw- 1 nobody nogroup 189, 129 Jan 21 17:46 002

Install dump1090, piaware and piaware-web using abcd567’s scripts https://discussions.flightaware.com/t/build-install-piaware-ver-8-2-on-amd64-x86-64-and-arm64-aarch64-computers-using-sripts/85662/6 or whatever you use to install Piaware. (Since I was using Debian as root I needed to remove sudo from abcd57’s scripts) .

In the container, run the command below to ensure “plugdev” is part of dump1090 group

root@Piaware ~# groups dump1090
dump1090 : nogroup plugdev

Finally run the URL given at the end of piaware-web installation. You should see “1090 radio”, “Piaware” and “Flightaware” in green. MLAT will be red until you provide a location for the receiver.

That’s the recipe but YMMV - no explanation provided of how it works. If you want to know or it does not work, let me know…

This topic was automatically closed 365 days after the last reply. New replies are no longer allowed.