[NSRCA-discussion] Rules change proposals

[Scott McHarg]

Hi Jim,
   There are differences here.  Neither the Contra Drive nor aerodynamic
appendages have the ability to accept variables and change their nature
according to those variables that are input.  They are quite static in
relation to what is going on around them.  In other words, they act the
same regardless of the situation.  It's important to remember the scope of
the rule and not look at an example of the rule expressly although the
example can still be defended easily.  We are simply speaking of telemetry
here.  We are concerned with input received by the transmitter (the cpu of
the radio system) from the aircraft and the radio system being able to
process that information and send back automatic commands to the aircraft
that affect flight.  The "do not allow" items (at least the majority of
them including #9) are in the existing rule 4.4: Equipment Functions.  All
we are doing is asking the AMA Contest Board to allow us voltage, current
and temperature, etc to be allowed per the rule to be received by the
transmitter in the name of safety.  We are still not sending any commands
back to the aircraft due to this information.  In this case, safety applies
to not crashing your bird due to something that, with a little notice and
information, could be prevented by an early landing and dismissal of the
remaining portion of the flight.

Best regards,
Scott

On Mon, Apr 23, 2012 at 3:54 PM, James Oddino <joddino at socal.rr.com> wrote:

> Scott, I don't want to beat this to death but you must be very careful.  I
> could interpret this to disallow Contra Drive prop set ups that
> automatically cancel the effects of spiral slipstream, torque, gyroscopic
> precession and P-Factor.  What about adding aerodynamic appendages that
> improve stability and damping?  It is not clear why the aerodynamicist
> should should be given an advantage over the power management guy or the
> electronics guy.  I'll never understand why the variable thrust alignment
> system was disallowed.
>
> I don't really care what is decided, but if the rule is not well defined
> it will cause turmoil and new guys thinking about getting into pattern
> won't like it.
>
> Jim
>
> On Apr 23, 2012, at 10:05 AM, Scott McHarg wrote:
>
> Good Afternoon,
>    First, let's agree that "Engine managment" was not a correct term that
> we derived from the "old days" and we will fix that (per John Fuqua)
> assuming it passes the initial vote.  Second, let's not lose sight that we
> are speaking about telemetry and we are speaking of automated functions
> here, not those that require direct and manual input.  The wording is such
> that engine management systems that COORDINATE (through telemetry and read:
> automatically adjust) power output (to maintain a speed or anything that
> may relate to) with model performance, position, or attitude.  Honestly,
> this is no different than a gyro correcting attitude and we certainly don't
> want to allow that.  We simply are trying to allow telemetry that is
> important for safety and continue to dis-allow anything that automates
> flying the aircraft.  In my very humble opinion and to answer your
> question; Yes, I think we do want to outlaw something that makes our models
> fly better IF it is automated and not pilot-induced.
>
> On Mon, Apr 23, 2012 at 11:10 AM, James Oddino <joddino at socal.rr.com>wrote:
>
>> What does it mean?  Electric motors change the power as a function of the
>> load applied.  For a given throttle setting the motor will draw more
>> current as the model is pulled vertical for instance.  Is the rule trying
>> to prevent that or prevent an improvement in its ability to do that?  Is it
>> trying to outlaw braking or variable pitch props?
>>
>> The question we should ask is; do we really want to outlaw anything that
>> might make our models fly better?
>>
>>
>>  9. Engine management systems that coordinate power output with model
>> performance, position, or ****
>> attitude.”
>>
>>
>>
>> _______________________________________________
>> NSRCA-discussion mailing list
>> NSRCA-discussion at lists.nsrca.org
>> http://lists.nsrca.org/mailman/listinfo/nsrca-discussion
>>
>
>
>
> --
> *Scott A. McHarg*
>
>  _______________________________________________
> NSRCA-discussion mailing list
> NSRCA-discussion at lists.nsrca.org
> http://lists.nsrca.org/mailman/listinfo/nsrca-discussion
>
>
>
> _______________________________________________
> NSRCA-discussion mailing list
> NSRCA-discussion at lists.nsrca.org
> http://lists.nsrca.org/mailman/listinfo/nsrca-discussion
>



-- 
*Scott A. McHarg*
Sr. Systems Engineer - Infrastructure
Bryan Research & Engineering
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.nsrca.org/pipermail/nsrca-discussion/attachments/20120423/a3095e5f/attachment.html>