Hi there,
I am uploading from a Pi at Berlin, Germany.
Today between 09 and 10 GMT I had the callsign GAF099 listed in my DUMP readout as 3e88bd. While my station was listed on the uploading sites list, the GAF099 flight so far didn't show up in the Europe>Germany>current section.
When I am using the search function of the website, the callsign is found, submitted by other sites, but without the tpx hex address. Still it doesn't make it into the current logs.
Is there anything on my behalf I would have to do different?
Why is nobodys uploaded reception of this flight displayed in the "current" section?
Why is my upload mentioned nowhere?
Why is the upload of a nearby site available in the search section but leaving out the tpx address of that flight?
optional:
1. What am I understanding/doing wrong?
2. I just cut the upload of my PI to do some maintenance. My site is still listed active, even after being offline for 20 minutes?
submitted data not showing on website
Re: submitted data not showing on website
btw, about an hour the flight left from Berlin-Tegel, it now shows up in the "current" section, in the Munich area, but without the callsign. Now clicking on it there, brings up a list of submitted receptions (my site apparently never contributed). This listing http://www.live-military-mode-s.eu/popu ... ing=3E88BD shows, that GAF099 was logged by your site since about two and a half hours, during which it never showed up in the "current" flights.
Re: submitted data not showing on website
Hello Rongor,
what do you mean with dump (output of dump1090 or output of modes.class) and what exactly is in your dump (for example MSG3 LatLonPi)?
I also would find it helpful to have a description of how the database works.
Maybe the flight was first seen by the station "Lej, Lej" and so it was listed in country "Lej" and not "DE"=Germany.
what do you mean with dump (output of dump1090 or output of modes.class) and what exactly is in your dump (for example MSG3 LatLonPi)?
I also would find it helpful to have a description of how the database works.
Maybe the flight was first seen by the station "Lej, Lej" and so it was listed in country "Lej" and not "DE"=Germany.
Re: submitted data not showing on website
dump1090 is providing the raw data on the defined port. Albert's software then listens to that port to parse the desired data for feeding to his site. You also can locally listen to that port and therefore observe that dump1090 is doing is job.
The assorting for countries wouldn't be of much help if flights were only listed in the country of first appearance. The first site of a country reporting a flight (regardless where it was reported to this point) should trigger the flight being listed in the "current" section of that country.
The assorting for countries wouldn't be of much help if flights were only listed in the country of first appearance. The first site of a country reporting a flight (regardless where it was reported to this point) should trigger the flight being listed in the "current" section of that country.
Re: submitted data not showing on website
Do I understand it right that you did not log the data sent by modes.class but the data coming out of dump1090? In that case one cannot say whether the server was not reachable or there went something wrong with the database.
My station often throws SQL exceptions of the kind: "Table 'modes.LATLONPI' doesn't exist". When an exception was thrown, the processed MSG is lost. The call or execution (insert statement into database) of the connection to SQL is the last processing step. There is no functionality of retrying until success.
My station often throws SQL exceptions of the kind: "Table 'modes.LATLONPI' doesn't exist". When an exception was thrown, the processed MSG is lost. The call or execution (insert statement into database) of the connection to SQL is the last processing step. There is no functionality of retrying until success.
Re: submitted data not showing on website
I have no idea about modes.class. I did set up the Pi according to Albert's instructions and never had to deal with sql nor any raw data in the process.
Since my dump1090 output is working, I can confirm the data being available on that port. Launching Albert's software manually also shows incoming data from that port. So I am pretty convinced that data is being processed. The upload should also be fine, since my site is listed in the online stations. So we should be safe when ruling out client-server communication problems.
Since my dump1090 output is working, I can confirm the data being available on that port. Launching Albert's software manually also shows incoming data from that port. So I am pretty convinced that data is being processed. The upload should also be fine, since my site is listed in the online stations. So we should be safe when ruling out client-server communication problems.
Re: submitted data not showing on website
These two assemblies of my receiver site feed also confirms, that there is no communication problem nor a processing error of the data on my end.
http://www.live-military-mode-s.eu/Popu ... rlin,%20DE
http://www.live-military-mode-s.eu/Popu ... rlin,%20DE
http://www.live-military-mode-s.eu/Popu ... rlin,%20DE
http://www.live-military-mode-s.eu/Popu ... rlin,%20DE
Re: submitted data not showing on website
Hello Rongor,
I just checked both your and my locations, I can see your submitted data!
Just out of curiosity, how does your setup look like?
I just checked both your and my locations, I can see your submitted data!
Just out of curiosity, how does your setup look like?
Re: submitted data not showing on website
Hi,
maybe I do understand now what you mean.
The tables show that your station (running on a RPi) has sent some data but you cannot see a corresponding plane marker on the map. Is this what you have observed?
The same thing I have seen today. There are two tables. The first table view (zoekLOC=station) shows a list of reported MSG1 statements by a single station. The second view shows a list of stations, that have reported Hexids (zoekstring=HexId) which is also based on MSG1 statements. So MSG1 statements of RPi-stations seem to be registered in database and can be accessed via web interface - thats fine.
But this is not true for MSG3 statements (positions).
I am logging all of the prepared statements that are injected into the SQL-driver, that copies the date into the database. Example: for the plane C-135W, 62-4131, AE01CC on Wed 20.04.2016: In the log I found valid MSG3 statements without exceptions but when I look on the map, the only data that I see in my area is from a non-RPi station "Bratislava, SK". That means, the position data (LATLONPI) was not processed or at least is not shown on map view.
I will investigate this further.
maybe I do understand now what you mean.
The tables show that your station (running on a RPi) has sent some data but you cannot see a corresponding plane marker on the map. Is this what you have observed?
The same thing I have seen today. There are two tables. The first table view (zoekLOC=station) shows a list of reported MSG1 statements by a single station. The second view shows a list of stations, that have reported Hexids (zoekstring=HexId) which is also based on MSG1 statements. So MSG1 statements of RPi-stations seem to be registered in database and can be accessed via web interface - thats fine.
But this is not true for MSG3 statements (positions).
I am logging all of the prepared statements that are injected into the SQL-driver, that copies the date into the database. Example: for the plane C-135W, 62-4131, AE01CC on Wed 20.04.2016: In the log I found valid MSG3 statements without exceptions but when I look on the map, the only data that I see in my area is from a non-RPi station "Bratislava, SK". That means, the position data (LATLONPI) was not processed or at least is not shown on map view.
I will investigate this further.
Re: submitted data not showing on website
@bosgnoom, My RPi runs the software just as Albert's guide instructed the installation. Only difference is that I made it start up automatically after a RPi reboot.
@modesfan, No, I didn't regard the map in this case, as the map only shows the adsb reports. I was addressing the mode-s reports listed in the "current"-tables. I would expect the "current"-tables to display any mode-s contact which was recently reported in that specific country (or area). Since my site reported something, which still wasn't shown in that "current" table, I am questioning the purpose and usefulness of the "current"-table at all. There seem to be problems with the server when it decides to show or not to show some reported contact in that table. Or there is some preconditions it waits to be fulfilled, which would then be helpful to know.
Currently there apparently may be mode-s contacts which get reported to the server but still don't show up in the "current"-tables, negating those tables' use. I had hoped that Albert could look into this or in any way may clear up what happens under the hood in such a case.
@modesfan, No, I didn't regard the map in this case, as the map only shows the adsb reports. I was addressing the mode-s reports listed in the "current"-tables. I would expect the "current"-tables to display any mode-s contact which was recently reported in that specific country (or area). Since my site reported something, which still wasn't shown in that "current" table, I am questioning the purpose and usefulness of the "current"-table at all. There seem to be problems with the server when it decides to show or not to show some reported contact in that table. Or there is some preconditions it waits to be fulfilled, which would then be helpful to know.
Currently there apparently may be mode-s contacts which get reported to the server but still don't show up in the "current"-tables, negating those tables' use. I had hoped that Albert could look into this or in any way may clear up what happens under the hood in such a case.