PilotAware
British Forum => Technical Support => Topic started by: DavidIOW on November 19, 2022, 05:39:01 pm
-
Today we had a second incidence of PAW Rosetta stopping working for no apparent reason. We have it connected to SD and suddenly SD showed it had lost gps position. The Trig transponder, which has gps input from PAW, also showed it had lost gps position. Switching PAW off (actually switching off the Charge 4 power supply that feeds PAW and several other things) and back on again restored gps to Trig but you then have to re-link it to SD, and reconnect igrid etc. which is not ideal to do in flight.
We also saw that when the Trig lost its gps input from PAW it didn’t function at all in any mode. Awkward as it happened in the middle of a zone transit and controller had to confirm which dot on his radar we were. Is that usual when a Mode S ES/ADS-B transponder loses its gps input then it doesn’t just revert to being a Mode S?
Any idea why PAW should suddenly cut out like that? Other than these two incidences of spontaneous shutdown it has worked really well and we love it! Many thanks. David
-
You weren't transiting Birmingham airspace today were you?
There are GPS jamming trials going on there this weekend.
(FWIW my Trig gets its position data from a GNS430W. If I switch that off, or it loses integrity, the Trig keeps working but you just get a message to say that the position source has been lost).
-
It was Solent zone and all was working fine before and then again after the reset so probably only offline for a couple of minutes but enough to give the controller a scare! The Trig did show a message that position info had been lost but it seems that the controller couldn’t then see things you’d expect them to see under the Trig’s basic Mode S such as call sign, altitude etc which was a surprise.
-
Hi David
That all sounds very odd
A controller will only see your mode S data anyway, NATS do not have any infrastructure for ADSB
Thx
Lee
-
Yes it does seem odd but the controller was clear that we had just turned into a simple dot on his radar at the point where the message came up about loss of gps. I’ll take this up directly with Trig and see if they have come across this before.
Going back to the original question about the blip in gps feed from PAW to SD and Trig, is there anything we can do to stop this happening? I know intermittent and infrequent faults like this are really hard to diagnose! Many thanks.
-
Latest situation: Today we had three incidences of the PAW gps stopping. The first was in Manchester low level corridor inbound to Barton which was a bit hairy. We didn’t try to restart PAW as it’s an intense bit of airspace but just switched to iPad gps. The second time was just pre take off from Barton. This time we restarted PAW and reconnected it. Later in the day it happened again, this time while we were in contact with Solent radar on our return. This time we had time to restart PAW and the gps came back on and Solent didn’t comment (perhaps because we hadn’t yet entered their zone though we had their clearance). Seems to be a PAW gps drop-out issue but it is certainly a concern, especially when it happens in LL corridor! Feedback from Trig is that they would expect the Trig to maintain Mode S so were surprised by what happened in the original post.
Any ideas why the gps keeps dropping out and what we can do to avoid it? Thanks!
-
Just change the GPS, it seems to happen often enough to soon find out if that is where the issue is. Watch out for failing ADSB dongles as well as they can draw enough current to cause outages
-
I don’t have a second gps input source to hand at the moment. By ‘ads-b’ dongle do you mean the special usb to serial cable I have from PAW to the Trig?
-
No I am not refering to the USB to serial cable adaptor which will connect to your trig.
I don't know what version you have, so cannot describe it. It is the USB dongle that has the shorter antenna attached to it. If you do remove it and the PAW works for GPS position, it will not show ADSB or mode S traffic, but this is just a test.
Cheers
Ian
-
Thanks Ian. I have the 2022 Rosetta. The two PAW aerials are external and their coax leads are attached to the PAW box by the screw on aerial terminals at one end of the box. The PAW gps mouse aerial plugs into one of the 4 USB sockets on the PAW. Hope that helps!
-
When you removed that cover to plug in the RS232 cable and GPS cable there was another dongle plugged in with a thin coax cable connected. That is the ADSB dongle. Make a note of which socket.
Was your Rosetta only supplied with the USB mouse on the long cable?
-
Thanks for your help, Ian. The only long cable supplied with the PAW was the gps mouse one. Looking at the sockets ( from their open side and with the RJ45 socket on the left side of the unit) we have the following use of the 4x USB sockets: Bottom right: ADSB dongle you describe. Top right: GPS mouse. Bottom left: Serial cable to Trig transponder. Top left: iGrid USB stick. Does that help? Do we need to rearrange them? Thanks. David
-
Wasn't aware you had iGrid. If it worked after adding the iGrid, then don't swap anything around.
ADSB dongles are SDR Radio dongles. when these fail they can draw high currents and pull down you PAW causing intermitant or even full failure of the PAW. Suggest you remove it to see if your GPS returns to working normally.
If that makes no change, it is possible the GPS reciever has failed.
-
Though they may be of different types both iGrid and ADSB dongles are both SDR Radio dongles.
If that makes no change, it is possible the GPS reciever has failed.
Erm, isn't the iGRid dongle a small wireless USB adaptor?
-
Correct Steve, I'm having a brain fart :-\
Post amended
-
Thanks to you both for your ongoing engagement with this. I installed the igrid dongle at the same time as the PAW was first used so it’s never not had it. The problem we see is highly intermittent: it all worked beautifully for several months but failure of the PAW gps input to SD and Trig has happened more frequently recently. I can’t say if these gps output failures also caused the whole PAW to stop working (we were too busy fixing the problem!) but maybe there is a way of looking at flight logs to check that? However we do know for sure that it certainly stopped SD displaying our position and we got the warning on the Trig about loss of gps signal. Should I remove the gps mouse and send it to someone for checking? Many thanks.
-
Hi David
a flight track and an approximate time of the incident, would allow us to try and debug the issue
Thx
Lee
-
Lee. Thank you for your help. These are the three most recent gps dropouts. In all these cases Skydemon also lost gps and Trig gave warning message re lost gps.
Henstridge to Sandown
1441 UTC 19 Nov
over Lymington
Just changed from Bournemouth App to Solent Radar. When Solent gave squawk, we put it on standby and on switching back to Alt then had the ‘Warning no ADSB position’ on the Trig. PAW was then turned off and on again but Solent said they could then only see us as a dot, even though Trig was still on Alt. By then we had left CAS so requested to change to Sandown and continue outside CAS changing to squawk 7000.
Sandown - Manchester
1202 UTC 25 Nov
Over Thelwall Viaduct
Changing from Manchester Monitoring Squawk (7366) to Barton (7365). Squawk is 7000 during the time the transponder was down
Error 3: Manchester to Sandown
1516 UTC 25 Nov
SW of Newbury, error occurs on track between Combe and Faccombe
Changing from Brize Squawk (3713) to Solent Squawk (3661)
Aircraft hex iD 403B4C
Hope you can make sense of this and maybe see if PAW was still working (though after the gps dropout PAW was turned off and on again to reboot it.
-
David, Lee will need the relevent track file from your PAW for each of those flights. You may need to host them somewhere(like DropBox) as they can be large.
-
Ok .I hadn’t appreciated that and will need to look up how to do that. Is it somewhere in the PAW website?
-
Hi David
use your tablet or laptop to log on to your Paw unit in the usual way and use the drop down "Go To" Menu to scroll down to the "Track Files", where you will see the track files listed in date order, (below a couple of Demo Tracks.)
Year-Month-Day-Time.trk followed by the file size. Download the ones you are interested in. Most are too large to post in the forum or email direct so as Iain says you have to either deposit them in "Dropbox" or similar and send a link to Lee, or possibly use something like WhatsApp to send it to Lee.
Hope that helps
Regards
Alan
-
Thanks for the explanation, Alan. I’ll do that as soon as I am back with the aircraft and then set up a Dropbox or something for transfer. Many thanks. David
-
I have finally managed to download the relevant track files from the aircraft, and have created a Dropbox folder for these. I have also added a note to explain the files. Dropbox location is at:
https://www.dropbox.com/sh/0h69itav5xc0p89/AABc0K0P3eHZLoRgQqzyxf0Fa?dl=0
I hope this will be useful. Many thanks for the support. Davi
-
Hi David, and a Happy New Year,
I take it you are still waiting for a reply to your last post, (though Ash tells me he has sent you a PM)?
I normally leave track analysis to Lee as he can analyse track files using software much quicker and more efficiently than I can. (I have to do it manually - by physically looking through the files in Wordpad on my Windows laptop - which is much less efficient and FAR more time consuming.) I am surprised that Lee hasn't responded yet, but I do know that he has been very busy with development work - as well as his 'day job' so guess he has probably just missed the post or hasn't had time to get round to looking at the files yet.
In the absence of a response from Lee, I have nonetheless taken a look at all the files you uploaded to Dropbox over the past three days and found the following.
I started by examining your first track file from 19th November - which starts with bootup (at Henstridge) at 140556. Everything starts up as expected, and I can see regular GPS reports ($GPGGA and $GPRMC files) at one second intervals right through the log until the file ends suddenly at 143557, presumably with your Rosetta shutting down several minutes before your reported GPS dropout over Lymington at 1441. Running the file on the PilotAware / Aircrew Playback Tool shows that your Rosetta must have shut down just as you were about to cross the A338 well before you reached Lymington.
The second track file, which is a continuation of the above flight, starts at 144245 as you headed out over the Solent, with a fresh reboot of your Rosetta AFTER your reported 1441 dropout. This file shows a completely normal reboot with GPS position reports at 1 second intervals all the way through 'til the file stops after landing at Sandown - so in this case completely normal.
The first set of logs from 25th November shows pretty much the same thing - normal startup at 0945 and regular GPS reports at 1 second intervals throughout the track (for two and a quarter hours) until the log stops suddenly just after a routine set of GPS reports at 120019. This again indicates that the GPS was working normally throughout the entire flight up to the point where the Rosetta shut down at least a minute and a half before your reported dropout at Thelwall. Unfortunately this track won't replay on the PilotAware / Aircrew Track Replay Tool, which makes it a bit more difficult to say exactly where the Rosetta stopped working.
The second track file for 25th November starts at 13:42 - presumably as you were getting ready to Depart Barton for your return flight. Analysis of this log again shows regular GPS reports at 1 second intervals for 90 minutes - right up to 151249, shortly after which the track log again stops - again in my opinion indicating a shutdown of Rosetta, rather than a GPS failure. This track file also unfortunately won't run on the Replay Tool.
The final track file starts with a system restart at 151814, and after restart, again shows regular GPS reports throughout the log until the system shuts down at 1538.
In short, all of these files show solid reporting of GPS positions through fairly long flight periods, with in the case of the first file on 19th November and the First and Second Files on 25th November a sudden shutdown of the Rosetta unit rather than a simple GPS failure, so we need to look elsewhere than the GPS for the reason.
My primary suggestion would be to fully investigate the power feed to Rosetta. I am aware that (like myself) you are powering your Rosetta from a Charge4, so that should be pretty much bombproof, though it's worth checking that you aren't overloading it with other devices. I would concentrate my attention on the power cable and connections between the Charge4 and Rosetta. Are you using the supplied power cable, or have you fitted a longer one - and if so is it of the recommended gauge? Check for a solid connection between the microUSB plug and socket at the Rosetta end. Do the 'wiggle test' while observing the red 'Power' LED (which is inside the case on the antenna end of Rosetta under the 869MHz antenna socket). The Power LED must show solid constant Red - If it blinks or goes out at all, you have a bad connection. Also look for Voltage Warnings or Errors on the PAW Home Screen, though I can't see any of those reported in the track logs.
Another less likely possibility - is there any chance of the unit having been subjected to significant overheating? - for example is it mounted in close proximity to the cabin heating system? Again, I can't see any evidence of this in the log, but could have missed it.
Please let us know if you find anything and we can take things from there.
Best Regards
Peter
-
Peter
Happy New Year to you too and thank you for the detailed reply.
Yes I had received a PM from Ash earlier in December and he explained that he and Lee were going to be out of action for a bit but that he hadn't forgotten me!
Thank you for doing the detailed track analysis. I'm a bit confused by the appearance of the Rosetta seeming to shut down a few minutes before the GPS signal goes since surely the GPS signal in question is coming from the Rosetta? Or is there something in the Rosetta that allows it to continue sending its GPS signal to the Trig and Skydemon for a little while after the rest of the Rosetta has shut down? I'm not sure how we would observe that the Rosetta had shut down on its own other than by lack of seeing aircraft contacts on the SD display (though we could also interpret that as there not being any aircraft nearby!) whereas we can easily see the GPS signal going off as it is very clearly notified on both the Skydemon display and the Trig display. The GPS dropout at Thelwell was particularly noticeable and alarming as we were navigating the Manchester LL corridor at the time and acutely aware of the need to be sure of our position!
I don't think the Rosetta is overheating but it is mounted behind the instrument panel so is hard to observe. There is no cabin heat fitted. Besides the PAW, the Charge 4 is also powering an i-pad mini (for SD) and an i-phone (for i-grid). The cable from the Charge 4 to the Rosetta is the one supplied with the Rosetta though the Charge 4 and Rosetta are only mounted about 20cm apart behind the panel so the power cable is coiled up a bit.
I'll take the panel apart to access the Rosetta and try to observe the red light you mention and look for any messages on the PAW home screen. I'll report back on this once I have some news from this.
Many thanks for all the support on this issue. I am so impressed with the support that the PAW team provides!
-
Hi David,
Sorry, slight confusion - the PAW tracks end in each case within a second or so (not minutes) of the last recorded GPS position report in each log. If you open the 2022-11-19_14.05.trk file in Wordpad, for example, and scroll right to the bottom, you will see a series of $PFLAA and $PAWRT reports - all time-stamped 20221119, 143556 (so just before 14:36). These are traffic reports. If you scroll back up 40 lines or so, you will see the last GPS Reports ($GPGGA / $GPRMC) - BOTH time-stamped 143557. There are no further reports in that log after 143557.
The other logs show very similar reports - so only traffic already being processed in the system would be passed to your tablet (SkyDemon) after the last GPS report logged in the .trk file. Obviously no further position reports could be passed to the transponder either as there are no further GPS position reports recorded.
In practice, SD would probably have reported the dropout initially as a loss of GPS signal, by a banner across the top of the tablet screen - and with no further visible traffic. SD's 'Waiting for Device' banner would then have appeared, though it is possible that it would have gone straight to the 'Loss of Connection / Waiting For Device' banner in view of the fact that it lost traffic data almost at the same time after its last GPS report. The only warning you would get from your transponder is the 'ADSB Position Failure Warning' on the Trig Control Head (sorry, I can't remember exactly what that says) and you could easily have missed it if you were 'eyes out' or dealing with something else - such as a change of radio frequency / squawk at the time - especially if you had the transponder switched to standby while changing squawk (I don't usually bother).
I have now also run a search (using the 'Find' Tool in Wordpad) for TEMPERATURE reports. These are reported automatically during the boot sequence and thereafter where the core temperature of the unit is rising. There are a few of these in 4 of the 5 tracks, (all except the last one). The maximum temperature reached is 64.45oC (at 13.42 in the log for the first leg out of Barton). This isn't a level that I would be particularly worried about. Also, all of the Temperature reports that I can see are in the first half to 2/3 of the relevant flights, with none at all near the end of any of the relevant track logs where the system appears to have dropped out, so I would now discount overheating as a likely cause.
I also tried a search for voltage error reports or warnings, but didn't find any (though I may have been searching for the incorrect code - as I have said, I don't do this very often). From past experience, however, I still think a loss of power - for whatever reason - is most likely to be the cause of the failures.
Please let me know what (if anything) your investigations reveal.
Best Regards
Peter
-
Peter. Thanks very much for the explanation of timings of PAW stopping and GPS stopping which makes more sense now. Yes we did get instant warnings in a banner on SD and a message on the Trig about ‘no position data available’ or something like that.
I took the panel apart today and unmounted the PAW. Even wiggling the power plug quite a bit I could not see any break in the red light by the aerial. I also looked at the screen on my iPad and could not see anything showing loss of voltage.
Although I can’t imagine it is related (unless we’ve got old/faulty software or something - the unit was bought in Aug last year), I would say that we have had some other problems which I mention in case it ‘rings any bells’! When PAW is running and the iPad is connected to it, when you go to the radar screen we see no contacts at all even though plenty are showing up in the traffic page. We have set the range and altitude well beyond where those contacts are but still see nothing. Secondly, I cannot get the PAW to see my iPhone hotspot at all to get the igrid working. This is despite the iPad seeing the hot spot perfectly well. We had seen this problem on the flights in question and found that eventually we would get a hotspot connection to a different iPhone but after a long wait. Today I couldn’t get it to see the hotspot at all, no matter how long I waited. I did try the ‘clear cache’ but that made no difference.
Could these strange things be in any way related to the original problem or indicative of something going on? Clutching at straws probably!!
-
Hi again David,
Thanks for the update.
You mention the possibility of old/faulty software. From the track files, your Rosetta is running Software Version 20220805 - which is the most recent publically available version, so certainly not 'Old Software'. It is of course possible that there could be a software issue, but I'd consider it unlikely in view of the fact that the unit has clearly been running for fairly prolonged periods before dropping out.
The MicroSD card containing the software in Rosetta is a simple 'push fit' into its holder on the antenna end of the Rosetta. I have never personally experienced the card slipping out or becoming dislodged (even if the unit was mounted with the card socket facing down), but as suggested by Graham Baker in the similar 'Intermittent Rosetta MicroUSB Power Socket' thread, it would be worth checking that the card is properly seated into it's socket as he has recently experienced a badly located card resulting in intermittent power issues. You can do this by powering off the Rosetta, then carefully easing the card out of the socket. Check that the contacts are clean, then carefully replace the card into its holder (with the contacts facing upwards), making sure it goes into the holder not between the holder and the case - then pushing it gently fully home.
If that doesn't help, I would suggest getting back in touch with Ash and asking him to send you a replacement software card, which will resolve the dual possibilities of a software or card fault.
Re your lack of visible contacts on the Radar Screen that is confusing. If you are seeing the Radar Screen on your display device, then the device is obviously connected to your PAW. The only things which can then affect display of traffic are firstly whether you have Traffic (TFC) selected (ticked) in the Radar Screen Menu on the LHSide of the screen, secondly what Horizontal and Vertical Range you have chosen for the Radar Screen, and thirdly what type of traffic is actually showing on the Traffic Screen.
Finally regarding connecting your PAW to your iPhone Hotspot, there are a few known issues depending on the specific device and iOS software version. Take a look at this thread, which details the various issues and let me know how you get on...
http://forum.pilotaware.com/index.php/topic,2218.msg23128.html#msg23128
Best Regards
Peter
-
Supplement to my last post above
See the 'Official' iGRID installation and operating instructions on the PilotAware website here...
https://www.pilotaware.com/knowledgebase/igrid-operating-instructions
Regards
Peter
-
Peter,
Thanks once again for the reply. I've run some more trials, though now I have to 'jury rig' the set up since the panel is dismantled and I have a small temporary power supply to replace the main battery.
i) Firstly, the radar display problem was indeed my problem on not having the 'TFC' box selected on the device that I now use. It was there originally and then we switched devices. Now displays same traffic as in Traffic page. Definitely 'operator error' here!
ii) Secondly, I followed those links about getting i-phone hotspots to connect and after trying all the various options that people had suggested, managed to get it to work. I think the main trick that made it happen was the one to do with having the i-phone hotspot set-up page actually open and 'live' when PAW was trying to locate it. I think this is an issue for later i-phones, where if you close the hotspot page (even though you've selected the hotspot to be available and visible) it somehow makes it disappear from view for devices such as PAW. Anyway, it connected and more traffic was then definitely visible so it was clearly then doing something through i-grid.
iii) I powered off and then removed the SD card and it all looked very clean but I gave it another clean anyway. Nothing seemed to change but then the gps dropout was an intermittent problem anyway so I'm probably unlikely to see it on a random check. I'll ask Ash about sending another card in case, but we won't really be able to check it all out until the aircraft is back in the air after its winter maintenance (probably April). Alternatively, given that the GPS drop-out affected both the transponder and the SkyDemon display simultaneously, I could just let it run with the aircraft being static, transponder off, but SD on, and see if we get another drop-out flagged up on SD. If I did that would I need to sit and watch the SD, looking for the moment when/if it dropped GPS, or would we be able to see any such drop on later review of a track file (given that there would be no aircraft movement)?
Many thanks for all the help.
David
-
Hi David,
Great to hear that you have achieved results on items i) and ii) - That's Brilliant ! - and my respect for 'owning up' to the 'operator error' with the RADAR Screen settings - that always makes things a lot more straightforward (and after all we ALL make mistakes).
Also OK on checking the microSD card contacts and 'fit' of the card and that nothing undue was found.
As I have stated above, from my analysis of your track logs, you haven't been experiencing GPS dropouts, but shutdowns of the Rosetta. The only way to confirm this for sure is by running the unit in as near to the same 'real life' conditions as you were before, for several prolonged periods (I'd suggest at least a couple of hours at a time in view of the fact that we know it ran previously all the way from Sandown to the Manchester LLC). If you aren't able to fly, you can certainly 'soak test' the unit on the ground without the Transponder, though there is no 'guarantee' that it will perform the same as it did in flight. In particular you need to make sure that the GPS has a good clear view of the sky or this will obviously skew the results. If you then download and check the track files, you will fairly quickly recognise the logging pattern and will easily be able to check the timestamps at the start and end of each log and compare these with the times that you ran the unit for. If the log stops short of the end of the test period, then the unit must have shut down, in which case you need to try a new software install - preferably on a new microSD card to rule out a card fault. That's certainly what I would do myself.
Let me know if you need any help.
Best Regards
Peter
-
Thanks so much for the reply and support, Peter. Interesting that it seems it's the whole Rosetta randomly shutting down (and taking the GPS feed to SD and transponder with it). I'll try that static soak test and then see if I do get any drops in the track file after the kind of duration of that Barton flight, though it has also happened previously much sooner after take off. I'll repost here any results I get. Many thanks. David