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