An ADS-B In Question

[Dan Marotta]

Hopefully Darryl will respond to this but anyone with the knowledge will
be appreciated.

I have a home-grown ADS-B system consisting of a Raspberry Pi 2 and a
couple of software defined radios feeding Avare on my smart phone. I
have line of sight to the ADS-B tower on top of Sandia Peak, on the east
side of Albuquerque. I see a number of 1090ES targets around the ABQ
area, one at 10,400PA', one at 8,200PA' over SAF, several in the high
30s to low 40s pressure altitude. But I don't see any targets very far
away from Albuquerque.

Is it that only targets within some volume are being transmitted through
the tower within view or am I simply receiving the 1090ES transmissions
directly from the aircraft? I think this may be the case as I don't see
and aircraft on my display that I couldn't see with binoculars from my
house.

When I first turned on the system I saw some aircraft that appeared to
be in the traffic pattern at ABQ and, from where I live on the east side
of the mountains, their transmissions would be blocked by the
mountains. I speculate that there was an ADS-B Out aircraft flying
relatively low near my house and I was receiving TIS-B transmissions
meant for him. I also saw ADS-B weather that day and there were a lot
of snow storms up and down the Rockies.
--
Dan, 5J

[Darryl Ramm]

Dan

The ADS-B ground station will be broadcasting ADS-R and TIS-B data for client aircraft that are near (i.e. within the ADS-B service "jockey puck" of +/- 3.500' and 15nm radius around the client aircraft). So it may not be, and does not need to be, client aircraft near *you*. Say a suitable equipped ADS-B Out aircraft was 1,000' directly overhead some other transponder only equipped traffic (within SSR coverage) on the other side of a mountain range, where all those aircraft are out of sight to you. The ADS-B ground you had line of site to the ADS-B ground tower covering that airspace you would still see those ground broadcasts intended really for he client aircraft on the other side of the range.

That's again points to the basic irony looking at TIS-B and ADS-R transmissions, they are made for client aircraft near the target, not necessarily near you. As the other target aircraft moves away from the client aircraft, maybe towards you. You stop seeing it on ADS-B. Oops. And in your case it is more likely than not won't be a ADS-B client aircraft near you that is causing what you see for a remote aircraft on the other side of a mountain, the client aircraft will be over on the other side, closer to the target.

What you see at distances will depend on the signal strength and distance to the aircraft or ground station and you antenna setup. These small software defined radio modules are fun to play with but built at low cost and don't have the worlds best analog RF front ends. It would be fun to compare them to what is used in commercial portable devices. Part of the reason I'm not too excited about folks using these in their aircraft for more than experimenting/playing around. The antenna used and it's location/sky visibility will affect coverage as well. It could well be that you will see lots of distant aircraft via ADS-R and TIS-B but not ADS-B direct, because you can receive transmissions from the ground tower well but not those more distant aircraft even if you have line of site to them.

I've mentioned in the past it is hard to try to reverse engineer overall what is going on, especially you cannot easily tell what is being broadcast for what client aircraft. However it should be relatively easy to technically tell if you are receiving data for a TIS-B target. That information is included in the air broadcast messages and fully exposed in the de-facto standard GDL-90 serial communications these portable (hobby and commercial) ADS-B receivers are using.

The GDL9-90 communication protocol is documented and publicly available. e.g. here https://www.faa.gov/nextgen/programs/adsb/wsa/media/GDL90_Public_ICD_RevA.PDF. (that one is old, I'd imagine there may be more recent updates even of he GDL90 has long ago stopped being interesting).

The first question I would have is how much of the GDL-90 protocol does and receiver software really implement and does it software correctly send out the target type field data. I've not played with it so I don't know, hopefully it does. Reading the source code should also make that clear.

So even if most commercial traffic display software won't show on the display what type an ADS-B target is it is possible for somebody a little technical to look at this stuff and tell. Easy for example to just grab the GDL-90 serial steam and process it with a text utility. The software Dan is using does logging and I suspect this is all in those log files or can be turned on, but I've not looked.

it is also clear over the air what a ADS-R or ADS-B direct messages are. If that is simply exposed in the traffic stream form any of these devices should be easy to work out for technical folks.. again just by reading the source code.

Hope that helps.









On Sunday, January 10, 2016 at 11:09:02 AM UTC-8, Dan Marotta wrote:
> Hopefully Darryl will respond to this but anyone with the knowledge
> will be appreciated.
>
>
>
> I have a home-grown ADS-B system consisting of a Raspberry Pi 2 and
> a couple of software defined radios feeding Avare on my smart
> phone.* I have line of sight to the ADS-B tower on top of Sandia
> Peak, on the east side of Albuquerque.* I see a number of 1090ES
> targets around the ABQ area, one at 10,400PA', one at 8,200PA' over
> SAF, several in the high 30s to low 40s pressure altitude.* But I
> don't see any targets very far away from Albuquerque.
>
>
>
> Is it that only targets within some volume are being transmitted
> through the tower within view or am I simply receiving the 1090ES
> transmissions directly from the aircraft?* I think this may be the
> case as I don't see and aircraft on my display that I couldn't see
> with binoculars from my house.
>
>
>
> When I first turned on the system I saw some aircraft that appeared
> to be in the traffic pattern at ABQ and, from where I live on the
> east side of the mountains, their transmissions would be blocked by
> the mountains.* I speculate that there was an ADS-B Out aircraft
> flying relatively low near my house and I was receiving TIS-B
> transmissions meant for him.* I also saw ADS-B weather that day and
> there were a lot of snow storms up and down the Rockies.
>
>
> --
>
> Dan, 5J

[Dan Marotta]

Very helpful, thanks!

So far I've only looked at the data stream being sent to the Avare
application. It's a text stream which includes aircraft call sign (if
avaliable, e.g., UAL178), the ICAO address, lat, lon, and altitude. I'd
look at the source code, but my eyes get bleary pretty quickly.

I don't intend for this to me much more than a toy, though I do plan to
try it in flight just to see how it works. When the time comes, I'll
get proper equipment.

Thanks again.

On 1/10/2016 1:43 PM, Darryl Ramm wrote:
> Dan
>
> The ADS-B ground station will be broadcasting ADS-R and TIS-B data for client aircraft that are near (i.e. within the ADS-B service "jockey puck" of +/- 3.500' and 15nm radius around the client aircraft). So it may not be, and does not need to be, client aircraft near *you*. Say a suitable equipped ADS-B Out aircraft was 1,000' directly overhead some other transponder only equipped traffic (within SSR coverage) on the other side of a mountain range, where all those aircraft are out of sight to you. The ADS-B ground you had line of site to the ADS-B ground tower covering that airspace you would still see those ground broadcasts intended really for he client aircraft on the other side of the range.
>
> That's again points to the basic irony looking at TIS-B and ADS-R transmissions, they are made for client aircraft near the target, not necessarily near you. As the other target aircraft moves away from the client aircraft, maybe towards you. You stop seeing it on ADS-B. Oops. And in your case it is more likely than not won't be a ADS-B client aircraft near you that is causing what you see for a remote aircraft on the other side of a mountain, the client aircraft will be over on the other side, closer to the target.
>
> What you see at distances will depend on the signal strength and distance to the aircraft or ground station and you antenna setup. These small software defined radio modules are fun to play with but built at low cost and don't have the worlds best analog RF front ends. It would be fun to compare them to what is used in commercial portable devices. Part of the reason I'm not too excited about folks using these in their aircraft for more than experimenting/playing around. The antenna used and it's location/sky visibility will affect coverage as well. It could well be that you will see lots of distant aircraft via ADS-R and TIS-B but not ADS-B direct, because you can receive transmissions from the ground tower well but not those more distant aircraft even if you have line of site to them.
>
> I've mentioned in the past it is hard to try to reverse engineer overall what is going on, especially you cannot easily tell what is being broadcast for what client aircraft. However it should be relatively easy to technically tell if you are receiving data for a TIS-B target. That information is included in the air broadcast messages and fully exposed in the de-facto standard GDL-90 serial communications these portable (hobby and commercial) ADS-B receivers are using.
>
> The GDL9-90 communication protocol is documented and publicly available. e.g. here https://www.faa.gov/nextgen/programs/adsb/wsa/media/GDL90_Public_ICD_RevA.PDF. (that one is old, I'd imagine there may be more recent updates even of he GDL90 has long ago stopped being interesting).
>
> The first question I would have is how much of the GDL-90 protocol does and receiver software really implement and does it software correctly send out the target type field data. I've not played with it so I don't know, hopefully it does. Reading the source code should also make that clear.
>
> So even if most commercial traffic display software won't show on the display what type an ADS-B target is it is possible for somebody a little technical to look at this stuff and tell. Easy for example to just grab the GDL-90 serial steam and process it with a text utility. The software Dan is using does logging and I suspect this is all in those log files or can be turned on, but I've not looked.
>
> it is also clear over the air what a ADS-R or ADS-B direct messages are. If that is simply exposed in the traffic stream form any of these devices should be easy to work out for technical folks.. again just by reading the source code.
>
> Hope that helps.
>
>
>
>
>
>
>
>
>
> On Sunday, January 10, 2016 at 11:09:02 AM UTC-8, Dan Marotta wrote:
>> Hopefully Darryl will respond to this but anyone with the knowledge
>> will be appreciated.
>>
>>
>>
>> I have a home-grown ADS-B system consisting of a Raspberry Pi 2 and
>> a couple of software defined radios feeding Avare on my smart
>> phone. I have line of sight to the ADS-B tower on top of Sandia
>> Peak, on the east side of Albuquerque. I see a number of 1090ES
>> targets around the ABQ area, one at 10,400PA', one at 8,200PA' over
>> SAF, several in the high 30s to low 40s pressure altitude. But I
>> don't see any targets very far away from Albuquerque.
>>
>>
>>
>> Is it that only targets within some volume are being transmitted
>> through the tower within view or am I simply receiving the 1090ES
>> transmissions directly from the aircraft? I think this may be the
>> case as I don't see and aircraft on my display that I couldn't see
>> with binoculars from my house.
>>
>>
>>
>> When I first turned on the system I saw some aircraft that appeared
>> to be in the traffic pattern at ABQ and, from where I live on the
>> east side of the mountains, their transmissions would be blocked by
>> the mountains. I speculate that there was an ADS-B Out aircraft
>> flying relatively low near my house and I was receiving TIS-B
>> transmissions meant for him. I also saw ADS-B weather that day and
>> there were a lot of snow storms up and down the Rockies.
>>
>>
>> --
>>
>> Dan, 5J

--
Dan, 5J

[Darryl Ramm]

If you have a GDL-90 compatible text stream from stratusx out of curiosity can you email it to me. My gmail email as used here.

[Dan Marotta]

Email sent with attached file, out.bin. Not text, but that's what I got
when executing the save function on the Avare External I/O app on my phone.

good luck!

On 1/10/2016 2:13 PM, Darryl Ramm wrote:
> If you have a GDL-90 compatible text stream from stratusx out of curiosity can you email it to me. My gmail email as used here.

--
Dan, 5J

[SoaringXCellence]

On Sunday, January 10, 2016 at 12:44:03 PM UTC-8, Darryl Ramm wrote:
> Dan
>
> The ADS-B ground station will be broadcasting ADS-R and TIS-B data for client aircraft that are near (i.e. within the ADS-B service "jockey puck" of +/- 3.500' and 15nm radius around the client aircraft). So it may not be, and does not need to be, client aircraft near *you*. Say a suitable equipped ADS-B Out aircraft was 1,000' directly overhead some other transponder only equipped traffic (within SSR coverage) on the other side of a mountain range, where all those aircraft are out of sight to you. The ADS-B ground you had line of site to the ADS-B ground tower covering that airspace you would still see those ground broadcasts intended really for he client aircraft on the other side of the range.
>
> That's again points to the basic irony looking at TIS-B and ADS-R transmissions, they are made for client aircraft near the target, not necessarily near you. As the other target aircraft moves away from the client aircraft, maybe towards you. You stop seeing it on ADS-B. Oops. And in your case it is more likely than not won't be a ADS-B client aircraft near you that is causing what you see for a remote aircraft on the other side of a mountain, the client aircraft will be over on the other side, closer to the target.
>
> What you see at distances will depend on the signal strength and distance to the aircraft or ground station and you antenna setup. These small software defined radio modules are fun to play with but built at low cost and don't have the worlds best analog RF front ends. It would be fun to compare them to what is used in commercial portable devices. Part of the reason I'm not too excited about folks using these in their aircraft for more than experimenting/playing around. The antenna used and it's location/sky visibility will affect coverage as well. It could well be that you will see lots of distant aircraft via ADS-R and TIS-B but not ADS-B direct, because you can receive transmissions from the ground tower well but not those more distant aircraft even if you have line of site to them.
>
> I've mentioned in the past it is hard to try to reverse engineer overall what is going on, especially you cannot easily tell what is being broadcast for what client aircraft. However it should be relatively easy to technically tell if you are receiving data for a TIS-B target. That information is included in the air broadcast messages and fully exposed in the de-facto standard GDL-90 serial communications these portable (hobby and commercial) ADS-B receivers are using.
>
> The GDL9-90 communication protocol is documented and publicly available. e.g. here https://www.faa.gov/nextgen/programs/adsb/wsa/media/GDL90_Public_ICD_RevA.PDF. (that one is old, I'd imagine there may be more recent updates even of he GDL90 has long ago stopped being interesting).
>
> The first question I would have is how much of the GDL-90 protocol does and receiver software really implement and does it software correctly send out the target type field data. I've not played with it so I don't know, hopefully it does. Reading the source code should also make that clear.
>
> So even if most commercial traffic display software won't show on the display what type an ADS-B target is it is possible for somebody a little technical to look at this stuff and tell. Easy for example to just grab the GDL-90 serial steam and process it with a text utility. The software Dan is using does logging and I suspect this is all in those log files or can be turned on, but I've not looked.
>
> it is also clear over the air what a ADS-R or ADS-B direct messages are. If that is simply exposed in the traffic stream form any of these devices should be easy to work out for technical folks.. again just by reading the source code.
>
> Hope that helps.
>
>
>
>
>
>
>
>
>
> On Sunday, January 10, 2016 at 11:09:02 AM UTC-8, Dan Marotta wrote:
> > Hopefully Darryl will respond to this but anyone with the knowledge
> > will be appreciated.
> >
> >
> >
> > I have a home-grown ADS-B system consisting of a Raspberry Pi 2 and
> > a couple of software defined radios feeding Avare on my smart
> > phone.* I have line of sight to the ADS-B tower on top of Sandia
> > Peak, on the east side of Albuquerque.* I see a number of 1090ES
> > targets around the ABQ area, one at 10,400PA', one at 8,200PA' over
> > SAF, several in the high 30s to low 40s pressure altitude.* But I
> > don't see any targets very far away from Albuquerque.
> >
> >
> >
> > Is it that only targets within some volume are being transmitted
> > through the tower within view or am I simply receiving the 1090ES
> > transmissions directly from the aircraft?* I think this may be the
> > case as I don't see and aircraft on my display that I couldn't see
> > with binoculars from my house.
> >
> >
> >
> > When I first turned on the system I saw some aircraft that appeared
> > to be in the traffic pattern at ABQ and, from where I live on the
> > east side of the mountains, their transmissions would be blocked by
> > the mountains.* I speculate that there was an ADS-B Out aircraft
> > flying relatively low near my house and I was receiving TIS-B
> > transmissions meant for him.* I also saw ADS-B weather that day and
> > there were a lot of snow storms up and down the Rockies.
> >
> >
> > --
> >
> > Dan, 5J

Darryl,

As always I appreciate your knowledge on this and I have a serious concern, based on what several of my programmer geek friends have noted after reading the TSO.

Here is the concern: The ADS-B protocols have no encryption/security protection! I.E. we have a "network" that easily hacked or spoofed, new pseudo-planes could be added to the network with scripted GPS/Altitude data, and no one would know. The whole system is based on the assumption that everyone is playing "nice" with the data.

It that what you understand? How secure is the network?

MB

[Darryl Ramm]

ADS-B is inherently not secure, a very bad mistake IMNSHO. Nothing is encrypted or cryptographically authenticated. Many technical folks, including experts on encryption etc. that I know also express extreme surprise with that. It is trivial to use to track aircraft which is good at times, but may be a security or physical attack risk, is easily spoofable with possibly bad consequences, including flooding/denial of service style attacks. And all that ground infrastructure, is potentially physically attackable.

That is one reason why it is good there is no way that ADS-B actually issues TCAS-II TYPE RAS (even if you have TCAS II version 7.1 with ADS-B enhancements). You could imagine what could happen with a malicious actor forcing aircraft TCAS systems to issue false RAs.

if its a low-level attack or some idiot just "messing around" then I expect the FAA to use technical means to mitigate some of the harm and to help track down the attackers. Obviously at on extreme they revert back to SSR, A serious technically sophisticated malicious attack, oh that sure worries me..

I do worry that FAA goals of eventually decommissioning a number of approach SSR systems as ADS-B is adopted is a dangerous fantasy. Proffered up by the FAA to congress to show how ADS-B would help save money. That SSR capability is needed as a complement and fallback to ADS-B in case bad things happen. The primary radar facilities are also needed so that somebody just can't turn off ADS-B Out and their transponder and cruise around with no radar coverage. The joint ARTCC/USAF ASRS-4 defense radar facilities are really impressive primary radars but you still want some backup with those local approach primary radars, even if they don't have capacities like the primary radar altitude capability that the big ARSR-4 systems have. How vulnerable that whole radar/SSR infrastructure is is another whole question.


On Sunday, January 10, 2016 at 3:28:06 PM UTC-8, SoaringXCellence wrote:
/snip/
> As always I appreciate your knowledge on this and I have a serious concern, based on what several of my programmer geek friends have noted after reading the TSO.
>
> Here is the concern: The ADS-B protocols have no encryption/security protection! I.E. we have a "network" that easily hacked or spoofed, new pseudo-planes could be added to the network with scripted GPS/Altitude data, and no one would know. The whole system is based on the assumption that everyone is playing "nice" with the data.
>
> It that what you understand? How secure is the network?
>
> MB

[SoaringXCellence]

On Sunday, January 10, 2016 at 6:58:27 PM UTC-8, Darryl Ramm wrote:
> ADS-B is inherently not secure, a very bad mistake IMNSHO. Nothing is encrypted or cryptographically authenticated. Many technical folks, including experts on encryption etc. that I know also express extreme surprise with that. It is trivial to use to track aircraft which is good at times, but may be a security or physical attack risk, is easily spoofable with possibly bad consequences, including flooding/denial of service style attacks. And all that ground infrastructure, is potentially physically attackable.
>
> That is one reason why it is good there is no way that ADS-B actually issues TCAS-II TYPE RAS (even if you have TCAS II version 7.1 with ADS-B enhancements). You could imagine what could happen with a malicious actor forcing aircraft TCAS systems to issue false RAs.
>
> if its a low-level attack or some idiot just "messing around" then I expect the FAA to use technical means to mitigate some of the harm and to help track down the attackers. Obviously at on extreme they revert back to SSR, A serious technically sophisticated malicious attack, oh that sure worries me.
>
> I do worry that FAA goals of eventually decommissioning a number of approach SSR systems as ADS-B is adopted is a dangerous fantasy. Proffered up by the FAA to congress to show how ADS-B would help save money. That SSR capability is needed as a complement and fallback to ADS-B in case bad things happen. The primary radar facilities are also needed so that somebody just can't turn off ADS-B Out and their transponder and cruise around with no radar coverage. The joint ARTCC/USAF ASRS-4 defense radar facilities are really impressive primary radars but you still want some backup with those local approach primary radars, even if they don't have capacities like the primary radar altitude capability that the big ARSR-4 systems have. How vulnerable that whole radar/SSR infrastructure is is another whole question.
>
>
> On Sunday, January 10, 2016 at 3:28:06 PM UTC-8, SoaringXCellence wrote:
> /snip/
> > As always I appreciate your knowledge on this and I have a serious concern, based on what several of my programmer geek friends have noted after reading the TSO.
> >
> > Here is the concern: The ADS-B protocols have no encryption/security protection! I.E. we have a "network" that easily hacked or spoofed, new pseudo-planes could be added to the network with scripted GPS/Altitude data, and no one would know. The whole system is based on the assumption that everyone is playing "nice" with the data.
> >
> > It that what you understand? How secure is the network?
> >
> > MB

Darryl,

Thanks for your reply, I fly almost every day in the ATC system of the US and I appreciate both the volume of traffic and the fragile nature of the human element in the ATC. I have yet to get what I believe was a truly dangerous clearance from a controller, but I've also had a few too-close encounters with VFR traffic while descending out of the clouds. ADS-B would sure be nice.

I can see a scenario where a malicious entity could fly into a busy area, engage a false data feed into the ADS-B out, spoofing a track in one direction while going altogether some place else. That's scarier that VFR traffic today.

Thanks again for your knowledgeable participation in these usegroups.

MB

[[email protected]]

Well that got technical right away. In general terms, would I be able to know about small aircraft with transponders, ie C172 etc, flying into the airport I fly? It's a class E airport, but near a class B airport so, most aircraft are transponder equipped. The device I am looking at is an ADS B - in, receiver, and I would send the information to my iPhone 6+ via wifi. It seems like most major areas now have ADS -B coverage and since I don't have to install an ADS-B out signal, yet. It seems like a solution to what I am looking for, which is some indication of another aircraft near me when my eyes did not pick him up.
Since I am not sending the "out" signal, would I not receive the transponder only traffic? Also since the "out" signal is not present, would the set up just report useless information to me and maybe even show my own glider as traffic?
The device I'm looking at is a TRX1000 from Air Avionics, used with iGlide software.
Thank you.

[Mike Schumann[_2_]]

On Wednesday, January 13, 2016 at 6:21:40 PM UTC-5, wrote:
> Well that got technical right away. In general terms, would I be able to know about small aircraft with transponders, ie C172 etc, flying into the airport I fly? It's a class E airport, but near a class B airport so, most aircraft are transponder equipped. The device I am looking at is an ADS B - in, receiver, and I would send the information to my iPhone 6+ via wifi. It seems like most major areas now have ADS -B coverage and since I don't have to install an ADS-B out signal, yet. It seems like a solution to what I am looking for, which is some indication of another aircraft near me when my eyes did not pick him up.
> Since I am not sending the "out" signal, would I not receive the transponder only traffic? Also since the "out" signal is not present, would the set up just report useless information to me and maybe even show my own glider as traffic?
> The device I'm looking at is a TRX1000 from Air Avionics, used with iGlide software.
> Thank you.

While you may see Transponder equipped aircraft transmitted via TIS-B by your local ADS-B ground station, this only happens if there is and ADS-B OUT equipped aircraft in the area. The ONLY way you can reliably expect to see all Transponder equipped aircraft in your vicinity is if your own aircraft is ADS-B OUT equipped.

Personally, I think that installing an ADS-B IN receiver without an ADS-B OUT transmitter is a really bad idea. It will have a tendency to make you falsely think that you are seeing all the traffic out there, which will inevitably breed a very dangerous form of complacency.

[Darryl Ramm]

On Wednesday, January 13, 2016 at 3:21:40 PM UTC-8, wrote:
> Well that got technical right away. In general terms, would I be able to know about small aircraft with transponders, ie C172 etc, flying into the airport I fly? It's a class E airport, but near a class B airport so, most aircraft are transponder equipped. The device I am looking at is an ADS B - in, receiver, and I would send the information to my iPhone 6+ via wifi. It seems like most major areas now have ADS -B coverage and since I don't have to install an ADS-B out signal, yet. It seems like a solution to what I am looking for, which is some indication of another aircraft near me when my eyes did not pick him up.
> Since I am not sending the "out" signal, would I not receive the transponder only traffic? Also since the "out" signal is not present, would the set up just report useless information to me and maybe even show my own glider as traffic?
> The device I'm looking at is a TRX1000 from Air Avionics, used with iGlide software.
> Thank you.

You are in the USA? Which local airport?

This really has been flogged to death in the past. have you tried looking up those past threads?

And any answer is going to be "technical". this stuff, especially in the USA, is a complex ball of string.

But the simple answer is if you are not outputting a *compliant* ADS-B Out signal, correctly configured to describe the aircraft's ADS-B In capability, the FAA ground infrastructure will not broadcast TIS-B data for your client aircraft. TIS-B is what lets you "see" transponder equipped traffic. So no ADS-B Out worrying about TIS-B is a non-starter.

Then even if you have all that, where exactly are you worrying about seeing such traffic? is that within both ADS-B ground coverage and SSR coverage? Don't assume, check - ask other local pilots who have ADS-B Out & In today.

TIS-B is a transitionary thing, and a bit of a mess. Over time as many aircraft equip with 1090ES our UAT Out then the ideal ADS-B receiver becomes a dual-link (1090ES and UAT In) device. That is the only thing that makes sense for stand-alone receivers in the USA GA market. And maybe there is some hope somebody will integrate a UAT receiver with PowerFLARM's internal 1090ES receiver. It's possible but would take somebody willing to d a lot for no chance of making money on it. of course if most aircraft just equip with 1090ES Out, they you just see them direct on a PowerFLARM. Totally whtotu reliance on ADS-B ground infrastructure.

I suspect the TRX1000 was never something intended for the USA market. Does it even support ADS-R and TIS-B as used in the USA? I'd be very careful assuming it was suitable for use here. Check with the manufacturer -- but unfortunately that same manufacturer has been giving some clueless answers about ADS-B questions to folks from the USA, which makes me think they don't understand much about the operation of ADS-B here.

I'm lost as to why anybody in the USA would look at an Air Avionic TRX1000 when the PowerFLARM is widely used and already has FLARM and 1090ES In (but (apparently) does not support TIS-B).

I guess my real answer to this is kind of unfortunately if you are having to ask questions like this,it is not the time for you really be playing with ADS-B. ADS-B right now is something for the geekier folks to play with. Everybody else in glider land in the USA either gets basic 1090ES In with their powerFLARM or should wait and see what happens with mandatory carriage and TABS regulations and new future products. But don't put off adopting a transponder if flying near busy airspace --and pick a good Mode S transponder (e.g. Trig TT-22) that will allow future 1090ES Out upgrades.

[kirk.stant]

Just to make it clear: PowerFLARM will not only show Flarm and 1090ES ADS-B traffic, but also all transponder- equipped aircraft (move C and S) as non-directional "threats" with altitude and approximate range (if being interrogated by SSR/ATC. So the short answer is: get a PowerFLARM, and back it up with a mode S transponder is you can.

Kirk
66

[Mike Schumann[_2_]]

On Wednesday, January 13, 2016 at 6:21:40 PM UTC-5, wrote:
> Well that got technical right away. In general terms, would I be able to know about small aircraft with transponders, ie C172 etc, flying into the airport I fly? It's a class E airport, but near a class B airport so, most aircraft are transponder equipped. The device I am looking at is an ADS B - in, receiver, and I would send the information to my iPhone 6+ via wifi. It seems like most major areas now have ADS -B coverage and since I don't have to install an ADS-B out signal, yet. It seems like a solution to what I am looking for, which is some indication of another aircraft near me when my eyes did not pick him up.
> Since I am not sending the "out" signal, would I not receive the transponder only traffic? Also since the "out" signal is not present, would the set up just report useless information to me and maybe even show my own glider as traffic?
> The device I'm looking at is a TRX1000 from Air Avionics, used with iGlide software.
> Thank you.
The TRX1000 is a completely useless piece of equipment for the US market. It's a 1090ES only receiver that doesn't support ADS-R or TIS-B, so you will never see any ADS-B UAT OUT equipped aircraft nor any transponder equipped aircraft, regardless of whether or not your own aircraft is ADS-B OUT equipped.

There are a number of reputable ADS-B receivers that are specifically designed for the US market that fully support ADS-R and TIS-B. A number of these are dual frequency, so they will directly see both UAT and 1090ES targets when you are not within range of an ADS-B ground station and/or are not ADS-B OUT equipped. That is the way to go.

The big question is whether iGlide will support any of these receivers. For the time being, you may have to use GA focused solutions like Foreflight for an ADS-B based collision avoidance system for use with these receivers.

[[email protected]]

In defense of Air Avionics, I just received an email from them today saying the TRX1000 would not do what I was looking for. I'll call a local avionics shop (recommended by my FSDO), and ask about a transponder/flarm solution.

[kirk.stant]

On Thursday, January 14, 2016 at 6:46:52 AM UTC-6, Mike Schumann wrote:

> There are a number of reputable ADS-B receivers that are specifically designed for the US market that fully support ADS-R and TIS-B. A number of these are dual frequency, so they will directly see both UAT and 1090ES targets when you are not within range of an ADS-B ground station and/or are not ADS-B OUT equipped. That is the way to go.
>

Mike, you are leaving out the critical fact that without ADS-B OUT in YOUR plane, you do NOT "directly see both UAT and 1090ES targets...". Just having a cheap dual freq (UAT and 1090) ADS-B receiver will NOT show you UAT traffic around you unless there is an ADS_B OUT equipped plane nearby, and will NOT show you current transponder-only equipped traffic. IT IS NOT "THE WAY TO GO" UNLESS YOU HAVE ADS-B OUT!!!! (yes I'm shouting ;^)!

Without ADS-B out the ONLY complete traffic awareness solution at present is PowerFLARM + Mode S xponder. Period.

> The big question is whether iGlide will support any of these receivers. For the time being, you may have to use GA focused solutions like Foreflight for an ADS-B based collision avoidance system for use with these receivers.

ARRRGGHH.... In a glider? Really?

Kirk
66

[Darryl Ramm]

Especially if your glider is certified I would be finding/calling a glider A&P who has done FLARM and a Transponder installs before. And look over any Transponder install documentation that may exist from your glider manufacturer. That is usually much better than trying to deal with an avionics shop.. Very few of those folks would know what a PowerFLARM is if it bit them on the ass.

[Dan Marotta]

Yesterday I took my home assembled (by someone else) ADS-B In thingy for
a ride in my Pipistrel Sinus within a 10-mile radius of Moriarty, NM.
Using Avare as my display software and my Android phone as the display
device (temporarily), I was very pleased with the traffic displayed.

I currently have the system set to display all traffic out to 100,000' -
I don't know if that's vertical, horizontal, or both, but I did see a
lot of airliners coming and going from ABQ or simply passing overhead in
the high 30s and low 40s. I also saw quite a bit of traffic down low in
the traffic patterns of airports along the Rio Grande (Mid Valley (E98),
Albuquerque (ABQ), Double Eagle II (AEG), and Santa Fe (SAF)). All of
the airports except for SAF were below my radio horizon so I surmise I
received their position, altitude, and direction via a ground station.
I also saw one aircraft southeast of Moriarty at 11,850' PA. I was
about 10 miles horizontally and 1,350' lower than him.

Arriving at the airport yesterday, I could not find my two rolls of Dual
Lock fasteners so I had to make do with duct taping everything to the
top of the glare shield (it's an experimental aircraft and the
components are light weight). I had heard that the system would create
a lot of electrical noise which could interfere with the comm radio, but
I found it to be completely "quiet".

Now, if it would only display targets on XCSoar so I wouldn't have to
switch screens... Note: This is currently simply an experiment and,
this time of year, there is little to no traffic where I'm flying.

I haven't yet figured out how to capture the data stream from the
receiver to see what I can learn from it.

On 1/10/2016 1:59 PM, Dan Marotta wrote:
> Very helpful, thanks!
>
> So far I've only looked at the data stream being sent to the Avare
> application. It's a text stream which includes aircraft call sign (if
> avaliable, e.g., UAL178), the ICAO address, lat, lon, and altitude.
> I'd look at the source code, but my eyes get bleary pretty quickly.
>
> I don't intend for this to me much more than a toy, though I do plan
> to try it in flight just to see how it works. When the time comes,
> I'll get proper equipment.
>
> Thanks again.
>
> On 1/10/2016 1:43 PM, Darryl Ramm wrote:
>> Dan
>>
>> The ADS-B ground station will be broadcasting ADS-R and TIS-B data for client aircraft that are near (i.e. within the ADS-B service "jockey puck" of +/- 3.500' and 15nm radius around the client aircraft). So it may not be, and does not need to be, client aircraft near *you*. Say a suitable equipped ADS-B Out aircraft was 1,000' directly overhead some other transponder only equipped traffic (within SSR coverage) on the other side of a mountain range, where all those aircraft are out of sight to you. The ADS-B ground you had line of site to the ADS-B ground tower covering that airspace you would still see those ground broadcasts intended really for he client aircraft on the other side of the range.
>>
>> That's again points to the basic irony looking at TIS-B and ADS-R transmissions, they are made for client aircraft near the target, not necessarily near you. As the other target aircraft moves away from the client aircraft, maybe towards you. You stop seeing it on ADS-B. Oops. And in your case it is more likely than not won't be a ADS-B client aircraft near you that is causing what you see for a remote aircraft on the other side of a mountain, the client aircraft will be over on the other side, closer to the target.
>>
>> What you see at distances will depend on the signal strength and distance to the aircraft or ground station and you antenna setup. These small software defined radio modules are fun to play with but built at low cost and don't have the worlds best analog RF front ends. It would be fun to compare them to what is used in commercial portable devices. Part of the reason I'm not too excited about folks using these in their aircraft for more than experimenting/playing around. The antenna used and it's location/sky visibility will affect coverage as well. It could well be that you will see lots of distant aircraft via ADS-R and TIS-B but not ADS-B direct, because you can receive transmissions from the ground tower well but not those more distant aircraft even if you have line of site to them.
>>
>> I've mentioned in the past it is hard to try to reverse engineer overall what is going on, especially you cannot easily tell what is being broadcast for what client aircraft. However it should be relatively easy to technically tell if you are receiving data for a TIS-B target. That information is included in the air broadcast messages and fully exposed in the de-facto standard GDL-90 serial communications these portable (hobby and commercial) ADS-B receivers are using.
>>
>> The GDL9-90 communication protocol is documented and publicly available. e.g. herehttps://www.faa.gov/nextgen/programs/adsb/wsa/media/GDL90_Public_ICD_RevA.PDF. (that one is old, I'd imagine there may be more recent updates even of he GDL90 has long ago stopped being interesting).
>>
>> The first question I would have is how much of the GDL-90 protocol does and receiver software really implement and does it software correctly send out the target type field data. I've not played with it so I don't know, hopefully it does. Reading the source code should also make that clear.
>>
>> So even if most commercial traffic display software won't show on the display what type an ADS-B target is it is possible for somebody a little technical to look at this stuff and tell. Easy for example to just grab the GDL-90 serial steam and process it with a text utility. The software Dan is using does logging and I suspect this is all in those log files or can be turned on, but I've not looked.
>>
>> it is also clear over the air what a ADS-R or ADS-B direct messages are. If that is simply exposed in the traffic stream form any of these devices should be easy to work out for technical folks.. again just by reading the source code.
>>
>> Hope that helps.
>>
>>
>>
>>
>>
>>
>>
>>
>>
>> On Sunday, January 10, 2016 at 11:09:02 AM UTC-8, Dan Marotta wrote:
>>> Hopefully Darryl will respond to this but anyone with the knowledge
>>> will be appreciated.
>>>
>>>
>>>
>>> I have a home-grown ADS-B system consisting of a Raspberry Pi 2 and
>>> a couple of software defined radios feeding Avare on my smart
>>> phone. I have line of sight to the ADS-B tower on top of Sandia
>>> Peak, on the east side of Albuquerque. I see a number of 1090ES
>>> targets around the ABQ area, one at 10,400PA', one at 8,200PA' over
>>> SAF, several in the high 30s to low 40s pressure altitude. But I
>>> don't see any targets very far away from Albuquerque.
>>>
>>>
>>>
>>> Is it that only targets within some volume are being transmitted
>>> through the tower within view or am I simply receiving the 1090ES
>>> transmissions directly from the aircraft? I think this may be the
>>> case as I don't see and aircraft on my display that I couldn't see
>>> with binoculars from my house.
>>>
>>>
>>>
>>> When I first turned on the system I saw some aircraft that appeared
>>> to be in the traffic pattern at ABQ and, from where I live on the
>>> east side of the mountains, their transmissions would be blocked by
>>> the mountains. I speculate that there was an ADS-B Out aircraft
>>> flying relatively low near my house and I was receiving TIS-B
>>> transmissions meant for him. I also saw ADS-B weather that day and
>>> there were a lot of snow storms up and down the Rockies.
>>>
>>>
>>> --
>>>
>>> Dan, 5J
>
> --
> Dan, 5J

--
Dan, 5J

[Dan Marotta]

I have to disagree with you, Kirk since you said "ONLY" and "Period".
That leaves no room for discussion.

"Without ADS-B out the ONLY complete traffic awareness solution at
present is PowerFLARM + Mode S xponder. Period."

Those are ONLY your OPINIONS, and those of a lot of others, but not
those of everyone. I have a Mode S transponder (TT-22) and an MRX PCAS
and I look outside. My electronics "see" the same aircraft as you do
assuming installed transponders and radar coverage which is pretty
complete where I fly. So what if I don't have 360 degree display of the
aircraft around me. It's not a difficult matter to make note of mileage
and delta altitude upon receiving an alert and taking another glance
several seconds later and deciding if the aircraft is closing or
separating from me. There are no worries about "pop up" alerts since I
receive the alerts continuously. It can get pretty annoying while
thermalling!

The only aircraft that has concerned me is that one which had PowerFlarm
installed but no transponder! Now why would anyone do that when he was
possibly invisible to ATC and definitely invisible to non Flarm equipped
aircraft (which includes a lot of airliners overflying Moriarty at 12-14
thousand feet) unless I saw him by looking outside?

As you and I are equipped, we have an equal chance of "seeing" each
other electronically out to the configured ranges of our respective
systems. The price of ADS-B (Out and In) is coming down (especially for
Experimental aircraft). I think I will be able to survive without Flarm
until I decide on which ADS-B system I will install.

On 1/14/2016 9:05 AM, kirk.stant wrote:
> On Thursday, January 14, 2016 at 6:46:52 AM UTC-6, Mike Schumann wrote:
>
>> There are a number of reputable ADS-B receivers that are specifically designed for the US market that fully support ADS-R and TIS-B. A number of these are dual frequency, so they will directly see both UAT and 1090ES targets when you are not within range of an ADS-B ground station and/or are not ADS-B OUT equipped. That is the way to go.
>>
> Mike, you are leaving out the critical fact that without ADS-B OUT in YOUR plane, you do NOT "directly see both UAT and 1090ES targets...". Just having a cheap dual freq (UAT and 1090) ADS-B receiver will NOT show you UAT traffic around you unless there is an ADS_B OUT equipped plane nearby, and will NOT show you current transponder-only equipped traffic. IT IS NOT "THE WAY TO GO" UNLESS YOU HAVE ADS-B OUT!!!! (yes I'm shouting ;^)!
>
> Without ADS-B out the ONLY complete traffic awareness solution at present is PowerFLARM + Mode S xponder. Period.
>
>> The big question is whether iGlide will support any of these receivers. For the time being, you may have to use GA focused solutions like Foreflight for an ADS-B based collision avoidance system for use with these receivers.
> ARRRGGHH.... In a glider? Really?
>
> Kirk
> 66
>

--
Dan, 5J

[Jonathan St. Cloud]

On Thursday, January 14, 2016 at 6:23:28 AM UTC-8, wrote:
> In defense of Air Avionics, I just received an email from them today saying the TRX1000 would not do what I was looking for. I'll call a local avionics shop (recommended by my FSDO), and ask about a transponder/flarm solution.

Well, I have gotten a mixed bag of information from Air-avionics. They had told me to connect the power flarm GPS to the VT-01 Mode S transponder and I would have a a working ADS-B out solution. This is not correct.

[xcnick]

On Thursday, January 14, 2016 at 8:50:31 AM UTC-8, Dan Marotta wrote:
>
> Now, if it would only display targets on XCSoar so I wouldn't have
> to switch screens...*

My first day with xcsoar. I am on page 16 of the manual and at the bottom is a reference to ADB input and I thought of your post. Post if you figure it out and I will too.

[Darryl Ramm]

On Thursday, January 14, 2016 at 3:16:36 PM UTC-8, xcnick wrote:
> On Thursday, January 14, 2016 at 8:50:31 AM UTC-8, Dan Marotta wrote:
> >
> > Now, if it would only display targets on XCSoar so I wouldn't have
> > to switch screens...*
>
> My first day with xcsoar. I am on page 16 of the manual and at the bottom is a reference to ADB input and I thought of your post. Post if you figure it out and I will too.

What is there to figure out? There is a very widely used defacto standard protocol for soaring software to receive traffic data. That is the FLARM dataport protocol. That is what XCSoar and all the other products use. If you are in the USA with XCSoar you get "ADS-B" traffic into XCSoar from a PowerFLARM. Connect it up and go... like hundreds of other glider pilots in the USA do with their soaring software or flight computers.

"ADS-B" is a fluffy term, what exactly you think it might mean I cannot guess. But in the case of PowerFLARM and the FLARM dataport protocol it means receiving and displaying traffic data from FLARM, 1090ES Out and PCAS. That is it. No UAT anything, No FIS-B, No TIS-B, No ADS-R, Nothing else of the USA specific soup that is not used elsewhere in the world. And like all other soaring software XCSoar supports the FLARM dataport protocol only, not GDL-90 or Garmin TIS or other formats so it does not work with GA ADS-B receivers. Its a soaring product, designed to work with soaring traffic systems.... i.e. in the USA that would be PowerFLARM.

[Mike Schumann[_2_]]

On Thursday, January 14, 2016 at 2:05:27 PM UTC-5, Vaughn Simon wrote:
> On 1/13/2016 7:41 PM, Mike Schumann wrote:
> > Personally, I think that installing an ADS-B IN receiver without an ADS-B OUT transmitter is a really bad idea.
>
> If you only consider traffic information, you have a defensible point.
> But an ADS-B receiver gives you more than that.
>
> I live in thunderstorm country, and carry an ADS-B receiver mainly for
> in cockpit weather depiction (FIS-B). Whatever traffic information I
> might incidentally receive is simply a bonus. My eyeballs and
> (secondarily) my PCAS are my main traffic-finding tools.
You are absolutely correct. An ADS-B UAT (not 1090ES) receiver will give you weather data, even if you do not have an ADS-B OUT transmitter. That is certainly worthwhile. I just want to remind people not to rely on the traffic data if they aren't ADS-B OUT equipped.

[xcnick]

On Thursday, January 14, 2016 at 3:49:25 PM UTC-8, Darryl Ramm wrote:
>
> What is there to figure out?

I apologize for my ignorance. When I rent a power plane I use a phone with a USB thing plugged in. Avare shows some traffic and weather as I fly across a sectional. I was just hoping the USB thing could also show this in xcsoar as I fly across its map. I thought that was what Dan was working towards.. Sorry I don't have a flarm.

[Darryl Ramm]

On Thursday, January 14, 2016 at 5:15:55 PM UTC-8, xcnick wrote:
> On Thursday, January 14, 2016 at 3:49:25 PM UTC-8, Darryl Ramm wrote:
> >
> > What is there to figure out?
>
> I apologize for my ignorance. When I rent a power plane I use a phone with a USB thing plugged in. Avare shows some traffic and weather as I fly across a sectional. I was just hoping the USB thing could also show this in xcsoar as I fly across its map. I thought that was what Dan was working towards. Sorry I don't have a flarm.

You do that in a glider today exactly how you work in a powered aircraft. Same ADS-B hardware, same clients etc. Soaring software does not speak to them.

In your GA airplane unless you have (properly set up) ADS-B Out here is no system that will reliably show you all the traffic data available. If you are using ADS-B In in a power aircraft I hope you have properly set up ADS-B Out, or at a minimum dual-link ADS-B In. I hope it is properly configured, and you know that it was set up to trigger the right ASB-B ground services for whatever receiver you were using -- if you are rolling up to a rental aircraft with basic ADS-B Out it possibly is not properly configured to work with whatever portable receiver you bring along. I expect we will have GA pilots die in mid-airs thinking their ADS-B toys are working when they are not.

It is really simple. If you fly a glider get a PowerFLARM and/or transponder (your choice what is more important). Anything else beyond that is for geeks to play with today. A raspberry pi based receiver likely no place in any cockpit besides playing around. And even then if you want say FIS-B data go get a real Stratus receiver and use your favorite GA app to see that data. You will need to work out where you mount all that stuff in the cockpit.. I'm not sure the hassle is worth it to most glider pilots, I think I used XM Weather on my Garmin 496 in anger once in my glider. If you want full fancy ADS-B everything in a glider then you need ADS-B out, which might cost you over $5k today (for a certified glider). And again, if you are having to ask lots of questions, this bleeding edge stuff is not for you, lots of things are likely to change if ADS-B Out and/or TABS is mandated for gliders. Just wait and see.

[smfidler]

This conversation reminds me of one of my favorite movies...

"Common.......learn god dammit, learn!"

http://youtu.be/NHWjlCaIrQo

[Dan Marotta]

But there's one minor point of contention in your reply, Darryl. I
don't have Flarm.

My XCSoar runs on a Dell Streak 5. XCSoar is supposed to display
targets from Flarm (which I don't have) following the Flarm dataport
protocol. I can run Avare on my Streak but, to display traffic from my
ADS-B In receiver (open source stuff) I need to also use the Avare
External I/O Plugin which is not compatible with the Streak 5 due to its
old version of Android.

As I have said continually since starting this thread, this is an
experiment for me. Play time, that's all. I could use my Nexus 7 which
will run both XCSoar and Avare (with the plugin), but it's pretty big
and my available space in the LAK is pretty small.

Now if I could just get XCSoar and Avare to run simultaneously with a
split screen, I'd suck it up and mount the Nexus 7. Hmmmmm.... This
looks like a new challenge! I'll report back if I have any success.

Good flying!

Dan

On 1/14/2016 4:49 PM, Darryl Ramm wrote:
> On Thursday, January 14, 2016 at 3:16:36 PM UTC-8, xcnick wrote:
>> On Thursday, January 14, 2016 at 8:50:31 AM UTC-8, Dan Marotta wrote:
>>> Now, if it would only display targets on XCSoar so I wouldn't have
>>> to switch screens...
>> My first day with xcsoar. I am on page 16 of the manual and at the bottom is a reference to ADB input and I thought of your post. Post if you figure it out and I will too.
> What is there to figure out? There is a very widely used defacto standard protocol for soaring software to receive traffic data. That is the FLARM dataport protocol. That is what XCSoar and all the other products use. If you are in the USA with XCSoar you get "ADS-B" traffic into XCSoar from a PowerFLARM. Connect it up and go... like hundreds of other glider pilots in the USA do with their soaring software or flight computers.
>
> "ADS-B" is a fluffy term, what exactly you think it might mean I cannot guess. But in the case of PowerFLARM and the FLARM dataport protocol it means receiving and displaying traffic data from FLARM, 1090ES Out and PCAS. That is it. No UAT anything, No FIS-B, No TIS-B, No ADS-R, Nothing else of the USA specific soup that is not used elsewhere in the world. And like all other soaring software XCSoar supports the FLARM dataport protocol only, not GDL-90 or Garmin TIS or other formats so it does not work with GA ADS-B receivers. Its a soaring product, designed to work with soaring traffic systems... i.e. in the USA that would be PowerFLARM.
>

--
Dan, 5J

[Dan Marotta]

I'm trying, Nick, but for me this is a game so don't expect miracles.

On 1/14/2016 6:15 PM, xcnick wrote:
> On Thursday, January 14, 2016 at 3:49:25 PM UTC-8, Darryl Ramm wrote:
>> What is there to figure out?
> I apologize for my ignorance. When I rent a power plane I use a phone with a USB thing plugged in. Avare shows some traffic and weather as I fly across a sectional. I was just hoping the USB thing could also show this in xcsoar as I fly across its map. I thought that was what Dan was working towards. Sorry I don't have a flarm.

--
Dan, 5J

[xcnick]

Thanks for sharing Dan.

I have the two programs running on a Galaxy S4 and neither AVare or xcsoar appear to support split screen.

It is just one question. No, or buy this and do this. So far switching back and forth is all I can do.

As far as opinions go I do agree that seeing only some traffic and thinking you are seeing it all is very dangerous.

[kirk.stant]

Dan, now you just have to figure out how to get the traffic data from your MRX into XCsoar!

(Or cheat and get a PF�😄)

Good luck, let us know how it works!

Kirk
66

[Darryl Ramm]

On Friday, January 15, 2016 at 8:20:51 AM UTC-8, Dan Marotta wrote:
> But there's one minor point of contention in your reply, Darryl.* I
> don't have Flarm.
>
/snip/
> Dan, 5J

Everybody here is well aware you don't have PowerFLARM, you seem to have some objection to it that I've never been able to follow logically.

But you are playing around with an ADS-B SDR toy, and learning about ADS-B, and some of the discussion shows you are learning about the ground-based services that you misunderstood until now. And you'll get a good feel for the carriage and coverage in your area (although a better receiver may give you more range and reliable reception). And that is all seriously great, you will know way more than most pilots about ASD-B. I totally encourage anybody interested to get something like this and set it up and play with it (mostly on the ground) to learn about ADS-B. Preferably with a dual-link receiver.

But when it comes to using an actual "ADS-B" In device in an aircraft, for actual in-flight use, other folks need to be clear in their minds about what exactly "ADS-B" means, what they will/won't receive and why they require ADS-B Out to get full ADS-B services.

The simple answer as always remains USA glider pilots interested in traffic avoidance technology should get a PowerFLARM or transponder or both (choice based on where they fly/what traffic they fly most with). Ideally a Mode S transponder that supports 1090ES or in future, e.g. a Trig TT-22. Everything beyond that for now is more for geeks who want to play around with stuff. And lots of things are likely to change with possible loss of carriage exemptions or TABS regulation... including more affordable/better ADS-B solutions, so for most folks just wait vs. trying too far down the ADS-B path.... but install a transponder or PowerFLARM now as appropriate.

[Mike Schumann[_2_]]

On Friday, January 15, 2016 at 12:28:44 PM UTC-5, Darryl Ramm wrote:
> On Friday, January 15, 2016 at 8:20:51 AM UTC-8, Dan Marotta wrote:
> > But there's one minor point of contention in your reply, Darryl.* I
> > don't have Flarm.
> >
> /snip/
> > Dan, 5J
>
> Everybody here is well aware you don't have PowerFLARM, you seem to have some objection to it that I've never been able to follow logically.
>
> But you are playing around with an ADS-B SDR toy, and learning about ADS-B, and some of the discussion shows you are learning about the ground-based services that you misunderstood until now. And you'll get a good feel for the carriage and coverage in your area (although a better receiver may give you more range and reliable reception). And that is all seriously great, you will know way more than most pilots about ASD-B. I totally encourage anybody interested to get something like this and set it up and play with it (mostly on the ground) to learn about ADS-B. Preferably with a dual-link receiver.
>
> But when it comes to using an actual "ADS-B" In device in an aircraft, for actual in-flight use, other folks need to be clear in their minds about what exactly "ADS-B" means, what they will/won't receive and why they require ADS-B Out to get full ADS-B services.
>
> The simple answer as always remains USA glider pilots interested in traffic avoidance technology should get a PowerFLARM or transponder or both (choice based on where they fly/what traffic they fly most with). Ideally a Mode S transponder that supports 1090ES or in future, e.g. a Trig TT-22. Everything beyond that for now is more for geeks who want to play around with stuff. And lots of things are likely to change with possible loss of carriage exemptions or TABS regulation... including more affordable/better ADS-B solutions, so for most folks just wait vs. trying too far down the ADS-B path.... but install a transponder or PowerFLARM now as appropriate.

The reason people aren't lining up to buy PowerFlarms is because it is a half-baked Europe centric solution that doesn't take into account the unique ADS-B situation in the US. If PowerFlarm supported TIS-B and ADS-R, which all ADS-B receivers in the US should implement, this would be a different story.

As of two days ago, Dynon has started shipping their 2020 compliant GPS position source. This module costs $590 and is a good indicator of other products that soon will be available. I think that by Oshkosh you will see Trig introduce a similarly priced GPS source that works with the Trig 22 transponder. With that, an ADS-B receiver designed for the US market, and an smart phone app, and you'll have a decent state of the art collision avoidance system that will show you every ADS-B and transponder equipped aircraft in your area. That's the kind of functionality than can get people interested in pulling the trigger and making this kind of investment.

[smfidler]

The US rules committee, and their puppet masters (otherwise known as the "SSA anti-technology oligarchy"), still won't allow smartphones to be "used" in our gliders during contests. Weather apps or even situational awareness beyond roughly 30 seconds with PowerFlarm (non-stealth/competition mode) is currently scheduled to become illegal.

Only recently did the USRC even allow the smartphone back in the cockpit at all, but only under strict orders never to use it! This even though most US pilots probably use a smartphone-based navigation app such as XC soar, iGlide or other similar. This whole thing is starting to get irritating.

They use words like "weak-assed." They use words like "tradition." They use phrases like "the spirit of soaring..."

This is the problem. Our anti-tech oligarchies "feelings" on the subject of new technology. This oligarchy are a relative few among us. Most of us dont care about weather, ADSB and smartphones. Some find it cool, and fun. Yet they drag us against the rising tide requiring tremendous effort to hold any ground.

I certainly have a good working knowledge of most of these new technologies.. I rarely if ever have a need to bother with them. Again, the typical max range is 3 miles and I have a solid antenna installation in my glider. I honestly believe that trying to fly a task based on cellular or ADSB weather is going to be a very rare occurrence. And it also has a safety benefit.. This seems to almost always be disregarded.

The problem IS NOT the natural progression of cost effective, relevant flight "data" and situational awareness & anti-collision technology. The problem is the feelings of a relative few.

And it's taking 10x the effort to prevent these technologies from entering the glider cockpit than will ever be gained from it. Particularly in the US contest environment.

In fact, if any of the oligarchs spent 1/4 the time studying ADSB as they do trying to promote stealth mode Flarm and demonize those who like PowerFlarm as it is, they would probably already be more proficient than most of us..

[Darryl Ramm]

On Friday, January 15, 2016 at 11:16:40 AM UTC-8, Mike Schumann wrote:
> On Friday, January 15, 2016 at 12:28:44 PM UTC-5, Darryl Ramm wrote:
> > On Friday, January 15, 2016 at 8:20:51 AM UTC-8, Dan Marotta wrote:
> > > But there's one minor point of contention in your reply, Darryl.* I
> > > don't have Flarm.
> > >
> > /snip/
> > > Dan, 5J
> >
> > Everybody here is well aware you don't have PowerFLARM, you seem to have some objection to it that I've never been able to follow logically.
> >
> > But you are playing around with an ADS-B SDR toy, and learning about ADS-B, and some of the discussion shows you are learning about the ground-based services that you misunderstood until now. And you'll get a good feel for the carriage and coverage in your area (although a better receiver may give you more range and reliable reception). And that is all seriously great, you will know way more than most pilots about ASD-B. I totally encourage anybody interested to get something like this and set it up and play with it (mostly on the ground) to learn about ADS-B. Preferably with a dual-link receiver.
> >
> > But when it comes to using an actual "ADS-B" In device in an aircraft, for actual in-flight use, other folks need to be clear in their minds about what exactly "ADS-B" means, what they will/won't receive and why they require ADS-B Out to get full ADS-B services.
> >
> > The simple answer as always remains USA glider pilots interested in traffic avoidance technology should get a PowerFLARM or transponder or both (choice based on where they fly/what traffic they fly most with). Ideally a Mode S transponder that supports 1090ES or in future, e.g. a Trig TT-22. Everything beyond that for now is more for geeks who want to play around with stuff. And lots of things are likely to change with possible loss of carriage exemptions or TABS regulation... including more affordable/better ADS-B solutions, so for most folks just wait vs. trying too far down the ADS-B path... but install a transponder or PowerFLARM now as appropriate.
>
> The reason people aren't lining up to buy PowerFlarms is because it is a half-baked Europe centric solution that doesn't take into account the unique ADS-B situation in the US. If PowerFlarm supported TIS-B and ADS-R, which all ADS-B receivers in the US should implement, this would be a different story.
>

Yes a half-baked solution that happens to include FLARM, designed for gliders, and totally dominates the worldwide glider traffic awareness market, for very good reasons. Too bad it is not absolutely perfect, how dare people adopt stuff that is not perfect. PowerFLARM, is just out there working in the real-world actually helping glider pilots actually avoid collisions.

Again I can't understand what bubble you fly in, but PowerFLARM is pretty well adopted in the USA gliding fleet for those follks who really care about glider-glider and glider-towplane scenarios. You apparently fly at some magical glider club where that is not enough of a concern to adopt PowerFLARM.. And where apparently nothing that is actually useful (PowerFLARM and/or transponders) is OK to adopt, and its better to keep dreaming about what could/will be...

Whatever mid-air collision risks you club does have it is apparently worth spending years going on and on about UAT silliness. But it is good to finally see you letting go of UAT. You don't actually own a glider do you? Have you ever owned a glider? What of all this stuff was it equipped with? Transponder? PCAS? ADS-B In? PowerFLARM? What exactly? With what traffic display? With your often-stated concerns about busy nearby GA traffic I hope your club gliders are transponder equipped. Are they? It is the Minnesota Soaring Club right? And it operates at the edge and presumably underneath busy Minneapolis Class B airspace right? With a victor airway running right over the top of the club airport.

And for those still playing along at home, no nothing that relies on TIS-B will "show you every ADS-B and transponder equipped aircraft". TIS-B requires both ADS-B ground station and more probably more of an issue SSR Radar coverage, which is uh not surprisingly lacking at many glider ports and smaller airports, especially near traffic pattern altitudes where traffic is converging, and where we have seen fatal mid-air collisions involving glider and towplanes within the last several years. One benefit of the PCAS coverage in PowerFLARM is you at least get some warning of nearby transponder equipped aircraft as long as their transponders are being interrogated, and in many locations TCAS and TCAD interrogators fill in that where ground based SSR will not reach the aircraft. Would TIS-B be a nice complement, yes sure, but wanting is not having. And in the real world we have to do what we can.

So while we are on this, what are the SSR and ADS-B minimum coverage altitudes over the Minnesota Soaring Club/Stanton Field? Got ADS-B ground service down to pattern altitude? How low exactly? SSR TIS-B service coverage to how low? Who knows you might be lucky, Stanton Field is roughly equidistant from the ADS-B towers at Minnesota International and Dodge City Airport, and ~30nm or so from the ASR at Minnesota International, or maybe there is TIS-B integration out of the ASR at Rochester International. I hope there have been lots of discussions between the club and the Minnesota TRACON folks about how good or bad primary radar coverage is near Stanton Field. But even more I'd hope you actually have flown a ADS-B system and tested out TIS-B coverage in the area. Still that does not mean other folks at other locations have useful TIS-B coverage, even if their gliders were properly equipped with ADS-B Out and In.

God I hope there is never a midair collision with a GA or larger aircraft involving a glider from your club not equipped with a transponder, obviously not for the risk to life and injury, but a liability lawyer will likely have a field-day going though your posts on DUC.

[Charlie M. (UH & 002 owner/pilot)]

On Friday, January 15, 2016 at 3:41:07 PM UTC-5, smfidler wrote:
> The US rules committee, and their puppet masters (otherwise known as the "SSA anti-technology oligarchy"), still won't allow smartphones to be "used" in our gliders during contests. Weather apps or even situational awareness beyond roughly 30 seconds with PowerFlarm (non-stealth/competition mode) is currently scheduled to become illegal.
>
> Only recently did the USRC even allow the smartphone back in the cockpit at all, but only under strict orders never to use it! This even though most US pilots probably use a smartphone-based navigation app such as XC soar, iGlide or other similar. This whole thing is starting to get irritating.
>
> They use words like "weak-assed." They use words like "tradition." They use phrases like "the spirit of soaring..."
>
> This is the problem. Our anti-tech oligarchies "feelings" on the subject of new technology. This oligarchy are a relative few among us. Most of us dont care about weather, ADSB and smartphones. Some find it cool, and fun. Yet they drag us against the rising tide requiring tremendous effort to hold any ground.
>
> I certainly have a good working knowledge of most of these new technologies. I rarely if ever have a need to bother with them. Again, the typical max range is 3 miles and I have a solid antenna installation in my glider. I honestly believe that trying to fly a task based on cellular or ADSB weather is going to be a very rare occurrence. And it also has a safety benefit. This seems to almost always be disregarded.
>
> The problem IS NOT the natural progression of cost effective, relevant flight "data" and situational awareness & anti-collision technology. The problem is the feelings of a relative few.
>
> And it's taking 10x the effort to prevent these technologies from entering the glider cockpit than will ever be gained from it. Particularly in the US contest environment.
>
> In fact, if any of the oligarchs spent 1/4 the time studying ADSB as they do trying to promote stealth mode Flarm and demonize those who like PowerFlarm as it is, they would probably already be more proficient than most of us.

OK, I've been trying to NOT add this (under some advisement of quite a few withing the US soaring community..... but here goes.....), some of the "cellphone issues" are NOT SSA RC OR US FAA issues, they are (yet another entity) FCC rules.
The FCC (which looks over COMMUNICATIONS, NOT flying) has an issue with "swamping CELL systems" when "at altitude". They are also sorta concerned (FAA more so) with corrupting other electronic devices with emitted radio waves..
"In general", it has been agreed that the chance (note: "CHANCE", regardless of the "Mythbusters testing"......) of an electronic device corrupting an AIRCRAFT device (notably navigation) is low, it's still there.
The FCC & the FAA has sorta agreed that high flying COMMERCIAL flights can use a picocell to connect travelers to a "landline", but they are out of range to swamp the ground based cell system.
What about glider pilots?
We are MORE LIKELY to be within range of multiple cell towers, thus the FCC concern.
BTW, the FCC (in the US) is a FEDERAL agency.
You can do your own search on why the FCC has issues with cell usage in flight.

Frankly, I sorta see an issue with the SSA RC ALLOWING a cellphone within reach of a pilot during as flight.
Yes, you can use "airplane mode" and use your "smartphone" as a display, but a tracking program/app seems to go against what the FCC wants. You run the risk of creating a communications issue (on the ground) that concerns the FCC.

Will you get caught? Who the frig knows.

Do I want to get caught by a federal agency, not really.

So....... Sean F & others, "look beyond the box" (seems to be a favorite comment towards "luddites"), see if you are still safe and within the federal rules.

Don't like the federal rules (in the US), then go raise "heck" with your government rep's.

I personally think the SSA RC has opened the SSA, contest management & pilots to yet another potential "OMG" if they get caught.
Based on probability, getting caught violating a FCC rule is way more likely than having a midair because of a degradation of what Flarm (in whatever flavor) does.

Not "stirring the pot", just alerting BOTH sides on other things to consider....

BTW, "Have a nice day"...... ;-)

PS, yes, the FCC allows you (the PIC) to determine if using a cellphone creates another hazard in VFR flight..... sorta opens the door to litigation when someone is dead..... just to keep this sorta honest and limit the, "But I found this, so I'm correct" stuff.....

BTW, "Have a nice day"...... ;-) again....

[Mike Schumann[_2_]]

On Friday, January 15, 2016 at 4:57:00 PM UTC-5, Darryl Ramm wrote:
> On Friday, January 15, 2016 at 11:16:40 AM UTC-8, Mike Schumann wrote:
> > On Friday, January 15, 2016 at 12:28:44 PM UTC-5, Darryl Ramm wrote:
> > > On Friday, January 15, 2016 at 8:20:51 AM UTC-8, Dan Marotta wrote:
> > > > But there's one minor point of contention in your reply, Darryl.* I
> > > > don't have Flarm.
> > > >
> > > /snip/
> > > > Dan, 5J
> > >
> > > Everybody here is well aware you don't have PowerFLARM, you seem to have some objection to it that I've never been able to follow logically.
> > >
> > > But you are playing around with an ADS-B SDR toy, and learning about ADS-B, and some of the discussion shows you are learning about the ground-based services that you misunderstood until now. And you'll get a good feel for the carriage and coverage in your area (although a better receiver may give you more range and reliable reception). And that is all seriously great, you will know way more than most pilots about ASD-B. I totally encourage anybody interested to get something like this and set it up and play with it (mostly on the ground) to learn about ADS-B. Preferably with a dual-link receiver.
> > >
> > > But when it comes to using an actual "ADS-B" In device in an aircraft, for actual in-flight use, other folks need to be clear in their minds about what exactly "ADS-B" means, what they will/won't receive and why they require ADS-B Out to get full ADS-B services.
> > >
> > > The simple answer as always remains USA glider pilots interested in traffic avoidance technology should get a PowerFLARM or transponder or both (choice based on where they fly/what traffic they fly most with). Ideally a Mode S transponder that supports 1090ES or in future, e.g. a Trig TT-22. Everything beyond that for now is more for geeks who want to play around with stuff. And lots of things are likely to change with possible loss of carriage exemptions or TABS regulation... including more affordable/better ADS-B solutions, so for most folks just wait vs. trying too far down the ADS-B path... but install a transponder or PowerFLARM now as appropriate.
> >
> > The reason people aren't lining up to buy PowerFlarms is because it is a half-baked Europe centric solution that doesn't take into account the unique ADS-B situation in the US. If PowerFlarm supported TIS-B and ADS-R, which all ADS-B receivers in the US should implement, this would be a different story.
> >
>
> Yes a half-baked solution that happens to include FLARM, designed for gliders, and totally dominates the worldwide glider traffic awareness market, for very good reasons. Too bad it is not absolutely perfect, how dare people adopt stuff that is not perfect. PowerFLARM, is just out there working in the real-world actually helping glider pilots actually avoid collisions.
>
> Again I can't understand what bubble you fly in, but PowerFLARM is pretty well adopted in the USA gliding fleet for those follks who really care about glider-glider and glider-towplane scenarios. You apparently fly at some magical glider club where that is not enough of a concern to adopt PowerFLARM. And where apparently nothing that is actually useful (PowerFLARM and/or transponders) is OK to adopt, and its better to keep dreaming about what could/will be...
>
> Whatever mid-air collision risks you club does have it is apparently worth spending years going on and on about UAT silliness. But it is good to finally see you letting go of UAT. You don't actually own a glider do you? Have you ever owned a glider? What of all this stuff was it equipped with? Transponder? PCAS? ADS-B In? PowerFLARM? What exactly? With what traffic display? With your often-stated concerns about busy nearby GA traffic I hope your club gliders are transponder equipped. Are they? It is the Minnesota Soaring Club right? And it operates at the edge and presumably underneath busy Minneapolis Class B airspace right? With a victor airway running right over the top of the club airport.
>
> And for those still playing along at home, no nothing that relies on TIS-B will "show you every ADS-B and transponder equipped aircraft". TIS-B requires both ADS-B ground station and more probably more of an issue SSR Radar coverage, which is uh not surprisingly lacking at many glider ports and smaller airports, especially near traffic pattern altitudes where traffic is converging, and where we have seen fatal mid-air collisions involving glider and towplanes within the last several years. One benefit of the PCAS coverage in PowerFLARM is you at least get some warning of nearby transponder equipped aircraft as long as their transponders are being interrogated, and in many locations TCAS and TCAD interrogators fill in that where ground based SSR will not reach the aircraft. Would TIS-B be a nice complement, yes sure, but wanting is not having. And in the real world we have to do what we can.
>
> So while we are on this, what are the SSR and ADS-B minimum coverage altitudes over the Minnesota Soaring Club/Stanton Field? Got ADS-B ground service down to pattern altitude? How low exactly? SSR TIS-B service coverage to how low? Who knows you might be lucky, Stanton Field is roughly equidistant from the ADS-B towers at Minnesota International and Dodge City Airport, and ~30nm or so from the ASR at Minnesota International, or maybe there is TIS-B integration out of the ASR at Rochester International. I hope there have been lots of discussions between the club and the Minnesota TRACON folks about how good or bad primary radar coverage is near Stanton Field. But even more I'd hope you actually have flown a ADS-B system and tested out TIS-B coverage in the area. Still that does not mean other folks at other locations have useful TIS-B coverage, even if their gliders were properly equipped with ADS-B Out and In.
>
> God I hope there is never a midair collision with a GA or larger aircraft involving a glider from your club not equipped with a transponder, obviously not for the risk to life and injury, but a liability lawyer will likely have a field-day going though your posts on DUC.

I have a brand new Phoenix Motorglider that is currently in the shop getting equipped with a full blown Dynon Skyview panel including ADS-B IN, and a fully 2020 compliant 1090ES ADS-B OUT system (including a Mode S transponder). Unfortunately, the ADS-B IN is not dual frequency (UAT only), but as you rightfully point out, nothing is perfect. Hopefully Dynon will fix this in the future.

It will be interesting to see how low the ADS-B ground station coverage is at Stanton. I expect to have excellent coverage at pattern altitude, as on a clear day, we can easily see the MSP airport. I will report back in the spring when I take the Phoenix back to MN.

This is obviously not a good setup for a typical glider. To make it work in the Phoenix, I am adding an extra high capacity battery so I can leave all of this on when the motor is off.

However, ADS-B is the obvious long term solution for all aircraft in the US, including gliders. FLARM may be interesting for the minority of glider pilots who are flying in contests at remote locations where a large percentage of gliders are similarly equipped and the concentration of GA and commercial aircraft is low. Those of us flying near large metro areas, need systems that support the full spectrum of air traffic, not a glider only niche.

Buying avionics is a long term investment for most pilots. When you make this kind of investment, you are not only looking at the immediate functionality of the equipment, but also at the reputation and longer term vision of the equipment supplier. Everything you buy is going to have quirks and limitations that are going to be irritating. The big question is what is the attitude of the manufacturer? Do they recognize these limitations and are they interested in correcting these in future versions of the product and/or firmware, or do they have their head in the sand and ignore the issues?

In the case of FLARM, there is absolutely no vision that incorporates the realities of the US ADS-B environment. Adding ADS-R and TIS-B support to PowerFlarm should be possible with a firmware upgrade to the existing hardware, which would resolve 90% of the beefs that people have with this system. None of the PowerFlarm people have ever even acknowledged that this would be a desirable feature in their product. All we ever hear about is how stupid the US for having UAT and how the FAA should scrap their entire architecture and do things the way the rest of the world does them.

Do you really want to spend your money investing in equipment from a company with this kind of attitude?

[Charlie M. (UH & 002 owner/pilot)]

OK, I've been trying to NOT add this (under some advisement of quite a few withing the US soaring community..... but here goes.....), some of the "cellphone issues" are NOT SSA RC OR US FAA issues, they are (yet another entity) FCC rules.
The FCC (which presides over COMMUNICATIONS, NOT flying) has an issue with "swamping CELL systems" when "at altitude". They are also sorta concerned (FAA more so) with corrupting other electronic devices with emitted radio waves.
"In general", it has been agreed that the chance (note: "CHANCE", regardless of the "Mythbusters testing"......) of an electronic device corrupting an AIRCRAFT device (notably navigation) is low, it's still there.
The FCC & the FAA has sorta agreed that high flying COMMERCIAL flights can use a picocell to connect travelers to a "landline", but they are out of range to swamp the ground based cell system.
What about glider pilots?
We are MORE LIKELY to be within range of multiple cell towers, thus the FCC concern.
BTW, the FCC (in the US) is a FEDERAL agency.
You can do your own search on why the FCC has issues with cell usage in flight.

Frankly, I sorta see a potential legal issue with the SSA RC ALLOWING a cellphone within reach of a pilot during as flight.
Yes, you can use "airplane mode" and use your "smartphone" as a display, but a tracking program/app seems to go against what the FCC wants (since it's using the cell towers). You run the risk of creating a communications issue (on the ground) that concerns the FCC.

Will you get caught? Who knows.

Do I want to get caught by a federal agency, not really.

So....... Sean F & others, "look beyond the box" (seems to be a favorite comment of some towards "luddites"), see if you are still safe and within the federal rules.

Don't like the federal rules (in the US), then go raise "heck" with your government rep's.

I personally think the SSA RC may have opened the SSA, contest management & pilots to yet another potential "OMG" if they get caught.
Based on probability, getting caught violating a FCC rule is way more likely than having a midair because of a degradation of what Flarm (in whatever flavor) does.

It has been proven that usiung a cellphone (talk or text) raises the chance of an accident (due to distraction) to about the same level as drunk driving. Do we really want to go there?
True, you're probably NOT talking or texting in flight, but if you can do it, some will regardless of the rules.

Not "stirring the pot", just alerting BOTH sides on other things to consider....

BTW, "Have a nice day"...... ;-)

PS, yes, the FCC allows you (the PIC) to determine if using a cellphone creates another hazard in VFR flight..... sorta opens the door to litigation when someone is injured or worse..... just to keep this sorta honest and limit the, "But I found this, so I'm correct" stuff.....

Not a good position for any RC to be in, many things to consider as it is, I don't relish the work they have to do now or down the road.

I support them and their decisions.

BTW, "Have a nice day"...... ;-) again....

[Dan Marotta]

That is why I never stop looking outside. Even the most complex
electronic system can hiccup now and then and in the case of collision
avoidance it could happen at the worst time. Keep your head out! (Pun
intended)

As for split screen, what I've so far discovered is that the Samsung G4
supports split screen. The Nexus does not unless I want to root the
device and install a custom ROM. I'm not sure I'm ready to try that
yet. Switching back and forth is not so simple with the Nexus as, when
running XCSoar, the electronic "buttons" of the Android are not
available. To switch, I have to touch the power button twice to get
back to the home screen, then the bottom right electronic button, then
select the app I want to run. Better to have two devices (or a device
which supports split screen), or just not mess with such toys in flight.

On 1/15/2016 9:45 AM, xcnick wrote:
> Thanks for sharing Dan.
>
> I have the two programs running on a Galaxy S4 and neither AVare or xcsoar appear to support split screen.
>
> It is just one question. No, or buy this and do this. So far switching back and forth is all I can do.
>
> As far as opinions go I do agree that seeing only some traffic and thinking you are seeing it all is very dangerous.

--
Dan, 5J

[Vaughn Simon[_2_]]

On 1/15/2016 6:48 PM, Charlie M. (UH & 002 owner/pilot) wrote:
> some of the "cellphone issues" are NOT SSA RC OR US FAA issues, they are (yet another entity) FCC rules.

Quote chapter and verse of the FCC rule(s) you are referencing.

Vaughn

[Dan Marotta]

Ya know, I was thinking about PF and XCSoar just a while ago and have a
few questions. I was going to start another thread but, what the heck,
maybe I can win the award (money and chicks) for longest thread on
RAS... :-D

I was wondering if, feeding XCSoar from PowerFlarm, and an alert arises,
does XCSoar automatically zoom to the correct scale to display the
threat? What if you're in a thermal with very high zoom factor, say 1
km, and a high energy glider is approaching. You're climbing, he's
descending and below you, and may simply pass through your thermal on
his way to non-leeching glory. But what if he pulls up? Now there's an
immediate threat alert (a pop-up) since your zoom level did not allow
you to see him coming. Of course you were looking outside and saw him
coming a reasonable distance away, but he was looking inside and might
be unaware of your presence.

Back to the ADS-B In thread. I enjoy seeing other traffic but it's not
very satisfying down low since I know I don't have a complete picture.
I'll still need the PCAS to see XPonder equipped, non-ADS-B Out aircraft
down low but, at the altitudes we usually fly out west, I don't think
there's much, if any, threat from non XPonder equipped aircraft. Most
GA aircraft just can't get that high. Oh yeah, there are still totally
unequipped aircraft flying in the Class E or G...

On 1/15/2016 10:01 AM, kirk.stant wrote:
> Dan, now you just have to figure out how to get the traffic data from your MRX into XCsoar!
>
> (Or cheat and get a PF�😄)
>
> Good luck, let us know how it works!
>
> Kirk
> 66

--
Dan, 5J

[Dan Marotta]

'Everybody here is well aware you don't have PowerFLARM, you seem to have some objection to it that I've never been able to follow logically.'


My only reason not to have Flarm is that, for _/my flying/_ in the area
/_where I fly_/ I don't feel that it provides me with anything more than
my PCAS already does. Simple as that. I don't understand why folks
can't comprehend that.

I only made the referred to statement because you referred to feeding
XCSoar with Flarm when I was trying to find a way to feed XCSoar via
this toy ADS-B In device. I won't be carrying it in my single seater
come the soaring season.

/__/
On 1/15/2016 10:28 AM, Darryl Ramm wrote:
> On Friday, January 15, 2016 at 8:20:51 AM UTC-8, Dan Marotta wrote:
>> But there's one minor point of contention in your reply, Darryl. I
>> don't have Flarm.
>>
> /snip/
>> Dan, 5J
> Everybody here is well aware you don't have PowerFLARM, you seem to have some objection to it that I've never been able to follow logically.
>
> But you are playing around with an ADS-B SDR toy, and learning about ADS-B, and some of the discussion shows you are learning about the ground-based services that you misunderstood until now. And you'll get a good feel for the carriage and coverage in your area (although a better receiver may give you more range and reliable reception). And that is all seriously great, you will know way more than most pilots about ASD-B. I totally encourage anybody interested to get something like this and set it up and play with it (mostly on the ground) to learn about ADS-B. Preferably with a dual-link receiver.
>
> But when it comes to using an actual "ADS-B" In device in an aircraft, for actual in-flight use, other folks need to be clear in their minds about what exactly "ADS-B" means, what they will/won't receive and why they require ADS-B Out to get full ADS-B services.
>
> The simple answer as always remains USA glider pilots interested in traffic avoidance technology should get a PowerFLARM or transponder or both (choice based on where they fly/what traffic they fly most with). Ideally a Mode S transponder that supports 1090ES or in future, e.g. a Trig TT-22. Everything beyond that for now is more for geeks who want to play around with stuff. And lots of things are likely to change with possible loss of carriage exemptions or TABS regulation... including more affordable/better ADS-B solutions, so for most folks just wait vs. trying too far down the ADS-B path... but install a transponder or PowerFLARM now as appropriate.
>
>

--
Dan, 5J

[[email protected]]

On Saturday, January 16, 2016 at 9:58:24 AM UTC-6, Vaughn Simon wrote:
> On 1/15/2016 6:48 PM, Charlie M. (UH & 002 owner/pilot) wrote:
> > some of the "cellphone issues" are NOT SSA RC OR US FAA issues, they are (yet another entity) FCC rules.
>
> Quote chapter and verse of the FCC rule(s) you are referencing.
>
> Vaughn

http://www.ecfr.gov/cgi-bin/text-idx?rgn=div8&node=47:2.0.1.1.2.8.27.12

Title 47, chapter 1, subchapter B, part 22, subpart H, 22.925.

§22.925 Prohibition on airborne operation of cellular telephones.

Cellular telephones installed in or carried aboard airplanes, balloons or any other type of aircraft must not be operated while such aircraft are airborne (not touching the ground). When any aircraft leaves the ground, all cellular telephones on board that aircraft must be turned off. The following notice must be posted on or near each cellular telephone installed in any aircraft:

"The use of cellular telephones while this aircraft is airborne is prohibited by FCC rules, and the violation of this rule could result in suspension of service and/or a fine. The use of cellular telephones while this aircraft is on the ground is subject to FAA regulations."

[Dan Marotta]

Dear Sean,

Were you never taught that loaded words, inflammatory comments, and
hysteria do not foster discussion?

This thread was started to discuss open source software and COTS
hardware and their possible use as an ADS-B solution. None of the
following were intended to be introduced to the discussion: Flarm,
stealth mode, contest flying, SSA, Rules Committee, and so forth.
Continuing to raise these subjects clouds the original intent.

Happy Flying,

Dan

On 1/15/2016 1:41 PM, smfidler wrote:
> The US rules committee, and their puppet masters (otherwise known as the "SSA anti-technology oligarchy"), still won't allow smartphones to be "used" in our gliders during contests. Weather apps or even situational awareness beyond roughly 30 seconds with PowerFlarm (non-stealth/competition mode) is currently scheduled to become illegal.
>
> Only recently did the USRC even allow the smartphone back in the cockpit at all, but only under strict orders never to use it! This even though most US pilots probably use a smartphone-based navigation app such as XC soar, iGlide or other similar. This whole thing is starting to get irritating.
>
> They use words like "weak-assed." They use words like "tradition." They use phrases like "the spirit of soaring..."
>
> This is the problem. Our anti-tech oligarchies "feelings" on the subject of new technology. This oligarchy are a relative few among us. Most of us dont care about weather, ADSB and smartphones. Some find it cool, and fun. Yet they drag us against the rising tide requiring tremendous effort to hold any ground.
>
> I certainly have a good working knowledge of most of these new technologies. I rarely if ever have a need to bother with them. Again, the typical max range is 3 miles and I have a solid antenna installation in my glider. I honestly believe that trying to fly a task based on cellular or ADSB weather is going to be a very rare occurrence. And it also has a safety benefit. This seems to almost always be disregarded.
>
> The problem IS NOT the natural progression of cost effective, relevant flight "data" and situational awareness & anti-collision technology. The problem is the feelings of a relative few.
>
> And it's taking 10x the effort to prevent these technologies from entering the glider cockpit than will ever be gained from it. Particularly in the US contest environment.
>
> In fact, if any of the oligarchs spent 1/4 the time studying ADSB as they do trying to promote stealth mode Flarm and demonize those who like PowerFlarm as it is, they would probably already be more proficient than most of us.
>
>

--
Dan, 5J

[kirk.stant]

On Saturday, January 16, 2016 at 8:35:09 AM UTC-6, Mike Schumann wrote:

> Do you really want to spend your money investing in equipment from a company with this kind of attitude?

(lots of bogus arguments clipped)

I preferred (4 years ago) to spend my money on equipment that worked (then and now) as advertised, instead of on expensive equipment that only puts out a half-baked solution and is still in flux.

If most ADS-B out installations end up being 1090ES, PF is the obvious solution SINCE IT WILL SHOW THEM ALL TODAY! For those who need weather info, then a cheap UAT in will fill that square.

As far as collision avoidance for gliders (which is a totally different problem than traffic seperation of power traffic), ADS-B is not a solution. It's designed for ATC use, not pilot self deconfliction (It's NOT TCAS!).

Sounds like a nice rig you are getting, have fun with it!

Kirk
66

[kirk.stant]

On Saturday, January 16, 2016 at 10:25:04 AM UTC-6, Dan Marotta wrote:

> I was wondering if, feeding XCSoar from PowerFlarm, and an alert
> arises, does XCSoar automatically zoom to the correct scale to
> display the threat?* What if you're in a thermal with very high zoom
> factor, say 1 km, and a high energy glider is approaching.* You're
> climbing, he's descending and below you, and may simply pass through
> your thermal on his way to non-leeching glory.* But what if he pulls
> up?* Now there's an immediate threat alert (a pop-up) since your
> zoom level did not allow you to see him coming.* Of course you were
> looking outside and saw him coming a reasonable distance away, but
> he was looking inside and might be unaware of your presence.

Dan, PF uses two distinct displays - a "map" that shows flarm and 1090ES ADS-B traffic in the vicinity (as well as a PCAS-like warning - alt diff and approx range - of transponder traffic nearby, similar to the MRX), and a "collision warning" display (circle of dots for direction of threat, bars above or below for alt diff) that replaces the situational awareness map when a collision potential between flarm equipped gliders is detected. Not sure how XCSoar is implemented, but my Oudie2/SYM and SN10 both mimic the dedicated, small flarm display. Plus you get audio warnings...

So, unless you are in Stealth mode (oh no not that again!!!) you have plenty of time to monitor your "radar" display for approaching traffic", and should not be surprised if a collision warning pops up (due to an aggressive thermal entry, for example).

As to what PF gives you that your PCAS doesn't, that's simple - 1090ES ADS-B traffic - which is pretty much all the fast movers that you are trying to scare off with your transponder. So now you can watch them "do the chicken" when their TCAS goes off! Of course, you are working on getting that with your "science project".

And it's a nice logger and GPS source for the rest of the glider toys.

Kirk
66

[kirk.stant]

On Saturday, January 16, 2016 at 10:41:56 AM UTC-6, w

> Title 47, chapter 1, subchapter B, part 22, subpart H, 22.925.
>
> §22.925 Prohibition on airborne operation of cellular telephones.
>
> Cellular telephones installed in or carried aboard airplanes, balloons or any other type of aircraft must not be operated while such aircraft are airborne (not touching the ground). When any aircraft leaves the ground, all cellular telephones on board that aircraft must be turned off. The following notice must be posted on or near each cellular telephone installed in any aircraft:
>
> "The use of cellular telephones while this aircraft is airborne is prohibited by FCC rules, and the violation of this rule could result in suspension of service and/or a fine. The use of cellular telephones while this aircraft is on the ground is subject to FAA regulations."

Seems to me the RC and contest CDs have no business prohibiting the carriage of cellphones, and their use is already prohibited by statute.

I'll keep on carrying mine, thank you.

Kirk
66

[[email protected]]

On Saturday, January 16, 2016 at 12:37:53 PM UTC-5, kirk.stant wrote:
> On Saturday, January 16, 2016 at 10:41:56 AM UTC-6, w
>
> > Title 47, chapter 1, subchapter B, part 22, subpart H, 22.925.
> >
> > §22.925 Prohibition on airborne operation of cellular telephones.
> >
> > Cellular telephones installed in or carried aboard airplanes, balloons or any other type of aircraft must not be operated while such aircraft are airborne (not touching the ground). When any aircraft leaves the ground, all cellular telephones on board that aircraft must be turned off. The following notice must be posted on or near each cellular telephone installed in any aircraft:
> >
> > "The use of cellular telephones while this aircraft is airborne is prohibited by FCC rules, and the violation of this rule could result in suspension of service and/or a fine. The use of cellular telephones while this aircraft is on the ground is subject to FAA regulations."
>
> Seems to me the RC and contest CDs have no business prohibiting the carriage of cellphones, and their use is already prohibited by statute.
>
> I'll keep on carrying mine, thank you.
>
> Kirk
> 66

I will too. Turned off as it should be.
Text of applicable rule that has been in place for quite a long time(following portions excerpted):

6.6.3 Carrying any two-way communication device is prohibited, with the following exceptions, each of which must be a standard,
commercially available model that is not used to provide any in-flight capabilities beyond those referenced below:
6.6.3.1 An aircraft-band VHF radio
6.6.3.2 An aircraft transponder
6.6.3.3 A wireless telephone (which is not to be used during flight)

UH

[Dan Marotta]

Kirk,

I reviewed the XCSoar documentation and, it appears that its Flarm
traffic display is only really useable when zoomed in as in thermalling,
not the normal 40-60 miles where I keep my screen during cruise. At
greater distances, all Flarm traffic would simply be a blob around the
own ship symbol. I can look some more, but it doesn't appear that
displaying ADS-B In traffic on XCSoar /running on a Dell Streak 5/,
which is what I use, will be working.

Unless I'm missing something, I currently "see" 1090ES traffic with my
PCAS if it's within 5 NM horizontally and 2,000' vertically when it
squawks in reply to ATC interrogation. I saw an airliner do the funky
chicken once before I had a transponder (and before Flarm existed). I
was glad they were looking outside! I had them in sight but the closure
was pretty quick.

On 1/16/2016 10:35 AM, kirk.stant wrote:
> On Saturday, January 16, 2016 at 10:25:04 AM UTC-6, Dan Marotta wrote:
>
>> I was wondering if, feeding XCSoar from PowerFlarm, and an alert
>> arises, does XCSoar automatically zoom to the correct scale to
>> display the threat? What if you're in a thermal with very high zoom
>> factor, say 1 km, and a high energy glider is approaching. You're
>> climbing, he's descending and below you, and may simply pass through
>> your thermal on his way to non-leeching glory. But what if he pulls
>> up? Now there's an immediate threat alert (a pop-up) since your
>> zoom level did not allow you to see him coming. Of course you were
>> looking outside and saw him coming a reasonable distance away, but
>> he was looking inside and might be unaware of your presence.
> Dan, PF uses two distinct displays - a "map" that shows flarm and 1090ES ADS-B traffic in the vicinity (as well as a PCAS-like warning - alt diff and approx range - of transponder traffic nearby, similar to the MRX), and a "collision warning" display (circle of dots for direction of threat, bars above or below for alt diff) that replaces the situational awareness map when a collision potential between flarm equipped gliders is detected. Not sure how XCSoar is implemented, but my Oudie2/SYM and SN10 both mimic the dedicated, small flarm display. Plus you get audio warnings...
>
> So, unless you are in Stealth mode (oh no not that again!!!) you have plenty of time to monitor your "radar" display for approaching traffic", and should not be surprised if a collision warning pops up (due to an aggressive thermal entry, for example).
>
> As to what PF gives you that your PCAS doesn't, that's simple - 1090ES ADS-B traffic - which is pretty much all the fast movers that you are trying to scare off with your transponder. So now you can watch them "do the chicken" when their TCAS goes off! Of course, you are working on getting that with your "science project".
>
> And it's a nice logger and GPS source for the rest of the glider toys.
>
> Kirk
> 66

--
Dan, 5J

[Dan Marotta]

I either set my Android phone to airplane mode or simply turn it off.
It also has the benefit of saving the battery should I need it later.

On 1/16/2016 12:10 PM, wrote:
> On Saturday, January 16, 2016 at 12:37:53 PM UTC-5, kirk.stant wrote:
>> On Saturday, January 16, 2016 at 10:41:56 AM UTC-6, w
>>
>>> Title 47, chapter 1, subchapter B, part 22, subpart H, 22.925.
>>>
>>> §22.925 Prohibition on airborne operation of cellular telephones.
>>>
>>> Cellular telephones installed in or carried aboard airplanes, balloons or any other type of aircraft must not be operated while such aircraft are airborne (not touching the ground). When any aircraft leaves the ground, all cellular telephones on board that aircraft must be turned off. The following notice must be posted on or near each cellular telephone installed in any aircraft:
>>>
>>> "The use of cellular telephones while this aircraft is airborne is prohibited by FCC rules, and the violation of this rule could result in suspension of service and/or a fine. The use of cellular telephones while this aircraft is on the ground is subject to FAA regulations."
>> Seems to me the RC and contest CDs have no business prohibiting the carriage of cellphones, and their use is already prohibited by statute.
>>
>> I'll keep on carrying mine, thank you.
>>
>> Kirk
>> 66
> I will too. Turned off as it should be.
> Text of applicable rule that has been in place for quite a long time(following portions excerpted):
>
> 6.6.3 Carrying any two-way communication device is prohibited, with the following exceptions, each of which must be a standard,
> commercially available model that is not used to provide any in-flight capabilities beyond those referenced below:
> 6.6.3.1 An aircraft-band VHF radio
> 6.6.3.2 An aircraft transponder
> 6.6.3.3 A wireless telephone (which is not to be used during flight)
>
> UH

--
Dan, 5J

[Vaughn Simon[_2_]]

On 1/16/2016 11:41 AM, wrote:
> On Saturday, January 16, 2016 at 9:58:24 AM UTC-6, Vaughn Simon wrote:
>> On 1/15/2016 6:48 PM, Charlie M. (UH & 002 owner/pilot) wrote:
>>> some of the "cellphone issues" are NOT SSA RC OR US FAA issues, they are (yet another entity) FCC rules.
>>
>> Quote chapter and verse of the FCC rule(s) you are referencing.
>>
>> Vaughn
>
> http://www.ecfr.gov/cgi-bin/text-idx?rgn=div8&node=47:2.0.1.1.2.8.27.12
>
> Title 47, chapter 1, subchapter B, part 22, subpart H, 22.925.
>
> §22.925 Prohibition on airborne operation of cellular telephones.
>
> Cellular telephones installed in or carried aboard airplanes, ...

Yes, but is your telephone a Subpart H device?

You see, just like the FARS, the FCC regs are divided into parts, so
therefore context is important.

Subpart H only applies to certain devices.

Title 47, chapter 1, subchapter B, part 22, subpart H, 22.905.

§22.905 Channels for cellular service.
The following frequency bands are allocated for assignment to service
providers in the Cellular Radiotelephone Service.

(a) Channel Block A: 869-880 MHz paired with 824-835 MHz, and 890-891.5
MHz paired with 845-846.5 MHz.

(b) Channel Block B: 880-890 MHz paired with 835-845 MHz, and 891.5-894
MHz paired with 846.5-849 MHz.

[67 FR 77191, Dec. 17, 2002]

Do you know what frequency band your phone operates on?

[SoaringXCellence]

On Saturday, January 16, 2016 at 11:16:31 AM UTC-8, Dan Marotta wrote:
> Kirk,
>
>
>
> I reviewed the XCSoar documentation and, it appears that its Flarm
> traffic display is only really useable when zoomed in as in

Actually, the XCSoar software can be set to turn on a miniature radar display when traffic is near and that display has a different "zoom" factor than the moving map.

If you then touch the radar it will switch to full screen flarm display which can also be zoomed with a different factor.

MB

[Charlie M. (UH & 002 owner/pilot)]

On Saturday, January 16, 2016 at 2:37:45 PM UTC-5, Vaughn Simon wrote:
> On 1/16/2016 11:41 AM, resigler wrote:
> > On Saturday, January 16, 2016 at 9:58:24 AM UTC-6, Vaughn Simon wrote:
> >> On 1/15/2016 6:48 PM, Charlie M. (UH & 002 owner/pilot) wrote:
> >>> some of the "cellphone issues" are NOT SSA RC OR US FAA issues, they are (yet another entity) FCC rules.
> >>
> >> Quote chapter and verse of the FCC rule(s) you are referencing.
> >>
> >> Vaughn
> >
> > http://www.ecfr.gov/cgi-bin/text-idx?rgn=div8&node=47:2.0.1.1.2.8.27.12
> >
> > Title 47, chapter 1, subchapter B, part 22, subpart H, 22.925.
> >
> > §22.925 Prohibition on airborne operation of cellular telephones.
> >
> > Cellular telephones installed in or carried aboard airplanes, ...
>
> Yes, but is your telephone a Subpart H device?
>
> You see, just like the FARS, the FCC regs are divided into parts, so
> therefore context is important.
>
> Subpart H only applies to certain devices.
>
> Title 47, chapter 1, subchapter B, part 22, subpart H, 22.905.
>
> §22.905 Channels for cellular service.
> The following frequency bands are allocated for assignment to service
> providers in the Cellular Radiotelephone Service.
>
> (a) Channel Block A: 869-880 MHz paired with 824-835 MHz, and 890-891.5
> MHz paired with 845-846.5 MHz.
>
> (b) Channel Block B: 880-890 MHz paired with 835-845 MHz, and 891.5-894
> MHz paired with 846.5-849 MHz.
>
> [67 FR 77191, Dec. 17, 2002]
>
> Do you know what frequency band your phone operates on?

Could be..... this link...(~1/3 of the way down) https://en.wikipedia.org/wiki/Cellular_frequencies seems to indicate my phone fits in "Subpart H" (Verizon "non-smartphone").
Other providers (different types of communications, 3G, 4G, etc.) also fit in what you are referencing. I would hazard a guess that it's a high probability that "US cellphones fall under Subpart H, thus are not to be part of a cell network in flight".

Full search (with a lot more hits) is here... https://www.google.com/webhp?sourceid=chrome-instant&ion=1&espv=2&ie=UTF-8#q=us%20cell%20phone%20band%20frequencies

[Dan Marotta]

Thanks, but that appears to be Flarm only. I've been looking through
the XCSoar menus trying to get it to listen to the wifi created by the
Raspberry Pi. No luck so far. Guess I need to get into the Pi and see
what protocol it's transmitting and then see if there's a combination of
selections in XCSoar that will allow it to listen.

Or, I can try to find an Android 3.1 ROM that will work on the Streak 5
and upgrade the operating system. Then I can use the Avare External I/O
Plugin and Avare to displan ADSB-In traffic and weather.

Neither of the options seems workable on the Streak.

On 1/16/2016 4:00 PM, SoaringXCellence wrote:
> On Saturday, January 16, 2016 at 11:16:31 AM UTC-8, Dan Marotta wrote:
>> Kirk,
>>
>>
>>
>> I reviewed the XCSoar documentation and, it appears that its Flarm
>> traffic display is only really useable when zoomed in as in
> Actually, the XCSoar software can be set to turn on a miniature radar display when traffic is near and that display has a different "zoom" factor than the moving map.
>
> If you then touch the radar it will switch to full screen flarm display which can also be zoomed with a different factor.
>
> MB

--
Dan, 5J

[Darryl Ramm]

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.

[Andy Blackburn[_3_]]

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 Marotta]

Thanks Darryl, the part about the GDL-90 format slipped by me.

I'll see if I can find another fun project now.

On 1/17/2016 12:46 PM, 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.

--
Dan, 5J

[Dan Marotta]

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

[Andy Blackburn[_3_]]

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.
>
> 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.* ;-)

More fun than - well, it depends what interests her.

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

[Darryl Ramm]

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.

[Andy Blackburn[_3_]]

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.

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.

9B

[xcnick]

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's manual page 102 7.13 Weather forecast, RASP talks about this. It is beyond me, but post if you can make it happen.

[xcnick]

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.

[Darryl Ramm]

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

[Darryl Ramm]

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.

[Darryl Ramm]

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.

[krasw]

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

[Sarah[_2_]]

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

[smfidler]

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!

[Dan Marotta]

<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

[Dan Marotta]

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

[jfitch]

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.

[Dan Marotta]

That looks really cool!!! But... Did you notice the map scale was set
at 585 km? I wonder what it would look like if scaled down to a more
reasonable 50-100 km full width.

On 1/17/2016 11:18 PM, 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's manual page 102 7.13 Weather forecast, RASP talks about this. It is beyond me, but post if you can make it happen.

--
Dan, 5J

[Charlie M. (UH & 002 owner/pilot)]

On Monday, January 18, 2016 at 10:52:40 AM UTC-5, smfidler wrote:
> 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!

Hi Sean,

I think everyone on RAS knows your feelings on a number of topics, the SSA RC is a main one.

This is not really the thread for this, but it relates to my posts above regarding that this is really a FCC issue.
The SSA RC (in allowing cellphone use in flight) is basically saying to pilots, "Hey, it's against the FCC rules, but thumb your nose at it and break the law".

1-The FCC rule section was linked.
2-Follow-up info was linked (regarding cell frequencies used as well as prohibited).
3-I have not seen anyone show where my reading of the FCC rules is incorrect, thus cellphone use INFLIGHT is against the FCC rules.
4-I don't see anything in the FCC rules that allows use of any tracker while inflight.

Oh, and a happy Monday to you as well.

[Darryl Ramm]

I am just pointing out (mostly to others following along) why I suspect wevwon't see a commercial product to do this vs. say existing serial port/Bluetooth mux'es which are trivial by comparison. And I want everybody to be aware of the difference between displaying traffic and getting a FLARM style alert. Just displaying traffic in your case should not be super difficult. Interesting to play with, but I would not want to fly with it (not without audible/simple FLARM style alerts).

[Dan Marotta]

Thanks, Sarah, it's now a matter of deciding whether to do a code search
or to go fly... Hmmmmm....

On 1/18/2016 6:57 AM, Sarah wrote:
> 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

--
Dan, 5J

[Martin Gregorie[_5_]]

On Mon, 18 Jan 2016 09:47:28 -0700, Dan Marotta wrote:

> 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!
>
If you are getting a nice picture from the ADSB software receiver on your
RaspberryPi, you may want to look at the touch-sensitive TFT displays
Adafruit sell for the RPi - they connect to the expansion socket and
pretty much clip onto the RPi board. Put one onto a Pi-zero and you'd
have quite a small package, though at the cost of adding another screen
to your cockpit and needing to find a case for it.


--
martin@ | Martin Gregorie
gregorie. | Essex, UK
org |

[Darryl Ramm]

On Monday, January 18, 2016 at 10:27:35 AM UTC-8, Martin Gregorie wrote:
> On Mon, 18 Jan 2016 09:47:28 -0700, Dan Marotta wrote:
>
> > 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!
> >
> If you are getting a nice picture from the ADSB software receiver on your
> RaspberryPi, you may want to look at the touch-sensitive TFT displays
> Adafruit sell for the RPi - they connect to the expansion socket and
> pretty much clip onto the RPi board. Put one onto a Pi-zero and you'd
> have quite a small package, though at the cost of adding another screen
> to your cockpit and needing to find a case for it.

Ah the Stratusx software does not display traffic, it just outputs GDL-90 format data from a software defined radio (SDR). Emulating a Appareo Status ADS-B receiver.

[Vaughn Simon[_2_]]

On 1/17/2016 11:46 AM, Charlie M. (UH & 002 owner/pilot) wrote:
> Could be..... this link...(~1/3 of the way down)
https://en.wikipedia.org/wiki/Cellular_frequencies
seems to indicate my phone fits in "Subpart H" (Verizon "non-smartphone").

I see no evidence that "Your" phone is a part H device. In fact, I see
no evidence that MY phone is a Part H device and I've been in the
communications biz for decades!

I have already quoted §22.905 (Channels for cellular service) which
gives the ONLY frequency sub-bands for part H devices. They happen to
be the original cellphone channels. If your phone operates in any other
of the several frequency bands, (700 MHZ, 750 MHZ, 1700 MHz, 1900 MHZ,
2100 MHZ and 2500 MHZ) then nobody has yet to show me a regulation that
stops it from being used aloft.


> Other providers (different types of communications, 3G, 4G, etc.)
also fit in what you are referencing.

Mostly wrong. They use the Part H frequency band plus many others.
According to the chart you reference, T-Mobile makes no use of 800
channels at all!

I would hazard a guess that it's a high probability that "US cellphones
fall under Subpart H, thus are not to be part of a cell network in flight".

I would hazard a high probability that you are wrong.


As I have mentioned, I've been in the radio communications biz for
years. I have yet to hear of the FCC actually citing a cell phone user
for using a cell phone aloft (Not saying it's never happened, I've just
never heard of it and never seen any evidence) The reason? It was
originally feared to be a problem. Originally, one airborne user could
tie up cells for hundreds of miles, rather than just the one cell that
he is supposed to use. But better antenna design has virtually
eliminated that problem. (By the way, the "solution" to that problem
makes your cellphone of dubious use when you are airborne, but that's
another discussion.)


My point here is that us glider drivers should leave FCC enforcement to
the FCC. I am no expert on FCC regs, and I doubt if anyone else here is
either. If you wish to exclude all personal communications devices from
glider races, then state your real objections and defend your position
on that basis!

And please, stop rolling out §22.925 and assuming/implying that it
applies to every personal communications device! Just like the FARS,
FCC regulations are more complex and nuanced than that.

[Vaughn Simon[_2_]]

On 1/18/2016 11:59 AM, Charlie M. (UH & 002 owner/pilot) wrote:
> 1-The FCC rule section was linked.

Wrongly, or at least incompletely applied to today's personal
communications devices.

> 2-Follow-up info was linked (regarding cell frequencies used as well as prohibited).

Which you obviously didn't bother to read (or at least, understand).
Part H, which is where the reg you referenced comes from, only applies
to certain 800 MHZ frequency bands. Your personal communications device
might be operating on any of at least six other frequency bands.

> 3-I have not seen anyone show where my reading of the FCC rules is incorrect,
thus cellphone use INFLIGHT is against the FCC rules.

I did show it, you rejected it.

> 4-I don't see anything in the FCC rules that allows use of any tracker while inflight.

"Allows?" It's prohibitions that matter. If your REAL concern is
trackers, then make your case on that basis. Stop playing FCC lawyer on
the Internet.

[Jonathan St. Cloud]

One can call "Flight Watch" and get weather for route ahead. I have done that to help pick a line. Of course XM weather on my LX90XX would be preferred!

LX wifi seems like a first step. When flying out of NV or UT can you really get cell data at altitude?

Anyone flown with Stratus 2 s and foreflight? Was it useful?


On Monday, January 18, 2016 at 8:55:23 AM UTC-8, jfitch wrote:
> 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.

[Charlie M. (UH & 002 owner/pilot)]

On Monday, January 18, 2016 at 4:05:49 PM UTC-5, Vaughn Simon wrote:
> On 1/18/2016 11:59 AM, Charlie M. (UH & 002 owner/pilot) wrote:
> > 1-The FCC rule section was linked.
>
> Wrongly, or at least incompletely applied to today's personal
> communications devices.
>
> > 2-Follow-up info was linked (regarding cell frequencies used as well as prohibited).
>
> Which you obviously didn't bother to read (or at least, understand).
> Part H, which is where the reg you referenced comes from, only applies
> to certain 800 MHZ frequency bands. Your personal communications device
> might be operating on any of at least six other frequency bands.
>
> > 3-I have not seen anyone show where my reading of the FCC rules is incorrect,
> thus cellphone use INFLIGHT is against the FCC rules.
>
> I did show it, you rejected it.
>
> > 4-I don't see anything in the FCC rules that allows use of any tracker while inflight.
>
> "Allows?" It's prohibitions that matter. If your REAL concern is
> trackers, then make your case on that basis. Stop playing FCC lawyer on
> the Internet.

Not an "FCC lawyer" either on the Internet or other places.
Not having an "agenda" for/against technology.

My comment on "cell based trackers" is whether or not these go against what airborne communications the FCC (in the US) allow, I'm not an expert, you "may" be better qualified than I am.

You saying I "rejected parts of your posts" is not valid in my mind, I posted items (as did another) and then you did 2 posts back to back. Sorta hard for anyone to reject something "after the fact".
This is my 1st response to you and your view/data.
Not sure where you came up with, "Which you obviously didn't bother to read (or at least, understand), Part H, which is where the reg you referenced comes from, only applies to certain 800 MHZ frequency bands."

My read is, quite a few freq's are banned from inflight use in the US.

Hey, while I'm a "sorta tech guy", radio communications is not my strong point, and we're trying to understand a US government agency rules. Sorta like, "FAA rules are clear & succinct, except for the exceptions".
Gives new meaning to, "Rules developed by lawyers so it takes a lawyer to understand.....sometimes....".

Not picking a fight (it's the Internet, grand scheme of things, I better things to do).
Speaking for myself, I have no control over the FAA, FCC, SSA RC, etc. Since I'm not a "current US contest pilot", I can't vote on current ideas or issues. That's my issue, not this forum.
I sorta get bent when peeps get slammed when they may have issues outside of the "small box" that create other issues.
Until I see further, I still think there are issues with ANY cellphone based communications (call, text, tracker) in the US while airborne.

[sorry, you have not convinced me, just added to the clutter to a sorta different thread...... I was only relying to a slam against the SSA RC on being Luddites]

[Andy Blackburn[_3_]]

On Monday, January 18, 2016 at 2:56:39 PM UTC-8, Charlie M. (UH & 002 owner/pilot) wrote:
> On Monday, January 18, 2016 at 4:05:49 PM UTC-5, Vaughn Simon wrote:
> > On 1/18/2016 11:59 AM, Charlie M. (UH & 002 owner/pilot) wrote:
> > > 1-The FCC rule section was linked.
> >
> > Wrongly, or at least incompletely applied to today's personal
> > communications devices.
> >
> > > 2-Follow-up info was linked (regarding cell frequencies used as well as prohibited).
> >
> > Which you obviously didn't bother to read (or at least, understand).
> > Part H, which is where the reg you referenced comes from, only applies
> > to certain 800 MHZ frequency bands. Your personal communications device
> > might be operating on any of at least six other frequency bands.
> >
> > > 3-I have not seen anyone show where my reading of the FCC rules is incorrect,
> > thus cellphone use INFLIGHT is against the FCC rules.
> >
> > I did show it, you rejected it.
> >
> > > 4-I don't see anything in the FCC rules that allows use of any tracker while inflight.
> >
> > "Allows?" It's prohibitions that matter. If your REAL concern is
> > trackers, then make your case on that basis. Stop playing FCC lawyer on
> > the Internet.
>
> Not an "FCC lawyer" either on the Internet or other places.
> Not having an "agenda" for/against technology.
>
> My comment on "cell based trackers" is whether or not these go against what airborne communications the FCC (in the US) allow, I'm not an expert, you "may" be better qualified than I am.
>
> You saying I "rejected parts of your posts" is not valid in my mind, I posted items (as did another) and then you did 2 posts back to back. Sorta hard for anyone to reject something "after the fact".
> This is my 1st response to you and your view/data.
> Not sure where you came up with, "Which you obviously didn't bother to read (or at least, understand), Part H, which is where the reg you referenced comes from, only applies to certain 800 MHZ frequency bands."
>
> My read is, quite a few freq's are banned from inflight use in the US.
>
> Hey, while I'm a "sorta tech guy", radio communications is not my strong point, and we're trying to understand a US government agency rules. Sorta like, "FAA rules are clear & succinct, except for the exceptions".
> Gives new meaning to, "Rules developed by lawyers so it takes a lawyer to understand.....sometimes....".
>
> Not picking a fight (it's the Internet, grand scheme of things, I better things to do).
> Speaking for myself, I have no control over the FAA, FCC, SSA RC, etc. Since I'm not a "current US contest pilot", I can't vote on current ideas or issues. That's my issue, not this forum.
> I sorta get bent when peeps get slammed when they may have issues outside of the "small box" that create other issues.
> Until I see further, I still think there are issues with ANY cellphone based communications (call, text, tracker) in the US while airborne.
>
> [sorry, you have not convinced me, just added to the clutter to a sorta different thread...... I was only relying to a slam against the SSA RC on being Luddites]

We are seeking clarification on FCC regs as applies to use of mobile data in airplanes - or specifically gliders. There is also an investigation of the practicality of accessing tracking web pages over 3G, 4G, LTE networks in the US. Initial indications are that, when it comes to tracking data, it is better to give than to receive.

I'd point out that there is a difference between: 1) permitting in flight access to tracker aggregation web pages (both from a competitive and FCC perspective), 2) the practicality of anyone being able to get good enough access to gain situational awareness at a distance given the connectivity issues and various lags in the systems, 3) permitting use of tracker transmitters in general and 4) specifying which tracker transmitters are or are not permitted.

Today only SPOT and InReach are permitted (Sean - my InReach seems to show up on Glideport.aero just fine). The issue on the table would be to remove the prohibition on mobile phone transmitters without endorsing or requiring its use. Whether it is or isn't prohibited by the FCC and whether the FCC would prosecute a pilot for use of low bandwidth data in mostly remote locations is certainly worth evaluating for any individual pilot, but since tracking via phone isn't required by the rules, and other transmitters are available and in use, the RC would neither be endorsing nor precluding mobile data use for sending tracking info. Note that the tracking pages that support mobile phone trackers appear on SSA.org so there is already precedent that the SSA is neutral on the issue.

9B

[Dan Marotta]

UPDATE!

I went and flew! Found wave a few miles east of Sandia Peak at 10K',
pulled engine to idle and climbed to 14K', shutdown and feathered the
prop and climbed up to 16,000' MSL. It was getting very cold inside and
the engine oil was also cooling rapidly so I started the engine, left it
a bit above idle, and flew home.

Way better day than operating my keyboard.

On 1/18/2016 10:13 AM, Dan Marotta wrote:
> Thanks, Sarah, it's now a matter of deciding whether to do a code
> search or to go fly... Hmmmmm....
>
> On 1/18/2016 6:57 AM, Sarah wrote:
>> 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
>
> --
> Dan, 5J

--
Dan, 5J

[SoaringXCellence]

On Monday, January 18, 2016 at 5:01:59 PM UTC-8, Dan Marotta wrote:
> UPDATE!
>
>
>
> I went and flew!* Found wave a few miles east of Sandia Peak at
> 10K', pulled engine to idle and climbed to 14K', shutdown and
> feathered the prop and climbed up to 16,000' MSL.* It was getting
> very cold inside and the engine oil was also cooling rapidly so I
> started the engine, left it a bit above idle, and flew home.
>
>
>
> Way better day than operating my keyboard.
>
>
>
>
> On 1/18/2016 10:13 AM, Dan Marotta
> wrote:
>
>
>
>
> Thanks, Sarah, it's now a matter of deciding whether to do a code
> search or to go fly...* Hmmmmm....
>
>
>
>
> On 1/18/2016 6:57 AM, Sarah wrote:
>
>
>
> 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
>
>
>
>
>
>
> --
>
> Dan, 5J
>
>
>
>
> --
>
> Dan, 5J

Now we're all jealous!

MB

[Paul B[_2_]]

Hi Martin

I have checked the site, but daylight visibility is not mentioned. Are any of the displays known for it?

Thanks

Paul

> If you are getting a nice picture from the ADSB software receiver on your
> RaspberryPi, you may want to look at the touch-sensitive TFT displays
> Adafruit sell for the RPi -

[Martin Gregorie[_5_]]

On Mon, 18 Jan 2016 21:33:47 -0800, Paul B wrote:

> Hi Martin
>
> I have checked the site, but daylight visibility is not mentioned. Are
> any of the displays known for it?
>
I haven't (yet) tried using them, but my guess would be that they are
similar to any other small screen that you might find on a budget satnav
or phone.

For comparison, I run LK8000 with terrain turned off and with the
background set to white and text set to solid black to maximise contrast
in my Libelle. I've used both Binatone B.350 and a Medion GoPAL S.3747
satnavs. The Binatone was usable but a bit washed out in normal
conditions and almost unreadable with direct sunlight on the display. The
Medion has a trans-reflective display and so is good in normal use but a
bit washed out with direct sunlight on the display.

I'll post a query on comp.raspberry-pi because I've been wondering how
well this sort of rig would run LK8000.


--
martin@ | Martin Gregorie
gregorie. | Essex, UK
org |

[Charlie M. (UH & 002 owner/pilot)]

On Monday, January 18, 2016 at 7:47:31 PM UTC-5, Andy Blackburn wrote:
> On Monday, January 18, 2016 at 2:56:39 PM UTC-8, Charlie M. (UH & 002 owner/pilot) wrote:
> > On Monday, January 18, 2016 at 4:05:49 PM UTC-5, Vaughn Simon wrote:
> > > On 1/18/2016 11:59 AM, Charlie M. (UH & 002 owner/pilot) wrote:
> > > > 1-The FCC rule section was linked.
> > >
> > > Wrongly, or at least incompletely applied to today's personal
> > > communications devices.
> > >
> > > > 2-Follow-up info was linked (regarding cell frequencies used as well as prohibited).
> > >
> > > Which you obviously didn't bother to read (or at least, understand).
> > > Part H, which is where the reg you referenced comes from, only applies
> > > to certain 800 MHZ frequency bands. Your personal communications device
> > > might be operating on any of at least six other frequency bands.
> > >
> > > > 3-I have not seen anyone show where my reading of the FCC rules is incorrect,
> > > thus cellphone use INFLIGHT is against the FCC rules.
> > >
> > > I did show it, you rejected it.
> > >
> > > > 4-I don't see anything in the FCC rules that allows use of any tracker while inflight.
> > >
> > > "Allows?" It's prohibitions that matter. If your REAL concern is
> > > trackers, then make your case on that basis. Stop playing FCC lawyer on
> > > the Internet.
> >
> > Not an "FCC lawyer" either on the Internet or other places.
> > Not having an "agenda" for/against technology.
> >
> > My comment on "cell based trackers" is whether or not these go against what airborne communications the FCC (in the US) allow, I'm not an expert, you "may" be better qualified than I am.
> >
> > You saying I "rejected parts of your posts" is not valid in my mind, I posted items (as did another) and then you did 2 posts back to back. Sorta hard for anyone to reject something "after the fact".
> > This is my 1st response to you and your view/data.
> > Not sure where you came up with, "Which you obviously didn't bother to read (or at least, understand), Part H, which is where the reg you referenced comes from, only applies to certain 800 MHZ frequency bands."
> >
> > My read is, quite a few freq's are banned from inflight use in the US.
> >
> > Hey, while I'm a "sorta tech guy", radio communications is not my strong point, and we're trying to understand a US government agency rules. Sorta like, "FAA rules are clear & succinct, except for the exceptions".
> > Gives new meaning to, "Rules developed by lawyers so it takes a lawyer to understand.....sometimes....".
> >
> > Not picking a fight (it's the Internet, grand scheme of things, I better things to do).
> > Speaking for myself, I have no control over the FAA, FCC, SSA RC, etc. Since I'm not a "current US contest pilot", I can't vote on current ideas or issues. That's my issue, not this forum.
> > I sorta get bent when peeps get slammed when they may have issues outside of the "small box" that create other issues.
> > Until I see further, I still think there are issues with ANY cellphone based communications (call, text, tracker) in the US while airborne.
> >
> > [sorry, you have not convinced me, just added to the clutter to a sorta different thread...... I was only relying to a slam against the SSA RC on being Luddites]
>
> We are seeking clarification on FCC regs as applies to use of mobile data in airplanes - or specifically gliders. There is also an investigation of the practicality of accessing tracking web pages over 3G, 4G, LTE networks in the US. Initial indications are that, when it comes to tracking data, it is better to give than to receive.
>
> I'd point out that there is a difference between: 1) permitting in flight access to tracker aggregation web pages (both from a competitive and FCC perspective), 2) the practicality of anyone being able to get good enough access to gain situational awareness at a distance given the connectivity issues and various lags in the systems, 3) permitting use of tracker transmitters in general and 4) specifying which tracker transmitters are or are not permitted.
>
> Today only SPOT and InReach are permitted (Sean - my InReach seems to show up on Glideport.aero just fine). The issue on the table would be to remove the prohibition on mobile phone transmitters without endorsing or requiring its use. Whether it is or isn't prohibited by the FCC and whether the FCC would prosecute a pilot for use of low bandwidth data in mostly remote locations is certainly worth evaluating for any individual pilot, but since tracking via phone isn't required by the rules, and other transmitters are available and in use, the RC would neither be endorsing nor precluding mobile data use for sending tracking info. Note that the tracking pages that support mobile phone trackers appear on SSA.org so there is already precedent that the SSA is neutral on the issue.
>
> 9B

Excellent reply, thank you.

[Charlie M. (UH & 002 owner/pilot)]

On Tuesday, January 19, 2016 at 5:22:57 AM UTC-5, Martin Gregorie wrote:
> On Mon, 18 Jan 2016 21:33:47 -0800, Paul B wrote:
>
> > Hi Martin
> >
> > I have checked the site, but daylight visibility is not mentioned. Are
> > any of the displays known for it?
> >
> I haven't (yet) tried using them, but my guess would be that they are
> similar to any other small screen that you might find on a budget satnav
> or phone.
>
> For comparison, I run LK8000 with terrain turned off and with the
> background set to white and text set to solid black to maximise contrast
> in my Libelle. I've used both Binatone B.350 and a Medion GoPAL S.3747
> satnavs. The Binatone was usable but a bit washed out in normal
> conditions and almost unreadable with direct sunlight on the display. The
> Medion has a trans-reflective display and so is good in normal use but a
> bit washed out with direct sunlight on the display.
>
> I'll post a query on comp.raspberry-pi because I've been wondering how
> well this sort of rig would run LK8000.
>
>
> --
> martin@ | Martin Gregorie
> gregorie. | Essex, UK
> org |

Since you seem rather well versed in R-pi, is there much support on a "R-pi" forum for things glider pilots may be interested in? If so, is there one or more sites that have better support and what would they be?

I've thought about using R-pi for other things, so it may be more worthwhile to cover many possible items under one basic processor.
TIA.

[smfidler]

Brilliant post. Happy to someone else gets it.

[smfidler]

RAS 1/19/16

Well, maybe for you Andy, but the InReach flight data (alt, airspeed, heading) doesn't show up for me or, more importantly, Tiffany. It did once, for a short time. Today, only position info (like Spot) is displayed for us. If it ever did work it is unreliable and inconsistent. This really should not be hard. When I recently inquired about the concern, I was told it was an "integration issue" and they could not figure it out right now (PAGC timeframe). I chose to leave it alone.

That said, it does drive us crazy. We know skylines works wonderfully for example. Th SSA tracker app, on the other hand, discourages our friends and colleagues almost immediately. Initially, when I described the idea (follow my flight live and watch a race!), many of my friends showed interest in following flights live. Most stopped bothering, rather quickly, including a major news reporter who became interested in soaring and gave it a shot.. To put it mildly, it didn't work well. They usually give up "watching" (10 minute updates is hardly, watching...) flights on the SSA page in under 30 minutes. Some switched to my InReach page (30 second updates). This of course misses the entire point of watching "a race" (no other gliders and no task info, of course, is available on the personal InReach (or spot) page).

Bottom line: the SSA tracking app is boring, pointless.l and any further development is a complete waste of time.

Side note: How hard would it be to have a contest commentator and do a live stream of every SSA contest flight by the way. This is not really that hard or far-fetched. Modern technology (the horror, I can already hear the screams....) such as the cellular data based LiveStream24 automatically gives us task relevant data and all sorts of telemetry such as altitude, current place, climb rate, heading, speed, etc. We could record these live streams and build an SSA YouTube contest task library of all of our tasks for pilots (new and experienced) and anyone else who is interested (family, friends, colleagues, students, media, sponsors, etc) to replay later. What a resource that would be. This could of course be done remotely for nearly zero cost. Amazing idea. But I digress.... Back to the actual SSA situation.

[smfidler]

Andy,

Well, maybe for you, but the InReach flight data (alt, airspeed, heading) doesn't show up for me or, more importantly, Tiffany (my crew/wife). It did once, a couple years ago, for a short time. Today, only position info (like Spot) is displayed for us. If it ever did work it was unreliable and inconsistent. This really should not be that hard. When I recently inquired about the concern, I was told it was an "integration issue" and they could not figure it out right now (PAGC timeframe). I chose to leave it alone.

That said, it does drive us crazy. We know Skylines and LiveTrack24 work wonderfully for example. The SSA tracker app, on the other hand, actually discourages our friends and colleagues almost immediately. Initially, when I described the idea (follow my flight live and watch a race!), many of my friends showed interest in following flights live. Most stopped bothering, rather quickly, including a major news reporter who became interested in soaring and gave the tracker a shot for a potential news story. To put it mildly, it didn't work well. They usually give up "watching" (10 minute updates is hardly, watching...) flights on the SSA page in under 30 minutes. Some switched to my InReach page (30 second updates). This was better but, of course, misses the entire point of watching "a race." No other competition gliders and no task info is available on the personal InReach (or Spot) page.

Bottom line: the SSA tracking app is boring, pointless, and any further development is a complete waste of time. It was a good idea but it has been overrun now by better, cheaper tech. Sat trackers is now, again, primarily emergency beacons. The truth is that most glider pilots are unwilling to pay the required Spot or InReach satellite "tracking" subscription and half of those who do pay forget to turn the tracking function on (simple checklist item...).

Side note: How hard would it be to have a contest commentator and do a live stream of every SSA contest flight by the way. Cell data based tracking enables this possibility. This is not really that hard or far-fetched. Modern technology (the horror, I can already hear the screams....) such as the cellular data based LiveStream24 automatically gives us task relevant data and all sorts of telemetry such as altitude, current place, climb rate, heading, speed, etc. We could simply record these live streams (with a good commentator) and then upload and build an SSA YouTube contest task library with all of our tasks for pilots (new and experienced) and anyone else who is interested (family, friends, colleagues, students, media, sponsors, etc) to replay anytime. What a resource that would be for the SSA and its membership. This could of course be done remotely for nearly zero cost. Amazing idea. But I digress.... Back to the actual SSA situation...

We have many great volunteers in the SSA. I am not blaming them for this problem, specifically. This is an example of more of a cultural problem. We consistently spend money (and precious volunteer time) on the wrong priorities. "The oligarchy" keeps us firmly in a relative stone age vs. our peer sports. See SSA website in general as a glaring example. The rest of the sailplane world seems to innovate and improve the sport continuously (Europe, Australia, etc).

Watching the Junior Worlds live via LiveTrack24 in Australia last month, for example, was an eye opening contrast in technology adoption philosophy. Not a single person (that I know of) brought up cellular data as being "illegal." Reason, because that is a ridiculous statement. In the US, we would have guys (oligarchs) saying it was illegal and calling the FAA. Pathetic, but sadly true. We all know this is a direct response to their technology insecurity and pointless crusade to attack any technology that moves, at almost any costs.

I wish to argue that we have numerous COTS (commercial off the shelf, ready to go) contest tracking options that are proven, great, affordable solutions (LiveTrack, Skylines, European COTS solutions, more every month) and yet we are still screwing around with some home grown (POS) SSA solution that doesn't really work for the trackers that are most worthwhile to track (InReach). Developing and maintaining custom software in an organization as small as the SSA is quite insane. See results. We should replace the SSA tracker with a livetrack24 solution (or similar).

Spot tracking and their infamous 10 minute "position only updates" (no altitude, no heading, no speed, etc) are completely useless and put people to sleep.

Furthermore, while watching an SSS tracker app task, any given pilot could be "on the ground" not moving (or dead) or could be at 18,000 ft going 150 knots! Who knows? Let's wait 10 minutes and see what happens! Did it move? Is it stuck? Is the transmitter blocked? Let's wait another 10 minutes and see what happens?!

Oh the suspense of SSA tracker app Spot contest tracking!!! Yeah! The SSA tracking app is useless for watching "a race" and even more useless as a safety tool. It can take up to 20 minutes to realize that a glider in in the same "Spot" (get it? Spot? -;)) or still moving. Far longer to determine if there is a problem, a potential land-out (or worse). This is a massive waste of critical time from a safety perspective. We should not even bother with the SSA satellite tracker tool any longer. It is already irrelevant. Has been for over a year. We must, wait for it, INNOVATE. Or put less politely, GET OUT OF OUR OWN WAY.

Meanwhile we have RAS "FCC lawyers" and anti technology "Oligarchs" typing out their posts in black robes wearing white curly wigs with round wire glasses as the scoff aloud. Cell phones are illegal in flight! Of course they have no idea what that actually means technically. "We walk uphill and into the wind all the time at the SSA, and we like it! See!" Meanwhile paragliding and hang-gliders (and large amounts of the sailplane world) are light years ahead of us...and gaining...

It's really quite out of control...the SSA needs to get out of its own way in many, many cases. Cellular data is a fine example. We need leaders who can help our sport innovate in the USA, not leaders who are hallucinating (that pilots can simply leech from BVR with their Flarms or cell phones) the desperate need to "protect us" from any new (evil) technology that comes along, at all costs like a on infamous 1700's witch hunt...

"Those young whipper snappers don't even look out the damn window anymore! They just watch their cell phones and Flarms like an X box game, finding synthetic thermals and leaching us, the rightful lords of soaring, from miles away!"

"It's unfair! It's not the tradition of soaring! It's blasphemous! Back in my day I had a map and compass, and I liked it! That's all you need for soaring! No fancy screens and gadgets! Pilots who use gadgets are "weak-assed!" Yeah! Yeah! It's weak assed!"

"Burn them! Burn those whipper snapping witches alive! Burn the young technology whipper snapper witches! Yeah! Guilty! GUILTY! Cheaters! They just use the cell tracking data to drive their leeching autopilots!!!"

"Weather data...Fuey! That's cheating! We just flew right thru the thunderstorm, and we liked it!"

Seriously. We need some reasonable people to take the reigns here. It's become a little spooky.

[[email protected]]

I (and a few others I know) used IGCDroid last year put out by alan walls.

My wish was the same as yours - I wanted my crew (My wife) to be able to see where I was and how I was doing - with the IGCDroid - she know my hight, speed and could watch me in close enough to real time, in order to know when to start up the van!.

Alan is going to be at the convention.

WH1

[kiwiindenver]

No, Alan is not going to the convention. Pedja, who wrote the Web tracker will be.

Alan

[xcnick]

On Monday, January 18, 2016 at 8:55:23 AM UTC-8, jfitch wrote:
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

Yup, that is what I am looking for. When leaving Boundary something like:

OK Google, Can you tell me how to get home around the cells?
"I'm completely operational, and all my circuits are functioning perfectly. I am putting myself to the fullest possible use, which is all I think that any conscious entity can ever hope to do. "
OK Google, Sierras or Grant?
"This mission is too important for me to allow you to jeopardize it. Go direct"
An hour later: OK Google, What the heck? There is a super cell over Gimmy's Bowl
"I've just picked up a fault in the 302 unit. It's going to go 100% failure in 72 seconds."
OK Google, open the spoilers.
"I am sorry Dave. I'm afraid I can't do that. Look Dave, I can see you're really upset about this. I honestly think you ought to sit down calmly, take a stress pill, and think things over."
OK Google, I won't argue with you anymore! Open the spoilers!
Dave, this conversation can serve no purpose anymore. Goodbye.

[Charlie M. (UH & 002 owner/pilot)]

On Tuesday, January 19, 2016 at 8:50:18 PM UTC-5, xcnick wrote:
> On Monday, January 18, 2016 at 8:55:23 AM UTC-8, jfitch wrote:
> 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
>
> Yup, that is what I am looking for. When leaving Boundary something like:
>
> OK Google, Can you tell me how to get home around the cells?
> "I'm completely operational, and all my circuits are functioning perfectly. I am putting myself to the fullest possible use, which is all I think that any conscious entity can ever hope to do. "
> OK Google, Sierras or Grant?
> "This mission is too important for me to allow you to jeopardize it. Go direct"
> An hour later: OK Google, What the heck? There is a super cell over Gimmy's Bowl
> "I've just picked up a fault in the 302 unit. It's going to go 100% failure in 72 seconds."
> OK Google, open the spoilers.
> "I am sorry Dave. I'm afraid I can't do that. Look Dave, I can see you're really upset about this. I honestly think you ought to sit down calmly, take a stress pill, and think things over."
> OK Google, I won't argue with you anymore! Open the spoilers!
> Dave, this conversation can serve no purpose anymore. Goodbye.

ROTFLMAO..... excellent! 2 gold stars for you tonight!

[xcnick]

Good, I wondered if it was worth sharing. I am in a state of shock immersing myself in this computer stuff most of you take for granted. I have been driving around with steam gauges and recording flights with a hand held GPS if I happen to find a couple of AA batteries. This winter is a cross between taking college courses and Orwell's 1984. Until last week I used a flip phone. Now if want to receive a call I have to agree for them to monetize all my content, take my first born and agree to be bombarded with adds which is data I pay for.

Anyways, back on topic, I bought the OTG wire the author of HIZ recommended and it powers the radio receiver as well as charging the cell phone. As I read on, it is a big deal because all the other wires just power the radio while Avare and bright screen kills the little, I mean tiny, gerbil powering the phone.

[Paul B[_2_]]

Thank you Martin

Cheers


Paul

On Tuesday, 19 January 2016 20:22:57 UTC+10, Martin Gregorie wrote:
> On Mon, 18 Jan 2016 21:33:47 -0800, Paul B wrote:
>
> > Hi Martin
> >
> > I have checked the site, but daylight visibility is not mentioned. Are
> > any of the displays known for it?
> >
> I haven't (yet) tried using them, but my guess would be that they are
> similar to any other small screen that you might find on a budget satnav
> or phone.
>
> For comparison, I run LK8000 with terrain turned off and with the
> background set to white and text set to solid black to maximise contrast
> in my Libelle. I've used both Binatone B.350 and a Medion GoPAL S.3747
> satnavs. The Binatone was usable but a bit washed out in normal
> conditions and almost unreadable with direct sunlight on the display. The
> Medion has a trans-reflective display and so is good in normal use but a
> bit washed out with direct sunlight on the display.
>
> I'll post a query on comp.raspberry-pi because I've been wondering how
> well this sort of rig would run LK8000.
>
>
> --
> martin@ | Martin Gregorie
> gregorie. | Essex, UK
> org |

[Martin Gregorie[_5_]]

On Tue, 19 Jan 2016 05:42:22 -0800, Charlie M. (UH & 002 owner/pilot)
wrote:

> Since you seem rather well versed in R-pi, is there much support on a
> "R-pi" forum for things glider pilots may be interested in? If so, is
> there one or more sites that have better support and what would they be?
>
Not much directly, but just recently a new expansion board for the Pi-
zero has appeared. Its designed for use in drone autopilots, but could
equally be the basis for a fairly fancy vario and/or nav system. Just add
code and a GPS... Here are links to an article about it and its website.

http://www.theregister.co.uk/2016/01/14/pfxmini_linux_autopilot/

https://erlerobotics.com/blog/pxfmini-open-autopilot-shield-for-raspberry-
pi-zero/

Andrew Tridgell, mentioned in the article, is well respected as an open
source programmer and the author of Samba, which lets Linux/UNIX systems
access files on Windows boxes and vice versa and is the man behind
several modeller's autopilot systems.

All RPi models share the same GPIO bus (expanded slightly on the RPi 2),
so any expansion card should work with any type of RPi. Many boards have
GPIO sockets matching their GPIO pins, so the cards can be stacked.

All RPi models can be run headless and those with an RJ45 ethernet socket
boot up with a DHCP client enabled, so should be able to pick up an IP
from your home router. IOW you can log in to it from anything running
Linux or Apple with no other software needed. Using Windows? install
PuTTY on the Windows system and you can login and use the RPi's command
line interface and transfer files. If you want a graphical interface
you'll need to install an X-server on your Windows box. There are FOSS X-
servers but as I don't use them (all my computers run Linux) you'll get
no recommendations from me.

Like all Linux systems, Raspbian comes with the full set of development
tools as standard.


----
The main RPi forum I use is the comp.sys.raspberry-pi newsgroup.

For websites, the starting point is probably http://www.raspberrypi.org/
which has links to a lot of other useful sites. The main OS is Raspbian,
a Debian clone, so look here: http://www.debian.org/

> I've thought about using R-pi for other things, so it may be more
> worthwhile to cover many possible items under one basic processor.
>
Sounds good to me. BTW, the XSCALE processor or derivative used by all
WinCE and WM5/6 satnavs and PNAs is an ARM Cortex CPU, the same ARM
series as the RPi uses. The main differences are that the RPis are all
clocked faster (at least 800MHz while all the WinCE things I've used ran
at about 500MHz), have more RAM (at least 500MB vs <256) and the RPis all
have a GPU. IOW, any code ported from WM5/6 (think XCSoar and LK8000)
should run faster on an RPi than on the WM5/6 device.


--
martin@ | Martin Gregorie
gregorie. | Essex, UK
org |

[[email protected]]

On Tuesday, January 19, 2016 at 7:50:18 PM UTC-6, xcnick wrote:
> On Monday, January 18, 2016 at 8:55:23 AM UTC-8, jfitch wrote:
> 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
>
> Yup, that is what I am looking for. When leaving Boundary something like:
>
> OK Google, Can you tell me how to get home around the cells?
> "I'm completely operational, and all my circuits are functioning perfectly. I am putting myself to the fullest possible use, which is all I think that any conscious entity can ever hope to do. "
> OK Google, Sierras or Grant?
> "This mission is too important for me to allow you to jeopardize it. Go direct"
> An hour later: OK Google, What the heck? There is a super cell over Gimmy's Bowl
> "I've just picked up a fault in the 302 unit. It's going to go 100% failure in 72 seconds."
> OK Google, open the spoilers.
> "I am sorry Dave. I'm afraid I can't do that. Look Dave, I can see you're really upset about this. I honestly think you ought to sit down calmly, take a stress pill, and think things over."
> OK Google, I won't argue with you anymore! Open the spoilers!
> Dave, this conversation can serve no purpose anymore. Goodbye.

After all the dirt-throwing and trump-esque rantings about oligarchs and subversive SSA units (no doubt infiltrated by Islamists) it is refreshing to read your well-researched posting, Nick. Thanks, made my day.

[smfidler]

ROTFL!!!

On Tuesday, January 19, 2016 at 8:50:18 PM UTC-5, xcnick wrote:
> On Monday, January 18, 2016 at 8:55:23 AM UTC-8, jfitch wrote:
> 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
>
> Yup, that is what I am looking for. When leaving Boundary something like:
>
> OK Google, Can you tell me how to get home around the cells?
> "I'm completely operational, and all my circuits are functioning perfectly. I am putting myself to the fullest possible use, which is all I think that any conscious entity can ever hope to do. "
> OK Google, Sierras or Grant?
> "This mission is too important for me to allow you to jeopardize it. Go direct"
> An hour later: OK Google, What the heck? There is a super cell over Gimmy's Bowl
> "I've just picked up a fault in the 302 unit. It's going to go 100% failure in 72 seconds."
> OK Google, open the spoilers.
> "I am sorry Dave. I'm afraid I can't do that. Look Dave, I can see you're really upset about this. I honestly think you ought to sit down calmly, take a stress pill, and think things over."
> OK Google, I won't argue with you anymore! Open the spoilers!
> Dave, this conversation can serve no purpose anymore. Goodbye.

[Andy Blackburn[_3_]]

On Sunday, January 17, 2016 at 10:38:00 PM UTC-8, Darryl Ramm wrote:

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

Here is a Kickstarter project to build a dual-band ADS-B In box based on Raspberry Pi and the Stratux Open Source project. It should be pretty straightforward to get NMEA sentences put out to the serial port and a level shifter to get to serial port voltages.

https://www.kickstarter.com/projects/251459606/flightbox-ads-b-receiver-kit

Stratux is written in Go. Here is the ask for creating code to put NMEA sentences onto the serial port.

https://github.com/cyoung/stratux/issues/218

A harder job would be to turn the RPi into a Mux to merge Flarm NMEA with the FlightBox UAT and TIS-B traffic and deliver a merged NMEA stream. Then all I need is ADS-B Out and I've got visibility into everything. Even before then I should be able to see

Any takers?

9B

[Darryl Ramm]

On Saturday, January 23, 2016 at 1:26:55 PM UTC-8, Andy Blackburn wrote:
> On Sunday, January 17, 2016 at 10:38:00 PM UTC-8, Darryl Ramm wrote:
>
> >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.
>
> Here is a Kickstarter project to build a dual-band ADS-B In box based on Raspberry Pi and the Stratux Open Source project. It should be pretty straightforward to get NMEA sentences put out to the serial port and a level shifter to get to serial port voltages.
>
> https://www.kickstarter.com/projects/251459606/flightbox-ads-b-receiver-kit
>
> Stratux is written in Go. Here is the ask for creating code to put NMEA sentences onto the serial port.
>
> https://github.com/cyoung/stratux/issues/218
>
> A harder job would be to turn the RPi into a Mux to merge Flarm NMEA with the FlightBox UAT and TIS-B traffic and deliver a merged NMEA stream. Then all I need is ADS-B Out and I've got visibility into everything. Even before then I should be able to see

The Raspberry Pi without some work is not ideal here if you want hard-wired serial out. They only have a single UART. TTL level so yes you level shift that for starters. So you can take NMEA position and traffic data in on that port from a PowerFLARM, but you don't have another serial port to send this out. That would be OK if you were going Bluetooth or WiFi from the Raspberry Pi to the destination device. It is not uncommon to 'bitbang' general IO pins or use a USB to serial adapter to get serial ports on the raspberry Pi but for anything intended to be reliable I would want a real hardwired UART an decent driver. So maybe add some UART systems engineering to the skills needed...

> Any takers?
>
> 9B

[Andy Blackburn[_3_]]

On Saturday, January 23, 2016 at 1:54:56 PM UTC-8, Darryl Ramm wrote:
>
> The Raspberry Pi without some work is not ideal here if you want hard-wired serial out. They only have a single UART. TTL level so yes you level shift that for starters. So you can take NMEA position and traffic data in on that port from a PowerFLARM, but you don't have another serial port to send this out. That would be OK if you were going Bluetooth or WiFi from the Raspberry Pi to the destination device. It is not uncommon to 'bitbang' general IO pins or use a USB to serial adapter to get serial ports on the raspberry Pi but for anything intended to be reliable I would want a real hardwired UART an decent driver. So maybe add some UART systems engineering to the skills needed...

I forgot there's only one UART on the RPi. Alternatively, you can get a K6Mux and smash the NMEA streams together after the fact. My K6Mux has been super-reliable.

Still a cool project.

9B

[Craig Funston]

On Saturday, January 23, 2016 at 2:43:32 PM UTC-8, Andy Blackburn wrote:
> On Saturday, January 23, 2016 at 1:54:56 PM UTC-8, Darryl Ramm wrote:
> >
> > The Raspberry Pi without some work is not ideal here if you want hard-wired serial out. They only have a single UART. TTL level so yes you level shift that for starters. So you can take NMEA position and traffic data in on that port from a PowerFLARM, but you don't have another serial port to send this out. That would be OK if you were going Bluetooth or WiFi from the Raspberry Pi to the destination device. It is not uncommon to 'bitbang' general IO pins or use a USB to serial adapter to get serial ports on the raspberry Pi but for anything intended to be reliable I would want a real hardwired UART an decent driver. So maybe add some UART systems engineering to the skills needed...
>
> I forgot there's only one UART on the RPi. Alternatively, you can get a K6Mux and smash the NMEA streams together after the fact. My K6Mux has been super-reliable.
>
> Still a cool project.
>
> 9B

I saw that too and noted the WAAS GPS module. Pretty cool.

7Q

[Darryl Ramm]

On Saturday, January 23, 2016 at 3:23:18 PM UTC-8, Craig Funston wrote:
> On Saturday, January 23, 2016 at 2:43:32 PM UTC-8, Andy Blackburn wrote:
> > On Saturday, January 23, 2016 at 1:54:56 PM UTC-8, Darryl Ramm wrote:
> > >
> > > The Raspberry Pi without some work is not ideal here if you want hard-wired serial out. They only have a single UART. TTL level so yes you level shift that for starters. So you can take NMEA position and traffic data in on that port from a PowerFLARM, but you don't have another serial port to send this out. That would be OK if you were going Bluetooth or WiFi from the Raspberry Pi to the destination device. It is not uncommon to 'bitbang' general IO pins or use a USB to serial adapter to get serial ports on the raspberry Pi but for anything intended to be reliable I would want a real hardwired UART an decent driver. So maybe add some UART systems engineering to the skills needed...
> >
> > I forgot there's only one UART on the RPi. Alternatively, you can get a K6Mux and smash the NMEA streams together after the fact. My K6Mux has been super-reliable.
> >
> > Still a cool project.
> >
> > 9B
>
> I saw that too and noted the WAAS GPS module. Pretty cool.
>
> 7Q

Just to be clear, lots of consumer GPS chipsets support WAAS. And that is all they are doing here, not to be confused with say a TSO-C145c "WAAS GPS" (like an ADS-B Out compliant systems might use) another whole thing, much more complex. My ancient PDA CF card GPS has WAAS. The Status ADS-B receivers and Garmin GDL 39 ADS-B receivers all have WAAS GPS. FLARM devices use WAAS.

[Craig Funston]

Darryl, thanks for being our ADS-B ambassador / guru. At this point I imagine you can cut and paste many of your responses. I'll go back and study harder :-)

[[email protected]]

On Sunday, January 24, 2016 at 2:07:56 AM UTC-6, Craig Funston wrote:
> Darryl, thanks for being our ADS-B ambassador / guru. At this point I imagine you can cut and paste many of your responses. I'll go back and study harder :-)

All these friggin acronyms - you sound like Sarah Palin to me, incoherent babble, anyone speaking English around here?

[Jonathan St. Cloud]

Well at least the punctuation is correct on the posts, something Sarah is incapable of learning.

On Sunday, January 24, 2016 at 11:05:22 AM UTC-8, wrote:
> On Sunday, January 24, 2016 at 2:07:56 AM UTC-6, Craig Funston wrote:
> > Darryl, thanks for being our ADS-B ambassador / guru. At this point I imagine you can cut and paste many of your responses. I'll go back and study harder :-)
>
> All these friggin acronyms - you sound like Sarah Palin to me, incoherent babble, anyone speaking English around here?

[Darryl Ramm]

On Sunday, January 24, 2016 at 11:05:22 AM UTC-8, wrote:
> On Sunday, January 24, 2016 at 2:07:56 AM UTC-6, Craig Funston wrote:
> > Darryl, thanks for being our ADS-B ambassador / guru. At this point I imagine you can cut and paste many of your responses. I'll go back and study harder :-)
>
> All these friggin acronyms - you sound like Sarah Palin to me, incoherent babble, anyone speaking English around here?

The coherent version of this as I have said many times is you should get a transponder and/or PowerFLARM depending on your needs. Everything else is futureware most glider pilots don't need to worry about now. If you can't understand the incoherent version then it's not something you should be worrying about.

[Sarah[_2_]]

Really?

Ok, I'm out. Civil conversation has ended here.


On Sunday, January 24, 2016 at 1:12:52 PM UTC-6, Jonathan St. Cloud wrote:
> Well at least the punctuation is correct on the posts, something Sarah is incapable of learning.
>
> On Sunday, January 24, 2016 at 11:05:22 AM UTC-8, wrote:
> > On Sunday, January 24, 2016 at 2:07:56 AM UTC-6, Craig Funston wrote:
> > > Darryl, thanks for being our ADS-B ambassador / guru. At this point I imagine you can cut and paste many of your responses. I'll go back and study harder :-)
> >
> > All these friggin acronyms - you sound like Sarah Palin to me, incoherent babble, anyone speaking English around here?

[[email protected]]

On Sunday, January 24, 2016 at 1:21:46 PM UTC-6, Darryl Ramm wrote:
> On Sunday, January 24, 2016 at 11:05:22 AM UTC-8, wrote:
> > On Sunday, January 24, 2016 at 2:07:56 AM UTC-6, Craig Funston wrote:
> > > Darryl, thanks for being our ADS-B ambassador / guru. At this point I imagine you can cut and paste many of your responses. I'll go back and study harder :-)
> >
> > All these friggin acronyms - you sound like Sarah Palin to me, incoherent babble, anyone speaking English around here?
>
> The coherent version of this as I have said many times is you should get a transponder and/or PowerFLARM depending on your needs. Everything else is futureware most glider pilots don't need to worry about now. If you can't understand the incoherent version then it's not something you should be worrying about.

Sorry Darryl, you are very coherent and agreeable - I was just baffled by the last couple of posts. I do have PFlarm and a transponder in my glider, wouldn't fly without them.

[[email protected]]

On Sunday, January 24, 2016 at 2:05:22 PM UTC-5, wrote:
> On Sunday, January 24, 2016 at 2:07:56 AM UTC-6, Craig Funston wrote:
> > Darryl, thanks for being our ADS-B ambassador / guru. At this point I imagine you can cut and paste many of your responses. I'll go back and study harder :-)
>
> All these friggin acronyms - you sound like Sarah Palin to me, incoherent babble, anyone speaking English around here?

OICU812
LOL
UH

[Dan Marotta]

Please don't leave, Sarah. You've at least had something intelligent to
say on the original topic of this post.


On 1/24/2016 12:24 PM, Sarah wrote:
> Really?
>
> Ok, I'm out. Civil conversation has ended here.
>
>
> On Sunday, January 24, 2016 at 1:12:52 PM UTC-6, Jonathan St. Cloud wrote:
>> Well at least the punctuation is correct on the posts, something Sarah is incapable of learning.
>>
>> On Sunday, January 24, 2016 at 11:05:22 AM UTC-8, wrote:
>>> On Sunday, January 24, 2016 at 2:07:56 AM UTC-6, Craig Funston wrote:
>>>> Darryl, thanks for being our ADS-B ambassador / guru. At this point I imagine you can cut and paste many of your responses. I'll go back and study harder :-)
>>> All these friggin acronyms - you sound like Sarah Palin to me, incoherent babble, anyone speaking English around here?

--
Dan, 5J

[Jonathan St. Cloud]

Oh, big misinterpretation here. I joking as I responded to and with quoted text of another's post regarding Sarah Palin, especially in light of her recent endorsement "speech" of the Donald. I certainly would not insult anyone on this newsgroup. And to have a lady actually post and comment is great as we have virtually no ladies flying or posting.




On Sunday, January 24, 2016 at 4:58:03 PM UTC-8, Dan Marotta wrote:
> Please don't leave, Sarah.* You've at least had something
> intelligent to say on the original topic of this post.
>
>
>
>
>
>
> On 1/24/2016 12:24 PM, Sarah wrote:
>
>
>
> Really?
>
> Ok, I'm out. Civil conversation has ended here.
>
>
> On Sunday, January 24, 2016 at 1:12:52 PM UTC-6, Jonathan St. Cloud wrote:
>
>
> Well at least the punctuation is correct on the posts, something Sarah is incapable of learning.
>
> On Sunday, January 24, 2016 at 11:05:22 AM UTC-8, wrote:
>
>
> On Sunday, January 24, 2016 at 2:07:56 AM UTC-6, Craig Funston wrote:
>
>
> Darryl, thanks for being our ADS-B ambassador / guru. At this point I imagine you can cut and paste many of your responses. I'll go back and study harder :-)
>
>
> All these friggin acronyms - you sound like Sarah Palin to me, incoherent babble, anyone speaking English around here?
>
>
>
>
>
>
>
>
> --
>
> Dan, 5J

[Andy Blackburn[_3_]]

Okay. I've been in contact with some folks developing ADS-B In receivers and the associated software. Providing NMEA serial output for ADS-B traffic (specifically PFLAA and GPRMC sentences) is now on the development list for Stratux - which is the open-source software project for ADS-B In. It will allow you to connect your glider flight computer to any of the inexpensive single or dual-band ADS-B receivers based on Raspberry Pi.

I have also take with one of the commercial hardware developers for ADS-B In receivers - FlightBox. They will have a product out this spring for $150-250 for UAT only and UAT/1090ES respectively. You should also be able to pick up TIS-B - either what's intended for other aircraft near you, or tailored for you if you have ADS-B Out. I have not yet figured out exactly how to configure ADS-B Out to get the correct TIS-B traffic - but that should be just setting parameters. Since I don't have a way to do ADS-B Out yet that is a future project.

It requires a little work to add a serial port to the hardware so I'm trying to figure out how to get that done too. If there were enough interest I suspect it could get manufactured professionally rather than being a home electronics project.

If you want to use it standalone it should work as-is, but you could also use it with Flarm or PowerFlarm and use a K6Mux to combine the NMEA traffic streams and connect to a glide computer serial port.

I'd be interested in whether people have an interest in such a device - I suspect Dan does. Any others?

References:

https://www.kickstarter.com/projects/251459606/flightbox-ads-b-receiver-kit

http://stratux.me

http://www.cumulus-soaring.com/k6.htm

9B

[smfidler]

Sounds fun, and we are currently working on some parallel ideas with a small start up. I would be happy to join in on your project.

[Dan Marotta]

Yes, I'm interested though my needs have recently changed.

I'm offering for sale my LAK-17a just as soon as I can write up an ad
and post some pictures. Later I'll be selling my Pipistrel Sinus.
These two have to go to make room for the Stemme S10-VT that will soon
be coming. :-D

On 1/29/2016 3:11 PM, Andy Blackburn wrote:
> Okay. I've been in contact with some folks developing ADS-B In receivers and the associated software. Providing NMEA serial output for ADS-B traffic (specifically PFLAA and GPRMC sentences) is now on the development list for Stratux - which is the open-source software project for ADS-B In. It will allow you to connect your glider flight computer to any of the inexpensive single or dual-band ADS-B receivers based on Raspberry Pi.
>
> I have also take with one of the commercial hardware developers for ADS-B In receivers - FlightBox. They will have a product out this spring for $150-250 for UAT only and UAT/1090ES respectively. You should also be able to pick up TIS-B - either what's intended for other aircraft near you, or tailored for you if you have ADS-B Out. I have not yet figured out exactly how to configure ADS-B Out to get the correct TIS-B traffic - but that should be just setting parameters. Since I don't have a way to do ADS-B Out yet that is a future project.
>
> It requires a little work to add a serial port to the hardware so I'm trying to figure out how to get that done too. If there were enough interest I suspect it could get manufactured professionally rather than being a home electronics project.
>
> If you want to use it standalone it should work as-is, but you could also use it with Flarm or PowerFlarm and use a K6Mux to combine the NMEA traffic streams and connect to a glide computer serial port.
>
> I'd be interested in whether people have an interest in such a device - I suspect Dan does. Any others?
>
> References:
>
> https://www.kickstarter.com/projects/251459606/flightbox-ads-b-receiver-kit
>
> http://stratux.me
>
> http://www.cumulus-soaring.com/k6.htm
>
> 9B

--
Dan, 5J

[Andy Blackburn[_3_]]

Some news on TIS-B services.

It appears that the FAA will be modifying TIS-B to make it available to anyone with an ADS-B receiver, regardless of ADS-B Out carriage. This means that you should be able to see rebroadcast of all transponder-equipped (as well as "opposite-band" ADS-B Out) aircraft within range of SSR with resolution as good as a few hundred feet simply by acquiring one of the relatively inexpensive ($100-150) ADS-B receivers. It may be available as early as this summer. It appears that this will enable a "God's eye view" of all transponder-equipped gliders (and other aircraft) in a broad flying area so long as there is SSR coverage. It remains to be confirmed whether or not PowerFLARM ADS-B In can decode TIS-B traffic. My understanding is that nothing special was included in the PowerFLARM design to accommodate TIS-B, but I am unsure whether TIS-B traffic resembles ADS-B direct transmissions closely enough to be decoded by PowerFLARM anyway. Either way there ought to be a glider-relevant solution available this year.

http://www.aopa.org/News-and-Video/All-News/2016/January/04/FAA-announces-changes-to-TIS-B

Additionally, it seems that the FAA will now rebroadcast ALL traffic regardless of ADS-B Out performance and configuration. Previously, some aircraft would not be rebroadcast if their ADS-B Out did not meet certain performance criteria and, as a result, would effectively be invisible so far as TIS-B services were concerned.

Things are moving pretty quickly. Surprising.

9B

[son_of_flubber]

On Tuesday, February 9, 2016 at 2:30:04 PM UTC-5, Andy Blackburn wrote:
>I am unsure whether TIS-B traffic resembles ADS-B direct transmissions closely enough to be decoded by PowerFLARM

I want to ask Flarm Inc. for clarification on this point, but I'm not sure of how to ask the right question.

[Mike Schumann[_2_]]

On Tuesday, February 9, 2016 at 2:30:04 PM UTC-5, Andy Blackburn wrote:
> Some news on TIS-B services.
>
> It appears that the FAA will be modifying TIS-B to make it available to anyone with an ADS-B receiver, regardless of ADS-B Out carriage. This means that you should be able to see rebroadcast of all transponder-equipped (as well as "opposite-band" ADS-B Out) aircraft within range of SSR with resolution as good as a few hundred feet simply by acquiring one of the relatively inexpensive ($100-150) ADS-B receivers. It may be available as early as this summer. It appears that this will enable a "God's eye view" of all transponder-equipped gliders (and other aircraft) in a broad flying area so long as there is SSR coverage. It remains to be confirmed whether or not PowerFLARM ADS-B In can decode TIS-B traffic. My understanding is that nothing special was included in the PowerFLARM design to accommodate TIS-B, but I am unsure whether TIS-B traffic resembles ADS-B direct transmissions closely enough to be decoded by PowerFLARM anyway. Either way there ought to be a glider-relevant solution available this year.
>
> http://www.aopa.org/News-and-Video/All-News/2016/January/04/FAA-announces-changes-to-TIS-B
>
> Additionally, it seems that the FAA will now rebroadcast ALL traffic regardless of ADS-B Out performance and configuration. Previously, some aircraft would not be rebroadcast if their ADS-B Out did not meet certain performance criteria and, as a result, would effectively be invisible so far as TIS-B services were concerned.
>
> Things are moving pretty quickly. Surprising.
>
> 9B

I believe that you are totally misinterpreting the information in the AOPA link you provided. While AOPA has been lobbying for years for the FAA to transmit all TIS-B data so that aircraft without ADS-B OUT will have access to this data, this is NOT what the FAA is doing. Instead, the FAA is actually clamping down and will no longer transmit TIS-B data to aircraft that are equipped with ADS-B OUT equipment that use GPS position sources that do not meet minimal performance standards.

If you want to reliably receive TIS-B data from an ADS-B ground station, your aircraft MUST be ADS-B OUT equipped.

Note: PowerFLARM does not support TIS-B and there has been no information provided by anyone that they are even thinking about adding this functionality to their product. That's a huge shortcoming in the product that is certainly not helping their sales efforts.

[JS]

I read the AOPA article the same way Andy does.
The ghosting thing is a problem, alarms that "you're near yourself" are useless.
But that's always been a problem with non-FLARM proximity warnings, the algorithms are not set for simple things like sharing a thermal.
Jim

[Andy Blackburn[_3_]]

On Tuesday, February 9, 2016 at 7:50:02 PM UTC-8, Mike Schumann wrote:

Hey Mike - if I'm misinterpreting it then so is AOPA (not that it's impossible). Take a look here, starting at 4:55.

http://www.aopa.org/AOPA-Live?watch=%7B3C1A2840-97BF-4676-BBB4-288197D11A94%7D

9B


>
> I believe that you are totally misinterpreting the information in the AOPA link you provided. While AOPA has been lobbying for years for the FAA to transmit all TIS-B data so that aircraft without ADS-B OUT will have access to this data, this is NOT what the FAA is doing. Instead, the FAA is actually clamping down and will no longer transmit TIS-B data to aircraft that are equipped with ADS-B OUT equipment that use GPS position sources that do not meet minimal performance standards.
>
> If you want to reliably receive TIS-B data from an ADS-B ground station, your aircraft MUST be ADS-B OUT equipped.
>
> Note: PowerFLARM does not support TIS-B and there has been no information provided by anyone that they are even thinking about adding this functionality to their product. That's a huge shortcoming in the product that is certainly not helping their sales efforts.

[son_of_flubber]

On Wednesday, February 10, 2016 at 12:06:59 AM UTC-5, Andy Blackburn wrote:

> Hey Mike - if I'm misinterpreting it then so is AOPA (not that it's impossible). Take a look here, starting at 4:55.
>
> http://www.aopa.org/AOPA-Live?watch=%7B3C1A2840-97BF-4676-BBB4-288197D11A94%7D
>

But there is no approved implementation plan for doing what AOPA wants. Whether it is technically feasible within the hard constraints remains to be proven.

[Dan Marotta]

What I heard was that the FAA has agreed to /_work with_/ AOPA towards
implementing a solution, not that they've agreed to do anything. Still,
there's hope...

On 2/10/2016 7:03 AM, son_of_flubber wrote:
> On Wednesday, February 10, 2016 at 12:06:59 AM UTC-5, Andy Blackburn wrote:
>
>> Hey Mike - if I'm misinterpreting it then so is AOPA (not that it's impossible). Take a look here, starting at 4:55.
>>
>> http://www.aopa.org/AOPA-Live?watch=%7B3C1A2840-97BF-4676-BBB4-288197D11A94%7D
>>
> But there is no approved implementation plan for doing what AOPA wants. Whether it is technically feasible within the hard constraints remains to be proven.

--
Dan, 5J

[kirk.stant]

On Tuesday, February 9, 2016 at 9:50:02 PM UTC-6, Mike Schumann wrote:

> I believe that you are totally misinterpreting the information in the AOPA link you provided. While AOPA has been lobbying for years for the FAA to transmit all TIS-B data so that aircraft without ADS-B OUT will have access to this data, this is NOT what the FAA is doing. Instead, the FAA is actually clamping down and will no longer transmit TIS-B data to aircraft that are equipped with ADS-B OUT equipment that use GPS position sources that do not meet minimal performance standards.
>
> If you want to reliably receive TIS-B data from an ADS-B ground station, your aircraft MUST be ADS-B OUT equipped.

Mike, please go back and carefully re-read the AOPA article. While poorly written, it specifically states that the FAA is implementing 2 changes: First, it will allow aircraft with non-conforming ADS-B out to be seen by certified ADS-B in (which covers people with experimental setups - perhaps even a Powerflarm GPS hooked up to a Trig TT21? Darryl, comment?) and second, it gets rid of the "hockey puck" limitation on TIS-B traffic transmission, so now anyone with an ADS-B IN receiver will see all the TIS-B traffic around them, not just traffic sent to a nearby certified ADS-B out-equipped aircraft.

It does talk about "certified ADS-B receivers". Does that include the inexpensive ones used with a tablet or smartphone? I may need to look into that myself.

> Note: PowerFLARM does not support TIS-B and there has been no information provided by anyone that they are even thinking about adding this functionality to their product. That's a huge shortcoming in the product that is certainly not helping their sales efforts.

Again, PowerFLARM does EXACTLY what it was designed for - provide glider-to-glider (with some additions, like british military aircraft) COLLISION AVOIDANCE information, with the added benefit of seeing all mode S ADS-B and Mode C transponder aircraft nearby. It is optimized for the European environment (no idiotic UAT) but works pretty damn well here in the US. Now, it looks like adding an inexpensive ADS-B in receiver will get TIS-B into your glider cockpit even if you don't have an ADS-B out setup.

It'll be interesting to see what glider nav setup first incorporates the ability to display TIS-B traffic - I'm hoping SYM on my Oudie will!

Kirk
66

[Mike Schumann[_2_]]

On Wednesday, February 10, 2016 at 10:29:20 AM UTC-5, Dan Marotta wrote:
> What I heard was that the FAA has agreed to work with
> AOPA towards implementing a solution, not that they've agreed to do
> anything.* Still, there's hope...
>
>
>
>
> On 2/10/2016 7:03 AM, son_of_flubber
> wrote:
>
>
>
> On Wednesday, February 10, 2016 at 12:06:59 AM UTC-5, Andy Blackburn wrote:
>
>
>
> Hey Mike - if I'm misinterpreting it then so is AOPA (not that it's impossible). Take a look here, starting at 4:55.
>
> http://www.aopa.org/AOPA-Live?watch=%7B3C1A2840-97BF-4676-BBB4-288197D11A94%7D
>
>
>
> But there is no approved implementation plan for doing what AOPA wants. Whether it is technically feasible within the hard constraints remains to be proven.
>
>
>
>
>
> --
>
> Dan, 5J

The video is the 1st information that I have seen that indicates that the FAA is looking into opening up the TIS-B system to ADS-B IN only users. That's great news. Realistically though, it's going to be a year or two before this actually is implemented.

Now if the PowerFlarm guys would get their act together and support TIS-B......

[Darryl Ramm]

On Tuesday, February 9, 2016 at 11:30:04 AM UTC-8, Andy Blackburn wrote:
> Some news on TIS-B services.
>
> It appears that the FAA will be modifying TIS-B to make it available to anyone with an ADS-B receiver, regardless of ADS-B Out carriage. This means that you should be able to see rebroadcast of all transponder-equipped (as well as "opposite-band" ADS-B Out) aircraft within range of SSR with resolution as good as a few hundred feet simply by acquiring one of the relatively inexpensive ($100-150) ADS-B receivers. It may be available as early as this summer. It appears that this will enable a "God's eye view" of all transponder-equipped gliders (and other aircraft) in a broad flying area so long as there is SSR coverage. It remains to be confirmed whether or not PowerFLARM ADS-B In can decode TIS-B traffic. My understanding is that nothing special was included in the PowerFLARM design to accommodate TIS-B, but I am unsure whether TIS-B traffic resembles ADS-B direct transmissions closely enough to be decoded by PowerFLARM anyway. Either way there ought to be a glider-relevant solution available this year.
>
> http://www.aopa.org/News-and-Video/All-News/2016/January/04/FAA-announces-changes-to-TIS-B
>
> Additionally, it seems that the FAA will now rebroadcast ALL traffic regardless of ADS-B Out performance and configuration. Previously, some aircraft would not be rebroadcast if their ADS-B Out did not meet certain performance criteria and, as a result, would effectively be invisible so far as TIS-B services were concerned.
>
> Things are moving pretty quickly. Surprising.
>
> 9B

Ah Nope you are reading this largely backwards... and you know what... this has been gone over on r.a.s recently in detail....

[Darryl Ramm]

On Tuesday, February 9, 2016 at 8:12:41 PM UTC-8, JS wrote:
> I read the AOPA article the same way Andy does.
> The ghosting thing is a problem, alarms that "you're near yourself" are useless.
> But that's always been a problem with non-FLARM proximity warnings, the algorithms are not set for simple things like sharing a thermal.
> Jim

Jim, you and Andy are reading it wrong, but it seems many other are as well.. The writing/"reporting" in the AOPA article is just embarrassingly bad. AOPA should be helping educate their members and instead they write this confusing crap. They should be making sure to explain what the FAA is doing is more opposite to what they have been wanting. I'm not picking sides here on the technical argument for or not for "open TIS-B", I am picking on AOPA for just awful reporting/clarity/education of their membership. Maybe they are too embarrassed to state clearly the FAA is **NOT** doing what they want them to do.

And like many things ADS-B related I've tried to clarify this particulat mess before, e.g. see the bottom part of this thread https://groups.google.com/forum/#!topic/rec.aviation.soaring/F-hMpqQ_VBU

[Andy Blackburn[_3_]]

Crap! Sorry all.

[Darryl Ramm]

On Wednesday, February 10, 2016 at 7:47:03 AM UTC-8, kirk.stant wrote:
> On Tuesday, February 9, 2016 at 9:50:02 PM UTC-6, Mike Schumann wrote:
>
> > I believe that you are totally misinterpreting the information in the AOPA link you provided. While AOPA has been lobbying for years for the FAA to transmit all TIS-B data so that aircraft without ADS-B OUT will have access to this data, this is NOT what the FAA is doing. Instead, the FAA is actually clamping down and will no longer transmit TIS-B data to aircraft that are equipped with ADS-B OUT equipment that use GPS position sources that do not meet minimal performance standards.
> >
> > If you want to reliably receive TIS-B data from an ADS-B ground station, your aircraft MUST be ADS-B OUT equipped.
>
> Mike, please go back and carefully re-read the AOPA article. While poorly written, it specifically states that the FAA is implementing 2 changes: First, it will allow aircraft with non-conforming ADS-B out to be seen by certified ADS-B in (which covers people with experimental setups - perhaps even a Powerflarm GPS hooked up to a Trig TT21? Darryl, comment?)

Well yes and no. See below for more. The only change actually happening now will make the glider in your scenario visible to aircraft with certified ADS-B In receivers but it does so only by creating a TIS-B target for your glider, relying on SSR/Transponder positioning and broadcasting that to the client aircraft. So obviously that only works within SSR coverage, and still only broadcasts TIS-B data about that glider if it is within the "hockey puck" of an aircraft with a complaint ADS-B Out system.

> and second, it gets rid of the "hockey puck" limitation on TIS-B traffic transmission, so now anyone with an ADS-B IN receiver will see all the TIS-B traffic around them, not just traffic sent to a nearby certified ADS-B out-equipped aircraft.

No. To be clear what you are talking about is futureware/hopeware and nothing to do with what is actually happening now. See below.

>
> It does talk about "certified ADS-B receivers". Does that include the inexpensive ones used with a tablet or smartphone? I may need to look into that myself.

A certified ADS-B receiver (and display) being talked about by the FAA here is something like say in the low/mid-range GA market is say a new Garmin GTX 345 connected to a GTN650 display. If an avionics shop is installing it in a certified aircraft in your panel then it's one of those. Portable ADS-B receivers connected to iPads, tablets, etc. are *not* one of those.

>
> > Note: PowerFLARM does not support TIS-B and there has been no information provided by anyone that they are even thinking about adding this functionality to their product. That's a huge shortcoming in the product that is certainly not helping their sales efforts.
>
> Again, PowerFLARM does EXACTLY what it was designed for - provide glider-to-glider (with some additions, like british military aircraft) COLLISION AVOIDANCE information, with the added benefit of seeing all mode S ADS-B and Mode C transponder aircraft nearby. It is optimized for the European environment (no idiotic UAT) but works pretty damn well here in the US.

No argument there.

>Now, it looks like adding an inexpensive ADS-B in receiver will get TIS-B into your glider cockpit even if you don't have an ADS-B out setup.

No it won't. Not today. And even if it does in future how you can or cannot connect any of this stuff is a significant issue.

> It'll be interesting to see what glider nav setup first incorporates the ability to display TIS-B traffic - I'm hoping SYM on my Oudie will!
>
> Kirk
> 66

OK more details...

The AOPA article is describing two things. I'll explain it more clearly since I see it is still causing confusion. Those two things are:

1. What the FAA is doing now (TIS-B target broadcasts of non-complaint ADS-B out as is documented by the FAA here https://www.faa.gov/nextgen/programs/adsb/media/TIS-B_service_change_summary_final_508_5-13-15-webV2.pdf). And again, this #1 thing currently happening has nothing to do with getting rid of the need to have complaint ADS-B Out to receive ground based services like TIS-B, it just makes TIS-B traffic data for aircraft with complaint ADS-B Out available to those client aircraft that are ADS-B Our and ADS-B In equipped. previously ADS-B In Certified/IFR class systems would not display those ADS-B targets (yes you cannot make this stuff up). And what is being done here is. The other part of what is being done here is actually to stop broadcasting TIS-B and ADS-R for non-complaint ADS-B Out client aircraft.... so actually that is kind of opposite of that the FAA wants... (in #2 below).

and

2. talking about what AOP wants the FAA to do in future, which is open TIS-B broadcast or something similar. In principle that might mean no client aircraft/hockey puck needed. In practice what it exactly means is... well... wait and see exactly. The video referred to above is only refers to this second thing AOPA wants the FAA to do.

The FAA is right now rolling out # 1. they are investigating # 2. Actually "working on a plan". So again lets see where that leads and see exactly what they are talking about before worrying too much about the details. It may or may not be technically possible to do exactly what people want with this everywhere.

I suspect neither #1 or #2 FAA action will have little if any affect on USA glider pilots as PowerFLARM does not receive TIS-B. And few gliders have ADS-B Out anything, wether compliant of not, so not much practical increase in observability of those gliders, still maybe useful to know for folks in some areas...

And for the Airliners and fast jets, they get to rely on TCAS so that works regardless of what ADS-B anything the glider has, just as long as it has a transponder. Oh and don't rush to add UAT-Out thinking change #1 mean anybody else will see you, the FAA us just using TIS-B here, the FAA ground infrastructure needs the SSR/transponder location to generate that data. Fly around with UAT Out and no transponder, or outside SSR and ADS-B base station coverage and those certified ADS-B In systems still won't see your glider with an approved ADS-B Out. That well equipped Kind Air or PC-12 who's pilot thinks his certified ADS-B In system can see everything? Bzzzzzt wrong! Down low out in the traffic pattern of a remote airport they'll just run right over the top of a glider with a non-complaint ADS-B Out install without even a beep. (so ideally do a complaint install if you want ADS-B out now, or wait for TABS... *if* TABS regulations happen then that should provide lower cost ways of providing complaint ADS-B Out which will be seen by all 1090ES In equipped aircraft in all situations).

Even if somebody makes a separate ADS-B UAT receiver or box able to merge FLARM and UAT data together it might not deliver a very usable product/significant enhancement over current PowerFLARM systems for most glider pilots. And folks need to be very careful talking about all this home grown/crowd-funded toys maybe eventually doing anything like this. Its one thing to play with stuff, or hope to just display traffic, but it's a very different thing to generate a FLARM like traffic warning. So hands up who would want a box that can display ADS-B traffic on your current soaring flight computer but will/can not issue any warning at all as you collide with a threat? ... and to be clear to everybody that is exactly what Andy is proposing that crowd funded project actually do. So lets separate our interesting to play with toy ideas from an actually usable collision awareness system like FLARM (or even a modern ADS-B In receiver which does its own style crude and less useful for gliding audible traffic warnings). For the later this seems to me like stuff that I'd want only FLARM doing.

TIS-B location data is derived from SSR/transponder data and so i much less precise than GPS derived FLARM or standard ADS-B. And where that data is generated from a Mode C (vs. Mode S) transponder it is much harder to deduplicate (part of the reason that there will be increased ghosting caused by the FAA change #1 on uncertified (e.g. portable) ADS-B in systems). How a FLARM like system would handle that is a research project that likely really needs FLARM R&D like skills, but I doubt it is worth FLARM investing in this for marginal benefit for the small US glider market (doing basic integration with outboard UAT In receivers to enable dual-link receive or adding ADS-R support on the other hand I could see being more useful).

[Darryl Ramm]

Dang, stupid ADS-B crap. I knew I would screw this up (one beer, now on my second). I left the NON- off NON-complaint in a critical sentence and left off CERTIFIED in another part of the sentence.. so I'll try again...

" it just makes TIS-B traffic data for aircraft with NON-complaint ADS-B Out available to those client aircraft that are equipped with CERTIFIED ADS-B Out and ADS-B In."

I am sure there are other typos but I'm about to run out of beer.

[Darryl Ramm]

Grrr too many typos, so I'll kill my previous posts and correction on Google Groups at least and repost my original here...

On Wednesday, February 10, 2016 at 7:47:03 AM UTC-8, kirk.stant wrote:
> On Tuesday, February 9, 2016 at 9:50:02 PM UTC-6, Mike Schumann wrote:
>
> > I believe that you are totally misinterpreting the information in the AOPA link you provided. While AOPA has been lobbying for years for the FAA to transmit all TIS-B data so that aircraft without ADS-B OUT will have access to this data, this is NOT what the FAA is doing. Instead, the FAA is actually clamping down and will no longer transmit TIS-B data to aircraft that are equipped with ADS-B OUT equipment that use GPS position sources that do not meet minimal performance standards.
> >
> > If you want to reliably receive TIS-B data from an ADS-B ground station, your aircraft MUST be ADS-B OUT equipped.
>
> Mike, please go back and carefully re-read the AOPA article. While poorly written, it specifically states that the FAA is implementing 2 changes: First, it will allow aircraft with non-conforming ADS-B out to be seen by certified ADS-B in (which covers people with experimental setups - perhaps even a Powerflarm GPS hooked up to a Trig TT21? Darryl, comment?)

Well yes and no. See below for more. The only change actually happening now will make the glider in your scenario visible to aircraft with certified ADS-B In receivers but it does so only by creating a TIS-B target for your glider, relying on SSR/Transponder positioning and broadcasting that to the client aircraft. So obviously that only works within SSR coverage, and still only broadcasts TIS-B data about that glider if it is within the "hockey puck" of an aircraft with a properly configured complaint ADS-B Out system.

> and second, it gets rid of the "hockey puck" limitation on TIS-B traffic transmission, so now anyone with an ADS-B IN receiver will see all the TIS-B traffic around them, not just traffic sent to a nearby certified ADS-B out-equipped aircraft.

No it does not. To be clear what you are talking about is futureware/hopeware and nothing to do with what is actually happening now. See below.

>
> It does talk about "certified ADS-B receivers". Does that include the inexpensive ones used with a tablet or smartphone? I may need to look into that myself.

A certified ADS-B receiver (and display) being talked about by the FAA here is something like say in the low/mid-range GA market like the new Garmin GTX 345 connected to a GTN650 display. If an avionics shop is installing it in the panel of a certified aircraft then it's one of those. Portable ADS-B receivers connected to iPads, tablets, etc. are *not* one of those.

> > Note: PowerFLARM does not support TIS-B and there has been no information provided by anyone that they are even thinking about adding this functionality to their product. That's a huge shortcoming in the product that is certainly not helping their sales efforts.
>
> Again, PowerFLARM does EXACTLY what it was designed for - provide glider-to-glider (with some additions, like british military aircraft) COLLISION AVOIDANCE information, with the added benefit of seeing all mode S ADS-B and Mode C transponder aircraft nearby. It is optimized for the European environment (no idiotic UAT) but works pretty damn well here in the US.

No argument there.

>Now, it looks like adding an inexpensive ADS-B in receiver will get TIS-B into your glider cockpit even if you don't have an ADS-B out setup.

No it won't. Not today. And even if it does in future how you can or cannot connect any of this stuff is a significant issue.

> It'll be interesting to see what glider nav setup first incorporates the ability to display TIS-B traffic - I'm hoping SYM on my Oudie will!
>
> Kirk
> 66

OK more details...

The AOPA article is describing two things. I'll explain it more clearly since I see it is still causing confusion. Those two things are:

1. What the FAA is doing now (TIS-B target broadcasts of non-complaint ADS-B out as is documented by the FAA here https://www.faa.gov/nextgen/programs/adsb/media/TIS-B_service_change_summary_final_508_5-13-15-webV2.pdf). And again, this #1 thing currently happening has nothing to do with getting rid of the need to have complaint ADS-B Out to receive ground based services like TIS-B, it just makes TIS-B traffic data for aircraft with non-complaint ADS-B Out available to those client aircraft that are equipped with certified/compliant ADS-B Out and certified ADS-B In. Previously ADS-B In certified (e.g. panel mount IFR class) systems would not/are not allowed to display those ADS-B targets (yes I kid you not, you cannot make this stuff up). The other part of what is being done here currently is to actually to stop broadcasting TIS-B and ADS-R for non-complaint ADS-B Out client aircraft...which until now the FAA has been doing, so actually that is kind of opposite of that AOPA wants the FAA to do... (in #2 below). That last gotcha will affect more some experimental power aircraft pilots who have been replying on non-complaint ADS-B Out systems to trigger TIS-B and ADS-R client services for their aircraft, maybe even in cases just working when they don't realize why/how and I hope those folks get the message the FAA is in the process of breaking how this works for them. If you know folks doing this in their experimental airplanes, slap them about the head and let them know they may be wanting to install a compliant ADS-B Out system.

and (very differently)...

2. talking about what AOPA wants the FAA to do in future, which is open TIS-B broadcast or something similar. In principle that might mean no client aircraft/hockey puck needed. In practice what it exactly means is... well.... wait and see exactly. The video referred to above is only refers to this second thing AOPA wants the FAA to do.

The FAA is right now rolling out # 1. they are investigating # 2. Actually "working on a plan". So again lets see where that leads and see exactly what they are talking about before worrying too much about the details. It may or may not be technically possible to do exactly what people want with this everywhere.

I suspect neither #1 or #2 FAA action will have little if any affect on USA glider pilots as PowerFLARM does not receive TIS-B. And few gliders have ADS-B Out anything, wether compliant of not, so not much practical increase in observability of those gliders, still maybe useful to know for folks in some areas...

And for the Airliners and many fast jet that rely on TCAS... that all works regardless of what ADS-B anything the glider has, just as long as it has a transponder. Oh and don't rush to add UAT-Out thinking change #1 mean anybody else will see you, the FAA is just using TIS-B here, the FAA ground infrastructure needs the SSR/transponder location to generate that data. Fly around with UAT Out only and no transponder, or outside SSR and ADS-B base station coverage and those certified ADS-B In systems still won't see your glider with a non-compliant ADS-B Out. That well equipped Kind Air or PC-12 who's pilot thinks his certified ADS-B In system can see everything? Bzzzzzt wrong! Down low out in the traffic pattern of a remote airport they'll just run right over the top of a glider with a non-complaint ADS-B Out install without even a beep. (so ideally do a complaint install if you want ADS-B out now, or wait for TABS... *if* TABS regulations happen then that should provide lower cost ways of providing complaint ADS-B Out which will be seen by all 1090ES In equipped aircraft in all situations).

Even if somebody makes a separate ADS-B UAT receiver or box able to merge FLARM and UAT data together it might not deliver a very usable product/significant enhancement over current PowerFLARM systems for most glider pilots. And folks need to be very careful talking about all this home grown/crowd-funded toys maybe eventually doing anything like this. It's one thing to play with stuff, or hope to just display traffic, but it's a very different thing to generate a FLARM like traffic warning. So hands up who would want a box that can display ADS-B traffic on your current soaring flight computer but will not/can not issue any warning at all as you collide with a threat? ... and to be clear to everybody that is exactly what Andy is proposing that crowd funded project actually do. So lets separate our interesting to play with toy ideas from an actually usable collision awareness system like FLARM (or even a modern ADS-B In receiver which does its own style crude and less useful for gliding audible traffic warnings). For the later this seems to me like stuff that I'd want only FLARM doing.

TIS-B location data is derived from SSR/transponder data and so is much less precise than GPS derived FLARM or standard ADS-B. And where that data is generated from a Mode C (vs. Mode S) transponder it is much harder to deduplicate from UAT Out or FLARM (part of the reason that there will be increased ghosting caused by the FAA change #1 on uncertified (e.g. portable) ADS-B in systems). How a FLARM like system would handle that is a research project that likely really needs FLARM R&D like skills, but I doubt it is worth FLARM investing in this for marginal benefit for the small US glider market (doing basic integration with outboard UAT In receivers to enable dual-link receive or adding ADS-R support on the other hand I could see being more useful).

[Dan Marotta]

On 2/10/2016 9:53 PM, Darryl Ramm wrote:
> So hands up who would want a box that can display ADS-B traffic on your current soaring flight computer but will/can not issue any warning at all as you collide with a threat?

I do, I do...!

Seems to me that simply having a picture of the traffic around you is
sufficient without all the whistles and bells yelling about an imminent
collision. There's another aircraft 5 miles away! Ho hum... Let's see
where he is on the next (or one after) update. Same relative clock
position (azimuth and elevation) only closer? Maybe a threat, I'll
monitor or deviate a little. Yes, in a busy airline cockpit, I can see
the need for collision warnings but, we're flying VFR and are supposed
to be looking outside. Knowing there's an aircraft at a particular
location and closing is all I need or want.

I'm not talking about gaggles or energy lines here. You have Flarm or
PCAS for those situations.

What I'd really like to know is why the FAA doesn't want to transmit all
aircraft positions in the blind. What is to be gained by denying me
information about local (to me) traffic just because I don't have a
particular box in the aircraft? Is it a bandwidth thing?
--
Dan, 5J

[Darryl Ramm]

On Thursday, February 11, 2016 at 7:55:21 AM UTC-8, Dan Marotta wrote:
> On 2/10/2016 9:53 PM, Darryl Ramm
> wrote:
>
>
>
> So hands up who would want a box that can display ADS-B traffic on your current soaring flight computer but will/can not issue any warning at all as you collide with a threat?
>
>
>
> I do, I do...!
>
>
>
> Seems to me that simply having a picture of the traffic around you
> is sufficient without all the whistles and bells yelling about an
> imminent collision.* There's another aircraft 5 miles away!* Ho
> hum...* Let's see where he is on the next (or one after) update.*
> Same relative clock position (azimuth and elevation) only closer?*
> Maybe a threat, I'll monitor or deviate a little.* Yes, in a busy
> airline cockpit, I can see the need for collision warnings but,
> we're flying VFR and are supposed to be looking outside.* Knowing
> there's an aircraft at a particular location and closing is all I
> need or want.
>
>
>
> I'm not talking about gaggles or energy lines here.* You have Flarm
> or PCAS for those situations.
>
>
>
> What I'd really like to know is why the FAA doesn't want to transmit
> all aircraft positions in the blind.* What is to be gained by
> denying me information about local (to me) traffic just because I
> don't have a particular box in the aircraft?* Is it a bandwidth
> thing?

There are likely bandwidth concerns in some situations. Which is why its important to wait and see exactly what proposal the FAA comes up with. The whole dual-link/claimed need for UAT to free more bandwidth on 1090 MHz has not worked out as the FAA had hoped. And blind transmitting TIS-B would effectively be going to use all that complex FAA ground system that was supposed to help reduce 1090 MHz congestion to actually increase 1090 MHz congestion, oh the irony. I was never strongly convinced by some of the 1090ES bandwidth arguments, there did not seem to be much competitive academic research on this and the European's for example took a different approach that relied on decommissioning Mode C transponders (their interrogation by TCAS especially in crowded airspace wastes lots of 1090MHz bandwidth), change 7.1 to TCAS, and over time maybe other tweaks and improvements to TCAS and SSR systems to reduce transponder interrogation rates and allow more bandwidth at 1090MHz for ADS-B.

But there are likely other reasons than just bandwidth, the FAA also has had some pretty weird approaches to what will "encourage" ADS-B Out adoption. And now everything is such a complex mess that there likely is not a single simple answer to your question. And to some extent as we get closer to 2020 and ADS-B carriage will be mandated in many aircraft TIS-B becomes less interesting (and ADS-B direct and ADS-R (to a much smaller extent because many folks seem to be going 1090ES Out than UAT Out and others dual-link ADS-B In) become more important. And right now where this whole system is at it is important that airspace users in general are encouraged to install ADS-B Out. The primary leading factor is likely to be cost, and while the FAA has not always done things to encourage reduced cost things are finally starting to move better there with mainstream manufactures producing more affordable ADS-B Out systems and hopefully TABS regulations and future availability of TABS devices will help reduce ADS-B Out equipage costs for gliders, that might come with the arguable downside of mandatory TABS/ADS-B Out carriage for gliders. All a part of why waiting and seeing what happens with TABS affects so much here.

The looming 2020 ADS-B carriage mandates (that gliders are currently exempt from) and possible (likely?) changes coming with TABS are all reasons why I'm just not that interested in TIS-B and PowerFLARM integration. But the time anything is here and actually working well enough it will be increasingly irrelevant (as most transponder equipped aircraft equip with ADS-B Out). Dual-link ADS-B receive in a PowerFLARM type systems for non-TIS-B use is probably more interesting longer term, maybe as well for FIS-B/weather and TFR data etc. but who will do all that integration work, and why it would be economically justified for a small USA market is unclear.


>
> --
>
> Dan, 5J

[Dan Marotta]

<snip>

On 2/11/2016 10:00 AM, Darryl Ramm wrote:
> the FAA also has had some pretty weird approaches

Yaaas... When I was working on ASDE-X in the mid-2000s, the FAA
required us all to fly to Washington, DC simply to have our pictures
taken for our "Public Trust" badges (at tax payer expense, of course).
Eventually someone at FAA realized that we slimy contractors had cameras
of our own to make our own company badges and we could simply email the
pictures to them to make their badges for us.

So glad to be retired... :-D
--
Dan, 5J

[kirk.stant]

On Wednesday, February 10, 2016 at 11:25:05 PM UTC-6, Darryl Ramm wrote:

(Lots of good stuff clipped...)

Well darn, I need to brush up on my reading comprehension skills! I felt that the AOPA article was poorly written (and mentioned it) but I guess I (and some others) read what we wanted to read...

Darryl, thanks again for stepping in and setting us straight - my head hurts just thinking about all this stuff!

Cheers,

Kirk
66

[Andy Blackburn[_3_]]

>>Even if somebody makes a separate ADS-B UAT receiver or box able to merge FLARM and UAT data together it might not deliver a very usable product/significant enhancement over current PowerFLARM systems for most glider pilots.. And folks need to be very careful talking about all this home grown/crowd-funded toys maybe eventually doing anything like this. It's one thing to play with stuff, or hope to just display traffic, but it's a very different thing to generate a FLARM like traffic warning. So hands up who would want a box that can display ADS-B traffic on your current soaring flight computer but will not/can not issue any warning at all as you collide with a threat? ... and to be clear to everybody that is exactly what Andy is proposing that crowd funded project actually do. So lets separate our interesting to play with toy ideas from an actually usable collision awareness system like FLARM (or even a modern ADS-B In receiver which does its own style crude and less useful for gliding audible traffic warnings). For the later this seems to me like stuff that I'd want only FLARM doing.

________________

These are all important statements. People need to take care with projects of this type and in general collision warning is best left to professional developers with the specialized skills to deal with all the complexities. Caveat Emptor.

However...To the extent that any GA in the US equip with UAT Out it would be nice to have a way for glider pilots to see them that is better than PCAS - which from my perspective becomes nearly useless as gliders equip with and use transponders - the nuisance alarms just become intolerable if you fly close to one or more of them. Ask me why I know this.

Since UAT Out is most likely to be carried in GA aircraft rather than gliders lacking Flarm, a simple traffic alert at 1mi and +/- 1000' ought to be sufficient - and certainly better than invisibility. While it would be nice in a perfect world, I don't anticipate GA traffic needing sophisticated Flarm collision algorithms unless someone in a Mooney wants to come thermal with us. Such a simple traffic warning appears to be possible and ought to be better than nothing. All the other stuff is either transitional (TIS-B), or a future option (FIS-B - assuming a glide computer maker decides they want to take up the development just for the US - which is a big unknown at best).

All of this is further support that gliders should equip with Flarm and a transponder first and UAT Out never. If you go ADS-B Out absolutely make it 1090ES or you will never get Flarm collision warning capability - at least not unless Flarm decides to add it to their box.

9B