Maybe somebody here has the same issue or was able to resolve it.
I have a green Radarbox dongle connected to a Thin client and it is feeding Flightaware and FR24.
For FR24 is regularly reports being online but not sending data (status online -no data on the status page).
Only remedy i found so far is rebooting it and then it starts to report again.
Since it is still seen online it doesn’t generate an alert so if I don’t check often it might lose multiple hours of sending data.
Flightaware reporting goes flawless and it is not showing any issues.
All other equipment ( ADSBexchange and FA Prostick plus dongles) don’t show this behavior.
Has anybody else this same behavior ? If so, were you able to fix it and how ?
Many thanks for any insights
This problem does not seem to be related to dongle (Radarbox Green Flightstick) or dump1090-fa, else all sites will be affected.
As far as I know, this is problem of FR24 servers.
Better ask this question in Flightradar24 forums. There moderator and members may be able to answer.
Analyzing the logs, this specific receiver will try to reconnect to FR24 but it is trying to do so on the type DVB-T but it is defined as AVR-TCP in the fr24feed.ini file.
AVR-TCP is correct so I’m trying to understand why it is attempting to connect on DVB-T instead of the AVR-TCP option as configured.
Since it gets no reponse from DVB-T it ends up in an endless loop trying to get connected.
Here; the contents of the ini file (Sharing key is intentionally removed)
receiver=“avr-tcp”
fr24key=“”
host=“127.0.0.1:30002”
bs=“no”
raw=“no”
logmode=“2”
windowmode=“0”
logpath=“/var/log/fr24feed”
mlat=“no”
mlat-without-gps=“no”
Software version 1.0.34 running om DietPi (Debian 11) Linux system, hardware is a HP Thinclient T620.
I have AVR-TCP configured on all the other systems as well.
None of them has this issue but this one does.
According to the manual you need to use AVR-TCP when using a stand-alone dump1090. I don’t use mutuabilty but the dump1090-fa as a datasource.
noted in secion 2.4 under dvbt decoder:
When using with stand alone dump1090 instance or another
software defined radio demodulator please use the “avr tcp” receiver type instead.
Sent the logs to FR24 again, when starting the application from the status page it will attempt to start the software again as a DVBT stick.
It is configured otherwise as avr-tcp.
When rebooting the ini file is picked up correctly and it will start feeding as avr-tcp.
So I’ve asked them why the ini file seems to be ignored when starting from the application and being accepted when rebooting.
In both cases the file is located at the same location in the /etc folder.
They have never encountered this error and advised me to reconfigure to
receiver=“beast-tcp”
host=“127.0.0.1:30005”
fr24key=
bs=“no”
raw=“no”
logmode=“0”
windowmode=“0”
mpx=“no”
mlat=“no”
mlat-without-gps=“no”
So receiver is reconfigured and connected straight away on the first attempt using the restart feature from the status page ( it didn’t connect previously on the avr-tcp setting).
So I’ll be monitoring the performance for the upcoming hours and next few days to determine if this is the solution.
Funny enough it is contradicting their own manual
The parameter receiver=“beast-tcp”, as well as following parameters were used in older versions of fr24feed, and are no more used in newer versions.
windowmode=“0”
mpx=“no”
What is the version of your fr24feeder?
You can find it displayed in browser at address IP:8754. Please see screenshot below. It shows latest version 1.0.37-0
Oh ok, I thought your problem is on RPi or an arm based SBC.
For AMD64, their latest version is still 1.0.34-0
I also have the version 1.0.34-0 installed on Debian 12 AMD64, and it works OK with settings receiver="avr-tcp" and host="127.0.0.1:30002". Please see screenshots below.
I will start the upgrade to Debian 12 when the other feeders based on RPI and other SBC’s are also upgraded (When FA releases the new software versions).
I have one test system already running Debian 12 but no other software installed on that.
