PilotAware
British Forum => Technical Support => Topic started by: pioneer on July 22, 2016, 07:22:04 pm
-
My Pilotaware unit has auto upgraded the software, on flight yesterday it lost the GPS signal, no changes have been made to the original settings would the upgrade have changed anything.
The other units with GPS were perforing ok with no loss of signal.
Other units:- MGL Enigma, Skymap 3C, Skydemon on Nexus 7(2012) and my phone in my pocket running Skydemon worked ok.
All the GPS aerials,except the phone and Nexus, are mounted on the coming with good view of the sky.
Have ther been any issues with the latest upgrade and can I revert to the previous software.
Thanks Brian
-
Where was the PilotAware situated in the aircraft
Regards
Keith
-
Hi Brian
I can assure you this is not related to the latest release,
In fact there was a GPS fix in 20160708, related to audio
Messages blocking the GPS
Can You please confirm to which version you have updated ?
Also, are you able to reproduce your findings, and if so,
Please go to the web home page and capture a screenshot
To post here
Finally, do you have Mode-S enabled ?
Thx
Lee
-
Hi Thanks for replies.
Pilot aware unit was sitting on the coaming just under the windshield with clear view of sky.
Mode S was enabled, Pilotaware version 20160708.
Mode S settings, Mode S separation + - 2000 ft.
Mode S detect Medium range
Mode S select Mode-S
Unit is running on a power bank with 2.1 Amp outlet.
Red and green internal led's are flashing, external red led flashing regularly.
All now seems ok.
Will try it out on Monday in the aircraft.
Thanks Brian
-
Hi Brian
If you have issues in the aircraft again, the lease capture the home page,
Also if you get the chance take a look at the logging page
This should provide some indicators
Thx
Lee
-
I had a similar problem a few weeks ago which was completely (and permanently?) solved by replacing the GPS dongle with the one from my beta-test PAW. If all else fails, this might be worth trying in your case too, although please also give Lee any support you can to get to the true root cause of this strange failure mode.
-
My GPS didn't drop our but you could see fewer Satelites than expected, reception improved when I put my dongle on the end of a 0.5m USB extension cable.
Now use a GPS mouse like the one available from the store.
-
I flew my PAW for the first time yesterday. Previously, I had run it sitting on top of a hill and seen 11 satellites showing on the system status list.
In the aeroplane, the uBlox GPS dongle is on a 1 metre USB lead connected to teh PAW, with the GPS itself mounted at the top of the bubble canopy. The same location had provided excellent results with my previous bluetooth GPS. During the 30 minute flight there were 3 periods of 10 - 20 seconds (all during level flight) when the tablet showed a white screen because it had no GPS data coming in. There were also a few very short duration gaps (only noticeable when I later inspected teh breadcrumb files) during turns. Do others get such losses or do I have a duff GPS (or duff cable)?
-
Hi Stu
Thanks forthe feedback few things to confirm,
1. Version of PilotAware
2. I do not understand "when the tablet showed a white screen because it had no GPS data coming in"
Can you elaborate this,when I use SkyDemon or EasyVFR - I get a banner saying "Seeking GPS Satellites"
or similar.
What nav tool are you using - I have never seen a 'white screen' due to no GPS
3. The Track file should provide the definitive answer, it will have the GPS messages indicating satellites in view etc
4. You mention cable, so are you using the GPS U-Blox Mouse ?
Thx
Lee
-
Thanks for the quick reply, Lee!
I'm running 20160820, which I believe is still the current version.
I'm using EasyVFR. It may have given a "tickertape" message across teh top of the screen "GPS position is inaccurate" (or something to that effect, I don't have ti in front of me). That is the standard message EasyVFR gives if it realises that it has lost its GPS input Usually, with an internal or bluetooth GPS, if EasyVFR loses its signal, it continues to show the map, but the plotplane position ceases to update as it is not getting new position co-ordinates. However, it seems that when the GPS feed from PAW fails, it sends - or perhaps "what it sends is interpreted as" - zero deg lat, zero deg long. That is actually off the coast of Africa and EasyVFR does not have a map for that location so it just shows a blank screen (with just the plotplane displayed). In the early days of EasyVFR (long before PAW!) , a few users did report seeing this "white screen" on first-ever start-up and it was eventually identified as occurring when there was a problem with the GPS feed (e.g. early iPads that had not GPS!). But when PAW came along, other EasyVFR Beta testers also reported the "white screen" effect when PAW flagged its GPS data as invalid, so I am pretty sure that is what I am seeing now - though I understood that this 20160820 PAW release was much less likely to "spuriously" declare its GPS output invalid? The problem then resolves itself with no need for any action on my part
I have just seen a post on another thread explaining how to copy out the track file - my PAW is still in the aeroplane but I should be able to get a copy of the track file in a few days time.
I'm using the standard supplied PAW u-Blox USB dongle, but connected via a USB M/F lead so I can put the dongle in an optimum location.
TIA
Stu B
-
Hi Stu
Strangely enough, I have noticed in thepast I have seen this message from EasyVFR, I have then flipped over to SkyDemon, which has not reported an error.
I wonder if the problem could be when a lot of traffic is being sent over the connection, that EasyVFR cannot proceess quickly enought ?
in other words what happens is the following for each send (pseudo code)
start:
send GPS data
loop over Traffic Table
send Traffic data
end loop
goto start
so if the traffic table is very large, then it is relying upon the processing speed of the receiver to loop through all the data, before seeing the next set of GPS coordinates
sounds likea long shot to be honest.
I think the track files will tell us all.
Thx
Lee
-
Thanks again Lee, I'll post again once I have the file. Also, next time I fly I'll use the PAW GPS as the source for both my Asus tablet (as last time) and also for my iPhone 6 - which I think processes much faster. On that last flight I had the iPhone running on its internal GPS which of course did not have the problem!
VBR
Stu B
-
Just to give you an update, Lee, I have now exported my track log fiel for that flight and am setting up a spreadsheet to facilitate understanding it. But basically teh log file does have the two frames which include GPS position every second through the flight except for 3 "missed" seconds, so it seems the GPS is good and the PAW is keeping up with processing it. What I don't know, I suppose, si how well the WiFi is working - either at the PAW end or at the receiving end, presumably some may be getting lost during that process and upsetting my tablet. However, talking with Rob at EasyVFR it seems that there ahs been some "pilot error" on my part - EasyVFR (Android version) has an option "Allow use of external GPS" and I had had that set to "On", as the PAW GPS is clearly "external" to the tablet running EasyVFR. However, Rob advised that I should leave that function set to "Off" for using the PAW GPS as the source. So, thanks to Rob's excellent help, I have since flown again with it "Off" and had an excellent GPS input through the flight on the Android tablet.
However, life is never simple and on this recent flight I also ran my iPhone off the GPS PAW signal, and, having just updated the phone to IOS 10, that now suffers from the "IOS 10 stutters with WiFi Mode B" problem! Fortunately I have now seen your other thread on that issue so that hopefully can now be fixed too.
BTW - is there any document available that gives the definition of all the parameters in the track files - I presume the $PFLAU message contains a list of status flags, perhaps including ones corresponding to the "4 green flashes" status LED flashes? $PAWRT puzzled me for a while but I have recently seen another thread here where I see that that one lists the various input signal types (Mode A, Mode C, Mode S, ADS-B, P3i, FLARM associated with an observed ICAO Hex Address. I presume the three GPS messages ($GPGGA, $GPGSA, $GPRMC) all comply with the standard NMEA structures.
-
Hi all,
Saw this note below - is this a correct setting for EasyVFR? If you set the option to "Off" I thought that EVFR would then use the internal GPS?
However, talking with Rob at EasyVFR it seems that there ahs been some "pilot error" on my part - EasyVFR (Android version) has an option "Allow use of external GPS" and I had had that set to "On", as the PAW GPS is clearly "external" to the tablet running EasyVFR. However, Rob advised that I should leave that function set to "Off" for using the PAW GPS as the source. So, thanks to Rob's excellent help, I have since flown again with it "Off" and had an excellent GPS input through the flight on the Android tablet.
-
Stu B/MrSums
I have been running EVFR & PAW on two android tablets, Asus Memopad, for some time now, and more recently a Nexus 7 (2013) and having just checked EVFR settings as a result of your post Stu, found they are both set to "enable external GPS". I have never experienced any problems with GPS drop-out with either of these tablets in this mode. I have just set up my PAW statically and connected both tablets and changed this setting in both tablets and it has had no effect. I, like you stu, concluded that PAW GPS was an outside source so this is how it has been running since I started with PAW early last year.
I wonder if Rob just meant that this did not "need" to be enabled for EVFR to receive PAW GPS.
Sorry Stu but you may find that it was not "Pilot Error" after all and there is some other answer to your loss of connection to GPS/WiFi interruption.
Regards
Alan
-
Thanks, Alan.
I have been putting together a spreadsheet which analyses the .TRK files. It produces a basic summary (duration, number of points, etc, max number of ADS-B responses fond during any single frame (over 80 tracks per frame!) plus a list of all ADS-B contacts, when each starts and stops, the time when the horizontal separation was at its minimum, and what the horizontal and vertical separation were at that point. It can then also produce a breadcrumb file fro any selected ADS-B target that can be plotted by EasyVFR. It also has a mode where it can tabulate the ownship PAW GPS data frame-by-frame alongside the GPS position that EasyVFR is using for its breadcrumb (so you can either use PAW as the GPS source for EasyVFR and see if all points are getting accepted, or you can run EasyVFR with its own GPS and compare performance. Unfortunately, because the .TRK files are so big, the spreadsheet that analyses them is huge (100MB+) so it runs painfully slow, and it also needs quite a bit of "mandraulic" work to get the .TRK file into the spreadsheet, so its not an easy tool to use and so far I have not really studied much data with it, I've just been satisfying myself that the tool itself works as intended. But I now have downloaded a set of TRK files and I'm ready to start examining them - I'll let you know how I get on.
-
Nice one Stu, sounds like something to tackle on those nights when insomnia kicks in. :D
Are you going to Telford at the week-end.
Alan