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