Stratux Status Message

Hi,
The purpose of this document is to propose through collaboration and agreement a status message for the Stratux ADS-B receiver.  This is a draft.  Provide all feedback through this thread.  The intent is to finalize this status message on or before December 31, 2015.  Please contribute to the discussion as soon as possible so that your ideas are heard early enough for discussions.
http://hiltonsoftware.com/stratux
Thanks,
Hilton

@HiltonG
I have read the .pdf and I believe that we are off to a good start.
I would like to propose, since this is open source, that whatever is agreed upon here remains an open stratux message that will be available for any developer to incorporate stratux into their hardware or software.  And that stratux remains open source.. not tied into a manufacturer.. otherwise I will just go back to getting paid for this.
If this project gains traction it will become more popular and at least one thing in aviation should be above corporate and government greed and that is safety.
that said, while we certainly need the message standard I have a couple questions and comments.
information is great provided its not for informations sake.  IE what are we doing with the information?
How will it be presented (does it need to be presented or just looked at behind the scenes), will it even be presented or will it just cause pop up warnings etc?  And what is appropriate for stratux to process vs just giving raw data and leave the presentation to the EFB software.
TRAFFIC
Traffic.. while having a messages/sec message might say something.. what is it saying?  I would like to see (no really need) to ensure whatever traffic is displayed on the screen is vetted and current.  I mentioned this somewhere else already but currently traffic shows up in WingX and others that is over a minute old without update and there is no differentiation.. that is no good.  I proposed at least for wingX since you place a circle around it anyway (why yellow) that the color of the circle mean something.  If traffic is within 5 miles / 1 min co-alt it needs to get my attention(flash/blink/do a jig).. if its close and its updates are more than a couple seconds old it needs to scream TARGET LOST.. blink/ change shape (like plane for current, diamond for lost/estimated) or something.  audio could be incorporated as well since people plug in their devices to the audio panel.  if any target is more than a coupe seconds old and updates stop.. just plain changing the color of its ring would be fine.. you could continue to move the target along its previous track estimating position using its speed.. but it needs to be different than a target that has a regular update.  Colored rings and blinking could be used, in wingX when the data changes, change between ID and seconds since updated for targets lost or something.  I cant specifically comment on details since I am on a non disclosure, but do some research on standard TCAS presentation standards and follow it)  Predictive collision would be a nice feature.. i.e. compare your projected flight track and the projected traffic and calculate a time to nearest point of collision.. set a circular error probable and if you predictively get within a mile ID the traffic with a predictive collision and time to NPC.  obviously it only needs to be done for targets that stands a chance of getting anywhere near you so most if not all targets would be thrown out without even getting a calc.
Stratux could possibly do the calcs, but I dont know if the GDL90 spec would allow or has the capability of changing the target status from active to estimated.. so most of this needs to be done in the EFB software... comparing message times since the iPad vs pi timestamp might be way off.
Rule number one in any product is bad information is worse than no information at all. Information overload causes distraction, distraction causes accidents.  My best friend in the U-2 was a single bezel button that would change the display from like 10 overlays back to a basic PFD/HSI presentation so that when shit got weird I could loose all the distraction and get the aircraft back under control.
Weather... again, while ADS-B message/sec is an indication of activity.. how much is garbled.. what is actually happening ... one of you competitors, with a single tap.. provides not just the status of how many towers and atcivity, but a tower radar view, hold old each FIS-B data group was.. i.e. TAF <1min, METAR>5min, Radar > 15 min.. it gives actual times since a valid message updated the weather database... that is useful info.
right now in wingx it take 2 taps just to see if the status page and it only displays indicators that something is attached...
my biggest complaint in WingX with weather is that when you tap an airport and bring up the wx screen.. again 2 or more tap.. while your competitor you just tap the aiprorts VFR/IFR on the map and it brings up the weather.. you get to the weather.. in big red letters it tells you that the internet weather is 2 days old.. who gives a shit if it was updated 5 minutes ago by FIS-B.. you have to look at each product to see if it as a small ADS-B marker and an even smaller update time..
Airport status and other products should not be visible on the map unless they are getting regular updates.. otherwise I could be looking a a green VFR button on my destination and in reality it could have gone IFR but ADS-B didnt update it.. if its not current within 2 cycles of the FAA FIS-B update timeline.. dont display it.. make me drill to the weather page to see its status and that way I see its age...
WORST part is that any updates over ADS-B do not permanantly  change the data in WingX.. if the iPad crashes, I have to restart the program, etc.. it reverts all data back to the internet data which could be days old.. that is really bad...
Weather is weather.. I dont care where it came from.. you should not even keep track.. it should just have a valid time/last updated and thats it
all of the weather products that I get from the internet are not retained for use in flight.. thats not ideal.. all the icing prog charts, the surface analysis etc.. are not stored.. dumb.. when I take my EFB to the aircraft.. its my charts, my weather, all my data for the flight.. it should stay in the device.
The most useless stuff in aviation is runway behind you, fuel on the ground, having 3 targets and only 2 bombs left, and an EFB that leaves most if its information on the ground when I disconnect from the internet.
What we noticed in the USAF is that round dial is round dial.. there many be more or less dials as you move between aircraft but pilots made the transition easily.. when students came to a non glass aircraft from a glass aircraft.. they could not fly a basic approach.. to many automations that made them lazy and unable to set power without a predictive speed bug to help them.. worse.. when they came from one glass to the next .. they had to unlearn all the symbology, logic, presentation layouts and screen trees to figure out the new one and it took longer to train them.. and they made more safety of flight mistakes along the way.. I dont think there will ever be a good standardization in this new glass age but these products have to be made to be safe to use while you have a handful of airplane or they are just getting in the way...
I flew some of the USAFs most complex and demanding aircraft.. I have more, single engine, single pilot night IFR than most and in the U-2 it was hand flown all the way up and all the way down with no autopilot or automation while wearing a space suit with oven gloves, and with my training as an Aerospace physiologist as well as a command pilot that aided the USAF in the design of 2 glass cockpit conversions I have an appreciation for what data is need and how to present it with excellent human factors figured in.  I have also been consulting on these EFB systems since the compaq Ipaq... and got paid well for it.. but none have been great because the developers were more interested in a  laundry list of features vs making the product informative and safe to use in flight from a human factors standpoint.. I left my last contract because the developer wanted an exclusivity clause again and also wanted to close off his product and safety innovations to make more money.. I could no longer agree with those philosophies .. if you make the best product, they will come, if you come up with something revolutionary, you can license it.. but keeping if from everyone does not help... look at the FAA.. could they broadcast TIS full time.. you be.. they won't because they want to punish you for not upgrading your equipment... even though its perfectly legal for you to fly in 80% of the airspace system without it... keeping safety products from pilots for leverage is reckless and I hope someone gets sued in the future.
I am looking for a developer that want to make something really extraordinary that increases GA safety an order of magnitude.. we are still trying to fit this new tech into the old paradigms when we could shed the old way of doing it and move fully into the digital age.
Hilton, if you want to talk more offline, let me know.. I am getting carpal tunnel!!

@deucedriver  I believe you're preaching to the choir, deuce.  All your
concerns lie in the EFB (tablet app), it seems to me.  To fully address
them, we'd need to create our own flight app (boy, we could make stratux
functionality SOLID then!)  I'm not opposed to that but it is a rather
large effort.  Avare comes to mine but I simply cannot stand their
current user interface. Talk about user unfriendly...
Some of your desires are met in iFlyGPs.  I think they have the 30-day
free trial, too, but not certain.  I know Garmin's does but Garmin tries
to make everything sole-source so that only their gear works with
their software, another thing I absolutely hate and will not buy into.
Now, at the risk of being flamed, how practical is it and how far can we
go with some of this data being displayed on the webui from stratux?  In
flight, that means minimizing the aviation app and pulling up the webui
window, then going back to the aviation app; a non-trivial effort during
flight.  (Thank you Google Android and Apple.)
Skypuppy
On 12/17/2015 08:21 AM, duecedriver wrote:

@HiltonG https://github.com/HiltonG
I have read the .pdf and I believe that we are off to a good start.
I would like to propose, since this is open source, that whatever is
agreed upon here remains an open stratux message that will be
available for any developer to incorporate stratux into their hardware
or software. And that stratux remains open source.. not tied into a
manufacturer.. otherwise I will just go back to getting paid for this.
If this project gains traction it will become more popular and at
least one thing in aviation should be above corporate and government
greed and that is safety.
that said, while we certainly need the message standard I have a
couple questions and comments.
information is great provided its not for informations sake. IE what
are we doing with the information?
How will it be presented (does it need to be presented or just looked
at behind the scenes), will it even be presented or will it just cause
pop up warnings etc? And what is appropriate for stratux to process vs
just giving raw data and leave the presentation to the EFB software.
TRAFFIC
Traffic.. while having a messages/sec message might say something..
what is it saying? I would like to see (no really need) to ensure
whatever traffic is displayed on the screen is vetted and current. I
mentioned this somewhere else already but currently traffic shows up
in WingX and others that is over a minute old without update and there
is no differentiation.. that is no good. I proposed at least for wingX
since you place a circle around it anyway (why yellow) that the color
of the circle mean something. If traffic is within 5 miles / 1 min
co-alt it needs to get my attention(flash/blink/do a jig).. if its
close and its updates are more than a couple seconds old it needs to
scream TARGET LOST.. blink/ change shape (like plane for current,
diamond for lost/estimated) or something. audio could be incorporated
as well since people plug in their devices to the audio panel. if any
target is more than a coupe seconds old and updates stop.. just plain
changing the color of its ring would be fine.. you could continue to
move the target along its previous track estimating position using its
speed.. but it needs to be different than a target that has a regular
update. Colored rings and blinking could be used, in wingX when the
data changes, change between ID and seconds since updated for targets
lost or something. I cant specifically comment on details since I am
on a non disclosure, but do some research on standard TCAS
presentation standards and follow it) Predictive collision would be a
nice feature.. i.e. compare your projected flight track and the
projected traffic and calculate a time to nearest point of collision..
set a circular error probable and if you predictively get within a
mile ID the traffic with a predictive collision and time to NPC.
obviously it only needs to be done for targets that stands a chance of
getting anywhere near you so most if not all targets would be thrown
out without even getting a calc.
Stratux could possibly do the calcs, but I dont know if the GDL90 spec
would allow or has the capability of changing the target status from
active to estimated.. so most of this needs to be done in the EFB
software... comparing message times since the iPad vs pi timestamp
might be way off.
Rule number one in any product is bad information is worse than no
information at all. Information overload causes distraction,
distraction causes accidents. My best friend in the U-2 was a single
bezel button that would change the display from like 10 overlays back
to a basic PFD/HSI presentation so that when shit got weird I could
loose all the distraction and get the aircraft back under control.
Weather... again, while ADS-B message/sec is an indication of
activity.. how much is garbled.. what is actually happening ... one of
you competitors, with a single tap.. provides not just the status of
how many towers and atcivity, but a tower radar view, hold old each
FIS-B data group was.. i.e. TAF <1min, METAR>5min, Radar > 15 min.. it
gives actual times since a valid message updated the weather
database... that is useful info.
right now in wingx it take 2 taps just to see if the status page and
it only displays indicators that something is attached...
my biggest complaint in WingX with weather is that when you tap an
airport and bring up the wx screen.. again 2 or more tap.. while your
competitor you just tap the aiprorts VFR/IFR on the map and it brings
up the weather.. you get to the weather.. in big red letters it tells
you that the internet weather is 2 days old.. who gives a shit if it
was updated 5 minutes ago by FIS-B.. you have to look at each product
to see if it as a small ADS-B marker and an even smaller update time..
Airport status and other products should not be visible on the map
unless they are getting regular updates.. otherwise I could be looking
a a green VFR button on my destination and in reality it could have
gone IFR but ADS-B didnt update it.. if its not current within 2
cycles of the FAA FIS-B update timeline.. dont display it.. make me
drill to the weather page to see its status and that way I see its age...
WORST part is that any updates over ADS-B do not permanantly change
the data in WingX.. if the iPad crashes, I have to restart the
program, etc.. it reverts all data back to the internet data which
could be days old.. that is really bad...
Weather is weather.. I dont care where it came from.. you should not
even keep track.. it should just have a valid time/last updated and
thats it
all of the weather products that I get from the internet are not
retained for use in flight.. thats not ideal.. all the icing prog
charts, the surface analysis etc.. are not stored.. dumb.. when I take
my EFB to the aircraft.. its my charts, my weather, all my data for
the flight.. it should stay in the device.
The most useless stuff in aviation is runway behind you, fuel on the
ground, having 3 targets and only 2 bombs left, and an EFB that leaves
most if its information on the ground when I disconnect from the internet.
What we noticed in the USAF is that round dial is round dial.. there
many be more or less dials as you move between aircraft but pilots
made the transition easily.. when students came to a non glass
aircraft from a glass aircraft.. they could not fly a basic approach..
to many automations that made them lazy and unable to set power
without a predictive speed bug to help them.. worse.. when they came
from one glass to the next .. they had to unlearn all the symbology,
logic, presentation layouts and screen trees to figure out the new one
and it took longer to train them.. and they made more safety of flight
mistakes along the way.. I dont think there will ever be a good
standardization in this new glass age but these products have to be
made to be safe to use while you have a handful of airplane or they
are just getting in the way...
I flew some of the USAFs most complex and demanding aircraft.. I have
more, single engine, single pilot night IFR than most and in the U-2
it was hand flown all the way up and all the way down with no
autopilot or automation while wearing a space suit with oven gloves,
and with my training as an Aerospace physiologist as well as a command
pilot that aided the USAF in the design of 2 glass cockpit conversions
I have an appreciation for what data is need and how to present it
with excellent human factors figured in. I have also been consulting
on these EFB systems since the compaq Ipaq... and got paid well for
it.. but none have been great because the developers were more
interested in a laundry list of features vs making the product
informative and safe to use in flight from a human factors
standpoint.. I left my last contract because the developer wanted an
exclusivity clause again and also wanted to close off his product and
safety innovations to make more money.. I cou ld no lo nger agree with
those philosophies .. if you make the best product, they will come, if
you come up with something revolutionary, you can license it.. but
keeping if from everyone does not help... look at the FAA.. could they
broadcast TIS full time.. you be.. they won't because they want to
punish you for not upgrading your equipment... even though its
perfectly legal for you to fly in 80% of the airspace system without
it... keeping safety products from pilots for leverage is reckless and
I hope someone gets sued in the future.
I am looking for a developer that want to make something really
extraordinary that increases GA safety an order of magnitude.. we are
still trying to fit this new tech into the old paradigms when we could
shed the old way of doing it and move fully into the digital age.
Hilton, if you want to talk more offline, let me know.. I am getting
carpal tunnel!!
—
Reply to this email directly or view it on GitHub
https://github.com/cyoung/stratux/issues/150#issuecomment-165463870.

Now, at the risk of being flamed, how practical is it and how far can we go with some of this data being displayed on the webui from stratux? In flight, that means minimizing the aviation app and pulling up the webui window, then going back to the aviation app; a non-trivial effort during flight. (Thank you Google Android and Apple.)

Practical - all of the data that passes through stratux can be displayed however you want. You get text updates and traffic on the UI if that's what you want. The question is if we want to use the webui to manage a weather receiver, or we want to start doing (what one would think of as) EFB functions?
I started work on having the Pi plug into my audio panel to read new METARs and adverse weather conditions to me as they are newly received. There's a lot that can be done with it - question is what is the most useful.

that is what I am talking about.. if in an  EFB settings menu you tell it you have it hooked up to audio.. than when you go to a weather page for an airport, you could push a button and have it read off whatever it is you pushed.. that is thinking out of the box...

@cyoung  How important is the impedance mismatch between the aviation
audio panel and the rest of the world, including audio out from the Pi2?
On 12/17/2015 08:46 AM, cyoung wrote:

Now, at the risk of being flamed, how practical is it and how far
can we go with some of this data being displayed on the webui from
stratux? In flight, that means minimizing the aviation app and
pulling up the webui window, then going back to the aviation app;
a non-trivial effort during flight. (Thank you Google Android and
Apple.)

Practical - all of the data that passes through stratux can be
displayed however you want. You get text updates and traffic on the UI
if that's what you want. The question is if we want to use the webui
to manage a weather receiver, or we want to start doing (what one
would think of as) EFB functions?
I started work on having the Pi plug into my audio panel to read new
METARs and adverse weather conditions to me as they are newly
received. There's a lot that can be done with it - question is what is
the most useful.
—
Reply to this email directly or view it on GitHub
https://github.com/cyoung/stratux/issues/150#issuecomment-165470088.

No clue, it wouldn't be an issue with my panel specifically because it has an audio input which hooks up to just about anything. If you mean hooking it up to a mic input, not sure. Doesn't seem like it would be a huge issue to deal with in any case.

@skypuppy
yeah.. not to preach.. BUT this is the problem I have seen with all these products, HARDWARE and SOFTWARE outside of certified equipment... the development process is .. lets throw shit at the wall to see what sticks.. in a open source hobby environment .. well that is that way it is.. hard to have a coordinated, well planned and thought out attack when you have your developers strewn across the globe, speaking different languages and they have a day job.. it is NOT appropriate for a company that is taking money for a product.
so.. since we have this effort to really think about a standard stratux message stream..
the idea that we sit down and do some really in-depth thought and use a system integration approach seems prudent..  you have to figure out what you want and how you want it before you can decide on the flow of information.
I think that sticking to a standard is a great idea. like GDL-90 or better GDL-88 (faster sat update I think) since it may make it more compatible once avionics manufacturers begin getting approval to allow portable info into their boxes.. like aspens connected cockpit
the part 23 re-write will help fast track cheaper avionics meant for GA soon too.. or at least that is my hope.

skypup.. impeedance is very important.. we just to hook up audio players to military aircraft intercom since it get boring flying 10hrs across the ocean alone at night.. we made impedance matching patch cables otherwise the signal would be so weak you couldn't here it .  the mil impedance was diff than GA audio panels too.. so we had our avionics techs make them for us...

@Skypuppy - early on there was a lengthy discussion of webUI "features". At that time I recommended we define the scope of the Stratux WebUI as "configuration and operational verification".
This has gone a long way to avoid huge amounts of EFB functionality creeping into Stratux.
This has also left the door open to other projects implementing EFB-like features. A great example is RPi2D2.
I still believe the driving focus on Stratux is to work with as many EFBs as possible. To this end, the WebUI is there to insure Stratux is configured and functioning and - where necessary - assist with interoperability diagnostics.

cyoung is correct, most audio panels have an aux in which is impedance matched for consumer music sources.. having it hooked up though a passthrough to the pilots headset cord would allow playback to only the pilot of clearances and such and record as well... so you could do a replay if you miss a clearance.. if your panel has vox..only issue is when you key the mike.. if the iPad screams something the controller will get an earful..  we had one aircraft that had bad blead from the intercom to the transmit bus and a pilot was listening to some music that basically had a phrase .. "gotta smack that ass" and he had keyed the mike at just the wrong time and center said it better not be mine that you want to smack.. i just gave you direct.. then a couple airliners chimed in.. I was on freq too and just about pissed my pants it just got that funny...

LOL, wish I could have heard that!
On 12/17/2015 09:05 AM, duecedriver wrote:

cyoung is correct, most audio panels have an aux in which is impedance
matched for consumer music sources.. having it hooked up though a
passthrough to the pilots headset cord would allow playback to only
the pilot of clearances and such and record as well... so you could do
a replay if you miss a clearance.. if your panel has vox..only issue
is when you key the mike.. if the iPad screams something the
controller will get an earful.. we had one aircraft that had bad blead
from the intercom to the transmit bus and a pilot was listening to
some music that basically had a phrase .. "gotta smack that ass" and
he had keyed the mike at just the wrong time and center said it better
not be mine that you want to smack.. i just gave you direct.. then a
couple airliners chimed in.. I was on freq too and just about pissed
my pants it just got that funny...
—
Reply to this email directly or view it on GitHub
https://github.com/cyoung/stratux/issues/150#issuecomment-165477779.

the dreaded feature creep!
On 12/17/2015 09:02 AM, bradanlane wrote:

@Skypuppy https://github.com/Skypuppy - early on there was a lengthy
discussion of webUI "features". At that time I recommended we define
the scope of the Stratux WebUI as "configuration and operational
verification".
This has gone a long way to avoid huge amounts of EFB functionality
creeping into Stratux.
This has also left the door open to other projects implementing
EFB-like features. A great example is RPi2D2.
I still believe the driving focus on Stratux is to work with as many
EFBs as possible. To this end, the WebUI is there to insure Stratux is
configured and functioning and - where necessary - assist with
interoperability diagnostics.
—
Reply to this email directly or view it on GitHub
https://github.com/cyoung/stratux/issues/150#issuecomment-165477211.

another good one.. a 4 ship of T-38s.. took off out houston .. had the callsign gaze... houston center gaze 11 flight of 4 passing 3000 direct amarillo.... next thing you hear is .. what.. this is texas boy we dont allow no gaze in amarillo... what, there are 4 gays here... this is american 401.. it isn't us.. bla bla.. it lated more than 2 minutes before center said enough, he had to actually you know.. control traffic.. I had a hard time staying in formation...

pilots do tend to cut up a lot.  :)  Thank God.
On 12/17/2015 09:09 AM, duecedriver wrote:

another good one.. a 4 ship of T-38s.. took off out houston .. had the
callsign gaze... houston center gaze 11 flight of 4 passing 3000
direct amarillo.... next thing you hear is .. what.. this is texas boy
we dont allow no gaze in amarillo... what, there are 4 gays here...
this is american 401.. it isn't us.. bla bla.. it lated more than 2
minutes before center said enough, he had to actually you know..
control traffic.. I had a hard time staying in formation...
—
Reply to this email directly or view it on GitHub
https://github.com/cyoung/stratux/issues/150#issuecomment-165478865.

no feature creap.. we are designing a box.. that box has info in it.. that info has to get out to the programmers.. they design the feature around what the box can provide..
the data stream needs to be compatible (i.e. of some standard), any additional info over the standard must not break the standard. and the the stream must be future proof.. the stream must be open source..
thinking about it ahead of time saves programmers from having to re-write their code  from scratch down the line..

a web ui would allow us to use data that a particular EFB program has yet to implement.. IE if you want to know the sat constellation status but your EFB just gives you a green light saying its attached.. switch to the web page to see your estimated error or waas status.. whatever..

2 different things though.. what the data stream needs to output vs what we could drill into via web page.. not everything the box can get at needs to be in the data stream..
we also need to decide if it will be a bi directional standard to allow the EFB to config the hardware or just config the hardware via web page

EFB config the hardware - there's pause/unpause of a data stream when the EFB knows it will become unable to accept data (going into background or closing). What other config is there?

the other thing I am trying to get across.. is take for example traffic...
if the target is lost.. is stratux still keeping it in the data stream at its last known position.. or does it drop in immediately..
if we are keeping it in the stream.. that it has to have a time tag so that the EFB can see the target has not been updated in xx seconds because it can compare the target last known time to gps message time.. or internal time.. whatever.. but we need to have that standard too.. who has the master time and how is it set to ensure everything is talking the same time..
this is basic system design

"we also need to decide if it will be a bi directional standard to allow the EFB to config the hardware or just config the hardware via web page"
Your config web page would (should) be hitting your own api so the EFB developers would be able to hit/display the same data...if they chose to do that.

I think there is already a standard for traffic data and at least ifly
implements it.  Can't remember what the nomenclature for that standard
is, though.
On 12/17/2015 09:20 AM, duecedriver wrote:

the other thing I am trying to get across.. is take for example traffic...
if the target is lost.. is stratux still keeping it in the data stream
at its last known position.. or does it drop in immediately..
if we are keeping it in the stream.. that it has to have a time tag so
that the EFB can see the target has not been updated in xx seconds
because it can compare the target last known time to gps message
time.. or internal time.. whatever.. but we need to have that standard
too.. who has the master time and how is it set to ensure everything
is talking the same time..
this is basic system design
—
Reply to this email directly or view it on GitHub
https://github.com/cyoung/stratux/issues/150#issuecomment-165481646.

@cyoung.
well ... one radio or 2.. what are the ppm offsets.. enable or disable ahrs, shutdown stratux.., re-cage the ahrs,  etc etc..
set system time... especially for internal iPad gps or no gps.. you dont need a gps position to use a chart program.. its a lot more helpful but I didnt have a dot moving across my paper chart and weather and traffic can still be put on a map without knowing where the users aircraft is.. but I think I have made my point...

if the target is lost.. is stratux still keeping it in the data stream at its last known position.. or does it drop in immediately..

Yes, for 60 seconds. https://github.com/cyoung/stratux/blob/master/main/traffic.go#L86-L92

Getting all those flight app vendors to comply is most likely impossible.
Would love to write my own flight app but who has the time or resources?
Maybe spruce up Avare...
On 12/17/2015 09:22 AM, David Ross wrote:

"we also need to decide if it will be a bi directional standard to
allow the EFB to config the hardware or just config the hardware via
web page"
Your config web page would (should) be hitting your own api so the EFB
developers would be able to hit/display the same data...if they chose
to do that.
—
Reply to this email directly or view it on GitHub
https://github.com/cyoung/stratux/issues/150#issuecomment-165482060.

@HiltonG - GNSS satellites in view would be a useful addition. For each satellite in view, and without bit packing, you'd need 5 bytes. You could squeeze this to 4 bytes by packing 9 bits of azimuth with 7 bits of elevation.
The format below is the same order as NMEA GxGSV sentences.

SV NMEA number: 1 byte // satellite ID -- see table
Elevation angle: 1 byte  // 0-90 deg
Azimuth: 2 bytes // 0-360 deg
SNR: 1 byte // 0-99 dB

Mapping of NMEA IDs below is from http://www.catb.org/gpsd/NMEA.txt if you wanted to mark GPS / GLONASS / SBAS differently in a data table or status display.
|====================================================
| 1 - 32    | GPS
| 33 - 54   | Various SBAS systems (EGNOS, WAAS, SDCM, GAGAN, MSAS)
| 55 - 64   | not used (might be assigned to further SBAS systems)
| 65 - 88   | GLONASS
| 89 - 96   | GLONASS (future extensions?)
| 97 - 119  | not used
| 120 - 151 | not used (SBAS PRNs occupy this range)
| 152 - 192 | not used
| 193 - 195 | QZSS
| 196 - 200 | QZSS (future extensions?)
| 201 - 235 | BeiDou
|====================================================

|====================================================
|System     |Satellite       |PRN            |NMEA-ID
|EGNOS      |AOR-E           |120            |33
|EGNOS      |Artemis         |124            |37
|EGNOS      |IOR-W           |126            |39
|MSAS       |MTSAT-1         |129            |42
|EGNOS      |IOR-E           |131            |44
|WAAS       |AMR             |133            |46
|WAAS       |PanAm           |135            |48
|MSAS       |MTSAT-2         |137            |50
|WAAS       |Anik            |138            |51
|====================================================

@HiltonG
yes.. it would be helpful information if you plan to implement it in the EFB software with a skyview page or you wanted to compare external gps error vs iPad error and either flag the issue or blend the solution..
but if the info is not going to be used by developers inside the program.. its just garbage on the bus... and could be displayed by accessing a webpage in the box

you dont get the vendors to comply... you publish what your box does and how it presents it.. they developers either support your box or they loose customers.. its that simple...

if this little box can become capable.. it will canabilze the handheld ADB-B in market to such an extent that at some point it may be greater that 50%.. but lets face facts.. lots of people are having basic hardware issues right now.. we dont really know if the SDRs are getting week or the signal is drifting so badly in flight after getting hot that they are missing things, the GPS is flakey on lots of peoples boxes over gpio.. likely due to noise and assisted startup info that we need to provide to the gps, and the ahrs hardware gives us nothing useful in accelerated flight yet..
am I missing something... we still have lots of work to do... and this goes back to my post of probably first baselining the hardware that we can get to work before we can tell with any certainty what data will be available to this new data stream..
the stream needs at its core
GPS position and time
Trafic position and its ability to filter out old / degraded traffic
ahrs.. useable attidude in accelerated flight with roll, pitch, coordinated flight (for a ball) speed, heading and vvi
everything else is eyewash

Don't forget weather.  My primary drivers for using stratux are weather,
traffic, and WAAS.
On 12/17/2015 09:36 AM, duecedriver wrote:

if this little box can become capable.. it will canabilze the handheld
ADB-B in market to such an extent that at some point it may be greater
that 50%.. but lets face facts.. lots of people are having basic
hardware issues right now.. we dont really know if the SDRs are
getting week or the signal is drifting so badly in flight after
getting hot that they are missing things, the GPS is flakey on lots of
peoples boxes over gpio.. likely due to noise and assisted startup
info that we need to provide to the gps, and the ahrs hardware gives
us nothing useful in accelerated flight yet..
am I missing something... we still have lots of work to do... and this
goes back to my post of probably first baselining the hardware that we
can get to work before we can tell with any certainty what data will
be available to this new data stream..
the stream needs at its core
GPS position and time
Trafic position and its ability to filter out old / degraded traffic
ahrs.. useable attidude in accelerated flight with roll, pitch,
coordinated flight (for a ball) speed, heading and vvi
everything else is eyewash
—
Reply to this email directly or view it on GitHub
https://github.com/cyoung/stratux/issues/150#issuecomment-165485849.

@skypuppy "I think there is already a standard for traffic data and at least ifly
implements it. "
Yes. There were some complaints posted in the iFly forum about the colors used for various targets. (Yellow targets hard to see on a Sectional.) IFly responded that they were following a standard.

I think we should arrive in this decade at some point and just let the EFBs hit the webserver, grab a JSON structure, and get data from that - easier for everyone, is it not? I can add new stats in a matter of minutes with this and have literally done so when @bradanlane was working on the interface.
Having a discussion about what bits go where and how to save a bit or two on the protocol is kind of silly. GDL90 was designed for 9600 baud serial connections. Our data rate with likely never reach even 50% of what it can be.

my oversight...
same with the weather products.. get the FULL FIS-B message stream.. I think that it should be the EFB developer that should parse it?  otherwise your have to change your data stream format each time the FAA adds a product which then has to flow to the EFB developers who then have to change their code..
just let the EFB maker take the full FIS-B and decode it.. they update their software regularly and work with the FAA proactively so that it can be implement fast.
Same with TIS... just output the FAA standard message and let the developers parse and display it..
if you want to have a way for the web page to access it too that is possible.. but the DATA STREAM that is constantly flowing from the box into the EFB should have the full FIS-B full TIS-B and probably custom ahrs stream unless someone knows of an existing industry standard that is not closed and proprietary.. I am sure there is an ARINC standard... since almost all certified systems get their data over the bus from a remote INU box and not internal to the display..

in the stream along with FULL TIS-B and FIS-B, and our ahrs stream, a stratux box heartbeat, a GPS status indictor for 3d position, status of a WAAS position, a hardware temp/failure bit (just a warning that would tell the user to go to the web page.. i dont think we should add a lot of specfic hardware status in the data stream)
what else.. lets build the list of what the box  MUST provide.. and then let Hilton run with it.. read his .pdf  FIRST .. its pretty comprehensive.. but I do feel that the box should put out the RAW FAA PRODUCTS and let the EFB parse it...

dont forget we are talking the DATA stream.. not what we can get from the box with our own custom interface..

All EFBs get the full FIS-B message stream currently. It is currently the EFBs responsibility to parse them.

otherwise your have to change your data stream format each time the FAA adds a product

Really isn't that much of an issue unless you go with a protocol that is highly obfuscated.

which then has to flow to the EFB developers who then have to change their code

Which happens anyways, except both the decoding and the "other" jobs are part of the EFB maintainer now. In which case:

the development process is .. lets throw shit at the wall to see what sticks

right.. but we cant force the EFB developer to use what is in the stream regardless.. so providing them with the RAW data gives them everything that the box is getting from the FAA without any additional work on the hardware side when things change..
the good EFB developers work with the FAA and know when the data stream is getting changed and can code for it.. we cant make the EFB programmers better.. hence the reason most people use foreflight since they have the best product... then I think FlyQ is second.. if I remember the marketing stats right..
the better the software the more customers they will have... right now HARDWARE makes a lot of people buy the forflight and garmin products because they are relatively cheap and do a good job..
when stratux gets the hardware right and our output stream gives the EFB developers everything they need to compete in a clean well thought out stream and other accessible data that we have in a published standards doc like hilton has on draft here.. they WILL USE IT, I guarantee it..
we are the EGG.. the chicken comes later in this case.. build it and they will come

along with FULL TIS-B are we adding in 1090 targets?  and if so I assume GDL-90 specs that.. and the EFB has to decide if the same target is coming from the ground via TIS or over 1090 direct to the radio
so 2 targets dont show up with a ghosting

All this stuff is over my head. But I once asked thr iFly team in their forum if their app could annunciate when WAAS data was being received from Stratux (as their dedicated box, with its own built in GPS, already does). I didn't get a response. I'm guessing there has to be an agreed upon flag from Stratux so that iFly could announce WAAS. Is this the time & place to decide these kind of things? (I suppose the Stratux UI could report WAAS., if it doesn't already. But as others have said already, the UI is more a diagnostic tool. I typically don't look at it in flight unless I have to.)

Yeah, they get the raw data stream in any case.
We should get back on track - the status message.
And yes, TIS-B and 1090 targets are combined by ICAO identifier.

The stratux UI does report WAAS - build the latest master branch. @AvSquirrel added it (https://github.com/cyoung/stratux/pull/127).

@cyoung "The stratux UI does report WAAS - build the latest master branch"
Ah, okay. Just found that in the commits. Guess I'll see it in the next beta. Is the WAAS indicator something that iFly could snag if it wanted to, to display a WAAS Annunciator on their EFB app?

that data stream should be minimal containing only the RAW FAA data as it comes in, the GPS position stream, the AHRS stream(roll, pitch,yaw(slip),), and a couple status bits(on/off) for waas status, hardware status (overheat and other warnings to be investigated), heartbeat,
for ahrs .. speed, heading (mag or track made good i.e.  gps) vvi etc should be in the stream somewhere either with the GPS data .... or wherever the GDL standard puts it..
remember .. it should hold to whatever standard we want to follow.. adding only what is necessary and used constantly.. any little used info like constellation info can be directly accessed on the box via our web tool or the developer can query the box directly.

@HiltonG
take charge here.. since you have built these data streams before and you have researched and recommended the GDL-90 standard.. we just need to format the current data to these standards and add in any status bits.. again I would not add it a whole bunch of fluf that is not used at least once per second.
the data stream is data used all the time.. specifics can address the hardware directly for specialty data

@HiltonG
the other thing I have notices is that you app does not run in the background.. and does not recapture the heartbeat reliably .. like 1 out of 10..
we also need a very clean implementation of cashing the data in a wait mode to burst it to the unit/software when it wakes.. I know you have some of this coded now.. so its probably already done.. but

@duecedriver - buffering of data while the app is asleep is done on the receiver side. I don't think it can be done on the app side, and probably don't want it to. AFAIK, we're the only receiver that does this in such a general manner that it works with all apps (that are on the list, at least).
Re: heartbeat, is this a stratux specific issue with WingX?
And the app "not working" in the background - not sure what that means but almost all apps going into the background will have some functions suspended.

personally I dont think this needs to be a full community pile on.. cyoung and hilton need to take this offline and get on a call together..
we are not designing an EFB.. we are not reinventing the wheel.. everything that stratux should be broadcasting into the stream is currently being implemented by certified and non certified developers and the standards exist...
RAW FAA FIS and TIS, ahrs etc is all spelled out in ARINC and perhaps Garmin standards.. since the G1000 uses off board attitude as well and I am betting they follow pretty close if not exactly to ARINC standards to make certification easy...
just decide on what additional STATUS bits to include and call it a day..
we can add developer hooks into the box for other data later.. this get the 99% of the must have data into the EFB developers hands as a STANDARD that they can start using... later they can add a stratux hardware page to their apps that will have the additional hardware and GPS detailed info..
my humble opinion... of course...

Well, parts of this discussion have been useful for working on compatibility - we need to address some things like heartbeats not being registered on WingX.

Hi all,
Wow, did this thread get off track...  OK, let me clarify a few thing.  We are talking about a Status message - the status message does not include traffic data, does not include weather data etc, it is simply to tell the app (for example) if GPS is WAAS or not - the GPS data is already defined in other messages.  Same with traffic - those come in using other well-defined messages - apps already display traffic from Stratux.  Implementing this simple status message will allow EFB apps to display a WAAS flag.  How an EFB developer displays this information is up to them.
So let's not talk about specific apps or the actual data (in this thread) - this proposed message is a Status message; i.e. how many targets, WAAS, is AHRS enabled, is the RY835AI board connected etc.
I'd strongly suggest that other topics such as audio, developing another app etc get moved to a different thread otherwise the on-message conversation about the proposed Status message will be lost.
Yes, this will be open, I don't own this in any way.  The reason I said that I would/should be the only one editing the document (and hence modifying the format) is so that we don't end up with 10 different versions.  Let's all agree on one format, I'll update the format/doc, we all agree, I make it final and a few days later EFB apps will be able to display a WAAS flag, show the Stratux firmware version, what hardware it is running on, etc.
Hilton

again.. dont think specifically about a particular app.. WE/YOU decide what you want the box to output.. its up to the EFB  developers to use it.. not the other way around..
in reality you could come up with your own data stream and IF stratux gets popular enough.. developers would be forced to add it to their products or loose business to customers who move on to a product that does..
or you could EMULATE someones elses custom box that is well represented in most EFBs ..but you run the risk of having to change every time they do..
keeping it to an open industry standard allows any EFB or system to parse the messages...
personally, I think any EFB maker that has its own hardware is going to lock you out... regardless of what you do.. until they loose enough sales that they turn back around and have to support it or die...

"personally I dont think this needs to be a full community pile on.. cyoung and hilton need to take this offline and get on a call together.."
While that would be expedient, I didn't want anyone to claim that I was being biased (towards WingX Pro7) in any way, hence the openness.  Now if cyoung wants to take this offline with me - we could probably agree to a format in one day and be done.  Again, I'm trying to coordinate, not dictate.
Hilton

Hilton, thanks for the time you've put into this.
What would be your thoughts on (instead of using GDL90), we do something like this:
 $ curl -vvvv http://<IP_ADDRESS>/getStatus
 *   Trying <IP_ADDRESS>...
 * Connected to <IP_ADDRESS> (<IP_ADDRESS>) port 80 (#0)
 > GET /getStatus HTTP/1.1
 > Host: <IP_ADDRESS>
 > User-Agent: curl/7.45.0
 > Accept: */*
 >
 < HTTP/1.1 200 OK
 < Access-Control-Allow-Origin: *
 < Content-Type: application/json
 < Date: Thu, 17 Dec 2015 16:52:14 GMT
 < Content-Length: 275
 <
 {"Version":"v0.5b1","Devices":0,"Connected_Users":1,"UAT_messages_last_minute":0,"UAT_messages_max":0,"ES_messages_last_minute":0,"ES_messages_max":0,"GPS_satellites_locked":0,"GPS_connected":false,"GPS_solution":"","RY835AI_connected":false,"Uptime":23091,"CPUTemp":28.786}
 * Connection #0 to host <IP_ADDRESS> left intact

(those are the currently implemented fields, as mentioned I can add other ones in a matter of minutes).
The benefits of doing this is 1) quick/easy additions on both ends, 2) two way communications, WingX can pause message flows actively just like FF/Stratus do.

@HiltonG
I agree. however for this project to really get traction and start moving we need a couple things
1> we nee to investigate and baseline some hardware that is going to WORK and code it.. AHRS I am looking mostly at you.. but GPS also has some hits and misses and the RY does both but in some cases is not doing well for either... gotta have the hardware working
2> once the hardware is working you can decide what info is now available and STANDARDIZE how to get it out.. documentation of what information is available and how to access it will be KEY to get developers to look at it.. they dont have the time to dick around trying to figure out how your box works.. it has to tell them how to easily use that data that your box delivers...
3> any web based tools or displays to allow users of stratux that use an EFB that does not fully support stratux the ability to get at the box to see gps status, temps, whatever...
we are not talking bias if its open sourced and documented so everyone can use it.. if you pulled all the EFBs into  a room I bet none of them are doing status messages the same way... data they may be very similar on except for those that have their own hardware...
there is the foreflight box and its closed
you have garmins boxes.. closed and encrypted...
as long as stratux provides reliable data and is open source.. it will be added to EFB software just like ilevel and the other manufacturers

Don't get me wrong: I'm all for feature creep as long as it makes sense.
Skypuppy
On 12/17/2015 09:45 AM, duecedriver wrote:

my oversight...
same with the weather products.. get the FULL FIS-B message stream.. I
think that it should be the EFB developer that should parse it?
otherwise your have to change your data stream format each time the
FAA adds a product which then has to flow to the EFB developers who
then have to change their code..
just let the EFB maker take the full FIS-B and decode it.. they update
their software regularly and work with the FAA proactively so that it
can be implement fast.
Same with TIS... just output the FAA standard message and let the
developers parse and display it..
if you want to have a way for the web page to access it too that is
possible.. but the DATA STREAM that is constantly flowing from the box
into the EFB should have the full FIS-B full TIS-B and probably custom
ahrs stream unless someone knows of an existing industry standard that
is not closed and proprietary.. I am sure there is an ARINC
standard... since almost all certified systems get their data over the
bus from a remote INU box and not internal to the display..
—
Reply to this email directly or view it on GitHub
https://github.com/cyoung/stratux/issues/150#issuecomment-165488542.

@cyoung
i dont see any reason that the stratux status messages cant be custom.. but if the GDL passes waas status just let the DGL data stream carry it... if you want to have other status messages that a certified or garmin systems doesn't have.. then ping it directly..
the high frequency data stream really should just be GDL formatted ADS-B,GPS, AHRS data and whatever statuses for that data is already supported..

IIRC, iFly shows a * in the GPS box (where they show relative signal
strength/number of sats) when they have WAAS or equivalent.
On 12/17/2015 10:21 AM, Ergonomicmike wrote:

@cyoung https://github.com/cyoung "The stratux UI does report WAAS -
build the latest master branch"
Ah, okay. Just found that in the commits. Guess I'll see it in the
next beta. Is the WAAS indicator something that iFly could snag if it
wanted to, to display a WAAS Annunciator on their EFB app?
—
Reply to this email directly or view it on GitHub
https://github.com/cyoung/stratux/issues/150#issuecomment-165499442.

PASS-THROUGH REPORTS
When the pass-through interface is in use, the GDL 90 will output the received ADS-B messages as-is without further processing. Targets are selected for output based on proximity to the ownship position, and the amount of data interface bandwidth available. No traffic alerting service is provided when this interface is in use. No report extrapolation or coasting is performed.
There are two Pass-Through report messages; one for the Basic UAT message (see Table 13), and one for the Long UAT message (see Table 14).

the GDL status heatbeat message has just about everything near as I can tell
1  message ID heartbeat
2 STATUS BYTE 2
Status Byte 1
Bit 7: GPS Pos Valid Bit 6: Maint Req'd Bit 5: IDENT
Bit 4: Addr Type
Bit 3: GPS Batt Low Bit 2: RATCS
Bit 1: reserved
Bit 0: UAT Initialized
3 Status Byte 2
Bit 7: Time Stamp
(MS bit)
Bit 6: CSA Requested
Bit 5: CSA Not Available Bit 4: reserved
Bit 3: reserved
Bit 2: reserved
Bit 1: reserved Bit 0: UTC OK
Time Stamp
Message Counts
you could hijack a reserved byte but then you stray from standard
https://www.faa.gov/nextgen/programs/adsb/wsa/media/GDL90_Public_ICD_RevA.PDF

aspen avionics connected cockpit is supposed to be an open format language.. its designed for wireless and panel certified communications and just got FAA approval
Hilton as a developer you could get their tech specs and see if its usable for our needs as well

@duecedriver WingX Pro7 has been compatible with Aspen Avionics system since almost day 1 (it's been a while, I'd need to go back and look at the inner workings).
Regarding status messages, ignoring Stratus and Garmin, all ADS-B receivers use a status message like the one I propose; i.e. small, defined fast, small, easy-to-read bytes (not JSON).  I think there are one or two ADS-B receivers that do not have a status message, but the Levils, Clarity, etc all have a status message specific to their hardware very similar to the one I proposed - that's why I did it like that; i.e. because that is the standard way (and a super efficient way) of passing status data.  We cannot use another manufacturers status message because it wouldn't include a flag to show if the RY835AI is connected (for example), perhaps Stratux will support other hardware in the future.  You'll see that I included a version number on the Status message, this allows us to add additional fields (e.g. sat azimuth) at a later date without breaking currently implementations.
Hilton

if the gps is providing a valid 3d fix.. do I care if its a RY835AI?
results based warning info...
think of them no as equipment heartbeat, think of them as data validity heartbeat..
valid 3d gps position set a bit high
valid WAAS set its bit high
valid statux heartbeat etc
I dont care what is hooked up.. that status bits in the GDL heartbeat are condition based.. not if its plugged in...

Like I kept telling my crew chief.. I dont care how it works.. why it wasn't working, or how you fixed it.. just as long as the annunciator panel said it was working....

Well, Apple has a built in JSON parser in their libraries NSJSONSerialization. Any format we come up with is going to be non-standard and a custom implementation for anyone that wants to use it.
I'm not emotionally attached to really any format, but mostly concerned that if it becomes too unwieldy that nobody will bother to use it - sending the ADS-B towers coordinates is useful, which GPS satellites are in view seems like something that would be used in the future. There are a lot of stats that stratux already collects, like signal levels of the ADS-B towers. That is information that the EFB is not exposed to. Will any EFB care to display this, and will users like/use it? Not my department. Can these things be provided? Yes. Is a GDL90 derivative message the best way to handle these needs? I don't think so.
Besides the format - Hilton, do you feel about some sort of flow control on received messages? Are receivers like Clarity/Levil just smashing UDP packets against the iPad and hoping the EFB receives it? What happens when the app goes out of context with these receivers, I assume that the EFB loses airtime.

did anyone bother to open the FAA pdf of the GDL-90 message format and look at the GDL-90 heartbeat and what all could be monitored in that one message.. it seems pretty good for keeping an eye on the important stuff...
lets focus on the steak.. we can get to the peas and carrots later..  lets just get bulk of the information into the map.. lets worry about how a user could get a sky view of the satellite constellation, or the gps firmware version number later...

@duecedriver - almost every bit of my GDL90-specitic code cites the section of that exact doc that it came from: https://github.com/cyoung/stratux/blob/master/main/gen_gdl90.go#L23 :) Thanks for pointing it out, though.

@HiltonG
I would be ecstatic with your product if on your map page, the GPS OK was changed to a GREEN GPS WAAS if was was present and RED if no gps updates are coming in and Yellow if the GPS is not at least 3d
the ADS-B green if there is a 1hz heartbeat... if I tap the ADS-B (yes it should be active button) I should get a screen that tells me the update status of EACH FAA FIS-B data product.  and replace internet weather with ADS-B weather as it comes in and RETAIN it though a restart or crash
AHRS - provided we had one that worked in accelerated flight, tapping AHRS would give options to kal
for your AHRS / synthetic vision... ADD a standard VVI tape nest to the alt readout
there are really not to many critical things to keep an eye on in the stream..
under the 2 or more taps required down arrow to external hardware tab.. just have a stratux tab that has the particulars.. it should go to whatever hardware is hooked up.. not yet another button to press.. it should be smart enough to know what you want to look at... too many buttons to press and drill downs when you are bounding around in IMC

agree with deucedriver and cyoung on this.
On 12/17/2015 12:48 PM, duecedriver wrote:

did anyone bother to open the FAA pdf of the GDL-90 message format and
look at the GDL-90 heartbeat and what all could be monitored in that
one message.. it seems pretty good for keeping an eye on the important
stuff...
lets focus on the steak.. we can get to the peas and carrots later..
lets just get bulk of the information into the map.. lets worry about
how a user could get a sky view of the satellite constellation, or the
gps firmware version number later...
—
Reply to this email directly or view it on GitHub
https://github.com/cyoung/stratux/issues/150#issuecomment-165545467.

I dont think that keeping it in the data steam with full info for a full 60 seconds is a good idea.. again.. bad data is worse than no data…
I would rather we either drop its tags or change something so its obvious its questionable.. make the callsign all ????? something…
it would be great if the EFB would handle the coming and going.. again.. we just pass the full stream… if a target goes missing the EFB can choose to hold it for a short time with a tag identifying at missing.. and or ghost plot it at its last known heading and speed for a couple seconds to see if it comes back…
but holding a defined target for a full minute.. and piper aerostar or TBM could be 4 miles down the road by then…

On Dec 17, 2015, at 10:25 AM, cyoung<EMAIL_ADDRESS>wrote:
if the target is lost.. is stratux still keeping it in the data stream at its last known position.. or does it drop in immediately..
Yes, for 60 seconds. https://github.com/cyoung/stratux/blob/master/main/traffic.go#L86-L92 https://github.com/cyoung/stratux/blob/master/main/traffic.go#L86-L92
—
Reply to this email directly or view it on GitHub https://github.com/cyoung/stratux/issues/150#issuecomment-165483003.

@duecedriver "if the gps is providing a valid 3d fix.. do I care if its a RY835AI?"  Maybe, maybe not.  Someone else might and it costs 1-bit, plus the code already has that bit available.  One day when these things are enclosed in a case, knowing what firmware and hardware is inside will be important.  You might not care to know how many 1090 targets there are, someone else might.  You might want to see where the ADS-B towers are, someone else might not.  I put this short message together based on what fields the software already has and what users might want to see.
Here's the thing: This will take Chris an hour or two to code, EFB developers an hour or two to code and we'll be done.  How about we agree on the Status Message now and be done?  Pilots will be able to get a great status page (if they want to see it), EFB apps will be able to display the WAAS flag, you'll know what firmware you're running just by looking at the Stratux status page in the app, and this message is perfectly consistent with other status messages from other ADS-B receivers, it is 'future proof' in that additional fields can be added later if required, it doesn't clash, we don't need to open a separate HTTP connection (check for time outs, parse JSON etc) - this message contains the available data in a very simple to read format and requires very few CPU cycles on the client and on the Rasberry board.
Again, this message has nothing to do with the actual traffic, 1 minute delays etc, it is just status for a WAAS flag and a status view.
Holding thumbs...  and hoping for @cyoung buy-in and approval - we can be done today.  Hint.  ;)
Hilton

Besides the format - Hilton, do you feel about some sort of flow control on received messages? Are receivers like Clarity/Levil just smashing UDP packets against the iPad and hoping the EFB receives it? What happens when the app goes out of context with these receivers, I assume that the EFB loses airtime.

All communication is UDP so if data goes missing you’re going to miss METARs, NEXRAD, traffic etc.  Given that the status messages will be sent out once per second (right after the heartbeat), if we drop a status message here and there, no-one will notice; e.g. if 50% of the status messages got lost, the WAAS flag would update every two seconds instead of every one second (no-one will notice and that’s at 50% loss which would surely be noticeable by other data loss (METARs, traffic etc)).
Hilton
From: cyoung<EMAIL_ADDRESS>Sent: Thursday, December 17, 2015 5:22 PM
To: cyoung/stratux<EMAIL_ADDRESS>Cc: Hilton Goldstein<EMAIL_ADDRESS>Subject: Re: [stratux] Stratux Status Message (#150)
Besides the format - Hilton, do you feel about some sort of flow control on received messages? Are receivers like Clarity/Levil just smashing UDP packets against the iPad and hoping the EFB receives it? What happens when the app goes out of context with these receivers, I assume that the EFB loses airtime.
—
Reply to this email directly or view it on GitHubhttps://github.com/cyoung/stratux/issues/150#issuecomment-165597317.

@HiltonG
I give up...

@cyoung
if the app takes a nap.. you can toss traffic, but I would save all the weather messages for at least an hour which is the longest of the ADS-B FIS-B data products.. after that they all get rebroadcast.. then when the device comes back up.. burst all held weather, position and current traffic.. the only data that is worth cuing is weather.. everything else including status is only valid in real time

@cyoung
of course that is for apps that are not backgrounding like wingx.. I think some of them are running as a background process and may still take data... dont know
If I were to WRITE the app.. I would have my EFB running traffic and monitoring bank angle because I could still issue some kind of collision alert and bank angle alert message from the background via message center and or audio..
but thats me..

@duecedriver That is what Clarity does (aka Data Burst Technology); i.e. buffers data then blasts it through.  If/When this happens it is a huge burden on the app to process all that data so I would prefer to see it sent a little slower than full speed to play nice with the app.
Hilton

@duecedriver - that's essentially what it does now. It continues to track traffic targets as it normally does, just does not send the traffic update messages until it detects that the app has come back alive. And it buffers all of the weather until it detects that it comes back. See: https://github.com/cyoung/stratux/blob/master/notes/app-vendor-integration.md
I haven't found an app for iOS or Android that this doesn't work for - and they never accept messages in the background.
Okay, so let's stay on topic here - the goal is to improve compatibility between stratux and WingX. Maybe other apps, too. But let's stick with that for now.
I have seen some weird behavior like you described with heartbeats @duecedriver - have you got more information? I haven't tested it thoroughly, and this should probably be packaged together and figured out while we're working on this.

@HiltonG - we're doing this now and limiting it to 2500 msg/sec, just sort of seemed right. If you could advise on this, it would be great to have your input.
https://github.com/cyoung/stratux/blob/master/main/network.go#L188

Regarding heartbeat (and other) messages: I'll fire it up tonight and see what I can find.  If WingX/Stratux has a problem and WingX/Clarity has a problem, then the fault probably lies within WingX, else...
Hilton

as far as heartbeats.. wingx almost never resumes.. and I cant figure out rhyme or reason for it.. sometimes it reconnects sometimes most times it does not... if switching windows or using the little sliide out safari window to check the web tool.
all I am saying is that the GDL code has a defined heartbeat message in its standards that will likely provide enough info to ensure that stratux is passing down the right info... heartbeat and status messages in the stream is what I am using when i am just on the map page cruising along and the app is either putting an indicator on my screen or going to give me a warning message.    I can see the frapping targets wait for it.. on the map.
if a radio goes dead that would be nice to know
if i want details on how the box is performing I would have to leave the map and go somewhere else in the program.. that could then poll the box..
I really dont see the benefit of throwing everything and the kitchen sink into the data stream on the off shot I might look at it once during a flight?
looking at the data..
5hz updates on position would be nice..
1hz on each traffic target.. and like I have been saying I would dump a target almost immediately and let the app decide it it wants to ghost it ...
the heartbeat could update all the IMPORTANT status issues, GPS quality, WAAS, etc 1hz

@cyoung
if you keep track of the weather messages perhaps you can supersede some data.. IE only keep relevant messages and dump superseded or duplicated but that would require stratux side processing

here is a good chart of FIS-B products and the update cycle for ref if you need it....
https://bruceair.wordpress.com/2014/09/09/flight-information-service-fis-b-weather-and-info-in-the-cockpit/

let hilton run with his concept.. beta it and see what kind of overhead we are dealing with then shoot it down if it craps up the data stream at this point..
I already have about 5 posts above where I express my opinion on what I think is relevant to keep an eye on in any regular 1 per second kind of way...
I just hope hope that it won't take me 5 presses and drill downs to get to it...

as far as heartbeats.. wingx almost never resumes.. and I cant figure out rhyme or reason for it.. sometimes it reconnects sometimes most times it does not... if switching windows or using the little sliide out safari window to check the web tool.

OK. We need to work on that...

all I am saying is that the GDL code has a defined heartbeat message in its standards that will likely provide enough info to ensure that stratux is passing down the right info

I'm not going to deviate from the spec on the heartbeat message, it is the same one used for every app and even though GDL90 says "unused", I'd be willing to bet that there is one app out there that will have some issue with us freeloading on "unused" parts of the message.
The WiFi connection will probably never be used more than 10% above its capacity, adding redundant or extra data to this message isn't really a concern from a resource management perspective. Besides that, there are some other issues you should probably discuss with Hilton that are just specific to WingX and how it does/doesn't display this data.

I digress....

I just read hiltons pdf again and for the life of me I just dont see the value added for half the items.. at least not updated at 1hz in a heartbeat message
I could see making use of some of that information on a regular basis but it would be considered data not heartbeat or status.. now if you are putting it in a separate message packet because the standard has not definition for it.. thats one thing..

The standard has no definition for it.
30 or 40 bytes once per second is nothing.
Hilton
On Thu, Dec 17, 2015 at 3:48 PM -0800, "duecedriver" <notifications<EMAIL_ADDRESS>wrote:
I just read hiltons pdf again and for the life of me I just dont see the value added for half the items.. at least not updated at 1hz in a heartbeat message
I could see making use of some of that information on a regular basis but it would be considered data not heartbeat or status.. now if you are putting it in a separate message packet because the standard has not definition for it.. thats one thing..

Reply to this email directly or view it on GitHubhttps://github.com/cyoung/stratux/issues/150#issuecomment-165617763.

@cyoung "I'm not going to deviate from the spec on the heartbeat message" - I agree 100%
@duecedriver From your posts you seem to imply that just because there is a status msg, that you will see all this data on the moving map.  EFB apps are free to ignore the status msg completely - in fact, this will be their default behavior.  WingX Pro7 will read the small status mag, show a WAAS flag the same way it currently does with other ADS-B receivers, know it is talking to a Stratux, and the other data will be shown in a popup status view if the user wishes to see it otherwise it is not shown
As @cyoung points out, we're talking 30-40 bytes per second on a WiFi network that can do MB/s.  It is trivial for the receiver to construct this msg (Stratux can eventually drop the 0xCC msg) and trivial for the app to process it.
Hilton

@HiltonG - I think what we can do now is go ahead with the status message as published , but will have a concurrent mechanism where an EFB can "GET" the data via HTTP (and request some extra variables as well). In the long run, maintaining the next versions will depend on adoption by EFBs.
The one condition on this is that we need to make this a part of the project and, while I appreciate your input and involvement (and hope we can continue to work together to our mutual benefit), allowing an EFB vendor be the keyholder on any part of the project would be a mistake. We need to remain app-agnostic and as compatible as possible, solving specific app compatibility issues in the most general way possible.
One more thing - on GDL90 traffic reports (0x14) - what would be a good way to differentiate 1090 from 978? What is the best way to make this differentiation that you've seen?

@HiltonG
I will say it one more time and then I am done..
there are status messages and then there is data...
a status message is generally a good/bad on/off ready/not ready flag that is constantly monitored and or displayed.. it must come in at a regular interval IE the heartbeat message and everything contained therein (the GDL standard not yours) if there is data in the heartbeat / status message that is not being utilized on each and every arrival.. its not a heartbeat status its either garbage or unneeded data
I have helped design actual certified flight decks and from a systems analysis standpoint that is just the way it is..
then there is data... like the satellite constellation geometry, attached hardware type and version, message rates, hardware temps.. etc... that is data that is polled or addressed when required
honestly.. hardware ready status is determined inside the box and stratux just sends a healthy not health.. if cyoung wants to allow users to see what is not healthy then he provides the EFB designers a location to get at whatever additional DATA that is available..
in a B-777 with thousands of devices and system do you think the heartbeat includes all the crap you are talking about... no.. there are thousands of data points in an INU alone, only a couple hundred are even available to be viewed when drilled way down.. and only handful of status bits fly around the system to keep the annunciator panel happy.. again that is the way its is..
the EFB from a heartbeat standpoint should not care about internal temps or anything else.. the box sends our a bit saying its healthy and attached.. that it
the gps status is either 3D locked or not
the WAAS is either locked or not
the rest of the crap you want is useless in a 1hz heartbeat... if you want to have a gps page that displays the satellite constellation you can pull that data when required, but its not a status message
I cant explain it any better..
the stratux box is a source of data...
the EFBs job is to display that data and alert or annunciate that that data is alive and valid.. thats it..
you are what the pilots call suffering from engineeringitus.. that is thinking that the operator (i.e. the pilot) gives a shit whats happening behind the scene... we dont.. we want cleanly displayed data with a minimal warning panel to inform us when one of the dogs gets off the leash.. most jets I flow had a master caution panel of a couple dozen lights.. that it .. for the whole aircraft... additional warning messages would be available on individual boxes like the FMS to give more defined or less critical warnings..
seriously.. you are way overthinking things here... Stratux just needs to send out all the Captured ADS-B data raw, the gps location, and ahrs angles,  so guys like you can parse it and display it, with a  couple bits comming out of the box at 1hz in its heartbeat staying I am connected/health, have a gps lock, waas active/ etc... not give you its life history and tell you what it had for breakfast...

I have not looked at how the statux gets its data from the GPS and how it pushes it out but most of the satellite status, location, and accuracy data is already included in the standard NMEA sentences so most of that if its getting to the iPad dont even need to be in the heartbeat.. if only the stratux sees all the NMEA then it can determine health and place that status bit in the heartbeat.  since we are using DGL.. garmin has PLENTY of custom NMEA sentences that cover just about everything GPS related
everything you ever wanted to know
https://www.garmin.com/support/pdf/NMEA_0183.pdf

per the GDL specs
Within this 90% limit, the GDL 90 will output the following messages:
� one Heartbeat message per second,
� followed by the Ownship report,
� followed by any Traffic Alert reports (if enabled),
� followed by a number of Uplink messages (configurable, maximum of 0 to 4 per second),
� followed by proximate Traffic reports,
� followed by additional Uplink messages (if extra bandwidth capacity is available).
the heartbeat message
BYTE  NAME               SIZE   VALUE
1         Message ID      1           010 = Heartbeat
2        Status Byte 1     1
Bit 7: GPS Pos Valid   1 = Position is available for ADS-B Tx
Bit 6: Maint Req'd       1 = GDL 90 Maintenance Req'd
Bit 5: IDENT                1 = IDENT talkback
Bit 4: Addr Type           1 = Address Type talkback
Bit 3: GPS Batt Low     1 = GPS Battery low voltage
Bit 2: RATCS                1 = ATC Services talkback
Bit 1: reserved
Bit 0: UAT Initialized     1 = GDL 90 is initialized
there are 3-7 .. look them up yourself...
should provide all the space needed to determine the health and accuracy of a device far less complex than a GDL-90
remember that is, in the end, a stratux and not a DGL-90 but keeping the messaging and data formats as conformal as possible to that other programmers and software can be easily coded to use a STRATUX not a GDL-90
The only POSSIBLE way any stratux info can be utilized by any actual certified equipment is as I have said before.. probably over an FAA approved interface like Aspens connected cockpit .. and since you said you were in on the ground floor there you should know that spec far better than the rest of us...

Now to inject a bit of levity..
http://messybeast.com/dragonqueen/hw-venus.html
and neither knows what the user actually needs or how to display it.. thats were the systems analyst, subject mater experts (pilots) and human factors specialists sit down to write the system specs and layouts ahead of time! hehe

@cyoung
do we really care, on the EFB were the traffic came from?  As the end user is there any value added in knowing or caring about 1090 vs 978... would I treat the traffic differently.. how would I use that data.. if I cant use it I dont need it....

another week of this crap and I am going to do what everyone else does these days...
Go get a whole bunch of Obama grant money to hire a shitload of high quality H1-B hardware and software guys to design it then send the design to china to be built for 10 bucks and charge $999 and be done with it!!! hehe
oh.. lets not forget about the stupid cash available though kickstarter too..

@cyoung
"I think what we can do now is go ahead with the status message as published"
I will finalize it by making the PDF a Version 1, tweak the text to make it final etc, and add some additional text to define unused bits as zero (just to be clear).
"but will have a concurrent mechanism where an EFB can "GET" the data via HTTP (and request some extra variables as well)."
Absolutely, that is a separate 'web service' you setup in Stratux (that other receivers don't have) - it's yours, run with it.
"In the long run, maintaining the next versions will depend on adoption by EFBs." - I think this message will be adopted very quickly by other EFBs.
"The one condition on this is that we need to make this a part of the project and, while I appreciate your input and involvement (and hope we can continue to work together to our mutual benefit), allowing an EFB vendor be the keyholder on any part of the project would be a mistake. We need to remain app-agnostic and as compatible as possible, solving specific app compatibility issues in the most general way possible."
I agree completely and have been clear about that all along, this is why I posted my proposed message here instead of just emailing between us.  Once I finalize the PDF, it's out there, not owned by me or anyone else (you own it really).  I would like to be able to update it periodically as required to ensure we maintain forwards and backwards compatibility (entirely up to you), but after finalizing the spec today, I will just be another EFB developer for the purposes of the Stratux Status Message.
"One more thing - on GDL90 traffic reports (0x14) - what would be a good way to differentiate 1090 from 978? What is the best way to make this differentiation that you've seen?" - Let me take a look and get back to you - gotta catch up on a bunch of things here at work.
As soon as you are done implementing the Stratux Status Message, create a build and I will get it up and running in WingX Pro7 - shouldn't take more than a day or three.  Also, many thanks to all contributions here about WingX Pro7 usability etc particularly the suggestion about being able to get the ADS-B Receiver status information faster/easier.
@cyoung Thanks again for your efforts.
Hilton

@cyoung
You do know I was kidding about the china thing..  keep up the good work.. we are all counting on you... but seriously.. would 1 H-1B hardware guy be too much to ask to get the AHRS working right!!! hehe

speaking of overpriced CRAP, did you see the bluetooth keyboard that I think it was avadyne just got approves.. its like a 10 dollar home theater keyboard with some custom keys the size of a calculator.. the price.. $299....
priceless... BOHICA

@duecedriver - patience ... we're making steady forward progress ...

Hi,
The final Stratux Status Message doc (Version 1) is now available.  I cleaned up a few things (e.g. specifying that unused bits are zero) and added a field for the number of radios connected.
http://hiltonsoftware.com/stratux/StratuxStatusMessage-V1.pdf
I will start implementing this message this weekend and as soon as I get a new Stratux firmware build from @cyoung with this message implemented, I will report back and show results.
Thanks, have a great weekend,
Hilton

Okay, it is implemented now - minus three issues:

The C code that is included in the Appendix B won't actually produce a hardware revision code that matches the table of Appendix A. Right now everyone should be using a Pi2B - zeroing it out for now. There will also be the Raspberry Zero but for now going to leave this field unused.
GPS satellites connected (not locked) - not collecting these stats yet. Set to 0.
The CPU temp formula doesn't make sense to me, but implemented as published.

Plug in stratux and do a git clone http://github.com/cyoung/stratux, "make", killall -9 gen_gdl90, then issue the following command (it will replay an actual flight recording):
 ./gen_gdl90 -replay -uatlog ./test-data/cyoung-09062015-noproblem-stratux-uat.log  -speed 2

@cyoung

I just copied that code from code someone posted on the web.  I have not verified it.  It would be nice to know what hardware it is running on.  All this information is very useful when trying to figure things out when a user reports a problem.  Let me know how you would like to differentiate between the first Rasberry Pi, the current one and the Zero.  I'll modify the doc accordingly.

Is this a field we need? I thought I saw this in you code so I added it but if you think it isn't useful, let's remove it - your call.

Just an easy way to avoid working with negative numbers, but still being able to represent them.

Hilton

The only RPi that stratux works on now is the RPi 2 - soon this will branch off and will have to start making use of this field. Not sure how to detect the UK vs China one? Will look into this. But just going to leave it 0'd for now and defer.
Should be ready to test unless you're making use of the hardware revision and satellites-in-view-but-not-locked data.

Sounds good, I agree with your comments.  I have found a small dependency.  Looking at a byte, bit 7 is traditionally on the 'left'; i.e. MSB and bit 0 is traditionally on the 'right'; i.e. LSB.  Either I change the doc or you change the code, but we should get these matching and be clear in the doc the we are using the convention that bit-7 is the MSB.
Probably easier if I change the doc and you leave the code as is.  Let me know.
Hilton

Longtime user - first time poster !!
@cyoung and @HiltonG   - you guys rock - making this project better everyday

One more thing, please change:
//TODO: Hardware revision.
msg[8] = 0
msg[9] = 0
msg[10] = 0
msg[11] = 0
to:

@HiltonG - can we stick with little endian, it matches up with the ownship reports and such.
@StratuxLover - Thanks!

@HiltonG e7a19f2296b43071772832aba11870048fec2917

and who will fund his salary, benefits, travel, etc?
On 12/18/2015 09:45 AM, duecedriver wrote:

@cyoung https://github.com/cyoung
You do know I was kidding about the china thing.. keep up the good
work.. we are all counting on you... but seriously.. would 1 H-1B
hardware guy be too much to ask to get the AHRS working right!!! hehe
—
Reply to this email directly or view it on GitHub
https://github.com/cyoung/stratux/issues/150#issuecomment-165811257.

@cyoung Altitude and ground speed are big-endian, not little-endian:
https://github.com/cyoung/stratux/blob/master/main/gen_gdl90.go#L281
Hilton

In offset 14, several more types of IMU's are being written for besides
the "standard" RY AHRS unit.  Please reserve 4 bits or more to identify
the other units.  Ditto even more for GPS units.
On 12/18/2015 11:01 AM, HiltonG wrote:

Hi,
The final Stratux Status Message doc (Version 1) is now available. I
cleaned up a few things (e.g. specifying that unused bits are zero)
and added a field for the number of radios connected.
http://hiltonsoftware.com/stratux/StratuxStatusMessage-V1.pdf
I will start implementing this message this weekend and as soon as I
get a new Stratux firmware build from @cyoung
https://github.com/cyoung with this message implemented, I will
report back and show results.
Thanks, have a great weekend,
Hilton
—
Reply to this email directly or view it on GitHub
https://github.com/cyoung/stratux/issues/150#issuecomment-165839619.

@skypuppy
the obama admin will gladly pay for all expenses  if you can provide proof it will result in at least 10 americans loosing their jobs and a promise to enroll him in the nearest democratic party and radical place of worship..

can we add a bit for case color too.. ok .. I am being a wise ass... but the holidays are coming.. what can I say...

@skypuppy I have 13 bits reserved for other devices in offset 14 (that's why I made it 16 bits not just 8 bits).
Hilton

I noticed that but it wasn't specified.
On 12/18/2015 01:57 PM, HiltonG wrote:

@skypuppy https://github.com/skypuppy I have 13 bits reserved for
other devices in offset 14 (that's why I made it 16 bits not just 8 bits).
Hilton
—
Reply to this email directly or view it on GitHub
https://github.com/cyoung/stratux/issues/150#issuecomment-165884526.

@skypuppy Good point - I'll add 'reserved' to both offset 12 and 14 just to be clear.
Very good feedback - thanks.
Hilton

I'm confused, looks to me like it's doing the same thing for altitude as for other fields even in this new message - if you want to change it just do a pull request

@HiltonG
I just read this complete thread and want to add an interesting pattern I have noticed
If you are in WingX and jump to another app here is what I have observed

If you resume WingX by just selecting the icon on the home screen – 75% of the time the heartbeat does not resume
If you resume WingX by double tapping the home button and selecting the already running WingX, heartbeat is resumed 100% of the tests I performed.

The only difference I noticed that when option 2 is used, the “GPS OK” flashes red then back to green, the ADSB heartbeat also resumes.
So how you resume the app seems to determine if the heartbeat is reestablished or not.
As I said, just an observation.

Anyone experience anything like this with WingX on other devices?
Might be the way we're detecting app-out-of-context

Doesn't that mean it's an OS (IOS or Android?) issue and not a stratux
one?  If you fix that for one OS, it might break the other.
All I want is a little standardization
Skypuppy
On 12/18/2015 02:48 PM, cyoung wrote:

Anyone experience anything like this with WingX on other devices?
Might be the way we're detecting app-out-of-context
—
Reply to this email directly or view it on GitHub
https://github.com/cyoung/stratux/issues/150#issuecomment-165894835.

yep.. and it has been mentioned in several places.. especially over on reddit
I find no rhyme or reason.. leave the app and come back it may or may not work.  pull out the slide over window to another app like safari to see that stratux web page and go back into wingx.. crap shoot.. gps for my internal gps comes back but stratux less than 50/50.. going in and out of wingx a couple times forces it back or shutting it down and starting opening it again works most times.. but if you do that you loose all your ADS-B weather updates and it reverts to last internet weather.. I have not taken it over to the ADS-B antenna since last weeks update.. but it definitely lost all FIS-B weather updates with the previous version.

Doesn't occur with any other app AFAIK - wouldn't say it's an iOS issue

when I was doing development and testing I had subscriptions to them all ... I have let them all lapse..
only have wingX at the moment

Hi,
I will do some testing and let you know my results.  Just because the Stratux/WingX Pro7 is the only one that doesn’t work properly does not mean that the bug lies in WingX Pro7.  WingX Pro7 closes ports when it is minimized so that others can jump in and use that port when they are moved to the foreground.  I think other apps don’t ‘play nice’ and hold onto the port thereby not allowing another app to use that port (and hence connect to the ADS-B receiver).  So, two obvious options, 1: Bug in WingX Pro7, or 2: Bug in Stratux not handling the port opening/closing/opening again.
Hilton
From: duecedriver<EMAIL_ADDRESS>Sent: Friday, December 18, 2015 4:10 PM
To: cyoung/stratux<EMAIL_ADDRESS>Cc: Hilton Goldstein<EMAIL_ADDRESS>Subject: Re: [stratux] Stratux Status Message (#150)
when I was doing development and testing I had subscriptions to them all ... I have let them all lapse..
only have wingX at the moment
—
Reply to this email directly or view it on GitHubhttps://github.com/cyoung/stratux/issues/150#issuecomment-165898364.

I think it may be a problem with WingX opening the port again after it goes back into context. Was just able to reproduce this now. tcpdump confirms that stratux is sending hearbeats -
  root@raspberrypi:~# tcpdump -n -i wlan0 port 4000
  tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
  listening on wlan0, link-type EN10MB (Ethernet), capture size 65535 bytes
  21:33:01.089303 IP <IP_ADDRESS>.60582 > <IP_ADDRESS>.4000: UDP, length 20
  21:33:01.189188 IP <IP_ADDRESS>.60582 > <IP_ADDRESS>.4000: UDP, length 20
  21:33:01.289165 IP <IP_ADDRESS>.60582 > <IP_ADDRESS>.4000: UDP, length 20
  21:33:01.389141 IP <IP_ADDRESS>.60582 > <IP_ADDRESS>.4000: UDP, length 20
  21:33:01.489167 IP <IP_ADDRESS>.60582 > <IP_ADDRESS>.4000: UDP, length 20
  21:33:01.589149 IP <IP_ADDRESS>.60582 > <IP_ADDRESS>.4000: UDP, length 20
  21:33:01.689158 IP <IP_ADDRESS>.60582 > <IP_ADDRESS>.4000: UDP, length 20
  21:33:01.789175 IP <IP_ADDRESS>.60582 > <IP_ADDRESS>.4000: UDP, length 20
  21:33:01.889184 IP <IP_ADDRESS>.60582 > <IP_ADDRESS>.4000: UDP, length 20
  21:33:01.971033 IP <IP_ADDRESS>.60582 > <IP_ADDRESS>.4000: UDP, length 11
  21:33:01.971250 IP <IP_ADDRESS>.60582 > <IP_ADDRESS>.4000: UDP, length 6
  21:33:01.971461 IP <IP_ADDRESS>.60582 > <IP_ADDRESS>.4000: UDP, length 159
  21:33:01.989157 IP <IP_ADDRESS>.60582 > <IP_ADDRESS>.4000: UDP, length 20
  21:33:02.089250 IP <IP_ADDRESS>.60582 > <IP_ADDRESS>.4000: UDP, length 20
  21:33:02.189185 IP <IP_ADDRESS>.60582 > <IP_ADDRESS>.4000: UDP, length 20
  21:33:02.289142 IP <IP_ADDRESS>.60582 > <IP_ADDRESS>.4000: UDP, length 20

nping from my desktop to the iPad (in the same state - looking at the "External Hardware" menu in WingX) that port 4000 UDP is "port unreachable"
  $ sudo nping -c 0 --udp -p 4000 -d2 -v2 <IP_ADDRESS>
  Nping will send packets at raw IP level

  Starting Nping 0.6.47 ( http://nmap.org/nping ) at 2015-12-18 16:33 EST
  Resolving specified targets...
  1 target IP address determined.
  BPF-filter: (not src host <IP_ADDRESS> and dst host <IP_ADDRESS>) and ((udp and dst port 53) or (icmp and (icmp[icmptype] = 3 or icmp[icmptype] = 4 or icmp[icmptype] = 5 or icmp[icmptype] = 11 or icmp[icmptype] = 12)) )
  Opening pcap device en0
  Pcap device en0 open successfully
  SENT (0.0334s) UDP [<IP_ADDRESS>:53 > <IP_ADDRESS>:4000 len=8 csum=0x6BCA] IP [ver=4 ihl=5 tos=0x00 iplen=28 id=34191 foff=0 ttl=64 proto=17 csum=0x7103]
  RCVD (0.1608s) ICMP [<IP_ADDRESS> > <IP_ADDRESS> Port unreachable (type=3/code=3) ] IP [ver=4 ihl=5 tos=0x00 iplen=56 id=29406 foff=0 ttl=64 proto=1 csum=0x83a8]
  SENT (1.0380s) UDP [<IP_ADDRESS>:53 > <IP_ADDRESS>:4000 len=8 csum=0x6BCA] IP [ver=4 ihl=5 tos=0x00 iplen=28 id=34191 foff=0 ttl=64 proto=17 csum=0x7103]
  RCVD (1.0662s) ICMP [<IP_ADDRESS> > <IP_ADDRESS> Port unreachable (type=3/code=3) ] IP [ver=4 ihl=5 tos=0x00 iplen=56 id=58601 foff=0 ttl=64 proto=1 csum=0x119d]
  SENT (2.0443s) UDP [<IP_ADDRESS>:53 > <IP_ADDRESS>:4000 len=8 csum=0x6BCA] IP [ver=4 ihl=5 tos=0x00 iplen=28 id=34191 foff=0 ttl=64 proto=17 csum=0x7103]
  RCVD (2.1036s) ICMP [<IP_ADDRESS> > <IP_ADDRESS> Port unreachable (type=3/code=3) ] IP [ver=4 ihl=5 tos=0x00 iplen=56 id=13836 foff=0 ttl=64 proto=1 csum=0xc07a]

I noticed as well that if you running WingX and right swipe to bring up for example the browser, how you close the right hand window also impacts heartbeat resuming
If you physical swipe the right hand window to close, WingX resumes heartbeat, but if it just tap on the WingX pane on the left, right pane closes but heartbeat does not resume.

Don't see how Stratux could be in it.  Stratux only stands over to the
side and shouts down the wifi well, with no feedback that I can tell.
On 12/18/2015 03:16 PM, HiltonG wrote:

Hi,
I will do some testing and let you know my results. Just because the
Stratux/WingX Pro7 is the only one that doesn’t work properly does not
mean that the bug lies in WingX Pro7. WingX Pro7 closes ports when it
is minimized so that others can jump in and use that port when they
are moved to the foreground. I think other apps don’t ‘play nice’ and
hold onto the port thereby not allowing another app to use that port
(and hence connect to the ADS-B receiver). So, two obvious options, 1:
Bug in WingX Pro7, or 2: Bug in Stratux not handling the port
opening/closing/opening again.
Hilton
From: duecedriver<EMAIL_ADDRESS>Sent: Friday, December 18, 2015 4:10 PM
To: cyoung/stratux<EMAIL_ADDRESS>Cc: Hilton Goldstein<EMAIL_ADDRESS>Subject: Re: [stratux] Stratux Status Message (#150)
when I was doing development and testing I had subscriptions to them
all ... I have let them all lapse..
only have wingX at the moment
—
Reply to this email directly or view it on
GitHubhttps://github.com/cyoung/stratux/issues/150#issuecomment-165898364.
—
Reply to this email directly or view it on GitHub
https://github.com/cyoung/stratux/issues/150#issuecomment-165899530.

WingX Pro7 bug.  I fixed it but it will have to wait until Apple employees get back from their Christmas vacation in about 10 days (I'm kinda amazed that they literally shutdown - surely they could have some employees there and keep the developer servers functioning and perhaps expedited reviews).
Anyway, thanks for pointing this one and nudging me to get it fixed.
Hilton

@HiltonG
Good job !!!!
If you ever want to send me the ipa file, I can test it :)

... it will have to wait until Apple employees get back from their
Christmas vacation in about 10 days (I'm kinda amazed that they literally
shutdown - surely they could have some employees there and keep the
developer servers functioning and perhaps expedited reviews).

Or better yet, they could start a "Trusted Developer" program that allows
apps that have been through the review process more than a few times to be
released "on your own recognizance" with the option of performing an audit
later. I assume that they have a large portion of the process automated.
Once you're on the "Trusted Developer" list they just scan the app to make
sure it doesn't attempt to call any non-published APIs and pushes it live.
(Yes, I know... Apple. But you can dream, right?)
--
Steven Sokol
408 Camelot Drive
Liberty, MO 64068
mobile: +1<PHONE_NUMBER>
fax: +1<PHONE_NUMBER>

@ssokol I agree.  I've suggested numerous things to (very high-ups at) Apple - none has been implemented; e.g. give a 10% discount of hardware purchases to the top 10 Top Grossing, Free etc in each category, allow the process you mention, Apple once refused to approve WingX Pro7 because they didn't like one button (out of the whole app) - I asked them to approve it in time for Airventure and I'd fix it immediately (they refused, but did help me in other ways which I really appreciated), I've suggested a way to jump ahead of fart apps (e.g. pay $100), more consistency (WingX Pro7 was once rejected for having something that another app still has) and a few more.
Having said that, I do think Apple have got better by improving the process such as validating the app for obvious things (automated test) before waiting 10 days and then getting the app rejected for some random metadata thing.
@ScraboTower and @cyoung Please email your UDID to me and let me know what type of device it is; e.g. iPad Air 2 64GB Celular
Hilton

Ok

@HiltonG
Email sent

Off topic, but I dumped Apple back when they let Scully take over.  I
was almost an evangel for them up until that time.  I positively hate
the company now.
Skypuppy
On 12/19/2015 08:19 PM, HiltonG wrote:

@ssokol https://github.com/ssokol I agree. I've suggested numerous
things to (very high-ups at) Apple - none has been implemented; e.g.
give a 10% discount of hardware purchases to the top 10 Top Grossing,
Free etc in each category, allow the process you mention, Apple once
refused to approve WingX Pro7 because they didn't like one button (out
of the whole app) - I asked them to approve it in time for Airventure
and I'd fix it immediately (they refused, but did help me in other
ways which I really appreciated), I've suggested a way to jump ahead
of fart apps (e.g. pay $100), more consistency (WingX Pro7 was once
rejected for having something that another app still has) and a few more.
Having said that, I do think Apple have got better by improving the
process such as validating the app for obvious things (automated test)
before waiting 10 days and then getting the app rejected for some
random metadata thing.
@ScraboTower https://github.com/ScraboTower and @cyoung
https://github.com/cyoung Please email your UDID to me and let me
know what type of device it is; e.g. iPad Air 2 64GB Celular
Hilton
—
Reply to this email directly or view it on GitHub
https://github.com/cyoung/stratux/issues/150#issuecomment-166056079.

@HiltonG
new wingx released today on App Store ... is this the version that was not coming out til Jan or is that one still in the pipeline?
This one advertises STRATUX AHRS support but the ahrs page still says that an ilevel box is required.. just a cosmetic oversight?
other boxes have a dedicated page on the external hardware page... we getting one for stratux or just using the generic fields for messaging errors and such...?

Hi,
Yes on cosmetic oversight – the one in the App Store now supports Stratux AHRS (and XGPS190 AHRS).  Now that the Stratux Status Message is finalized (with one more possible minor change), we’ll add a Stratux page.  I have already written the WingX Pro7 code to consume the message, now I need to add UI.
Hilton
From: duecedriver <notifications<EMAIL_ADDRESS>Reply-To: cyoung/stratux <reply<EMAIL_ADDRESS>Date: Sunday, December 20, 2015 at 2:58 PM
To: cyoung/stratux <stratux<EMAIL_ADDRESS>Cc: Hilton Goldstein <hilton<EMAIL_ADDRESS>Subject: Re: [stratux] Stratux Status Message (#150)
@HiltonGhttps://github.com/HiltonG
new wingx released today on App Store ... is this the version that was not coming out til Jan or is that one still in the pipeline?
This one advertises STRATUX AHRS support but the ahrs page still says that an ilevel box is required.. just a cosmetic oversight?
other boxes have a dedicated page on the external hardware page... we getting one for stratux or just using the generic fields for messaging errors and such...?
—
Reply to this email directly or view it on GitHubhttps://github.com/cyoung/stratux/issues/150#issuecomment-166150334.

@HiltonG - did anything come out of this request ?

please  email your UDID to me and let me know what type of device it is; e.g. iPad Air 2 64GB Celular

@ScraboTower Not yet, I'm finishing up the Status view and fixing and testing a couple of the issues.