|
pauls
|
|
|
Group: Forum Members
Posts: 21,
Visits: 0
|
+x+xWe're very conservative about adding anything like this, and I can't see us doing any conferring with the traffic device behind the scenes. It is right that traffic devices give data on all known traffic to the navigation app, and the latter decides what to do with it. Far from being a dumb display, SkyDemon's vocal traffic information service is the best of its kind.
I acknowledge that people would like something different while in the approach phase of flight, but it's by no means clear that there is a consensus on this at this stage. It's likely we won't develop a significant enhancement to traffic alerts in this phase of flight until one emerges. For the moment you have the option to silence the vocal alerts and then incorporate the display into your scan as you see fit. I'd still like to lobby hard for a simple solution whereby a setup option is provided to suppress audio warnings for traffic determined to be on the ground. I don't want to be finding buttons on the screen to touch when I'm on final nor remembering to do it again in a go-around. Nothing complex, just you either want the aural warnings or not. All other traffic still gets announced.
Solutions that rely on a handshake with an EC device are a non-starter, and anything where the options are complex will just lead to lack of understanding by the users. This in itself carries risks of pilots assuming that SD will warn them of something when it actually won't, because the setup options are not obvious.
It's interesting browsing the PAW forum, where time and time again the same questions get asked, or the same issues are encountered, because people just don't understand what they've bought and/or don't RTFM.
Graham - don't think we're asking for something different. I'd see the "prompt me" to "just do it" being user options.
of course, from a "safety perspective" i'd say that "just do it" can be a double edge sword. At least and "alert" to tell you that the "sensitivity" has been reduced automatically may be wise
|
|
|
|
|
grahamb
|
|
|
Group: Forum Members
Posts: 608,
Visits: 29K
|
+xWe're very conservative about adding anything like this, and I can't see us doing any conferring with the traffic device behind the scenes. It is right that traffic devices give data on all known traffic to the navigation app, and the latter decides what to do with it. Far from being a dumb display, SkyDemon's vocal traffic information service is the best of its kind.
I acknowledge that people would like something different while in the approach phase of flight, but it's by no means clear that there is a consensus on this at this stage. It's likely we won't develop a significant enhancement to traffic alerts in this phase of flight until one emerges. For the moment you have the option to silence the vocal alerts and then incorporate the display into your scan as you see fit. I'd still like to lobby hard for a simple solution whereby a setup option is provided to suppress audio warnings for traffic determined to be on the ground. I don't want to be finding buttons on the screen to touch when I'm on final nor remembering to do it again in a go-around. Nothing complex, just you either want the aural warnings or not. All other traffic still gets announced.
Solutions that rely on a handshake with an EC device are a non-starter, and anything where the options are complex will just lead to lack of understanding by the users. This in itself carries risks of pilots assuming that SD will warn them of something when it actually won't, because the setup options are not obvious.
It's interesting browsing the PAW forum, where time and time again the same questions get asked, or the same issues are encountered, because people just don't understand what they've bought and/or don't RTFM.
|
|
|
|
|
TimT
|
|
|
Group: Forum Members
Posts: 89,
Visits: 92
|
+xWe're very conservative about adding anything like this, and I can't see us doing any conferring with the traffic device behind the scenes. It is right that traffic devices give data on all known traffic to the navigation app, and the latter decides what to do with it. Far from being a dumb display, SkyDemon's vocal traffic information service is the best of its kind.
I acknowledge that people would like something different while in the approach phase of flight, but it's by no means clear that there is a consensus on this at this stage. It's likely we won't develop a significant enhancement to traffic alerts in this phase of flight until one emerges. For the moment you have the option to silence the vocal alerts and then incorporate the display into your scan as you see fit. I am indeed very happy with SD's intelligent filtering of traffic alerts passed onto it by PAW.
|
|
|
|
|
pauls
|
|
|
Group: Forum Members
Posts: 21,
Visits: 0
|
+xWe're very conservative about adding anything like this, and I can't see us doing any conferring with the traffic device behind the scenes. It is right that traffic devices give data on all known traffic to the navigation app, and the latter decides what to do with it. Far from being a dumb display, SkyDemon's vocal traffic information service is the best of its kind.
I acknowledge that people would like something different while in the approach phase of flight, but it's by no means clear that there is a consensus on this at this stage. It's likely we won't develop a significant enhancement to traffic alerts in this phase of flight until one emerges. For the moment you have the option to silence the vocal alerts and then incorporate the display into your scan as you see fit. @TimD - you've misunderstood my comment about "dumb" . What i meant was I assume you had no appetite for SD to actively filter out EC data sent from an external source. Looks like you're saying that may not be the case, in which case my proposal changes. See below
The other nuance of course is that some people use the EC devices audio in preference to the SD one. I prefer to SD one, but it doesnt give my bearginless alerts. Hence the suggestion of SD being able to have a two way interaction with EC devices, to tell the EC device to shut up / reduce sensitivty (range/heigh) at certain stages of flight
So, not withstanding the above suggestion, of SD telling EC device to change it's output..... If you're willing to consider a more intelligent traffic system based on phase of flight, I still think an adjustment to my original proposal still meets peoples requirements without making SD overly complex:
However, it would be great to have the following options SD knows when you are on the ground* or can prompt to say "put me in ground mode" SD can prompt when you're near the circuit/atz of your destination and prompt to say "put me in circuit mode"
Then...
1) In Ground Mode - No (or reduced**) audio alerts when you're "on the ground". Rationale - if i operate from an ATZ environment i'm happy to have a quick glance at skydemon but audio warnings over OTT during takeoff
2) In Circuit Mode - Reduced** audio alerts when in the circuit. I think its will be possible to do
* my speed < 20kts AND AGL<100ft for example ** reduced range and height from me versus cruise notification
|
|
|
|
|
Tim Dawson
|
|
|
Group: Forum Members
Posts: 8.2K,
Visits: 9.6K
|
We're very conservative about adding anything like this, and I can't see us doing any conferring with the traffic device behind the scenes. It is right that traffic devices give data on all known traffic to the navigation app, and the latter decides what to do with it. Far from being a dumb display, SkyDemon's vocal traffic information service is the best of its kind.
I acknowledge that people would like something different while in the approach phase of flight, but it's by no means clear that there is a consensus on this at this stage. It's likely we won't develop a significant enhancement to traffic alerts in this phase of flight until one emerges. For the moment you have the option to silence the vocal alerts and then incorporate the display into your scan as you see fit.
|
|
|
|
|
pauls
|
|
|
Group: Forum Members
Posts: 21,
Visits: 0
|
+x+x+x+x+xMy setup - PaW Classic with audio fed into intercomm. Display on Skydemon. I've staretd a thread running on the PaW forum on the same issue - the amount of audio alerts. Reason I've posted here is that I'd like the solution to be controlled via SD. Maybe a cheeky API integration?
Overall - I think its a BAD idea to mute audio alerts in the circuit - surely that's where you'll find lots of other planes!
However, it would be great to have the following options
1) No (or reduced*) audio alerts when you're "on the ground**". Rationale - if i operate from an ATZ environment i'm happy to have a quick glance at skydemon but audio warnings over OTT during takeoff
2) Reduced* audio alerts when in the circuit. I think its will be impossible to do - how would PaW know you're in the circuit. This is where something in SD would be neat a button called "i'm in the circuit Tim, please be quiet, I need to concentrate" - But my nirvana here- if I've set PaW to alert me on traffic in 10km - that's useful for the cruise. But not so much for a circuit. Like wise if there's traffic 2000ft above me in the circuit, I'm not (immimently) worried about it. "even better if" - if i'm facing downwind i care about traffic on final converging with me. I dont care so much about traffic converging from behind me as that's how circuits work
* reduced range and height from me versus cruise notification
** my speed < 20kts AND AGL<100ft for example
You are turning these consumer grade equipment from TCAS I (TA) into maybe TCAS IV or higher (automated anti collision steering). This is experimental terrain, even in the commercial world. Do we really believe we should awake the Feature Creep on a Skydemon level? hmmm, i disagree
TCAS has algorithms which are dynamic. it also mandates/advise actions. What i'm talking about is a user controlled option to tell the EC device/data, to reduce it's sensitivity during certain stages of flight. You can do this already in PaW for example - you set the height and distance and type of traffic you want to know about. My assertion in the circuit is that you want to know about stuff alot closer to you and on take off you probably want to know even less
the reason for postin on here rather than PaW (although I have on their forum too) is a usability one. I can do what i've suggested already through the PaW admin/app. But it'd be more dangerous fiddling with those settings in the take off roll or when doing an OHJ!
the "feature creep" that may be interesting is a two way interaction between SD/EFBs and EC devices. At the moment the EC device broadcasts on UDP and SD/EFBs fairly dumbly (no offence) display the data. That is why they are NOT TCAS devices. However if the EC device is API enabled, you can allow the EFC to at least control the existing parameters dynamically, with the EC device still be responsible for deciding what data packets to transmit and using it's internal algorithms. The SD wouldn't be doing nay filtering out etc @Tim is it worth splitting out my recent suggestion to a seperate thread? it kind of answers the same problem statement as the original poster but with a different solution Nah, I think this is the right thread. Thanks @TimT I meant @TimD :-)
|
|
|
|
|
TimT
|
|
|
Group: Forum Members
Posts: 89,
Visits: 92
|
+x+x+x+xMy setup - PaW Classic with audio fed into intercomm. Display on Skydemon. I've staretd a thread running on the PaW forum on the same issue - the amount of audio alerts. Reason I've posted here is that I'd like the solution to be controlled via SD. Maybe a cheeky API integration?
Overall - I think its a BAD idea to mute audio alerts in the circuit - surely that's where you'll find lots of other planes!
However, it would be great to have the following options
1) No (or reduced*) audio alerts when you're "on the ground**". Rationale - if i operate from an ATZ environment i'm happy to have a quick glance at skydemon but audio warnings over OTT during takeoff
2) Reduced* audio alerts when in the circuit. I think its will be impossible to do - how would PaW know you're in the circuit. This is where something in SD would be neat a button called "i'm in the circuit Tim, please be quiet, I need to concentrate" - But my nirvana here- if I've set PaW to alert me on traffic in 10km - that's useful for the cruise. But not so much for a circuit. Like wise if there's traffic 2000ft above me in the circuit, I'm not (immimently) worried about it. "even better if" - if i'm facing downwind i care about traffic on final converging with me. I dont care so much about traffic converging from behind me as that's how circuits work
* reduced range and height from me versus cruise notification
** my speed < 20kts AND AGL<100ft for example
You are turning these consumer grade equipment from TCAS I (TA) into maybe TCAS IV or higher (automated anti collision steering). This is experimental terrain, even in the commercial world. Do we really believe we should awake the Feature Creep on a Skydemon level? hmmm, i disagree
TCAS has algorithms which are dynamic. it also mandates/advise actions. What i'm talking about is a user controlled option to tell the EC device/data, to reduce it's sensitivity during certain stages of flight. You can do this already in PaW for example - you set the height and distance and type of traffic you want to know about. My assertion in the circuit is that you want to know about stuff alot closer to you and on take off you probably want to know even less
the reason for postin on here rather than PaW (although I have on their forum too) is a usability one. I can do what i've suggested already through the PaW admin/app. But it'd be more dangerous fiddling with those settings in the take off roll or when doing an OHJ!
the "feature creep" that may be interesting is a two way interaction between SD/EFBs and EC devices. At the moment the EC device broadcasts on UDP and SD/EFBs fairly dumbly (no offence) display the data. That is why they are NOT TCAS devices. However if the EC device is API enabled, you can allow the EFC to at least control the existing parameters dynamically, with the EC device still be responsible for deciding what data packets to transmit and using it's internal algorithms. The SD wouldn't be doing nay filtering out etc @Tim is it worth splitting out my recent suggestion to a seperate thread? it kind of answers the same problem statement as the original poster but with a different solution Nah, I think this is the right thread.
|
|
|
|
|
pauls
|
|
|
Group: Forum Members
Posts: 21,
Visits: 0
|
+x+x+xMy setup - PaW Classic with audio fed into intercomm. Display on Skydemon. I've staretd a thread running on the PaW forum on the same issue - the amount of audio alerts. Reason I've posted here is that I'd like the solution to be controlled via SD. Maybe a cheeky API integration?
Overall - I think its a BAD idea to mute audio alerts in the circuit - surely that's where you'll find lots of other planes!
However, it would be great to have the following options
1) No (or reduced*) audio alerts when you're "on the ground**". Rationale - if i operate from an ATZ environment i'm happy to have a quick glance at skydemon but audio warnings over OTT during takeoff
2) Reduced* audio alerts when in the circuit. I think its will be impossible to do - how would PaW know you're in the circuit. This is where something in SD would be neat a button called "i'm in the circuit Tim, please be quiet, I need to concentrate" - But my nirvana here- if I've set PaW to alert me on traffic in 10km - that's useful for the cruise. But not so much for a circuit. Like wise if there's traffic 2000ft above me in the circuit, I'm not (immimently) worried about it. "even better if" - if i'm facing downwind i care about traffic on final converging with me. I dont care so much about traffic converging from behind me as that's how circuits work
* reduced range and height from me versus cruise notification
** my speed < 20kts AND AGL<100ft for example
You are turning these consumer grade equipment from TCAS I (TA) into maybe TCAS IV or higher (automated anti collision steering). This is experimental terrain, even in the commercial world. Do we really believe we should awake the Feature Creep on a Skydemon level? hmmm, i disagree
TCAS has algorithms which are dynamic. it also mandates/advise actions. What i'm talking about is a user controlled option to tell the EC device/data, to reduce it's sensitivity during certain stages of flight. You can do this already in PaW for example - you set the height and distance and type of traffic you want to know about. My assertion in the circuit is that you want to know about stuff alot closer to you and on take off you probably want to know even less
the reason for postin on here rather than PaW (although I have on their forum too) is a usability one. I can do what i've suggested already through the PaW admin/app. But it'd be more dangerous fiddling with those settings in the take off roll or when doing an OHJ!
the "feature creep" that may be interesting is a two way interaction between SD/EFBs and EC devices. At the moment the EC device broadcasts on UDP and SD/EFBs fairly dumbly (no offence) display the data. That is why they are NOT TCAS devices. However if the EC device is API enabled, you can allow the EFC to at least control the existing parameters dynamically, with the EC device still be responsible for deciding what data packets to transmit and using it's internal algorithms. The SD wouldn't be doing nay filtering out etc @Tim is it worth splitting out my recent suggestion to a seperate thread? it kind of answers the same problem statement as the original poster but with a different solution
|
|
|
|
|
pauls
|
|
|
Group: Forum Members
Posts: 21,
Visits: 0
|
+x+xMy setup - PaW Classic with audio fed into intercomm. Display on Skydemon. I've staretd a thread running on the PaW forum on the same issue - the amount of audio alerts. Reason I've posted here is that I'd like the solution to be controlled via SD. Maybe a cheeky API integration?
Overall - I think its a BAD idea to mute audio alerts in the circuit - surely that's where you'll find lots of other planes!
However, it would be great to have the following options
1) No (or reduced*) audio alerts when you're "on the ground**". Rationale - if i operate from an ATZ environment i'm happy to have a quick glance at skydemon but audio warnings over OTT during takeoff
2) Reduced* audio alerts when in the circuit. I think its will be impossible to do - how would PaW know you're in the circuit. This is where something in SD would be neat a button called "i'm in the circuit Tim, please be quiet, I need to concentrate" - But my nirvana here- if I've set PaW to alert me on traffic in 10km - that's useful for the cruise. But not so much for a circuit. Like wise if there's traffic 2000ft above me in the circuit, I'm not (immimently) worried about it. "even better if" - if i'm facing downwind i care about traffic on final converging with me. I dont care so much about traffic converging from behind me as that's how circuits work
* reduced range and height from me versus cruise notification
** my speed < 20kts AND AGL<100ft for example
You are turning these consumer grade equipment from TCAS I (TA) into maybe TCAS IV or higher (automated anti collision steering). This is experimental terrain, even in the commercial world. Do we really believe we should awake the Feature Creep on a Skydemon level? hmmm, i disagree
TCAS has algorithms which are dynamic. it also mandates/advise actions. What i'm talking about is a user controlled option to tell the EC device/data, to reduce it's sensitivity during certain stages of flight. You can do this already in PaW for example - you set the height and distance and type of traffic you want to know about. My assertion in the circuit is that you want to know about stuff alot closer to you and on take off you probably want to know even less
the reason for postin on here rather than PaW (although I have on their forum too) is a usability one. I can do what i've suggested already through the PaW admin/app. But it'd be more dangerous fiddling with those settings in the take off roll or when doing an OHJ!
the "feature creep" that may be interesting is a two way interaction between SD/EFBs and EC devices. At the moment the EC device broadcasts on UDP and SD/EFBs fairly dumbly (no offence) display the data. That is why they are NOT TCAS devices. However if the EC device is API enabled, you can allow the EFC to at least control the existing parameters dynamically, with the EC device still be responsible for deciding what data packets to transmit and using it's internal algorithms. The SD wouldn't be doing nay filtering out etc
|
|
|
|
|
pilot-byom
|
|
|
Group: Forum Members
Posts: 323,
Visits: 388
|
+xMy setup - PaW Classic with audio fed into intercomm. Display on Skydemon. I've staretd a thread running on the PaW forum on the same issue - the amount of audio alerts. Reason I've posted here is that I'd like the solution to be controlled via SD. Maybe a cheeky API integration?
Overall - I think its a BAD idea to mute audio alerts in the circuit - surely that's where you'll find lots of other planes!
However, it would be great to have the following options
1) No (or reduced*) audio alerts when you're "on the ground**". Rationale - if i operate from an ATZ environment i'm happy to have a quick glance at skydemon but audio warnings over OTT during takeoff
2) Reduced* audio alerts when in the circuit. I think its will be impossible to do - how would PaW know you're in the circuit. This is where something in SD would be neat a button called "i'm in the circuit Tim, please be quiet, I need to concentrate" - But my nirvana here- if I've set PaW to alert me on traffic in 10km - that's useful for the cruise. But not so much for a circuit. Like wise if there's traffic 2000ft above me in the circuit, I'm not (immimently) worried about it. "even better if" - if i'm facing downwind i care about traffic on final converging with me. I dont care so much about traffic converging from behind me as that's how circuits work
* reduced range and height from me versus cruise notification
** my speed < 20kts AND AGL<100ft for example
You are turning these consumer grade devices from TCAS I (TA) into maybe TCAS IV or higher (automated anti collision steering). This is experimental terrain, even in the commercial world. Do we really believe we should awake the Feature Creep on a Skydemon level?
|
|
|
|