PilotAware
British Forum => Technical Support => Topic started by: DavidIOW on August 30, 2022, 10:34:28 pm
-
I have PAW Rosetta set up to provide GPS input via NMEA to Trig TT22 for Mode S Extended Squitter (with SIL/SDA at 0 as required). I have followed all the set up advice and instructions in Trig and PAW ( baud rates etc etc) and there seems to be communication between the two devices communicating. However when I look at the gps position shown on the Trig (by double pushing the Trig Fn button) it shows a Lat/Long GPS position but it is just not very accurate! It puts us about 1.5miles south of where we actually are! More weirdly, PAW is also linked to Skydemon and on the SD map, when selecting ‘use PilotAware’ under the ‘Go Flying’ tab then it shows the plane in exactly the correct position (and I assume this GPS position is coming from PAW and not the iPad)! I have used the recommended USB to RS232 converter cable from Farnell so I am mystified as to why the Trig does not appear to be receiving the correct gps position and presumably will then also use that same, slightly incorrect, gps position when it transmits in ADS-B ES out? I have therefore not been able to use my transponder lest it is transmitting incorrect gps data. Any ideas of what I can check or fix? Is there a screen in PAW where I can read the gps position it thinks it is at? Many thanks!
-
Can I ask how you have determined the gps coordinates are incorrect?
Please explain your exact method
The reason I ask is whether you are using the correct coordinate representation
Thx
Lee
-
Thank you for the reply, Lee. I have plotted the Lat/Long position read from the Trig on Google Maps, having converted the deg/min/sec format from Trig into degree decimals used by Google Maps. I checked the calculations so I think they are correct but I may be wrong. Here is the screen shot attached so maybe you can work out whether it is on the airfield or in the nearby town!? Hope it may be as simple as that!
-
Hi David
The same NMEA messages are sent to the trig, as are sent to SD
Also, you could download the track file to a wifi connected device and take a look at the NMEA messages which would go to the trig
Thx
Lee
-
Hi David.
If you create a user waypoint in SD using the coordinates as shown on the Trig display above, it is depicted as just outside the hangar at Sandown airport. Is that what you’d expect?
The Trig display is already in degrees and decimal minutes, and not deg/min/sec format, so doesn’t need converting.
-
Graham. I think you've spotted where I've gone wrong! If the Trig display is indeed in decimals, and not deg/min/sec as I had assumed, then the location you say you see on SD (outside the hanger) is spot on. I guess I should have noticed that the Trig was in decimals. Why do we have two (very similar) co-ordinate systems ...? :-\ :-\
-
Graham. I think you've spotted where I've gone wrong! If the Trig display is indeed in decimals, and not deg/min/sec as I had assumed, then the location you say you see on SD (outside the hanger) is spot on. I guess I should have noticed that the Trig was in decimals. Why do we have two (very similar) co-ordinate systems ...? :-\ :-\
Dont get me started on cartesian and polar co-ordinates as well ....
-
Hmm. Still a bit confused here. I created that waypoint in SD using the text input format: N5038.9 W00111.1 and it puts it about 100m away. Is that the correct input format for SD for this co-ordinate? Really confusing these decimal degrees! Or is the ±100m a reasonable error?
-
Hmm. Still a bit confused here. I created that waypoint in SD using the text input format: N5038.9 W00111.1 and it puts it about 100m away. Is that the correct input format for SD for this co-ordinate? Really confusing these decimal degrees! Or is the ±100m a reasonable error?
Have you tried
N50.389 and W001.111
A
-
Hmm. Still a bit confused here. I created that waypoint in SD using the text input format: N5038.9 W00111.1 and it puts it about 100m away. Is that the correct input format for SD for this co-ordinate? Really confusing these decimal degrees! Or is the ±100m a reasonable error?
Don't input the coordinates using the wheels; touch the 'Touch here to type them in' and SD shows you the varios formats it will accept - the default one shown is the one you need - just type in the digits you see on the Trig display in the format SD defaults to.
-
OK. Here is the latest situation...!
We met with Keith at LAA Popham who was extremely helpful (we had to drive there). Following his advice today we checked what the aircraft GPS position was from PAW linked to Skydemon. It was exactly correct on the SD map. We also looked at the co-ordinates of the aircraft that were showing at the top of our PAW traffic page. When these were plotted onto SD map as a user waypoint, again they were spot on. So it seems PAW has correct GPS position and is sending that correct position to SD. We then noticed that the co-ordinates showng on the Trig were still exactly the same as those in the photo sent earlier. However, since that photo had been taken we had moved the aircraft about 150m before we did the checks described earlier. It seems as if Trig has 'frozen' with a set of GPS co-ordinates that it picked up at some point from PAW and hasn't updated even as the aircraft has moved around. Any ideas? Thanks for all the input and guidance you've all given so far!
-
Our gps antenna gets covered when the canopy is slid back.
Is your GPS antenna in full view of the sky?
-
Yes. GPS aerial has a very clear view of the sky (and the GPS is the one attached to PAW which is giving the PAW the correct location when displayed on PAW or SD. It’s just the Trig that seems to be displaying the wrong coordinates even though they’re all using the same GPS input!
-
Yes. GPS aerial has a very clear view of the sky (and the GPS is the one attached to PAW which is giving the PAW the correct location when displayed on PAW or SD. It’s just the Trig that seems to be displaying the wrong coordinates even though they’re all using the same GPS input!
Email Trig,
I've found their tech support to be legendary.
Deker.
-
Hi David I would first be inclined to pull the RS232 cable out of your PAW and this should then cause the Trig to not display a position as it will not have a feed. If it continues to hold those co-ordinates then I would bve inclined to give Trig a call. You should find them extremely helpful. If it clears the co-ordinates then re-plug the RS232 and fire it all up and see what you get.
Regards
Alan
-
Thank you Alan. I’ll give that a go and see if I can cause a ‘reset’ that way. Might be a few days before I can get to the plane but I’ll report back. I’ve also already sent an email to Trig to see if they have come across this before. Thanks for all the help.
-
OK. Sorry this has taken a while to get done but this is what we have now tried:
Fired up the PAW and plotted the aircraft position it was giving to Skydemon and it was spot on where the aircraft had been moved to. Trig still showing the original incorrect position from previous photo despite the aircraft being in a new position.
Turned everything off.
Unplugged the PAW serial cable connected to the Trig (providing GPS input).
Powered it all back up
Trig then showed no GPS position. So it recognised that it no longer had any GPS data from the PAW.
Turned it all off and reconnected the cable from PAW.
Trig then showed a GPS position again but it was exactly the same slightly incorrect position that it seemed to have got locked into before (and as in the photo). ie the data hadn’t changed even though the aircraft had moved around.
Is it correct to assume that the position data being sent down the usb cable to the Trig is exactly the same position data as PAW is sending to SD (and also showing at top of PAW traffic page)? Trying to understand if it is PAW sending wrong data down the cable (and seeming to be stuck now with the same position data we had before) or is Trig somehow misinterpreting the data it’s receiving?
I’ve also shared this latest test feedback with Trig support.
Anything else we can try to pin down where the problem is? I should mention that I cut the usb cable to a shorter length before wiring it to the Trig as the PAW and Trig are close to each other and I didn’t want miles of spare cable. Does the USB cable perhaps only work if it is its full original length (which would seem very bizarre for a simple data cable!). Can these cables be faulty so that they transmit data but somehow slightly corrupt it?
David
David
-
What does a flight tracking website say is your position compared to a SkyDemon track? I.e. is it actually wrong or is this just a display issue?
-
Since the Trig is not yet ‘approved’ by the LAA in this installation (we are waiting to get a read-out from someone who has PAW showing that we are transmitting SIL/SDA 0) then we haven’t dared to turn the transponder fully on (we have just stdby) and then fly with it to see what eg Flight radar is showing as our position. So we are assuming that what the Trig is displaying is what it would transmit as its position if we were to turn the transponder fully on. Do you know if it is OK to turn the transponder fully on and then fly with it for the purposes of testing?
-
David, I would sugest connecting your USB to serial cable from the PAW to a serial port on a PC and loging the data messages from the PAW. You may need a second USB to RS232 cable or adaptor to make the cross over cable.
Can you also quote the full model number of the USB-RS232 cable you have installed. Perhaps a photo of the label?
-
The NMEA sentences have a checksum, so I can't see it being data corruption. I suspect if you go for a flight the trig display will be correct, even if you don't enable the output.
-
Thanks to both of you for the replies. I’m away at the moment and working only on my phone so can’t send a photo of the cable label. Not so easy to connect that cable to a PC since on the non-USB end there are only the black and orange wires remaining (the ones that go to the GPS input to the Trig). I could replace the whole cable but the one I got had bare wires on the non-USB end, not any kind of plug that would go into a computer.
Interesting comment about the data being effectively incorruptible. I guess we could go flying with the transponder switched to stdby and see whether by making a large aircraft displacement from origin, the coordinates it is displaying could be made to change at all. Of course in stdby we couldn’t then trace what the transponder was transmitting as our position...
-
This is the cable we have:
https://uk.rs-online.com/web/p/interface-adapters-converters/6877828
It was from a link in one of the PAW forums/info sources.
If we’ve somehow got the wrong one, then do let me know!
-
David, That is the correct cable and you should not need any additional wires than the ground and data out. Ground to ground and the 'out' will go to the 'in' of the second serial port. Nothing fancy, just poking wires into holes will do.
The idea is to get a log of the messages and note the position given in the strings IIRC there is more than one. This should match your GPS location. If it does then the TRIG is the issue, if not the PAW has a problem.
Are SD and TRIG reading the same message string?
No time today, but may test my own tomorrow.
-
Ian. Thanks for all your support here. Good to know we have the correct cable at least. Regarding linking it up to a computer: May take a while as I am not at the aircraft until next weekend. I also don’t have a PC with serial port (I have a Mac). Is there a way to get a Mac to ‘read’ what’s coming out of the cable? Even if I get hold of a PC, not sure where I would stick the orange and black wires from the cable!
-
Hi David,
I am not sure what you are looking for.
The same GPS NMEA messages go to the RS232 as are sent to SkyDemon
So if the messages were wrong going to the Trig, they would be wrong going to SkyDemon.
If SkyDemon is showing your correct position, then the same will be true on the RS232
If you really want to test this, you will need an RS232 input to your computer - the same as the one connected to Pilotaware
then run a terminal emulator on the computer opening the serial device to view the content.
Regarding data corruption, the NMEA messages are sent with a 2 character checksum at the end, so if the data was corrupted, then the checksum would fail, and the data would be discarded.
Thx
Lee
-
Hi David
I use a trig TT21 linked to the Paw for GPS but for the life of me I cannot remember how many digits are displayed on the Controller Head to indicate lat & lon position but I don't think it's that many. I think what is displayed is only to confirm that a recognised message format is being received and may not be accurate enough to register small movements around the airfield. I would think that a short test flight in full ALT mode is required to satisfy yourself that all is well with your positional info. As others have said, if SD is reporting accurate positional info then it is highly likely that the transponder will do likewise.
Regards
Alan
-
Thanks Alan. That’s very helpful. I think what you say may be correct ie that the coordinates displayed on the Trig are an approximation but do indicate that it is getting a GPS feed. The Trig display is to one decimal place on the minutes for lat and long. Have to do the maths to work out what that means in terms of potential error in meters.
We did do a couple of minutes check today with Trig on when airborne over known positions. When replotted on aircrew.co.uk/playback we could see that if we plot the track with just PilotAware selected in the ‘Transmission’ menu it is exactly the same as the track showing when just ‘ADS-B’ is selected. I assume this means that the position data the ground stations are picking up is the same whether transmitted directly by PAW or indirectly via the transponder and its aerial. Altitude data seemed to match too (I think PAW altitude data is derived from gps and effectively based on 1013 and ADS-B altitude data seen by Atom ground stations is the alt data from transponder’s barometer, which is also based on 1013?)
-
Hi David
PilotAware emits GPS altitude
Your transponder will emit the altitude calculated by its own barometric source (unrelated to gps)
Thx
Lee
-
Hi David,
Sorry, I obviously missed you at Popham. I was unfortunately a bit distracted due to trying to track down the reasons for an electrical failure in my own aircraft on the way down on the Thursday, so was off the stand quite a bit and left early on the Sunday in an unsuccessful attempt to avoid the weather, but have been following this thread with interest. I haven’t commented previously as the others have covered all the relevant points at least as well as I could.
I have been flying with a Trig TT21 emitting Mode-S/ES ADSB (via a different uncertified GPS position source) since Project EVA* was first mooted back in early 2015 (while PilotAware was still in its early development phase) and took part in the Project Eva Trials run up here in Scotland by Trig. I joined PilotAware later that year and, working with Lee as part of the Development Team was instrumental in developing the Mode-S Detection and Alerting System and later, Direct Flarm Integration and ADSB-Out processes using USB to RS232 Serial cables..
Initial testing proved to be extremely reliable and Project EVA confirmed the position reliability and accuracy when using uncertified GPS units as the position source at around 98% - which IIRC was slightly higher than the reported accuracy from comparative certified systems.
Since we first mooted the possibility, literally hundreds (possibly even thousands) of transponder users have gone down this route, with a variety of GPS sources, (though the majority I suspect will be using PAW or Trig’s TN72) with an extremely high success rate, so I would not be in the least concerned about the accuracy of your setup. From what you have already said, it appears to be transmitting a Mode-S/ES as expected and as you have already seen from your Aircrew replays, the signal is displaying the same degree of accuracy as your PilotAware, so will be well within the required parameters. So stop worrying, turn your transponder to ALT (as you are legally required to do) and go flying - then seek out a friendly local PAW user to provide you with the necessary screen grab to prove your SIL/SDA Settings and your local inspector and apply for your Mod.
*The project set up by the CAA and NATS to determine if it was safe to allow the use of uncertified GPS sources to provide ‘ADSB-Out’ via transponders, which eventually led to the issue of CAP1391.
Best Regards
Peter
,