PilotAware
British Forum => General Discussion => Topic started by: tnowak on January 13, 2017, 06:53:27 pm
-
This is getting some publicity now:
http://www.uavionix.com/products/echo-att-20b/
Seems it's an ADS-B In and ADS-B out device, but not a transponder.
Looks like it's what the LPAT was going to be but use your own display device.
Tony Nowak
-
This is getting some publicity now:
http://www.uavionix.com/products/echo-att-20b/
Seems it's an ADS-B In and ADS-B out device, but not a transponder.
Looks like it's what the LPAT was going to be but use your own display device.
Tony Nowak
Hi Tony,
That's pretty much what it is. It's advertised on the uAvionix website as 'The World’s First Approved Portable ADS-B Out Solution' - built to comply with UK CAP 1391 (the LPAT standard).
As you have presumably discovered, the unit is currently ONLY available via Amazon UK Marketplace, sold Direct by uAvionix from the USA and re-branded as 'SkyEcho' - presumably to avoid confusion with Amazon's new 'Echo' voice controlled music and data system.
When I first downloaded the Installation and User Guide from the uAvionix website late last year, it appeared that the unit couldn't be used with a Mode S Transponder, due to the limitation which precludes the transmission of the aircraft ICAO Hex address from more than one 1090MHz device at any one time. In response to a question I posted on Amazon at the start of December however, uAvionix advised that the software has been updated to allow the Echo's transmitter to be turned off if you already have a Mode S transponder running, so only one 1090MHz device will transmit the ICAO Hex address. In this case the Echo becomes a relatively expensive ADSB Only Receiver.
Whilst the price seems reasonable for a 1090MHz LPAT device (albeit without the anticipated inbuilt display), it is still not clear whether the advertised price covers UK Import Duty and VAT or whether this is extra. I have posted a question to clarify this on the Amazon website and am awaiting a reply.
FYI it is compatible with SkyDemon, which has been restructured to run the GDL90 data protocol, as well as several other common US Nav Systems. I am not sure about current compatibility with other common UK Nav Systems.
Personally, I'm sticking with my Trig ADSB-Out and PilotAware.
Regards
Peter
-
Hi Guys
I can confirm that the latest release of EasyVFR (just a couple of days ago) is also compliant with the GDL90 protocol.
Not that I am in any way advocating the use of the Echo-ATT-20B, Like Peter I'm already ADS-B equipped and therefore will stick to my PilotAware. You can however now connect your PAW to EVFR and feed all of this data to your EFIS if you're fortunate enough to have one. :)
Not enough panel space left in my flexwing. :-\
You pays your money and takes your choice!!!!!!!!
Alan
-
Yes, it does seem to be priced on the high side but everyone knows that anyone who flies has stacks of cash available....................!
I expect the certification costs were significant and will probably account for £100 (minimum) to the cost of each unit sold.
You only need to read the specification page of a Trig TT21 transponder to see the range of tests that have to be carried out to meet compliance/certification requirements.
Then add all the other company related costs (R&D, manufacture, testing and mark-up) and cost soon spirals up.
Tony
-
...to see the range of tests that have to be carried out to meet compliance/certification requirements.
Then add all the other company related costs (R&D, manufacture, testing and mark-up) and cost soon spirals up.
Tell me about it!
To the point of setting fire to things to ensure they don't self combust, and I am only testing to a small part of ETSO-C71.
Once you jump through the hoops you discover they have found some more down the back of the sofa.
-
Hope that's a non-flammable sofa Jeremy ;)
Regards
exfirepro
-
Well I have just received the Echo ATT20B 8)
I currently have a power issue and think it is battery related, but hope to do some ground testing very soon and see how it integrates with PAW and SkyDemon.
I am not Transponder equipped.
-
Sean,
I presume you purchased it via the Amazon UK Marketplace? If so, what was the situation regarding UK Tax and Import Duty? I tried to find out whether these are covered by the quoted price but uAvionics haven't replied to my enquiry.
Regards
Peter
-
Hi Sean
I am very interested to hear your findings.
It appears there is a serious flaw regarding the altitude reporting for skyecho,
This is due to the fact it has no barometric sensor
Details here
https://forums.flyer.co.uk/viewtopic.php?f=1&t=102806&hilit=Pilotaware&start=60#p1512134
This will be most prominint on days when the pressure is significantly off from 1013.25
Thx
Lee
-
Sean,
I presume you purchased it via the Amazon UK Marketplace? If so, what was the situation regarding UK Tax and Import Duty? I tried to find out whether these are covered by the quoted price but uAvionics haven't replied to my enquiry.
Regards
Peter
No duties added on my delivery and unit arrived within a week from ordering.
-
Hi Sean
I am very interested to hear your findings.
It appears there is a serious flaw regarding the altitude reporting for skyecho,
This is due to the fact it has no barometric sensor
Details here
https://forums.flyer.co.uk/viewtopic.php?f=1&t=102806&hilit=Pilotaware&start=60#p1512134
Thx
Lee
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 ???
-
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
I think you will need 2 devices to run side by side
You could connect from a PC and connect to the radar screen or traffic screen on PAW
thx
Lee
-
Thanks Sean,
Just wanted to check. Still sticking with PilotAware personally, as I don't need another ADSB transmitter (edit: or receiver!!). Also concerned about the lack of Barometric sensing as this will mean your reported altitude could be considerably different from that of the majority of other ADSBs which are derived from transponders.
Let us know how you get on.
Regards
Peter
-
Hi Sean
I am very interested to hear your findings.
It appears there is a serious flaw regarding the altitude reporting for skyecho,
This is due to the fact it has no barometric sensor
Details here
https://forums.flyer.co.uk/viewtopic.php?f=1&t=102806&hilit=Pilotaware&start=60#p1512134
This will be most prominint on days when the pressure is significantly off from 1013.25
Thx
Lee
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.
-
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
I think you will need 2 devices to run side by side
You could connect from a PC and connect to the radar screen or traffic screen on PAW
thx
Lee
Thanks Lee
Still playing, so have PAW connected to Tablet and ATT20B to phone. SD running on both and showing ALT difference of 10ft on first reading and 20ft on second reading. QNH1021 and not changed between readings. On the ATT20B 'APP' the Altitude/GPS was 220 on first reading and 215 on second reading.
Will do some testing over the next few weeks before trying in flight.
Sean
-
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
-
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
-
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
-
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
-
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
-
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
-
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
-
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
-
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 8)
-
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?
-
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