<div class="gmail_extra">Hi Jim,<br> 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.<br>
<br>Best regards,<br>Scott<br><br><div class="gmail_quote">On Mon, Apr 23, 2012 at 3:54 PM, James Oddino <span dir="ltr"><<a href="mailto:joddino@socal.rr.com" target="_blank">joddino@socal.rr.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div style="word-wrap:break-word">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. <div>
<br></div><div>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.</div><div><br></div><div>Jim</div><div>
<div class="h5"><div><br><div><div>On Apr 23, 2012, at 10:05 AM, Scott McHarg wrote:</div><br><blockquote type="cite"><div class="gmail_extra">Good Afternoon,<br> 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.<br>
<br><div class="gmail_quote">On Mon, Apr 23, 2012 at 11:10 AM, James Oddino <span dir="ltr"><<a href="mailto:joddino@socal.rr.com" target="_blank">joddino@socal.rr.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div style="word-wrap:break-word"><div>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? </div>
<div><br></div><div>The question we should ask is; do we really want to outlaw anything that might make our models fly better?</div><div><div><br></div><div><br><blockquote type="cite"><span style="border-collapse:separate;font-family:Helvetica;font-style:normal;font-variant:normal;font-weight:normal;letter-spacing:normal;line-height:normal;text-align:-webkit-auto;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px;font-size:medium"><blockquote type="cite">
<span style="border-collapse:separate;font-family:Helvetica;font-style:normal;font-variant:normal;font-weight:normal;letter-spacing:normal;line-height:normal;text-align:-webkit-auto;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px;font-size:medium"><div link="blue" vlink="purple" lang="EN-US">
<div><div><div><div><div><div><div><div><div style="margin-top:0in;margin-right:0in;margin-left:0in;margin-bottom:0.0001pt;font-size:12pt;font-family:'Times New Roman',serif"><span style="font-size:10pt;font-family:Arial,sans-serif">9. Engine management systems that coordinate power output with model performance, position, or <u></u><u></u></span></div>
</div><div><div style="margin-top:0in;margin-right:0in;margin-left:0in;margin-bottom:0.0001pt;font-size:12pt;font-family:'Times New Roman',serif"><span style="font-size:10pt;font-family:Arial,sans-serif">attitude.”</span></div>
</div></div></div></div></div></div></div></div></div></span></blockquote></span></blockquote></div><br></div></div><br>_______________________________________________<br>
NSRCA-discussion mailing list<br>
<a href="mailto:NSRCA-discussion@lists.nsrca.org" target="_blank">NSRCA-discussion@lists.nsrca.org</a><br>
<a href="http://lists.nsrca.org/mailman/listinfo/nsrca-discussion" target="_blank">http://lists.nsrca.org/mailman/listinfo/nsrca-discussion</a><br></blockquote></div><br><br clear="all"><br>-- <br><b style="color:rgb(51,51,255)"><font style="font-family:comic sans ms,sans-serif" size="4">Scott A. McHarg</font></b><br>
<br>
</div>
_______________________________________________<br>NSRCA-discussion mailing list<br><a href="mailto:NSRCA-discussion@lists.nsrca.org" target="_blank">NSRCA-discussion@lists.nsrca.org</a><br><a href="http://lists.nsrca.org/mailman/listinfo/nsrca-discussion" target="_blank">http://lists.nsrca.org/mailman/listinfo/nsrca-discussion</a></blockquote>
</div><br></div></div></div></div><br>_______________________________________________<br>
NSRCA-discussion mailing list<br>
<a href="mailto:NSRCA-discussion@lists.nsrca.org">NSRCA-discussion@lists.nsrca.org</a><br>
<a href="http://lists.nsrca.org/mailman/listinfo/nsrca-discussion" target="_blank">http://lists.nsrca.org/mailman/listinfo/nsrca-discussion</a><br></blockquote></div><br><br clear="all"><br>-- <br><b style="color:rgb(51,51,255)"><font style="font-family:comic sans ms,sans-serif" size="4">Scott A. McHarg</font></b><br>
Sr. Systems Engineer - Infrastructure<br>Bryan Research & Engineering<br><br>
</div>