Plane Finder Client Beta3 (3.0.1657)

Status
Not open for further replies.

eddm_muc

New Member
@Lee
After having installed the new client on my Radarcape, it told me to go to http://192.x.1.21:30053. (which is the the correct IP of the cape)
when I check the logfile in the browser I see that a wrong IP (192.x.0.21) is used in the config
In order to change the settings via the browser I need the new sharer code...
how do I get the new sharer code?

edit:found it directly in the config file of the Radarcape
its connected to port 10003 now
 
Last edited:

Bryan M

New Member
Lee
Had to replace my router, so after router setup I updated to 3.0.1657 along with the current raspian. I am not seeing aircraft at ip:30053, but I am at ip:8080. The client stats page shows up time and the sharer list says that I am live, but the map and data view show no activity. I went through the configuration to change my rpi static IP. Here is an excerpt from the log file. What am I missing?

2015-06-12 22:47:52.255115 Failed TCP connection to all provided addresses for: 10.0.0.7:30005
2015-06-12 22:47:52.254713 Failed to open connection to socket: Connection timed out (errno: 110)
2015-06-12 22:45:39.935061 Failed TCP connection to all provided addresses for: 10.0.0.7:30005
2015-06-12 22:45:39.934672 Failed to open connection to socket: Connection timed out (errno: 110)
2015-06-12 22:43:27.615203 Failed TCP connection to all provided addresses for: 10.0.0.7:30005
2015-06-12 22:43:27.614724 Failed to open connection to socket: Connection timed out (errno: 110)
2015-06-12 22:41:15.295483 Failed TCP connection to all provided addresses for: 10.0.0.7:30005
2015-06-12 22:41:15.294958 Failed to open connection to socket: Connection timed out (errno: 110)
2015-06-12 22:39:02.975425 Failed TCP connection to all provided addresses for: 10.0.0.7:30005
2015-06-12 22:39:02.975034 Failed to open connection to socket: Connection timed out (errno: 110)
2015-06-12 22:36:50.655085 Failed TCP connection to all provided addresses for: 10.0.0.7:30005
2015-06-12 22:36:50.654702 Failed to open connection to socket: Connection timed out (errno: 110)
2015-06-12 22:34:38.343473 Failed TCP connection to all provided addresses for: 10.0.0.7:30005
2015-06-12 22:34:38.334692 Failed to open connection to socket: Connection timed out (errno: 110)
2015-06-12 22:32:26.15068 Failed TCP connection to all provided addresses for: 10.0.0.7:30005
2015-06-12 22:32:26.14676 Failed to open connection to socket: Connection timed out (errno: 110)
2015-06-12 22:30:13.695089 Failed TCP connection to all provided addresses for: 10.0.0.7:30005
2015-06-12 22:30:13.694695 Failed to open connection to socket: Connection timed out (errno: 110)
2015-06-12 22:28:01.375100 Failed TCP connection to all provided addresses for: 10.0.0.7:30005
2015-06-12 22:28:01.374700 Failed to open connection to socket: Connection timed out (errno: 110)
2015-06-12 22:25:49.55102 Failed TCP connection to all provided addresses for: 10.0.0.7:30005
2015-06-12 22:25:49.54705 Failed to open connection to socket: Connection timed out (errno: 110)
2015-06-12 22:23:36.735314 Failed TCP connection to all provided addresses for: 10.0.0.7:30005
2015-06-12 22:23:36.734749 Failed to open connection to socket: Connection timed out (errno: 110)
2015-06-12 22:21:24.415085 Failed TCP connection to all provided addresses for: 10.0.0.7:30005
2015-06-12 22:21:24.414714 Failed to open connection to socket: Connection timed out (errno: 110)
2015-06-12 22:19:17.18705 Client restarted successfully
2015-06-12 22:19:16.192022 Restarting due to configuration change

sharer Bryan M
 

Lee Armstrong

Administrator
Staff member
If the client is on the same machine as Dump1090 just change the IP to 127.0.0.1

The log is showing we cannot connect to 10.0.0.7 port 30005
 

ab cd

Senior Member
Change which IP to 127.0.0.1? Dump1090 & PF Client are running on an RPi with dongle.

Please see "CONFIGURE" in this post:

http://forum.planefinder.net/threads/raspberry-pi-b-plus-installation-instructions-for-raspbian-dump1090-data-feeder.241/#post-2451

PFClient Config 4a.PNG
 
Last edited:

darethehair

New Member
[Newbie here...]

In the last week I have successfully configured my RPi with 'PiAware', feeding FlightAware and FlightRadar24 successfully. I thought I would try to add PlaneFinder as a 3rd feed, but I am running into problems. Looking at the 'reverse' time log:

Code:
2015-06-20 22:56:36.643644 TCP connection established: 127.0.0.1:30005
2015-06-20 22:56:36.643037 Client restarted successfully
2015-06-20 22:56:36.642979 Closed TCP connection
2015-06-20 22:56:36.642722 Decoder select timeout occurred, restarting...
2015-06-20 22:56:26.636778 Echo port is now listening on: http://192.168.1.118:30054
2015-06-20 22:56:26.636499 TCP connection established: 127.0.0.1:30005
2015-06-20 22:56:26.636074 Web server is now listening on: http://192.168.1.118:30053
2015-06-20 22:56:26.634113 user_longitude = -98.200000
2015-06-20 22:56:26.634053 user_latitude = 49.100000
2015-06-20 22:56:26.633989 web_server_port = 30053
2015-06-20 22:56:26.633952 select_timeout = 10
2015-06-20 22:56:26.633909 aircraft_timeout = 30
2015-06-20 22:56:26.633842 data_format = 3
2015-06-20 22:56:26.633797 tcp_port = 30005
2015-06-20 22:56:26.633740 tcp_address = 127.0.0.1
2015-06-20 22:56:26.633684 connection_type = 1
2015-06-20 22:56:26.633202 pfclient (3.0.1657 armhf) started with the following options:

What can I do about the 'Decoder select timeout' error?

Thanks!
 

Lee Armstrong

Administrator
Staff member
When we have a period of no traffic we actually disconnect and reconnect to make sure that it hasn't hung at the other end. We don't miss any data as it's so quick but that is usually the cause
 

darethehair

New Member
When we have a period of no traffic we actually disconnect and reconnect to make sure that it hasn't hung at the other end. We don't miss any data as it's so quick but that is usually the cause

Makes sense, but I just tracked a flight (CX828) near my location, and though it was detected (and plotted) with my receiver, there were no obvious indications in either the PlaneFinder 'log' or 'stats' that it had also detected it. Any thoughts on why this might be?
 

Lee Armstrong

Administrator
Staff member
It's hard to say but it may not have been passed on to us for some reason!?

We mainly focus & test on direct connection to a dedicated ADS-B receiver and I know from testing we use everything we are passed from those.
 

darethehair

New Member
It's hard to say but it may not have been passed on to us for some reason!?

We mainly focus & test on direct connection to a dedicated ADS-B receiver and I know from testing we use everything we are passed from those.

Well, if anyone out there is running a similar setup to what I have (i.e. PiAware on a Raspberry Pi), trying to feed FlightAware, FlightRadar24, *and* PlaneFinder -- but not having success with the latter -- I would be interested to know how you are doing it :)
 

ab cd

Senior Member
Well, if anyone out there is running a similar setup to what I have (i.e. PiAware on a Raspberry Pi), trying to feed FlightAware, FlightRadar24, *and* PlaneFinder -- but not having success with the latter -- I would be interested to know how you are doing it :)
I am running a setup just like your setup, but never faced any problem feeding any of the three (i.e. flightaware, flightradar24 & planefinder)
 

darethehair

New Member
I am running a setup just like your setup, but never faced any problem feeding any of the three (i.e. flightaware, flightradar24 & planefinder)

Great! In that case, do you see anything wrong with my parameters -- listed in message #66 above? If detected planes *are* passed on to 'planefinderclient', would I see confirmation in both the 'log' and 'stats'?
 

ab cd

Senior Member
Great! In that case, do you see anything wrong with my parameters -- listed in message #66 above? If detected planes *are* passed on to 'planefinderclient', would I see confirmation in both the 'log' and 'stats'?
I never bothered to check so minutely as you did, but generally the number of planes picked by antenna+dongle are all shown both in log as well as stats. I do notice connection failed and restart, but it is not frequent. As Lee has already explained, it happens with me when no planes are detected such as during low traffic times between midnight & early morning.

I suggest you keep an eye on your system logs for couple of days to find how frequently this occurs.
 
Last edited:

darethehair

New Member
I never bothered to check so minutely as you did, but generally the number of planes picked by antenna+dongle are all shown both in log as well as stats. I do notice connection failed and restart, but it is not frequent. As Lee has already explained, it happens with me when no planes are detected such as during low traffic times between midnight & early morning.

I suggest you keep an eye on your system logs for couple of days to find how frequently this occurs.

Well, for me, the 'timeout' occurs regularly every 10 seconds -- which perhaps is normal if no planes are detected -- but right now I am *never* having any planes detected, so something must be wrong. As far as I know, my port settings are correct (30005, right)...
 

Lee Armstrong

Administrator
Staff member
Sorry I didn't realise you weren't seeing planes ever! The log only showed the one reconnect.

Your settings do look a little off actually! You are connecting to Dump1090 port 30005 which should be open but it is Beast Binary format and you don't have that set. I think you have 30003 format set from memory there!
 

darethehair

New Member
Sorry I didn't realise you weren't seeing planes ever! The log only showed the one reconnect.

Your settings do look a little off actually! You are connecting to Dump1090 port 30005 which should be open but it is Beast Binary format and you don't have that set. I think you have 30003 format set from memory there!

Thanks! After changing the port to 30003, it does seem to now be feeding flight info when data is detected e.g.

Code:
...
2015-06-22 15:24:22.692619 Client restarted successfully
2015-06-22 15:24:22.692552 Closed TCP connection
2015-06-22 15:24:22.692198 Decoder select timeout occurred, restarting...
2015-06-22 15:24:18.385772 Successfully sent 4 aircraft updates over the past minute (2.00kb)
2015-06-22 15:24:12.688690 TCP connection established: 127.0.0.1:30003
2015-06-22 15:24:12.687973 Client restarted successfully
2015-06-22 15:24:12.687909 Closed TCP connection...

The 'restart' and 'close connection' events do occur every 10 seconds, so the log is full of those messages -- but I guess this is normal.

Something strange this morning was that I was seeing no log activity whatsoever, even though the status of 'pfclient' was 'running'. I decided to reboot, and then noticed (again) that the client had not restarted itself. I wasn't sure if the install process had set it up that way or not, so I used the following earlier to insure that it was:

Code:
sudo update-rc.d pfclient defaults

Since this had not worked during the reboot, I did restarted it manually and noticed this error message:

Code:
[email protected] /etc/init.d $ sudo ./pfclient start
[....] Starting pfclient: pfclient./pfclient: 35: ./pfclient: cannot create /var/log/pfclient/error.log: Directory nonexistent

I corrected this (temporarily) by creating the missing directory:

Code:
sudo mkdir /var/log/pfclient/

However, this leads me to what is perhaps a silly question: why should I need to do this? I *think* the entire '/var/log' directory schema is created each time a reboot occurs, so this isn't a 'one time' fix, right?

Thanks!
 

Lee Armstrong

Administrator
Staff member
Thanks! After changing the port to 30003, it does seem to now be feeding flight info when data is detected e.g.

Code:
...
2015-06-22 15:24:22.692619 Client restarted successfully
2015-06-22 15:24:22.692552 Closed TCP connection
2015-06-22 15:24:22.692198 Decoder select timeout occurred, restarting...
2015-06-22 15:24:18.385772 Successfully sent 4 aircraft updates over the past minute (2.00kb)
2015-06-22 15:24:12.688690 TCP connection established: 127.0.0.1:30003
2015-06-22 15:24:12.687973 Client restarted successfully
2015-06-22 15:24:12.687909 Closed TCP connection...

The 'restart' and 'close connection' events do occur every 10 seconds, so the log is full of those messages -- but I guess this is normal.

Something strange this morning was that I was seeing no log activity whatsoever, even though the status of 'pfclient' was 'running'. I decided to reboot, and then noticed (again) that the client had not restarted itself. I wasn't sure if the install process had set it up that way or not, so I used the following earlier to insure that it was:

Code:
sudo update-rc.d pfclient defaults

Since this had not worked during the reboot, I did restarted it manually and noticed this error message:

Code:
[email protected] /etc/init.d $ sudo ./pfclient start
[....] Starting pfclient: pfclient./pfclient: 35: ./pfclient: cannot create /var/log/pfclient/error.log: Directory nonexistent

I corrected this (temporarily) by creating the missing directory:

Code:
sudo mkdir /var/log/pfclient/

However, this leads me to what is perhaps a silly question: why should I need to do this? I *think* the entire '/var/log' directory schema is created each time a reboot occurs, so this isn't a 'one time' fix, right?

Thanks!
Not sure how you installed but if you used the .deb it sets up the init itself. If you downloaded the tar.gz you are very much on your own!

30003 format is also not the preferred format. I would change it back to 30005 as the port and Beast Binary mode.
 

darethehair

New Member
Not sure how you installed but if you used the .deb it sets up the init itself. If you downloaded the tar.gz you are very much on your own!

30003 format is also not the preferred format. I would change it back to 30005 as the port and Beast Binary mode.

Re-installing is, I think, overkill since everything is basically working now :)

I installed from a '.deb' file, so I am OK there. I just double-checked and confirmed that it is *only* port 30003 that works for me -- not 30005. On the 'setup' page, here are the options I have set -- let me speculate that having the 'data format' set to '30003' means that I am *not* using 'Beast Mode' format?

Code:
Setting    Value
Tcp Address    127.0.0.1
Tcp Port    30003
Select Timeout    10
Data Format    30003
Connection Type    TCP
Aircraft Timeout    30
Latitude    49.100000
Longitude    -98.200000

As for the other issue of the '/var/log/pfclient' directory needing to exist when that service is started, the only solution that I can think of is to change some 'initialization' file somewhere (?) to point it to another location. In other words, 'pfclient' should not assume that it exists or will continue to exist through a reboot process, right?

Thanks
 

Lee Armstrong

Administrator
Staff member
Re-installing is, I think, overkill since everything is basically working now :)

I installed from a '.deb' file, so I am OK there. I just double-checked and confirmed that it is *only* port 30003 that works for me -- not 30005. On the 'setup' page, here are the options I have set -- let me speculate that having the 'data format' set to '30003' means that I am *not* using 'Beast Mode' format?

Code:
Setting    Value
Tcp Address    127.0.0.1
Tcp Port    30003
Select Timeout    10
Data Format    30003
Connection Type    TCP
Aircraft Timeout    30
Latitude    49.100000
Longitude    -98.200000

As for the other issue of the '/var/log/pfclient' directory needing to exist when that service is started, the only solution that I can think of is to change some 'initialization' file somewhere (?) to point it to another location. In other words, 'pfclient' should not assume that it exists or will continue to exist through a reboot process, right?

Thanks
30005 and beast binary format should indeed work and in fact we favour this over 30003 data coming from clients, before you had tried port 30005 and 30003 format it seems.

Our .deb "just works" out of the box for a raspbian install so if you haven't got a /var/log you will have to create it or modify the init script to point to that location, on a vanilla OS this just works and so it sounds like you are doing something different and will have to modify paths yourself.
 
Status
Not open for further replies.
Top