My Flightaware antenna doesn't function

FlightAware ADS-B Flight Tracking
102

i added the server
mlat-client

20200221 12:58:26.772  INFO     mlattrack            Read 0 blacklist entries
20200221 12:58:26.780  INFO     client               JSON client handler listeni                                              ng on :::1234 (TCP)
20200221 12:58:26.780  INFO     client               JSON client handler listeni                                              ng on 0.0.0.0:1234 (TCP)
20200221 12:58:49.111  INFO     client               [127.0.0.1:42334] Accepted                                               new client connection
20200221 12:58:49.112  INFO     client               [127.0.0.1:42334] Handshake                                               successful (test v3 dump1090 0.2.11 tcp zlib2)'
20200221 12:58:49.701  INFO     client               [127.0.0.1:42338] Accepted                                               new client connection
20200221 12:59:19.704  ERROR    client               [127.0.0.1:42338] Exception handling client
Traceback (most recent call last):
  File "/root/mlat-server-master/mlat/server/jsonclient.py", line 277, in handle_connection
    hs = yield from asyncio.wait_for(self.r.readline(), timeout=30.0)
  File "/usr/lib/python3.7/asyncio/tasks.py", line 423, in wait_for
    raise futures.TimeoutError()
concurrent.futures._base.TimeoutError
20200221 12:59:19.709  INFO     client               [127.0.0.1:42338] Disconnected
20200221 12:59:22.200  ERROR    asyncio              Task exception was never retrieved
future: <Task finished coro=<JsonClient.handle_connection() done, defined at /root/mlat-server-master/mlat/server/jsonclient.py:262> exception=CancelledError()>
concurrent.futures._base.CancelledError

mlat server

(env) root@raspberrypi:~/mlat-server-master# python3 mlat-server --work-dir /hom                                              e/pi/test --client-listen 1234
20200221 12:58:26.772  INFO     mlattrack            Read 0 blacklist entries
20200221 12:58:26.780  INFO     client               JSON client handler listeni                                              ng on :::1234 (TCP)
20200221 12:58:26.780  INFO     client               JSON client handler listeni                                              ng on 0.0.0.0:1234 (TCP)
20200221 12:58:49.111  INFO     client               [127.0.0.1:42334] Accepted                                               new client connection
20200221 12:58:49.112  INFO     client               [127.0.0.1:42334] Handshake                                               successful (test v3 dump1090 0.2.11 tcp zlib2)'
20200221 12:58:49.701  INFO     client               [127.0.0.1:42338] Accepted                                               new client connection
20200221 12:59:19.704  ERROR    client               [127.0.0.1:42338] Exception handling client
Traceback (most recent call last):
  File "/root/mlat-server-master/mlat/server/jsonclient.py", line 277, in handle_connection
    hs = yield from asyncio.wait_for(self.r.readline(), timeout=30.0)
  File "/usr/lib/python3.7/asyncio/tasks.py", line 423, in wait_for
    raise futures.TimeoutError()
concurrent.futures._base.TimeoutError
20200221 12:59:19.709  INFO     client               [127.0.0.1:42338] Disconnected
20200221 12:59:22.200  ERROR    asyncio              Task exception was never retrieved
future: <Task finished coro=<JsonClient.handle_connection() done, defined at /root/mlat-server-master/mlat/server/jsonclient.py:262> exception=CancelledError()>
concurrent.futures._base.CancelledError
^C20200221 12:59:38.819  INFO     root                 Halting on SIGINT
20200221 12:59:38.820  INFO     root                 Server shutting down.
20200221 12:59:38.820  INFO     client               [test] Disconnected
/root/mlat-server-master/mlat/server/coordinator.py:255: RuntimeWarning: coroutine 'wait' was never awaited
  util.safe_wait([self._write_state_task, self._write_profile_task])
RuntimeWarning: Enable tracemalloc to get the object allocation traceback
20200221 12:59:38.830  INFO     root                 Server shutdown done.
103

that’s mlat-server log twice.
just post the command line for a start.

104

At this point I can get everything working, including the connection via basestation format to virtualradar except the correct connection between client and server. I don’t understand what I’m wrong, could you please read the log I posted above that I can’t interpret it?
In practice I seem to understand from it that the client continues to disconnect from the server but I’m not sure.

105

The command line is not the log.
Please provide the command line as you had that so horribly wrong before.

Basically you need this setup:

mlat-server --client-listen 1234
mlat-client --input-type dump1090 --no-udp --input-connect localhost:30005 --server localhost:1234 --user feeder_1 --lat 50.12345 --lon 10.12345 --alt 123m --results beast,connect,localhost:30104 --results basestation,listen,31003

Add the work-dir for the mlat-server …

106

i’m using this:
python3 mlat-server --work-dir /home/pi/test --client-listen 1234 --write-csv testcsv --basestation-listen 3040

mlat-client --lat ****** --lon ***** --alt *****--user test --input-connect 127.0.0.1:30005 --input-type dump1090 --results beast,connect,127.0.0.1:1234 --server 127.0.0.1:1234

Now i try your setup
EDIT: I simply added --no-udp to my setup and solved several problems, but on mlat-client I still get this error: Fri Feb 21 19:44:56 2020 Beast-format results connection with 127.0.0.1:3018: [Errno 111] Connection refused while on mlat-server I don’t get any more errors.

107

You are connecting the results to the mlat server.

The mlat results are meant for dump1090-fa so they can be displayed.
Use my command line please … port 30004 is the port you want to connect to so they get sent to dump1090-fa

Really you need to try and understand what the connections do.

mlat client connects to dump1090 on 30005 to get the actual data you receive from the aircraft.
mlat client also connects to dump1090 on 30004, to provide it with mlat results.

mlat client also needs to connect to the mlat server to send it messages and the server will on the same connection send it back results.

Now you need to understand this basic setup or you won’t be able to configure it properly.

Giving the same address port for two different functions demnonstrates that you really don’t seem to know what the arguments mean.
Maybe now you understand why this can’t work.

108

Thanks a lot, I don’t really know how to thank you!
Now I don’t get any more errors.
However I think I have finally understood everything.
I wanted to ask you a couple of technical questions?
To leave mlat-server and mlat-client on all day, even when I close the session I have to use screen, as I already do for virtualradar?
In addition, the server returns data only when it manages to perform multilateration, so when I have at least 4 clients connected, or am I wrong?

109

No data will be returned until the server actually locates an aircraft, that’s correct.

Well normally you just use systemd services.
I’ve outlined how to do that here: Generic systemd service · wiedehopf/adsb-wiki Wiki · GitHub

I won’t explain that further though, you have to figure that out for yourself.

I would advise against running virtualradar on the Pi.
It will use up all your CPU and screw up MLAT while you have the website open.

111

@ssrdc is running his custom MLAT setup on a Pi 4. I’m running PiAware and Virtual Radar Server under Mono on a Pi 3B under tmux and I’m not seeing any evidence of it using up all my CPU or interfering with my MLAT stats while I have the website open.

Mono ticks along showing around 10% CPU usage, sometimes increasing to around 30%. This is with the VRS map open and active, flags and silhouettes rendering, ADS-B and MLAT data coming from localhost via the PiAware platform, tile server caching active and default process priority, as well as SkyAware also open and active in another browser and socat constantly feeding a remote server VRS instance.

Do you have a mechanism for measuring the effect VRS is having on MLAT, compared to when VRS is not running, since I’m seeing no impact or errors reported?

If desired, Mono’s default process priority can be lowered by increasing its niceness to, say, 10. Start it with:

$ nice -n 10 mono /path/to/VirtualRadar.exe -nogui

or to lower the priority if already running:

$ renice 10 -p $(pgrep mono)
113

FWIW, in theory the only semi-real-time-performance-sensitive part of mlat is the dump1090 demodulator itself, and the default install will nice it to a higher priority: dump1090/dump1090-fa.service at master · flightaware/dump1090 · GitHub … though if VRS is indeed taking all the remaining CPU then that will only mitigate the problem so far.

114

Indeed I noticed it was at -5 instead of 0. There is fa-mlat-client at 0 but it hangs around 0.7% CPU on my 3B. As you say dump1090-fa is the thing that is active and that hovers around 15-20% here. Mono and VRS don’t add much and I’ve not seen them screw up MLAT timing by consuming all the CPU resource or by any other means. I’m not aware of a way to measure any effect though, I’m just going by the lack of problems with MLAT and the CPU being far from maxed out.