I think you may be
narrowing in on the cause of your problem, Mike.
Remoting the cold
start and/or controller selection switch might have unintended effects. IF
this were the cause, my bet would be on the controller select switch.
I don’t know what all that switch does – but it clearly transfers control of
the ignition and injectors to the B controller (when so switched). So
several High Power circuits are being turned on (or switched over) to the B
controller by a switch that is no longer co-located on the program
Controller PCB. Again, IF this remoting of the switches could cause
this, the question is HOW?
Not certain of what
de-bounce routine Tracy uses – whether software or hardware – but if you
turned on the switch to B controller, I would presume the B controller
immediately loads the MAP into its working memory. I would assume the
Map (as well as other data such as staging) would normally reside in
EEPROM and upon activation one of the first things the B controller would do
is to load this MAP and data. Now, lets say a second voltage spike
from the un-debounced switch were sent to the B controller during the time
it was loading the fuel Map, it could cause the chip to do a reset during
this interval. That could result in part of the MAP or other data
stored in EEPROM getting corrupted. I don’t know the internal coding for
moving data from EEPROM to working memory inside the EC2, I do know
that for the Serial data its code is in MIDI format.
Using the MIDI
format means if only one bit is corrupted out of the 256 bytes used to
transmit the Map over the serial link – then all data after that point is
corrupted. That is one of the reasons I had to give the Rs232 USART
comm. Module in my EFISM chip top priority during interrupts. I can
lose any number of injector pulses and it not affect its accuracy enough to
display – but corruption of the most significant bit of the High byte MIDI
pair during the MAP serial transmission and the remaining bytes are
hopelessly corrupted.
I was pretty
confident the problem was not caused by the EFISM as it has no way to talk
to the B controller, but glad to have it confirmed. The only way I can
see the EFISM affecting the B controller is rather round about.
You would have to 1st make the change to the A MAP using the
EFISM and then use the EC2 to copy the A MAP to the B MAP. Even then
you can not change the staging point using the EFISM only the Map and
ignition.
A second thought is
whether any “ground currents” could be in play. You have probably
already done this, but try connecting an alligator clamp (or your favorite
attachment device) to the ground of your controller switch and hook the
other end to the grounding stud on the EC2. If a ground circuit
current/voltage was playing a role this might eliminate
it.
Good luck on your
trouble shooting. Don’t give up – I think you may be on the right
track.
From:
Rotary motors in aircraft [mailto:flyrotary@lancaironline.net] On Behalf Of Mike Wills
Sent: Thursday, July 02, 2009 12:37
AM
To: Rotary motors in
aircraft
Subject:
[FlyRotary] Re: frustrating couple of days
So I vented to you guys, lost
some sleep last night pondering this, wasted more time today thinking about
it, and then went back to the airport to check things
out.
I had previously made all of the
changes Tracy recommended in case there was an issue with ground or supply
noise. I didnt believe that was the problem before, but with no better ideas
went ahead and made the changes. I'm now pretty sure that the electrical
system is solid.
Another possibility was that
there was something about the EFISM installation that caused this problem.
Not sure how this could be the case but the EFISM does have the capability
to write to the MCT, so maybe something was getting scrambled in the
process?
I disconnected the EFISM. And
the EFISM was disconnected yesterday when this latest problem occured, so
its not the cause. Yesterday just before I quit in disgust I reconnected the
EFISM and captured the MCT to make sure it hadnt been corrupted. It looked
fine and thats why it was so puzzling.
Today when I started the engine
it was clearly still screwed up. I put the EFISM in EC2 monitor mode and
immediately saw the problem. This latest problem was due to the fact that my
A controller injector staging point had been corrupted and set to 12" MAP.
The engine sure wont idle on 4 injectors! I reset the staging point to where
it belongs and the engine is back to running as it
should.
I now have 5 known episodes of
spontaneous changes to the EC2 (possibly more). The first time the staging
point was erased and the secondaries wouldnt come on. The next 3 cases
(twice in the past couple of days) the B controller lost its program (since
I dont have a way to view the B MCT I dont actually know whats happening
here, just that the engine immediately dies when I flip to B). And then this
last episode with the staging point resetting to 12". I say there may have
actually been more cases because my engine has never really ran well on the
B controller after doing an A to B copy. But it does run -
usually.
So Ed asks is there an action or
sequence of actions that may be related? Well the common thread here is
switching to B. I ran this engine for about 20 hours of ground testing
before I noted the first instance of this occuring. And this coincides with
when I started actually flying the airplane - and routinely switching to B
as part of my pre takeoff checklist. Then I stopped flying about 4 months
ago to make all of these changes and further tune the engine. During this
time I dont think I ever switched to B and noted no problems. This past
weekend I started prepping to fly and went through my typical pre takeoff
prep and once again problems. Started troubleshooting by routinely checking
the B controller and once again corrupted the EC2, this time the staging
point.
Since my most consistent
indicator of a change is corruption of the B MCT its hard to say for sure,
but if i can force the staging point screw up a few times by switching to B
I'll be convinced. I should note that my install is not standard for the EC2
PCM. I removed the A/B switch, Cold Start switch, and Coil Test switch from
the PCM and remoted them to my instrument panel. Tracy noted this as an
optional way to do things in my EC2 manual. I dont recall how Tracy
implements these switches, but I assume they are SPST to a pullup resistor
on the EC2. I dont know if he has any circuitry to de-bounce or noise filter
the switch input? I dont even know for sure that this is the cause but seems
to be the most reasonable explanation at this point. Stay
tuned.
----- Original Message -----
Sent:
Wednesday, July 01, 2009 6:15 AM
Subject:
[FlyRotary] Re: frustrating couple of days
Mike, its got to
be frustrating to have it run well for a couple of months and just when
you have convinced yourself the problem is gone, it comes
back.
I presume there
is nothing (no action, sequence of actions) that you can think of having
taken recently - any different than you have done during the months the
engine ran well that you can think of. Nothing different perhaps in
getting ready for another flight?
Since the fuel
map is stored in non-volute memory, it’s hard to figure out how it is
being re-written or destroyed. Normally (as you know) access to
EEPROM on a chip is a rather non-trivial process. Since the A
and B controller are two different chips, I suppose there could be a
problem with the B chip – but, while that does happen, it’s pretty
rare. Have not had one myself (yet).
You are able to
copy over the A MAP to the B MAP and it apparently does the copy, but then
something causes it to be re-written with garbage. You do not have
Auto tune and I presume you do not attempt to change the B MAP – but it
changes on its own. It sounds as it the changes to B happen whether
you have selected B controller or not – is that correct. Or does it
only happen when you are using the B controller or can you
tell.
Ed
From:
Rotary motors in aircraft [mailto:flyrotary@lancaironline.net] On Behalf Of Mike Wills
Sent: Wednesday, July 01, 2009 12:10
AM
To: Rotary motors in
aircraft
Subject:
[FlyRotary] frustrating couple of days
I havent flown my RV since a
couple of cases of lost data in the EC2 back in february. Spent the last
few months making a bunch of mods, some suggested by Tracy, others were
things that I thought might increase long term reliability. Also had to
fix leaking fuel tanks in the ensuing period.
Been working up toward
renewing flight testing. Engine has been running really well for the last
few months. Thought that the problem was cured, though not clear
how. Then on saturday found that once again my B controller had lost
all data. Engine wouldnt run at any throttle setting on B. Restored the B
controller by copying A > B.
Last night after work ground
ran the engine for about 30 minutes at various throttle settings and it
ran as good as always. Also ran fine on the B
controller.
Tonight after work I fired it
up. Ran fine initially. After about 15 minutes noted some minor surging at
a couple of throttle settings below 2000 RPM. Also noticed that in this
RPM range where the mixture had previously been fine, my mixture monitor
is off the scale lean. Slowly got worse, to the point that it wouldnt
idle at what was previously a solid 1350RPM. Couldnt get it to run at all
below 1500, everything between 1500 and about 3000 RPM pretty rough.
Everything over 3000 is fine. No idea what caused this change. I put the
airplane away and walked away in disgust. I'm back to where I was a year
ago and I'm just about fed up with this thing.
__________ Information from ESET NOD32
Antivirus, version of virus signature database 3267 (20080714)
__________
The message was checked by ESET NOD32
Antivirus.
http://www.eset.com
__________ Information from ESET NOD32
Antivirus, version of virus signature database 3267 (20080714)
__________
The message was checked by ESET NOD32 Antivirus.
http://www.eset.com