An ADS-B In Question

On Sunday, January 17, 2016 at 7:06:25 PM UTC-8, Andy Blackburn wrote:
For now I'd love to be able to put the BlipMap forecast in as an overlay that I could pull up.

9B

xcsoar manual page 102 7.13 Weather forecast, RASP talks about this. Post if you can make it work.

On Sunday, January 17, 2016 at 7:06:25 PM UTC-8, Andy Blackburn wrote:
On Sunday, January 17, 2016 at 4:19:57 PM UTC-8, Darryl Ramm wrote:
On Sunday, January 17, 2016 at 3:09:47 PM UTC-8, Dan Marotta wrote:
A protocol converter might work!* I'll ask my wife if she's willing
to come out of retirement to play with it.


A protocol converter could be built to go from GDL-90 to FLARM dataport.. But it is a bit harder then it might first appear to do something properly. Starting with FLARM display devices rely on the FLARM device creating traffic alerts, not just passing the traffic location, so you now have to have that logic in the data converter. It would be inexcusable to have traffic displayed and then let a pilot fly right into it without a warning. And it would certainly be nice to keep that alert logic anywhere nears as good as how FLARM manages to do traffic alerts (low level of spurious alerts for typical glider scenarios, even if hopefully you are not thermalling with too many folks with UAT Out.. but you may be seeing TIS-B traffic. including from other gliders, and that logic of how you account for less precise position data needs to be taken into account.. Ideally it would actually be FLARM doing this software, they are the experts. FLARM also claims legal rights to their dataport interface specs, that may or may not present problems for third parties wanting to produce a commercial converter. I'd actually not want any half-baked attempts here on the market, it is much more complex than say the serial data converters that just merge a GPS/NMEA and FLARM/NMEA stream, and could be dangerous if done poorly. As I've said before I just cannot really imagine it being worth anybody doing this commercially. Now hen it is just for a small fraction of an already small USA glider market, and they'd be talking on all the associated product liability.

And since nearly all soaring software/flight computers just understand the FLARM dataport protocol and that protocol has no concept of displaying TFIS-B or any other weather data so a converter won't help you there with FIS-B. And I expect the very last thing FLARM folks would want to spend efforts on would be supporting weather graphics over what are frequently slow serial data links, sometimes to underpowered devices, when they are in the saving lives and avoiding mid-air collisions business. The soaring software itself would need to extensively modified to read FIS-B data directly over GDL-90 (or similar more proprietary formats) It is not clear it is worth the effort for anybody to do that, especially when the easy answer for the few folks who want this is just grab another PDA/PNA/tablet and use that for TIS-B.

And then some users might want to say try to add a UAT traffic input to a PowerFLARM, there you have to do the deduplciation of FLARM, 1090ES, PCAS, with UAT/ADS-R/TIS-B traffic. And that can get messy, and require lots of care and testing, and can never be perfect (not with Mode C transponders or Mode C interrogators in the area.

And yes LXNAV is spending effort doing Internet based weather stuff on their displays. I'm conflicted there, I like to see innovation like that, but part of me thinks cockpit weather in a glider is mostly masturbation,... let go of your err multifucntion joysticks/pointing device or whatever you have your hand ons, and look outside the frigging cockpit. And the LXNAV stuff will only work in flight for folks who can get a cellphone data connection. uh right. And that I expect largely reflects not wanting to use the closed/expensive airborne weather data available in Europe. All seems like a waste of time for the USA market, if LXNAV cares about the USA market maybe we'll see TIS-B and (even better) XM Weather integration.

I guess I was thinking about taking only UAT direct and TIS-B (which would be better if you had 1090ES Out because maybe you could turn off the Flarm PCAS which goes completely and uselessly nuts when a glider near you has a transponder - I would think most of the time if a transponder is lighting up PCAS they will show up on TIS-B - but with an actual location rather than a rough range based on power). I believe LXNav does audible traffic alerts for traffic that gets within 1 mile and 1000' - that's okay by me for UAT and transponder traffic - I'm happy with a 1mi radius +/-1000' traffic warning for anyone without Flarm. I guess depending on what you tell ADS-B ground station your configuration is you could have more or less of a problem with de-conflicting, but if you could eliminate PCAS then you are left with cutting out UAT traffic with Mode C transponders since Mode C has no ICAO ID - but I suspect that is a problem with TIS-B no matter what you do unless ADS-R de-dups automatically based on proximity.

I'm sure I missed something, but perfect can sometimes be the enemy of better than we have now. What I have now is very good Flarm and ADS-B 1090ES and useless PCAS unless I'm flying with no other gliders with a transponder operating. Adding UAT and especially TIS-B for transponders would be better.

Getting compliant ADS-B Out in your '27 so you have reliable working TIS-B client coverage is your first challenge. Call me when you have that sorted. If you are trying to expand/supplement a PowerFLARM you would likely want to do that with UAT In (so you can get UAT direct). But yes that leaves some complexity around what capability codes to set in the ADS-B Out, it is not actually clear to me what to do there. Something to discus with the ADS-B vendors. You want TIS-B broadcast for you on the UAT link not the 1090ES link, but you want the ground system to know you have 1090ES so it does not do ADS-R for you. Ugh, see why we can't have pretty things.

Then do you have TIS-B coverage where you care about transponder equipped GA traffic, you my not have that down low/say close to many GA airports/gliderports where it might be handy (and where PCAS may still work).

You can't perfectly reliably debupe Mode C PCAS and TIS-B, maybe you can altitude filter and crudely range filter and discard some PCAS mode C targets. Or even better I'd hope the system can have enough confidence you are within TIS-B coverage to suppress all PCAS targets. Given it is supposed to receive
entering/exiting service coverage messages the system could track that. See how complex things get quickly.

But it's kinda gotta work in a half understandable way and reliably. And if you don't provide close FLARM legacy style alerts with TIS-B Traffic but do for others that may dangerously confuse folks, You may need to do something in the middle with a new class of TIS-B alert. A 6 second or so old TIS-B position, based on fuzzy radar data, then magically extrapolated is one thing when driving around in yer old Cessna and a very very different thing with gliders thermalling together. You especially don't' want the system sending off alerts for a bogus target location in a thermal while you collide with the glider in it's actual position.. oops "found it". The whole UI may needs to warn differently for a TIS-B vs. FLARM/1090ES threat, but better than PCAS, and how do you make all that clear and understandable? You got lots of money to fund FLARM doing what is now a TIS-B accuracy/dynamics/collision risk/UI?UX R&D project? See more why we can't have pretty things.

In the big picture TIS-B will go away over time as most of those transponder equipped aircraft also gain 1090ES Out or UAT Out, so the problem sort of corrects itself, maybe in less time than futzing with adding support for it into any FLARM technology (either in the box or in a converter).

Yes - cellular weather seems problematic - satellite and FIS-B seem like things computer makers would be better off trying to accommodate. Hard to know it it's useful. For now I'd love to be able to put the BlipMap forecast in as an overlay that I could pull up.

Just download the latest raw data over your Iridium satellite link and crunch the blipmap onboard. That way you can focus on crunching local data at high resolution and timeframes you want. Maybe enhanced with actual measured local soundings (from your ship). or launch sounding balloons/drones. :-)

Sounding ballon use in competitions might worry some folks....

On Sunday, January 17, 2016 at 10:20:31 PM UTC-8, xcnick wrote:
On Sunday, January 17, 2016 at 7:06:25 PM UTC-8, Andy Blackburn wrote:
For now I'd love to be able to put the BlipMap forecast in as an overlay that I could pull up.

9B

xcsoar manual page 102 7.13 Weather forecast, RASP talks about this. Post if you can make it work.

RASP forecast support is nothing more than the ability to manually upload a bunch of RASP weather forecast PNG pictures and overlay it on the display.. You would care about this if you have a local RASP forecast available, and especially if you already use them. RASP *are* frequently very impressive (thanks Dr. Jack!) but this does take some futzing around. But some folks will find it handy, the accuracy of RASP forecast convergence lines in the blue for example can be spectacular in some areas and you want to track the movement of that blue convergence forecast vs. time of day.

None of that that has *anything* to do with receiving or displaying FIS-B weather data.

Andy's running LXNAV big-iron, so he does not get to even do what XCSoar can.

On Sunday, January 17, 2016 at 10:53:19 PM UTC-8, Darryl Ramm wrote:
On Sunday, January 17, 2016 at 10:20:31 PM UTC-8, xcnick wrote:
On Sunday, January 17, 2016 at 7:06:25 PM UTC-8, Andy Blackburn wrote:
For now I'd love to be able to put the BlipMap forecast in as an overlay that I could pull up.

9B

xcsoar manual page 102 7.13 Weather forecast, RASP talks about this. Post if you can make it work.

RASP forecast support is nothing more than the ability to manually upload a bunch of RASP weather forecast PNG pictures and overlay it on the display. You would care about this if you have a local RASP forecast available, and especially if you already use them. RASP *are* frequently very impressive (thanks Dr. Jack!) but this does take some futzing around. But some folks will find it handy, the accuracy of RASP forecast convergence lines in the blue for example can be spectacular in some areas and you want to track the movement of that blue convergence forecast vs. time of day.

None of that that has *anything* to do with receiving or displaying FIS-B weather data.

Andy's running LXNAV big-iron, so he does not get to even do what XCSoar can.

Some folks just print out or save RASP forecasts images on their phones or PDAs.

Oops technically geolocated jpg, not png, but same difference.

RASP is good tool to know when to drive to airport and go flying. Once airborne, it is utterly useless.

Dan, it's probably easier than you think (for the right person).

Stratux is entirely open source - it should be possible to gin up whatever data the FLARM-in wants. I sent you a couple links about this in email: The Flarm data protocol and how to get serial output from the pi.

As an IT manager would say ... " just a simple matter of programming ".

Sarah Anderson

On Sunday, January 17, 2016 at 5:09:47 PM UTC-6, Dan Marotta wrote:
A protocol converter might work!* I'll ask my wife if she's willing
to come out of retirement to play with it.



For me, I'd just let the weather information fall onto the cockpit
floor.* I don't see the utility, for my type of flying,
of having weather information displayed in my VFR glider cockpit.*
I'll continue to look out the window for that.* ;-)




On 1/17/2016 3:33 PM, Andy Blackburn
wrote:



On Sunday, January 17, 2016 at 11:46:30 AM UTC-8, Darryl Ramm wrote:


Dan you are wasting your time trying to get these to talk together, as I have already mentioned (in this meandering thread). XCSoar accepts Flarm dataport format data (including FLARM, ADS-B and PCAS data from a PowerFLARM). Stratusx outputs GDL-90 format data. They are not compatible at all.


Might it be possible for someone to write a Raspberry Pi program to convert GDL-90 data to Flarm data port format? Is GDL-90 proprietary? Do you have to pay a license fee to use it or something? Since it's ADS-B generated data and Flarm outputs ADS-B targets from its own receiver I would think it would be relatively straightforward for a competent programmer to do. You might even be able to plug the Flarm serial output directly into the Raspberry Pi and Mux the two data streams together for output to a flight computer.

That still leaves the question of how to handle any ADS-B weather (especially weather radar) information, the display of which presumably no soaring flight computer maker has provided for yet. However, LXNav is rolling out their own cellular data-based weather map service. If that's not a proprietary/closed format some additional work somewhere could allow making ADS-B weather data suitable for display as well - at least on some displays. Cellular data feeds can be problematic for technical and regulatory reasons so using the ADS-B free weather is ultimately probably a superior solution - just in the US. Satellite subscription could be useful elsewhere I suppose.

Just spitballing - I'm no expert on this. Would be cool if it could work though.

9B





--

Dan, 5J

And now for another glaring example of the USRC's anti innovation crusades utter failure...

Cellular data is used regularly for several high performance tracking systems in many cases....(including weather in many, but I will get back to that later)

LiveTrack24
http://www.livetrack24.com/docs/index
LiveTrack24 is very popular mobile data based tracking system. It is very affordable ($1-2 a month). It utilizes (in many cases, including the recent recent Junior World Championships in rural Australia) mobile data to provide spectators and contest staff near real time tracking of the competitors.. The performance of livetrack24 was incredible and we were all blown away at how well the system worked.

SkyLines (integrated with XC Soar)
https://skylines.aero/tracking/info
This is a very popular tracking application that is literally built into XCSoar and has exceptional performance as well. All you need to do is open XC Soar and (in configured) it automatically begins transmitting and updating your flight data. It's free I believe.

Many, many people are using regularly these technologies in the US and Europe and Australia, etc, etc. (and have been doing so for years). This includes light aircraft, gliders, hang gliders, paraglide let's, etc. Most glider pilots could literally care less what he USRC has to say about it. Some of us, sadly, do turn it off at contests knowing some crybaby (oligarch) will likely protest us for using it (claiming we are a cheater, etc).

Instead, we have to pay $300 for InReach data plans and $40 a month to get the same 1 second tracking resolution. But the SSAs tracking website "investment" (ROTFL) can't even manage InReach data (the case for several years now). So nobody can even see pilots with InReach while "racing" SSA contests (sorry, flying OLC tasks). Instead, spectators are treated to the snooze fest of Spot only updates which are on a 10 minute cycle and include no altitude, no speed, and no heading. What a joke. What a JOKE! You can't make this up.

Mobile data is simply not a threat to safety in a glider. In fact, it's a ridiculous statement. Mobile data is a convenient, affordable friend to the sport of gliding in numerous ways. Only the USRC and their oligarch puppet masters cannot seem to get their heads around the value it and other new technologies provide us. Instead, they quiver in fear, telling tall tales (people are regularly winning contests without any skills, simply by using Flarm to leech and with a cell phone showing them the weather, etc). They use words like "tradition," and phrases like "how it should be," while calling us "weak-assed." It really is quite remarkable to witness. They desperately fight the rising tide, and have zero chance of winning this ridiculous "battle" to stop it. Yet they force us to tread water with them while they scream and whine their typical battle cries...

All of this discussion on ADSB is entirely worthless gentleman. The US RC (and the oligarch which motivates them) will NEVER allow it. They consistently make rules banning new technology. ADSB and even normal POWERFlarm function is currently ILLEGAL in the contest cockpit for 2016. Correct? Maybe we need to address that elephant in the room before posting hundreds of comments on how to install ADSB in a glider (even though and FAA mandate looms...)

If we are to get out of this ridiculous pattern, we need USRC representatives who see the world differently and are not "one" with the US anti tech oligarchy. Otherwise, we will drown with them in the oncoming tide of new technology while being mercilessly strip searched before and after every contest flight next season and penalized (tarred and feathered) for recieving a text message.

Wait a minute, the USRC is also famous for not enforcing rules...OK, OK...I will stop for now.....

Happy Monday! I feel so much better now!

Chuckle

I've only had one glider flight east of the Mississippi (at Harris
Hill), but I am familiar with crappy visibility and I don't have an ILS
in my glider. =-O But, where I fly, I can see much further than a final
glide will get me which is why I don't see the value in having satellite
radar in the cockpit.

The blipmap suggestion is intriguing if you can get it from the macro to
the micro scale. Admittedly, I haven't used it but, the looks I've
taken appear to be quite general when zoomed down to the 5-10 or even 20
mile radius that I think might be of interest. Again, where I fly, a
simple look at the sky for clouds or the ground for thermal generators
seems to be of more use. I'm talking fun flying, not hard driving
contest flying.

But this is once again getting away from the original topic. We're
going to take a look at the Stratux source code and see how much work it
will be to change the output stream from GDL-90 (did I remember that
correctly) to Flarm protocol. If we can do that, I can fool my Streak
into thinking I've got a Flarm installed.

On 1/17/2016 4:50 PM, Andy Blackburn wrote:
snip

I'd like to have BlipMaps on the display - updated over the course of
the day would be a nice to have, but probably not essential - that's
separate from ADS-B weather of course. For the ADS-B stuff, knowing
where the thunderstorms are can be useful for those final glide
decisions where you want to know whether you might need to use the ILS
by the time you get there. Also for knowing whether you can get around
a cell or not, how far to the sun on the far side of the blowoff. The
usual nail-biter decisions where most people can only make a guess.
Even for you some of those scenarios might be occasionally useful aids
to getting home on an OD day. 9B

--
Dan, 5J

Whoa, Big Fella...!

I'm not looking to create anything commercial (no product liability) and
I don't give a hoot about Flarm traffic alerts. My focus is very, very
narrow; I want to display ADS-B traffic /_only_/ on my Dell Streak 5
using the output of my Raspberry Pi. Weather? I don't need no steenkin'
weather!

BTW, I really did enjoy your last couple of sentences! :-D

On 1/17/2016 5:19 PM, Darryl Ramm wrote:
On Sunday, January 17, 2016 at 3:09:47 PM UTC-8, Dan Marotta wrote:
A protocol converter might work! I'll ask my wife if she's willing
to come out of retirement to play with it.

A protocol converter could be built to go from GDL-90 to FLARM dataport. But it is a bit harder then it might first appear to do something properly. Starting with FLARM display devices rely on the FLARM device creating traffic alerts, not just passing the traffic location, so you now have to have that logic in the data converter. It would be inexcusable to have traffic displayed and then let a pilot fly right into it without a warning. And it would certainly be nice to keep that alert logic anywhere nears as good as how FLARM manages to do traffic alerts (low level of spurious alerts for typical glider scenarios, even if hopefully you are not thermalling with too many folks with UAT Out.. but you may be seeing TIS-B traffic. including from other gliders, and that logic of how you account for less precise position data needs to be taken into account.. Ideally it would actually be FLARM doing this software, they are the experts. FLARM also claims legal rights to their dataport interface specs, that may or may not present problems for third parties wanting to produce a commercial converter. I'd actually not want any half-baked attempts here on the market, it is much more complex than say the serial data converters that just merge a GPS/NMEA and FLARM/NMEA stream, and could be dangerous if done poorly. As I've said before I just cannot really imagine it being worth anybody doing this commercially. Now hen it is just for a small fraction of an already small USA glider market, and they'd be talking on all the associated product liability.

And since nearly all soaring software/flight computers just understand the FLARM dataport protocol and that protocol has no concept of displaying TFIS-B or any other weather data so a converter won't help you there with FIS-B. And I expect the very last thing FLARM folks would want to spend efforts on would be supporting weather graphics over what are frequently slow serial data links, sometimes to underpowered devices, when they are in the saving lives and avoiding mid-air collisions business. The soaring software itself would need to extensively modified to read FIS-B data directly over GDL-90 (or similar more proprietary formats) It is not clear it is worth the effort for anybody to do that, especially when the easy answer for the few folks who want this is just grab another PDA/PNA/tablet and use that for TIS-B.

And then some users might want to say try to add a UAT traffic input to a PowerFLARM, there you have to do the deduplciation of FLARM, 1090ES, PCAS, with UAT/ADS-R/TIS-B traffic. And that can get messy, and require lots of care and testing, and can never be perfect (not with Mode C transponders or Mode C interrogators in the area.

And yes LXNAV is spending effort doing Internet based weather stuff on their displays. I'm conflicted there, I like to see innovation like that, but part of me thinks cockpit weather in a glider is mostly masturbation,... let go of your err multifucntion joysticks/pointing device or whatever you have your hand ons, and look outside the frigging cockpit. And the LXNAV stuff will only work in flight for folks who can get a cellphone data connection. uh right. And that I expect largely reflects not wanting to use the closed/expensive airborne weather data available in Europe. All seems like a waste of time for the USA market, if LXNAV cares about the USA market maybe we'll see TIS-B and (even better) XM Weather integration.




--
Dan, 5J

On Monday, January 18, 2016 at 7:57:51 AM UTC-8, Dan Marotta wrote:
Chuckle



I've only had one glider flight east of the Mississippi (at Harris
Hill), but I am familiar with crappy visibility and I don't have an
ILS in my glider.* =-O
But, where I fly, I can see much further than a final glide will get
me which is why I don't see the value in having satellite radar in
the cockpit.



The blipmap suggestion is intriguing if you can get it from the
macro to the micro scale.* Admittedly, I haven't used it but, the
looks I've taken appear to be quite general when zoomed down to the
5-10 or even 20 mile radius that I think might be of interest.*
Again, where I fly, a simple look at the sky for clouds or the
ground for thermal generators seems to be of more use.* I'm talking
fun flying, not hard driving contest flying.



But this is once again getting away from the original topic.* We're
going to take a look at the Stratux source code and see how much
work it will be to change the output stream from GDL-90 (did I
remember that correctly) to Flarm protocol.* If we can do that, I
can fool my Streak into thinking I've got a Flarm installed.




On 1/17/2016 4:50 PM, Andy Blackburn
wrote:


snip


I'd like to have BlipMaps on the display - updated
over the course of the day would be a nice to have, but probably
not essential - that's separate from ADS-B weather of course. For
the ADS-B stuff, knowing where the thunderstorms are can be useful
for those final glide decisions where you want to know whether you
might need to use the ILS by the time you get there. Also for
knowing whether you can get around a cell or not, how far to the
sun on the far side of the blowoff. The usual nail-biter decisions
where most people can only make a guess.
Even for you some of those scenarios might be occasionally useful
aids to getting home on an OD day.
9B




--

Dan, 5J

I have tried to use satellite weather in the cockpit. There are several smart phone apps that show nearly real time hi res doppler radar and satellite photos. The photos are probably some time delay behind. The radar purports to be very recent. The reason I saw value in it is on days with a lot of thunderstorm activity it might give a clue as to viable routing: example, flying south to the White Mountains and things begin to OD, if I turn north should I go to the Patterson Range or is it already OD'd there, or west to the Sierra or east of the Yerington Valley? I cannot possibly see that far on a day with OD, and the choice may preclude others making the difference between getting home and not. The smart app (I use RadarUS+) shows convection cells, intensity, travel direction and speed, lightening, etc.

What I discovered was that generally, the data is too old to be useful. It requires a good data connection which is often not available in remote areas, the data is some minutes old when you get it, and in the hour it takes to fly to the part you couldn't see it is now more than an hour old. I have used it once or twice to determine if my home airport was OD'd, which was helpful. Maybe in an area with less dynamic weather it would work.

My conclusion is that cockpit weather, like Flarm radar, is only a theoretical advantage, not a practical one in competition.