Echo-ATT-20B

[exfirepro]

From CAP 1391

AMC 1391-4.12: Altitude data
Refer to RTCA DO-260B/EUROCAE ED-102A §2.2.5.1.5 a. for pressure altitude or b. for GNSS HAE.
It is envisaged that a Basic/transmit-only device would report GNSS height, whereas a more elaborate Intermediate device may use a barometric altitude sensor. Suitable provision to set up an EC device incorporating a barometric altitude sensor should be  made, ie as part of a status display. Also, the operating manual should provide sufficient information for this to be practically achievable.

If capable, the EC device may provide GNSS Height Above the Ellipsoid (HAE) in accordance with RTCA DO-260B/EUROCAE ED-102A §2.2.5.1.5 b.

So entirely within the specification of the CAP on the device approval  and therefore an assumption that the device providing the alerts/display resolves the difference.

IMHO therefore not a flaw in the design.

Hi Alan,

You are certainly correct in your interpretation that GPS derived altitude meets the standard for basic/transmit only LPAT devices, so there is obviously an assumption that GPS derived altitude will suffice for 'basic' LPAT devices talking to each other (which isn't unreasonable - PilotAware uses GPS derived altitude for P3i to P3i comparison and I'm pretty sure basic FLARM does the same).

I don't agree with your assumption however that it its the responsibility of the provider of the alerts/display to resolve differences between this and Baro Driven ADSB transmitters.

My reading of the CAP is that if fitting a baro, the EC system must provide a means of checking/ calibrating the barometer via the EC Unit's Status Display - e.g. in the case of the Echo, (if a baro was incorporated) via its 'Control App' Screen. I certainly don't read this as placing any responsibility to resolve height variations on 3rd party (e.g. Nav) system providers.

IMHO a somewhat wooly concept, however, for a supposed aviation safety system!!

Regards

Peter

[AlanB]

From CAP 1391

So entirely within the specification of the CAP on the device approval  and therefore an assumption that the device providing the alerts/display resolves the difference.

IMHO therefore not a flaw in the design.

I don't agree with your assumption however that it its the responsibility of the provider of the alerts/display to resolve differences between this and Baro Driven ADSB transmitters.

My reading of the CAP is that if fitting a baro, the EC system must provide a means of checking/ calibrating the barometer via the EC Unit's Status Display - e.g. in the case of the Echo, (if a baro was incorporated) via its 'Control App' Screen. I certainly don't read this as placing any responsibility to resolve height variations on 3rd party (e.g. Nav) system providers.

IMHO a somewhat wooly concept, however, for a supposed aviation safety system!!

Regards

Peter

I think I see where we differ.

I was referring to the fact that Lee was concerned that the PING Device was only transmitting GPS altitude and no Baro therefore any device comparing altitude from a Ping Device with GPs Altitude and a Device with Baro only altitude would have a significant difference when it comes to alerting especially with the differences in pressure we have been experiencing lately. The device alerting the pilot to a possible target in an relative altitude band would have to resolve and difference between Baro and GPS and therefore detect which reference the transmitting device is using.

Sounds more complicated to write than say so I hope you see what I mean.

As to a Safety System, having written many Safety Cases for my former employer, if I was to tackle the safety Case it would have the lowest, if any, risk factors as it is not the primary means of providing separation IMHO. In VFR the Mk One Eyeball is the primary means for both pilots and an electronic conspicuity is an aid. As an aid to the pilot to claim any thing higher would increase the design mitigation that would have to be applied and therefore cost.

Kind Regards

Alan

[exfirepro]

Well the power issue was/is with the battery connector on the battery. Have got it working now in my dining room and connects and working with SD ok.

Not sure on how to use the ATT20B and PAW together though, as ATT20B connects via GDL90 and PAW via FLARM on SD 

Hi Sean,

Thinking a bit more about this. If you are tight for space, the most effective way would be to run the SkyEcho as a 'blind' transmitter and connect SkyDemon to your PAW. That way you will be transmitting ADSB and P3i and receiving/displaying ADSB, P3i, Mode C and Mode S from your PAW, plus of course the 'potential' to integrate gliders later if you need to.

Regards

Peter

[exfirepro]

Morning Alan,

We're not at odds I assure you! I completely agree. I fully understand and appreciate the concerns re a lack of barometric comparison, when - at least in the short to medium term - the only targets the ATT-20B is likely to see this side of the pond will be from ADSB aircraft whose altitude is derived from 1013.2 via a baro cell. The only point I had issue with was the implication that this places a responsibility on the display (Nav) system developer to resolve this, which IMO isn't what the quoted section of CAP 1391 is referring to. As pilots, however this still leaves us with yet another problem we need to be aware of and be able to deal with if the conditions are relevant.

Best Regards (as always)

Peter

[Admin]

Hi Alan,

I think I see where we differ.

I was referring to the fact that Lee was concerned that the PING Device was only transmitting GPS altitude and no Baro therefore any device comparing altitude from a Ping Device with GPs Altitude and a Device with Baro only altitude would have a significant difference when it comes to alerting especially with the differences in pressure we have been experiencing lately. The device alerting the pilot to a possible target in an relative altitude band would have to resolve and difference between Baro and GPS and therefore detect which reference the transmitting device is using.

Maybe I wasn't clear, my concern is unrelated to whether PING transmist GNSS or BARO Altitude, I think this is fine.
In the case of PilotAware we decode and compare the Altitude based upon its reference format, so if it is GNSS, we compare to the local GNSS, if it is BARO, we compare to the local BARO.

My concern was on the Nav display, eg skydemon.
Skydemon is receiving the Ownship message (ie me) altitude in GNSS
but it being given traffic reports in BARO.

So now there is an inconsistency, my own altitude is reported in GNSS, but everybody else in BARO, and as Tim Dawson quite rightly said in his posting

https://forums.flyer.co.uk/viewtopic.php?f=1&t=102806&hilit=PilotAware&start=60#p1512134

This is a disadvantage of devices without a barometric sensor which I have not managed to figure out a good workaround for.
Without a barometric sensor you are left trying to compare pressure altitudes (from other devices) with GPS altitude (from the onboard device) in order to give the user the relative height of other traffic. And you just can't do it.

This is an onerous task to place on the NAV software, because in GDL90 the altitudes are reported in absolute, in a different reference format.
PAW reports the altitude differences as relative, so this is already resloved prior to dispatch to the NAV device

Sorry for any confusion I may have caused, I hope this is now clear.

Thx
Lee

[AlanB]

Now I understand thanks lee.


One other question you asked was availability of test documents.

The CAA audit the evidence supplied by manufactures and expect appropriate test a documentation and results to be available from the supplers/manufacturers verifying against published standards. In the case of cap1391 all the ref docs are in the public domain although you may need a subscription to gain access to the up to date ones. If you google them you may just get old copies.

As Cub said NATS and caa Staff are unable to offer business related answers to questions on public domain.

Hope that helps

Alan

[AlanG]

PAW reports the altitude differences as relative, so this is already resloved prior to dispatch to the NAV device

Sorry for any confusion I may have caused, I hope this is now clear.

Thx
Lee

Hi Lee

Does the above apply regardless of whether the Nav device is using its own GPS source or does it have to be using PAW as the GPS source.  I ask because I initially used to run with EVFR nav system using the tablet GPS with the thought that if PAW went down for any reason I didn't lose GPS to my navigation but have recently switch to using  Flarm GPS (PAW) as EVFR GPS as I thought this kept everything singing from the same sheet.  Plus I thought that the Baro Altitude from PAW would be more accurately compared to my altimeter.
1: Am I correct in thinking, from what you say above, that All relative altitudes I see on my screen will be correct regardless of which GPS source I choose for EVFR to use.
2: If using PAW GPS as source, is EVFR being fed Baro Altitude or GPS altitude for its other on-screen altitude information.

Sorry if I'm being  thick here.

Regards
Alan

[Admin]

Message to Seanjd

You can return your SkyEcho and get a barometer fitted, I would fully recommend this
https://forums.flyer.co.uk/viewtopic.php?f=1&t=102806&hilit=PilotAware&start=90#p1512518

Thx
Lee

[Seanjd]

Well the power issue was/is with the battery connector on the battery. Have got it working now in my dining room and connects and working with SD ok.

Not sure on how to use the ATT20B and PAW together though, as ATT20B connects via GDL90 and PAW via FLARM on SD 

Hi Sean,

Thinking a bit more about this. If you are tight for space, the most effective way would be to run the SkyEcho as a 'blind' transmitter and connect SkyDemon to your PAW. That way you will be transmitting ADSB and P3i and receiving/displaying ADSB, P3i, Mode C and Mode S from your PAW, plus of course the 'potential' to integrate gliders later if you need to.

Regards

Peter

I have plenty of room, so space is not an issue, but agree with your post quoted above 

Message to Seanjd

You can return your SkyEcho and get a barometer fitted, I would fully recommend this
https://forums.flyer.co.uk/viewtopic.php?f=1&t=102806&hilit=PilotAware&start=90#p1512518

Thx
Lee

Thanks Lee. I had an email from them earlier today, so am a very satisfied customer so far 

[Paul_Sengupta]

Alan - as I understand it, the PAW sends the relative altitude of the contact to the nav display in the Flarm protocol, so the PAW works it out before sending, comparing with either its baro source or GPS source as appropriate.

If I understand Lee correctly, the GDL-90 protocol that the ATT-20B uses sends the absolute received altitude (or FL!) of the contact, then the nav device works it out. Is this correct?

[Admin]

Yes Paul you are correct.
Flarm format (which paw uses), is relative altitude already calculated
GDL90, is absolute, requiring a 3rd party (nav tool) to calculate the relative offset

Thx
Lee