Conditional Contact or Alarm

[skysailor]

Is there a chance Dynon might have a conditional contact and/or alarm in the Skyview? The first example that jumps to mind is a contact which determines canopy closed/locked status. I can currently set a contact to monitor this but it would be a real bonus if this could be set to only alarm above a user configurable value of say 2000 RPM. In this way, taxi and even run up could be conducted in the summer still allowing ventilation but if power were advanced beyond 2000 RPM for takeoff the alarm would show in time to prevent the canopy leaving the aircraft due to higher speed. As another example the actual oil pressure at idle might show 15 PSI but the alarm would not be triggered. 15 PSI oil pressure at idle is not necessarily a problem in a hot engine at idle but in flight even 30 PSI should trigger an alarm in addition to the actual reading. It would be ideal if the user could select the triggering event (within reason) such as engine RPM, manifold pressure, indicated airspeed etc. to best correlate with the alarm desired.

I view this as a second order configurable alarm. While I am sure it is possible, I confess I do not know the amount of work required by your engineering team to produce the result. If memory serves there are other items which work in this fashion such as angle of attack alarms which are disabled below a threshold indicated airspeed so I hold out some hope. As a fall back perhaps we could trigger based on this existing conditional state already monitored by Skyview.

I would view this as a "nice to have" versus critical improvement. There is little doubt others will come up with additional and better uses for this capability. It is a suggestion for future development only.

 

[Dynon]

Not currently, but, it's on the list to look into. One of the challenges is everyone has a different conditional in mind, and so before you know it, you've invented a complex and hardly-usable feature that no one likes because it doesn't quite do the exact thing they want it to do.

 

[skysailor]

Fair enough. That was part of my reluctance to ask. I too envisioned everyone wanting to tie any two (or more) parameters together. Any chance we might gain access to the trigger you use for the AOA alarms? Even I it were triggered at a low but repeatable airspeed below flight speed a chance to abort the takeoff should be available. I am very happy with my choice of Dynon and your quick reply to entertain the idea is why I think the company is so successful.

 

[Battson]

Yes - I would also like to like other parameters e.g. contacts to the "in flight" condition.

Examples
- if in flight, alarm if park brake is on
- if in flight, alarm if canopy is open

 

[mmarien]

There have been a few requests for conditional alarms. VP-X supplies a few. The starter is disabled while the engine is running and the flaps can be disabled at too high air speeds for example. With EMS/ADAHRS/SYS serial data now available from Skyview it's possible to have another device (iPad/Android) filter the data and provide some alarms.

Perhaps a CONDITION could be added to the LATCHING or SELF-CLEAR alarms in Skyview.

alarm_type=SELF-CLEAR CONDITION RPM>2000

If the gauge goes into the RED the alarm is triggered only when the condition is met. So a contact can be RED for OPEN, but wouldn't be triggered unless the RPM goes over 2000. Close the contact and the alarm goes away.

This would satisfy a lot of the requests.

 

[dynonsupport]

The VP-X does not actually supply user configurable conditional alarms. The VP-X has specific conditions pre-programmed that you can turn on and off. Not really any different than us being able to hide engine alarms until the engine is started or block the AoA tone below a certain speed. They aren't arbitrary, "make any alert combination you want" conditionals like we are perceiving people are asking for.

The very first post in this thread discusses having conditions of "engine RPM, manifold pressure, indicated airspeed etc." as possibilities, so just RPM won't necessarily cover most of the requests (or even the first one...)

This is one of those things where in experimental aviation, everyone is likely to want something different, and thus the system needs to be very flexible or it's not of much use at all, and it's the flexibility that makes it complex to conceve, implement, and document. If we put this feature in, before you know it, someone will want us to write a computer program for the PC to make setting them up easier

Again, none of this is to say this feature isn't on the list. But it is to say that it isn't the highest thing right now...

 

[mmarien]

The very first post in this thread discusses having conditions of "engine RPM, manifold pressure, indicated airspeed etc." as possibilities, so just RPM won't necessarily cover most of the requests (or even the first one...)

The RPM condition was just an example. The condition could include any gauge that's available plus some of the ADAHRS data.

alarm_type=SELF-CLEAR CONDITION AIRSPEED>120

alarm_type=LATCHING CONDITION CANOPY=OPEN

alarm_type=LATCHING CONDITION PRCNT_POWER<50

The condition would be added to the SENSOR SETUP. When running Skyview checks the gauge to be able to know it's in the RED and if there is an ALARM_TYPE. It just has to check if there is a condition to the alarm. We won't ask for AND's or OR's just yet.

Everybody likes the built-in functions, but experimental is all about tweaking.

 

[skysailor]

The first use I would plan for this capability would be a canopy alarm. My plane (like Mmarien) has canopies that will detach from the airframe and be lost while possibly damaging the tail surfaces if opened in flight. I suggested several triggers as possible in my original post. For my primary concern, if I could simply set an alarm and have it tie to the existing Skyview conditional alarm that would work for now in this case. The AOA alarms are currently not presented below a set speed which I think is 20 KIAS. I would like to set a contact with alarm for the canopy and  allow it to be constrained by the same restriction they already employ. I think Dynon is correct that the imaginations of layered conditional alarms might swell given the robust level of thought in the experimental community. Might we at least gain access to the constraint you already use even if we could not alter the trigger value? In our example, when IAS hits the 20 KIAS trigger the system already uses, the AOA alarms become active and so would the linked contact (canopy OPEN in my case).