Incorrect GPS position sent to Trig TT22

[DavidIOW]

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.

[DavidIOW]

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

[JCurtis]

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?

[DavidIOW]

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?

[Ian Melville]

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?

[JCurtis]

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.

[DavidIOW]

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...

[DavidIOW]

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!

[Ian Melville]

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.

[DavidIOW]

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!

[Admin]

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

[AlanG]

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

[DavidIOW]

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?)

[Admin]

Hi David

PilotAware emits GPS altitude
Your transponder will emit the altitude calculated by its own barometric source (unrelated to gps)

Thx
Lee

[exfirepro]

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

,