|
pilot-byom
|
|
|
Group: Forum Members
Posts: 323,
Visits: 388
|
Looks like all targets reporting ground level are now suppressed? So we have to assume all reported altitudes have to be correct and aircraft sending no altitude or Zero are suppressed in collision warning?
|
|
|
|
|
TimT
|
|
|
Group: Forum Members
Posts: 88,
Visits: 92
|
+xLooks like all targets reporting ground level are now suppressed? So we have to assume all reported altitudes have to be correct and aircraft sending no altitude or Zero are suppressed in collision warning? SD Team: Is that correct? Let's just face it: The biggest mid-air risk is in the pattern, and at altitues below 1,000 FT AGL. This recent incident is a case in point: Muting traffic alerts in this scenario, in my opinion, would be the wrong thing to do, despite the additional information load they create. It is exactly when there is lots of traffic, when you think you have seem (some) traffic and when it is already very busy that you need to additional awareness afforded by PCAS like PilotAware. That includes traffic that is straight below you. Seeing the Original Post here it appears that individual needs can be very different. But SD, if you add additional filters, please make them optional.
|
|
|
|
|
Tim Dawson
|
|
|
Group: Forum Members
Posts: 7.8K,
Visits: 8.4K
|
Thank you for the helpful video about what happens when two aircraft crash.
No, we have not (yet) made any changes to the way this works.
It is possible that in the future we would decide an aircraft is on the ground if its groundspeed was nearly zero AND its altitude reported below a certain height AGL, and ignore it for the purposes of collision detection. Those two together would be quite a safe way of "proving" it. If they're very wrong, collision detection isn't going to work anyway.
|
|
|
|
|
pilot-byom
|
|
|
Group: Forum Members
Posts: 323,
Visits: 388
|
+xThank you for the helpful video about what happens when two aircraft crash.
No, we have not (yet) made any changes to the way this works.
It is possible that in the future we would decide an aircraft is on the ground if its groundspeed was nearly zero AND its altitude reported below a certain height AGL, and ignore it for the purposes of collision detection. Those two together would be quite a safe way of "proving" it. If they're very wrong, collision detection isn't going to work anyway. Giving recent experience, I'd vote not to spend too much effort into 'how to delete signals from the collision warning". One of the most prominent issues this virus times is certain pilots not looking out and entering the runway while someone is on short final. It is not very wise to omit the aircraft at the holding point on the ground at zero speed from collision warning for the approaching aircraft ...
|
|
|
|
|
grahamb
|
|
|
Group: Forum Members
Posts: 507,
Visits: 25K
|
+x+xThank you for the helpful video about what happens when two aircraft crash.
No, we have not (yet) made any changes to the way this works.
It is possible that in the future we would decide an aircraft is on the ground if its groundspeed was nearly zero AND its altitude reported below a certain height AGL, and ignore it for the purposes of collision detection. Those two together would be quite a safe way of "proving" it. If they're very wrong, collision detection isn't going to work anyway. Giving recent experience, I'd vote not to spend too much effort into 'how to delete signals from the collision warning". One of the most prominent issues this virus times is certain pilots not looking out and entering the runway while someone is on short final. It is not very wise to omit the aircraft at the holding point on the ground at zero speed from collision warning for the approaching aircraft ... I have to disagree. The one place I am looking when approaching to land is the runway. I've got past the stage where I shut my eyes and hope when on short final.
|
|
|
|
|
pauls
|
|
|
Group: Forum Members
Posts: 21,
Visits: 0
|
My 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
|
|
|
|
|
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?
|
|
|
|
|
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
|
|
|
|
|
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
|
|
|
|
|
TimT
|
|
|
Group: Forum Members
Posts: 88,
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.
|
|
|
|