Windows feeder discontinued 7-May-19

[esom]

Thanks to Stealth and Wiedehopf. I have am not using Wifi, LAN connection is via cable. An expert friend of mine looked into log files and said that device is disconnecting from LAN and not returning, which is very similar to Wiedehopf's Wifi problem. He will pass by today and help me by writing a script to automatically restart the device every 6 hours, which I hope will solve the problem temporarily until I find the real cause. By the way what was the cause of your random Wifi disconnection?

[wiedehopf]

I am NOT happy at all after being forced to change from Windows to Raspberry Pi with Pi24 image. Receiver is SBS-3 connected via TCP
Raspberry Pi stops randomly sometimes once a day sometimes after few days. The device stops completely and doesn't respond neither to Putty nor to ping.. Only solution is power off and restart. .

Once had the problem of my RasPi randomly disconnecting from WiFi and not reconnecting.

But that isn't necessarily your problem so let's make the logs permantent (normally they only live in the RAM).

For that we first need to check that the sd-card isn't mounted read-only, can you show the output of:

cat /etc/fstab
mount | grep mmc
sudo mount -o remount ,rw /

The last command makes sure you can write to the sd-card so the following changes to journald (making logs permantent) will stick:

sudo nano /etc/systemd/journald.conf
Change 
#Storage=auto
to
Storage=persistent
(remove the #, otherwise the line will be ignored)

Ctrl-o and enter to save, Ctrl-x to exit.

Apply the journald changes:

sudo systemctl restart systemd-journald

After the next problem and power cycle you should be able to check for example dhcpcd logs:

sudo journalctl -eu dhcpcd -b -1

-b -1 means that it shows the log from the previous startup and -e is for scrolling to the end.
So in case WiFi not reconnecting is the problem it should show here.

Note that in case the sd-card is always mounted read-only you'll have to change that so it continues to write logs after a reboot.
(changing to read write was only for the current boot)

[Stealth]

I am NOT happy at all after being forced to change from Windows to Raspberry Pi with Pi24 image. Receiver is SBS-3 connected via TCP
Raspberry Pi stops randomly sometimes once a day sometimes after few days. The device stops completely and doesn't respond neither to Putty nor to ping.. Only solution is power off and restart. Being a person without any RasPI or Linux experience I have no idea what to do? On the other hand I am a frequent traveller and not at home always to restart the device manually. At least the Windows, basestation, SBS-3 worked perfectly once the automatic windows update was disabled during my travels.
Any ideas or little help into which log files I could have a look will be very much appreciated.

I'm not a Raspberry user, but from my readings the three potential fail areas for them are, power supply, SD Card and finally hardware failure. The last issue does not seem as common as the first two.
Its unfortunate that you have already spent the money on the hardware, but an alternative is stick with Windows, then run linux and the FR24 feeder on a virtual machine. I've been running it for 10 days now and the only downtime has been at FR24's end. Everything starts up after power outages automatically, including the linux and feeder on the VM.

[esom]

I am NOT happy at all after being forced to change from Windows to Raspberry Pi with Pi24 image. Receiver is SBS-3 connected via TCP
Raspberry Pi stops randomly sometimes once a day sometimes after few days. The device stops completely and doesn't respond neither to Putty nor to ping.. Only solution is power off and restart. Being a person without any RasPI or Linux experience I have no idea what to do? On the other hand I am a frequent traveller and not at home always to restart the device manually. At least the Windows, basestation, SBS-3 worked perfectly once the automatic windows update was disabled during my travels.
Any ideas or little help into which log files I could have a look will be very much appreciated.

[Stealth]

Alternate to UDP connection for ISPs that kill constant connections thinking they are torrenting or similar. Causes gaps in feeding in strange increments. Will then send via http instead.

Thanks. That's not a problem that I've had so far, I'll leave it hashed and stick with UDP. Although I must do some reading up to see if running under a VM might have been stopping the http feed.

[Oblivian]

Not related to the Airspy question, but I revisited those last two settings you give in the .ini file this morning and found something odd. On restarting fr24feed the log file showed a lot of configuration and other steps that indicated it was talking to FR24 (although I don't usually see most of those lines). However, no data was being incremented on the FR 'data sharing' page although it showed I was 'online'. Subsequently it showed a 21 minute break in 'daily availability'. I hashed those two lines out, rebooted, and all is normal again. What is 'use-http' designed to achieve?

Alternate to UDP connection for ISPs that kill constant connections thinking they are torrenting or similar. Causes gaps in feeding in strange increments. Will then send via http instead.

[Stealth]

/etc/fr24feed.ini should look like this:

use-http=yes
http-timeout=20
[/code]

Not related to the Airspy question, but I revisited those last two settings you give in the .ini file this morning and found something odd. On restarting fr24feed the log file showed a lot of configuration and other steps that indicated it was talking to FR24 (although I don't usually see most of those lines). However, no data was being incremented on the FR 'data sharing' page although it showed I was 'online'. Subsequently it showed a 21 minute break in 'daily availability'. I hashed those two lines out, rebooted, and all is normal again. What is 'use-http' designed to achieve?

[esom]

Thanks Wiedehopf!
Very helpful information. I will look into it and prepare myself in case current solution doesn't work on long term. Actually it is better for me to continue with SBS3 and RaPi, as the receiver is dedicated to the feed and I can continue using airspy as SDR for other things.

[wiedehopf]

Setting up the airspy is not quite trivial.
You need to run its own ADSB decoder and configure fr24-feed to beast-tcp and use the output of airspy_adsb.
(It's not rtl-sdr compatible and thus not supported directly by fr24 when you choose the DVB-T config option)

If you want further information about how you can setup airspy_adsb, you can check here:

https://github.com/wiedehopf/airspy-conf#airspy-conf

https://github.com/wiedehopf/airspy-conf/wiki/Manual-airspy-configuration-to-work-with-dump1090-fa-and-piaware

The correct fr24feed configuration to go with the above guide is:
beast-tcp
host: 127.0.0.1
port: 30005

/etc/fr24feed.ini should look like this:

receiver="beast-tcp"
fr24key="xxxxxxxxxxxxxxxx"
host="127.0.0.1:30005"
bs="no"
raw="no"
logmode="1"
logpath="/var/log/fr24feed"
mlat="yes"
mlat-without-gps="yes"
use-http=yes
http-timeout=20

[esom]

Hello
I have been a windows feeder using SBS-3 connected via network to Basestation running on Windows PC. Due to latest decision of FR24 dropping windows support, I quickly ordered Raspberry Pi B 3 Plus kit from ABOX. With some support from a friend and internet search I managed to boot the device with Pi24 image. Here I must admit there are no clear instructions and step by step guidance on FR24 site, which is not good. They expect everybody to understand Raspberry Pi. Anyway my first attempt to use Airspy SDR connected via USB to RpI didn't work system was up but there was not a single aircraft. I still have no idea why?
Then I chose the option in FR24 SBS3 via TCP entered IP address and port. Suddenly everything worked.
For those of you in a similar situation forced to switch from windows to Rpi, I wanted to confirm that SBS-3 and Rpi works. I am still observing and hope it will continue as it is.

[Stealth]

There is no indication anywhere for a change of plans.

Why should not removing the download option mean anything?

Just wishful thinking Alter Bursche

[wiedehopf]

There is no indication anywhere for a change of plans.

Why should not removing the download option mean anything?

[Stealth]

I note the Windows feed software link is still available on the Share Your Data webpage...does this mean there has been a change of plan and Windows will still be supported post 1st May?

Damn, I hope not after all the time that I and others have spent making changes just for them!

[FlyingAnt]

I note the Windows feed software link is still available on the Share Your Data webpage...does this mean there has been a change of plan and Windows will still be supported post 1st May?

[Stealth]

So you would need to check the "raw" checkbox for the TCP/IP server in planeplotter correct?

And then use beast-tcp as format for fr24feed running wherever.

pp and fr.jpg
io_screen.png