+x

 

pauls - 10/8/2020 11:35:45 AM

+x

 

pilot-byom - 10/8/2020 11:26:50 AM

+x

 

pauls - 10/8/2020 11:18:07 AM

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

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 

+x

 

pauls - 10/9/2020 9:07:39 AM

+x

 

pauls - 10/8/2020 11:35:45 AM

+x

 

pilot-byom - 10/8/2020 11:26:50 AM

+x

 

pauls - 10/8/2020 11:18:07 AM

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

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

+x

 

TimT - 10/9/2020 9:15:46 AM

+x

 

pauls - 10/9/2020 9:07:39 AM

+x

 

pauls - 10/8/2020 11:35:45 AM

+x

 

pilot-byom - 10/8/2020 11:26:50 AM

+x

 

pauls - 10/8/2020 11:18:07 AM

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

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.