PilotAware
British Forum => OGN-R PilotAware => Topic started by: neilmurg on August 30, 2020, 02:29:27 pm
-
I lost my ability to have a local (LAN) connection to the PWMurg ATOM GRID today, although on physical inspection if was powered and blinking in what looked like the correct manner.
Should I expect an email if it drops out from the rest of the GRID?
In the end I powered down the LAN and the station and repowered that part of the LAN, once it was up and running I powered on the station and it continued as before, and I have now re-acquired access on the LAN.
I didn't investigate whether it was still accessible over the internet via data.'etc'.com while I couldn't get to it via 192...etc. The disconnection wasn't because DHCP had assigned a new IP, it has a persistant IP from the router.
Any comments advice appreciated...
-
If your router supports mdns you can use
http://ognpaw.local
Thx
Lee
-
I didn't investigate whether it was still accessible over the internet via data.'etc'.com while I couldn't get to it via 192...etc. The disconnection wasn't because DHCP had assigned a new IP, it has a persistant IP from the router.
You may not have been able to log into it with 192.xxx.xxx.xx but if it really has a persistent or reserved IP address (usually done by reserving an IP address for a MAC address in the router) then the first thing to do is to ping that address from the PC you remote in from.
prompty thing>ping 192.xxx.xxx.xx (Windows or Linux)
In Linux you'll have to Ctrl-C out of it , as it does the same as ping -f in Windows IIRC.
If you get a ping back, then it's there, but it could be the other programs that have abended.
Reboot...
another useful command if it's a small LAN is arp -a
-
thanks. As reported I did solve it, but more analysis would have helped...
Lee, yes I use the IP address and https//ognpaw.local, although this (local) seems to take a while to propagate
steveu, I wasn't 'remoting in', I'm on the LAN. I'm confident it does have a fixed IP4 address issued via DHCP
I think the unit was running OK, but my LAN was having a problem, which didn't affect the station, just local connection.
If it happens again I'll do more diagnostics before rebooting.
I am aware of the tunnel (port forwarding) created in the router, and what it's for
I wasn't emailed to say it was down, even when I powered down for 5 minutes. Should I be? (I think I should). I have a timer which turns the system off an 4am (ish). I know that's no longer best practice, but I'm keeping it for now, unless advised otherwise.
-
I wasn't emailed to say it was down, even when I powered down for 5 minutes. Should I be? (I think I should). I have a timer which turns the system off an 4am (ish). I know that's no longer best practice, but I'm keeping it for now, unless advised otherwise.
Hi Neil
We do have the infrastructure to implement this, but have not done so (yet)
There are a number of stations explicitly setup to power down overnight
So this could be annoying for some maintainers
Thx
Lee
-
steveu, I wasn't 'remoting in', I'm on the LAN. I'm confident it does have a fixed IP4 address issued via DHCP
I think the unit was running OK, but my LAN was having a problem, which didn't affect the station, just local connection.
If it happens again I'll do more diagnostics before rebooting.
I understood that you were on the LAN, as 192.xxx.xxx.xx is a local address only.
By "remoting in" I meant that you were connecting to your ATOM-GRID over a network, unlike mine which has a keyboard and monitor connected directly (HDMI+USB) and can be seen if if the LAN is down.
With mine I'm able to log in directly on the box and run diagnostics.
-
PWMurg stopped again around 23:10 local last night. I couldn't log in locally or via data.p.......com.
I've disconnected the timer just in case that contributed (it shouldn't have).
It's working normally after recycling the power.
-
Hi Neil,
I had a strange experience with one of mine recently - like yours, still on an electronic timer.
I noticed that the station hadn't restarted one morning and on investigation up in the loft found that the power supply had failed (electronic caps blown in the output stage, so pretty terminal). Swapped in a 'spare' PSU which happened to be constructed 'the opposite way up' - i.e. it had the transformer body and cable exit 'above' the 3 pin plug rather than below it. Checked the timer settings, plugged the new PSU in and powered it up, - all fine, station back online. :)
Next morning - no station showing again. :-\ Removed the PSU from the timer and tested it downstairs in a different socket - all OK, so replaced it in the timer - but unit failed to power back up. Was on the brink of changing the RPi, when something told me to re-check the timer - and found that it was indicating 'RND' ??? . Then noticed that the timer has an 'RND' (Randomiser) button located just under where the 'top' corner of the new PSU sits - and had obviously been pressed as I plugged in the new PSU, and had set up random timer operation, but of course I couldn't see the timer screen because it was hidden behind the PSU... Duh! ::)
Reset the 'RND' button back to normal and the problem went away. Probably not a'go to' fault, but one to be aware of if running the station on a timer. (I have since changed to another 'down-hanging' PSU to keep the body well away from the timer buttons/screen - 'just in case'. ;)
Best Regards
Peter
-
I looked at the data.pilotaware.etc.... today
PWMurg (my station, aerials outside the roof). I'm on the Reports: Stations list, but not on the Reports: Base ranges list ???
When I log in locally (192 etc) I see aircraft, I have METARs.
I'm going to reboot tomorrow, I have no reboot timer for the station anymore (physically removed) after the last brownout. I have had a couple of temporary power cuts in the house, and the broadband takes a few minutes to return, the station is connected via a MESH extender (which recovers quicker). Is this causing a problem? Is there a programmatic solution to auto-recover?
As I said, I'll reboot tomorrow. I can leave it as is if that helps diagnosis
-
I logged in and tried a reboot, I got this: (see attachment)
looks like a failure of the ADSB dongle? I'll reboot and report back
-
OK, I seem to be back. History on contrib......url now shows aircraft, still no data on 'Base ranges'
But, a soft failure with no alert, and I was paying SOME attention but there was no 'heads up' for the failure, I was still on the network (METARs), the failure of the station (1090) was not obvious when I looked at the radar screen.
Can I do any analysis to help? Station password is non standard (for security), but I can change it if you PM me to agree a new one. If you have a back door, get rid of it (for security).
Regards
neilmurg
it was great that I could reboot using the config routine without going in the roof and pulling the power.
it would be nice to get confirmation that my station is now contributing properly, and how long it's been 'failed'.
-
I don't know if it is coincidence but, yesterday, when I looked at the ognrange.glidernet page all the coloured markers were either red or a purple-ish colour. I think there was one green station in Kent. My station was purple-ish but everything seemed to be working normally.
If you saw a black cat twice, it may have been a glitch in the OGN Matrix (or similar).
-
Looking now at PWEgerton, hard to believe there is no traffic over Kent...
-
PWMurg is now appearing in the Reports: Base ranges list again. Woopwoop!
Before I rebooted I could still see aircraft on my local VRS, but when I looked at the Playback page of data.pilota.......url for PWMurg only, it wasn't reporting tracking any aircraft. So I guess the ones I was seeing were via other stations, which was why it was hard to spot the soft failure.
My first clue that there was a problem was a low level aircraft that was near the house that didn't appear on my radar screen. Further analysis (looking at Playback for PWMurg, and Base ranges) revealed the issue. I was still showing METARs and seeing high level traffic locally.
Is there a regular check which would pick this up quicker?
[edit to add]PPS as part of the reboot which confirmed the issue, I appear to have received a software update. Could an unreported failed update process have initiated the problem?[/edit]
-
Regarding my post above; it would seem it's doing it again today. My station is receiving things normally and targets are showing on the VRS.
-
Yes it looks like the 1090 USB has failed again. How could you tell? -and- Thanks!
Redoing config now, 1st attempt failed with 'USB not named'(?)
is there a command to pipe the tty output to a text file?
-
I don't think anything has failed as I am seeing traffic normally. I just think it's something at the OGN map thing that may be amiss. The only reason why I knew they were purple agin is because I happened to have a look......no other indications.
-
Paul / Neil,
Not sure about the 'purple', though I think it is the equivalent for 'blue' stations as 'red' is to 'green', but the OGN stations going red (or purple) isn't particularly uncommon. It can mean there is an issue with one of the OGN servers, but IME it doesn't in any way affect the operation of or rebroadcast from our ATOM stations as we only feed data to the OGN - we don't take data from them (or at least not from their servers).
Regards
Peter
-
That's 2 weeks in a row that logging in to the Pi has shown/reported the 1090 SDR isn't working, fixed by rerunning the config.
I may buy a new SDR.
While checking it out I noticed PWEGLK is offline.
-
This morning. Station appeared to be working OK, METARs and showing aircraft, although I got a local (192.etc) response on my PC bt not on my phone. Ran config twice:
(10:06:40) FILESYS : Mount RW
Stopping Services
Do not plug in or remove any SDR dongles whilst this configuration script is running.
It is strongly advised to have the SDR's plugged in and then reboot the Pi before running this configuration script.
Found 2 SDR's:
WARNING: device 0 with serial number: 1090 cannot be found
Most likely the serial number has been altered and the Pi not rebooted before running this script.
Reboot required
If any of the SDR's are lugged into a powered USB hub then the hub will also need to be powered down at the same time.
Rebooting in 10 seconds
Please rerun config afterwards
(10:08:16) FILESYS : Mount RW
Stopping Services
Do not plug in or remove any SDR dongles whilst this configuration script is running.
It is strongly advised to have the SDR's plugged in and then reboot the Pi before running this configuration script.
Found 2 SDR's:
USB Port Top Left : SDR detected ID=1 currently allocated to OGN/FLARM reception on 868Mhz
USB Port Bottom Left : no SDR detected
USB Port Top Right : no SDR detected
USB Port Bottom Right: SDR detected ID=0 currently allocated to ADS-B reception on 1090Mhz
One SDR is currently configured for OGN and the other is configured for ADS-B reception.
Do you wish to change the SDR(s) configuration [y/N]:
Is this a problem?
-
Hi Neil,
Funnily enough (not funny really, sorry), I experienced the same thing recently when I reconnected my long running ATOM after having temporarily removed the Pi/Bridge unit to use the antennas and dongles to set up another station.
Replaced my original unit after I had finished, booted it up and re-ran the config with the dongles in Upper and Lower Left (which is where they always were) and got the same 'device 0 with serial number 1090 cannot be found' message.
Checked the dongles were in the correct slots and properly located then rebooted - this time all fine but still had to reconfirm 'use dongle 0 as 1090'. Rest of config went as expected and (AFAIK) the station has been running fine since (now well over a week). Oh and mine is still on a daily timer - off overnight.
Not sure how much this helps, but obviously something we need to keep an eye on.
Regards
Peter
-
I haven't touched a thing and yet this is the OGN map today. As I said before, I think this is a snag at the OGN end.
-
Hi Neil,
Funnily enough (not funny really, sorry), I experienced the same thing recently...............................
Peter
Thanks Peter
It MIGHT just be a glitch the first time config runs and not be an indicator of a degraded station. It still sees loads of ADSB traffic (I'm near Heathrow) which is via the 1090. Now I'm learning to read the 'Front page' better I can see MLAT targets that are detected locally. I'll keep an eye on it. Fof for the last 2 days has kept GA/Glider traffic numbers very low.
I will try and extract a pattern from the behaviour.