Irregular Gaps in statistics feed

[ua549]

A connection can be closed if there is no data within a certain amount of time, i.e., timeout.

[Oblivian]

What do you mean as a receiver that my Raspberry Pi goes offline creating a hole in the reception time as if I had turned off my receiver?

Yes.

If the servers you are feeding think there is an issue with the stick as they have not received data for a while. They have the permission to restart dump1090/feeder device to try and fix it. As you have low range, it is possible there are periods where you have no signal so is being reset.

You'll need to look at range/data improvement to ensure this is not happening.

And turn on logging and look back at the times of the outtage for the message received, If like this - the server is rebooting you

[reader][w]Global timeout exceeded, 1 msgs, 0 resyncs, reconnecting
[reader][i]Connection terminated

[dan52]

What do you mean as a receiver that my Raspberry Pi goes offline creating a hole in the reception time as if I had turned off my receiver?

[Oblivian]

Both FlightAware and fr24 can and do remotely reset connections if there is no signal from receiver incase it has gone offline

It is possible this is what's happening.

Sent from my EML-L09 using Tapatalk

[dan52]

Oblivian you are telling me that it is not the fault of the servers but because I do not see over 18nm and 34 aircraft, because when I had FR24 feed Windows did not happen this, only with Raspberry Pi I am confused!

[Oblivian]

You can't be so fast to blame the servers when most others are like this




Your issue is likely to be the fact you see only 18nm and 34 aircraft.

7 am here and already
AIRCRAFT SEEN
83

MAXIMUM DISTANCE
181nm

HITS REPORTED
85,153




Sent from my EML-L09 using Tapatalk

[dan52]

Still the problems with the servers persist, seeing the graph of the data that are not yet linear there are interruptions of temporary. When is there still to wait for a resolution to this problem? Thanks

[LN-MOW]

Possible. Either way it doesn’t fix the problem.


Sent from my iPad using Tapatalk Pro

[wiedehopf]

LN-MOW:
Are the config lines fixing it for a few hours or rather that you restart the feed?

My guess would be that it's the restart that somehow helps for a bit.

[LN-MOW]

Nooo. Your images have the pulsing start stop in incremental gaps. That is the known about bug that the config lines fix.

His, is full of holes of actual reporting failure.

Check the screenshots. Not to be confused.

OK, I see that. The config lines do not fix this, except for for a few hours.







Sent from my iPad using Tapatalk Pro

[Oblivian]

Oblivian:
[FAIL] Receiver: down ... failed!

This is not a problem with FR24 though but rather looks like a dump1090 problem.

My graphs might help both of you check that your local dump1090 continues working:

https://github.com/wiedehopf/graphs1090#graphs1090

.

The irony is.. the source is beast-splitter and a beast - not a USB/dump1090 for me other than testing/checking stuff for other users remember

My Dump1090-fa is hanging off the side and not doing a lot other than an alternate pretty map

I *think* it may be the old fr24feed build not liking more than 2 TCP network connections again and giving up the ghost in the most bizzare way. Similar to how people were seeing it die with SBS direct as source (before it stopped reading that data format totally)

It's similar to when I had it doing the direct beast read handling with multiple TCP connections to feeder output. Have since realised the start may also coincided with me starting up a 2nd TCP:30003 reader I had forgotten about. And despite only having 2, the logs are filling with it getting multiple connection detects.

Basically, if it is. FR24feed is arse for multiple TCP client connections. And throws its toys out by dropping the receiver and internal webpage while still trying to send received data.

[wiedehopf]

Oblivian:
[FAIL] Receiver: down ... failed!

This is not a problem with FR24 though but rather looks like a dump1090 problem.

My graphs might help both of you check that your local dump1090 continues working:

https://github.com/wiedehopf/graphs1090#graphs1090

If it's indeed dump1090 that stops working, i'd recommend switching to dump1090-fa:

https://github.com/wiedehopf/adsb-wiki/wiki/Bundle-install-for-dump1090fa

(you'd need to reinstall the graphs when switching to dump1090-fa after installing the graphs)

With a separate dump1090, problems can be more easily separated beteween fr24feed and dump1090.
Also there are dump1090-fa logs which one can check.

I'm not sure how fr24feed behaves when the dongle has insufficient voltage.
You should check if your RPi has sufficient power with this command:

dmesg --ctime | grep voltage

If there are under-voltage messages this points to an insufficient power supply which can lead to all sorts of problems with dongles.

[Oblivian]

Now if you were in my shoes, I'd be worried. 25% uptime.

fr24offline.JPG

Unlike others - Not only does it continue to say it's feeding but go offline at stat level, the web config goes offline along with the 30003 output data. It basically locks up the local feeder portion.

[ ok ] FR24 Feeder/Decoder Process: running.
[ ok ] FR24 Stats Timestamp: 2019-07-08 06:06:22.
[ ok ] FR24 Link: connected [TCP].
[ ok ] FR24 Radar: T-NZCH1.
[ ok ] FR24 Tracked AC: 1.
[FAIL] Receiver: down ... failed!
[ ok ] FR24 MLAT: ok [UDP].
[ ok ] FR24 MLAT AC seen: 0.

I'm considering looking into it starting after I added adsbx..

[Oblivian]

I have exactly the same issue, as mentioned in another post. I have three feeders, three pi’s, using both piaware and pi24 and it’s the same on all. It has lasted since I switched from Windows to RPi ...

But I’m feeding and it doesn’t seem to affect the number of hits. So hey ...


Sent from my iPad using Tapatalk Pro

Nooo. Your images have the pulsing start stop in incremental gaps. That is the known about bug that the config lines fix.

His, is full of holes of actual reporting failure.

Check the screenshots. Not to be confused.

[LN-MOW]

Irregular feed

I have exactly the same issue, as mentioned in another post. I have three feeders, three pi’s, using both piaware and pi24 and it’s the same on all. It has lasted since I switched from Windows to RPi ...

But I’m feeding and it doesn’t seem to affect the number of hits. So hey ...


Sent from my iPad using Tapatalk Pro