rusefi.com

Posted: **Sun Nov 20, 2016 1:20 pm**

It's baffling. I'll do some more troubleshooting tonight.
I'll scope the signal with the engine controlled by the stock ECU and want to see if we have the same issue. Then will swap sensors.
I can also try and run it off my backup MS and see what that does.

Posted: **Sun Nov 20, 2016 3:21 pm**

Perhaps the over-current condition broke something. Perhaps try a larger resistor, like 100kohm.

Posted: **Sun Nov 20, 2016 9:06 pm**

Looks like the observed signal inversion is what is supposed to happen!

The pullup in the stock ECU is apparently to 12V. Trace below shows a signal floor of ~1.4V and top at 12V.

: CAM Signal inverted.png (78.02 KiB) Viewed 33378 times

But it can't be all a current thing, since 3.3kOhm @12V and 1kOhm at 5V, which we used to have, should yield fairly comparable currents.

EDIT: I could install a resistor in the signal line and scope the current that way. 10Ohm at an estimated 5mA would give me 50mV. Enough to see, but unlikely to kill the signal.

Posted: **Sun Nov 20, 2016 10:22 pm**

Measured current. At 10 Ohm we get a voltage drop of 75mV. So we get 7.5mA. Suggesting a total resistance of 1600 Ohm. The voltage drop on the sensor is approx 1.4V suggesting approx 190 Ohm for the sensor itself.
At 5V we want a total of ~670 Ohm to get 7.5mA. That leaves us with 470 Ohm for the pullup.

: CAM current sniffer.png (66.15 KiB) Viewed 33376 times

Posted: **Sun Nov 20, 2016 10:36 pm**

Beware that the MAX chip will clamp to 5V. So your impedance might get a bit wonky as you exceed 5V with your 12V pullup. The MAX chip has rail clamping diodes, which will dump to the 5V rail. When it dumps like this you will need something to consume this energy or your 5V will raise above 5V and potentially damage 5V devices.

Posted: **Mon Nov 21, 2016 2:02 am**

Strange news everyone!
Looks like the behavior we observed is intentional. These are scope traces of the CAM sensor running with the stock ECU.

CAM signal while cranking around 200rpm (disconnected spark)

: Stock ecu cam cranking.png (73.85 KiB) Viewed 33363 times

CAM signal with spark plugs, cranking and firing up within just one turn of the crank

: Stock ecu cam starting.png (80.57 KiB) Viewed 33363 times

And with the engine running in idle

: CAM Signal inverted.png (78.02 KiB) Viewed 33363 times

At low rpms the sensor signal goes from a normal low to high when it sees a trigger. At running rpms the signal inverts and goes from high to low. So our electronics are fine. They are reporting the signal as it is presented by the sensors and that is intentional. I haven't verified it yet, because the crank sensor wiring is such a pain to get to, but from what I've seen before it behaves the same way.

Over to software?

Posted: **Mon Nov 21, 2016 2:30 am**

Pleasure talking with you @stefanst. Per our talking and testing, it appears that the OEM ECU exhibits this inverting signal that you captured above on the Frankenso board. I suspect this is caused by the hall sensor itself. I suspect that at low RPM, the hall sensor adjusts itself increasing an internal gain of an amplifier, such that it can capture the pulses which are generated by the lower magnetic fields that happen at the lower RPM's. Then once the pulses are coming in less than some certain amount of time, then it decreases the gain, and the pulses could potentially change at that point.

I wonder if there's a way this could be setup on a kind of jig which allows controlling of the RPM as well as measuring the RPM, then we could characterize the pulses based on RPM and see specifically when it happens and when it happens. I also wonder if we could tear one apart and find what the hall sensor is. Often these use an off the shelf hall sensor which may have a datasheet.

Posted: **Mon Nov 21, 2016 2:48 am**

BTW: The cranking rpm looks to be 200rpm on the cam- that is 400rpm crank.

Posted: **Mon Nov 21, 2016 2:55 am**

On the one hand, since VVT sync is running on rising fronts only, software would work with this as is - nothing to change in the software. Below 200 rpm VVT would be a bit off but who cares below 200rpm.
Is that with 5K pull-up resistors?

On the other hand, does not this all sound a bit too complex to be true? WHY would they intentionally do that? Could it be that this crazy stuff is only happening to us because +5 pull-up?

Posted: **Mon Nov 21, 2016 2:58 am**

Those signals are straight off the stock ECU (sensor output BEFORE the ECU).
So this has nothing to do with frankenso electronics at all...

Posted: **Mon Nov 21, 2016 3:14 am**

I'll try, but since your '03 and my '03 have the same issue- and both on the cam and crank sensors, I am pretty certain that this is OK.
I think the trigger code is getting confused somehow. Using the crank as primary instead of cam may contribute.
On the '99 we trigger off cam as primary- correct? And the VVT uses crank as primary.

Let's look at the engine logger from before:

We get the 1-2-1-2 on the rising flanks on the cam. But we're missing spark and fuel events and then we even have something that looks like a double-event.

Can we run the '03 with the NB1 code, or is the phase shift between cam and crank wrong for it?

Posted: **Mon Nov 21, 2016 3:19 am**

stefanst wrote:Can we run the '03 with the NB1 code, or is the phase shift between cam and crank wrong for it?

I would expect that 03 with NB1 should be good enough for 1st run, there is a chance that global trigger offset would be needed - but maybe not.

I believe on NB1 the single CAM tooth is within the first 180 degrees of the 720 degrees engine cycle.

Posted: **Mon Nov 21, 2016 3:28 am**

Do I remember right that we now use 0deg trigger angle offset for NB1 or is it still 276?
I can probably try tomorrow evening, but then I'm off for T-day week with the family in SC. I really hope to get it started first though

Posted: **Mon Nov 21, 2016 3:32 am**

https://svn.code.sf.net/p/rusefi/code/trunk/firmware/controllers/trigger/trigger_mazda.cpp now has build-in tdcPosition = 276 for NB1 so global trigger offset (which is extra offset in addition to trigger-specific tdcPosition) is not needed

That's assuming i have not messed up anything moving it from offset to tdcPosition.

Posted: **Mon Nov 21, 2016 11:50 pm**

Looks like the NB1 trigger evaluation is not happy with running the NB2 engine.
EDIT: Because I know the question is coming. Yes I tried both: Use Rise Edge Only yes and no.

: 2016-11-21_18_46rpm_0_maf_NaN.png (35.72 KiB) Viewed 33352 times

We can read the signal, but there is no injectioning or ignitioning going on.
Message log:

Code: Select all

2016-11-21 18_26: EngineState: templog engine has STOPPED [4][4E67070] [4][24E6B0A] 43517286
2016-11-21 18_26: EngineState: Template AUDI_AAN (1) trigger TT_MAZDA_MIATA_NB1 (4) useRiseEdge=No onlyFront=Yes gapBothDirections=No useOnlyFirstChannel=No
2016-11-21 18_26: EngineState: trigger#1 event counters up=0/down=84
2016-11-21 18_26: EngineState: trigger#2 event counters up=0/down=117
2016-11-21 18_26: EngineState: expected cycle events 3/8/0
2016-11-21 18_26: EngineState: trigger type=4/need2ndChannel=Yes
2016-11-21 18_26: EngineState: expected duty #0=0.08/#1=0.04
2016-11-21 18_26: EngineState: synchronizationNeeded=Yes/isError=No/total errors=0 ord_err=0/total revolutions=0/self=No
2016-11-21 18_26: EngineState: gap from 0.08 to 0.13
2016-11-21 18_26: EngineState: primary trigger input: PC6
2016-11-21 18_26: EngineState: primary trigger simulator: PD1 OM_DEFAULT freq=1200
2016-11-21 18_26: EngineState: secondary trigger input: PA5
2016-11-21 18_26: EngineState: secondary trigger simulator: PD2 OM_DEFAULT phase=6
2016-11-21 18_26: EngineState: trigger error extra LED: NONE OM_DEFAULT
2016-11-21 18_26: EngineState: primary logic input: NONE
2016-11-21 18_26: EngineState: secondary logic input: NONE
2016-11-21 18_26: EngineState: zeroTestTime=5 maxHowFarOff=17641
2016-11-21 18_26: EngineState: advanceLookupTime=471 now=82289777 fuelCalcTime=1573
2016-11-21 18_26: EngineState: ignitionMathTime=0 ignitionSchTime=0 injectonSchTime=323
2016-11-21 18_26: EngineState: mapTime=0/hipTime=0/rpmTime=0/mainTriggerCallbackTime=0
2016-11-21 18_26: EngineState: maxLockTime=0 / maxTriggerReentraint=0
2016-11-21 18_26: EngineState: maxEventQueueTime=231426
2016-11-21 18_26: EngineState: hipLastExecutionCount=0
2016-11-21 18_26: EngineState: hwSetTimerTime 266
2016-11-21 18_26: EngineState: totalTriggerHandlerMaxTime=2621

Posted: **Tue Nov 22, 2016 1:11 am**

There is a small chance it would work if you change onlyFront=Yes to onlyFront=No in TS

Posted: **Tue Nov 22, 2016 1:36 am**

Tried all four permutations of
use only rising edge true/false
and
VVT use rise front true/false

Not a single blip of rpm recognition.

Posted: **Tue Nov 22, 2016 1:37 am**

I am done fixing the exhaust, now I need to put it back on the car and I can lower it.

Posted: **Thu Nov 24, 2016 3:43 am**

enable trigger_details helps understand these kinds of issues. here with VVT we have two synchronizations - crank signal - which for us is trigger synchronization - is one, and VVT pattern synchronization is the other. Both values had issues on my car, trigger shape is hard-coded into the firmware, VVT ratio is configurable via TS.

Here is how it looks with a bit better values:

Code: Select all

2016-11-23 22_15: EngineState: gap=1.23/0.80/1.21 @ 1 while expected 0.75/0.98 and 0.00/100000.00 error=0
2016-11-23 22_15: EngineState: gap=0.81/1.23/0.80 @ 3 while expected 0.75/0.98 and 0.00/100000.00 error=0
2016-11-23 22_15: EngineState: vvt ratio 0.90
2016-11-23 22_15: EngineState: vvt ratio 0.09
2016-11-23 22_15: EngineState: gap=1.22/0.81/1.23 @ 1 while expected 0.75/0.98 and 0.00/100000.00 error=0
2016-11-23 22_15: EngineState: gap=0.81/1.22/0.81 @ 3 while expected 0.75/0.98 and 0.00/100000.00 error=0
2016-11-23 22_15: EngineState: gap=1.23/0.81/1.22 @ 1 while expected 0.75/0.98 and 0.00/100000.00 error=0
2016-11-23 22_15: EngineState: gap=0.81/1.23/0.81 @ 3 while expected 0.75/0.98 and 0.00/100000.00 error=0
2016-11-23 22_15: EngineState: vvt ratio 11.26
2016-11-23 22_15: EngineState: looks good: vvt ratio 11.26
2016-11-23 22_15: EngineState: gap=1.22/0.81/1.23 @ 1 while expected 0.75/0.98 and 0.00/100000.00 error=0
2016-11-23 22_15: EngineState: gap=0.80/1.22/0.81 @ 3 while expected 0.75/0.98 and 0.00/100000.00 error=0
2016-11-23 22_15: EngineState: gap=1.23/0.80/1.22 @ 1 while expected 0.75/0.98 and 0.00/100000.00 error=0
2016-11-23 22_15: EngineState: gap=0.81/1.23/0.80 @ 3 while expected 0.75/0.98 and 0.00/100000.00 error=0
2016-11-23 22_15: EngineState: vvt ratio 0.90
2016-11-23 22_15: EngineState: vvt ratio 0.09

1.22/0.81/1.23 means we have 1.23 ratio between current and previous gap followed by 0.81 followed by 1.22

Now with the fix the firmware expects the gap between 0.75 and 0.98 to sync trigger (NB1 value is about 1.5 and it did not work)

VVT messages are separate - we have a cycle of 0.9 followed by 0.09 followed by 11.26
New defaults are from 8 to 14 range, within that range you get "looks good: vvt ratio 11.26" message

Posted: **Thu Nov 24, 2016 3:46 am**

With these values I am getting some puffs, but no running

Posted: **Thu Nov 24, 2016 2:41 pm**

Could ignition timing be off now? I seem to remember that for start we should get ignition just a few degrees before the crank triggers on the wider part of the pattern. This is going from memory though....

Posted: **Fri Nov 25, 2016 2:26 am**

firmware 20161124 (synchronization gap widened to 0.35-0.98
Pre-warmed on stock ECU
still no MAP no AFR
global trigger offset 670 (once we measure the exact angle this would be moved into trigger defaults)
It runs

UPDATE: looks 5K pull-up resistors are the way to get proper trigger input with MAX9926 on Frankenso

Posted: **Fri Nov 25, 2016 4:50 pm**

Congratulations. Another runner!
So, bets are lost, blame will be shifted, heads will roll. But most importantly burritos will need eating. No turkey burritos though. I had enough turkey for a while...
Do you already have the wideband installed? Curious to see if your stock ECU is running as rich in full throttle as mine...

Posted: **Sun Nov 27, 2016 7:58 pm**

That last version did the trick!
The engine fired right up. And then stalled, because there's no tune yet, but it starts up without any trouble. It actually starts faster than my '99 with MS

These are the settings I used, stolen from @s tune.

: VVT trigger working.png (32.96 KiB) Viewed 33277 times

Now to hook up the rest of the sensors and tune this engine!

Posted: **Sun Nov 27, 2016 9:31 pm**

Sweet, and good to hear. I can't wait to see it tuned.

Posted: **Mon Nov 28, 2016 3:18 am**

So- had the car kind of idling, but realized that while the MAP sensor was connected, it was not connected to the intake. As a result the car was running insanely rich. I'm also experiencing trouble with the alternator control. I wired it already (HL5/PE10), but disabled it in the firmware. However, it looks like the alternator REALLY wants to charge my battery. Voltage spiking to 18V.
Do the HL outputs default to high or low?

Posted: **Mon Nov 28, 2016 11:20 am**

I know the STM has configurable weak internal pull up and pull down resistors. I'll have to rely on @russian to comment about how those are configured in software. I do not know if the default output would be 100% alternator or 0% alternator. Sounds like it's currently full alternator. If the STM output is floating it's not guaranteed to be either hi or low.

I know that in ChibiOS 3.0 in board.h they have #defines for PIN_PUPDR_PULLUP, PIN_PUPDR_PULLDOWN and PIN_PUPDR_FLOATING. I believe the defaults are that everything is floating, then changed via software as things are initialized. I also know that these can be set such that they are in that default state when powered on and you do not have to wait software to initialize.

Posted: **Mon Nov 28, 2016 3:16 pm**

stefanst wrote:I wired it already (HL5/PE10), but disabled it in the firmware.

HL is where we do not have hardware pull-downs on current version of the board, also HL is where your jumper sets it to GND or 5V or 12V. If not enabled in firmware you are running based on https://svn.code.sf.net/p/rusefi/code/trunk/firmware/chibios/boards/ST_STM32F4_DISCOVERY/board.h which says PIN_PUPDR_PULLDOWN(GPIOE_PIN10)

Posted: **Mon Nov 28, 2016 5:17 pm**

I seem to recall the internal pull up and pull down are kind of weak, something like 10k or 50k. The external pull down on the not yet released R0.5 was to allow for a guaranteed pull down independent of the software.

So default should be pulled down, which I seem to recall should prevent current from flowing in the green wire, and therefor not excite the field windings, and no alternator. Is there a schematic for the alternator / charging circuit? I'm not sure if low side drive would be 100% or 0% alternator. I think the field is connected to your battery negative, but perhaps your circuit has the battery connected to the battery positive.

Posted: **Mon Dec 12, 2016 2:55 pm**

Important and boring milestone for the new test mule

rusefi.com

red 2003 VVT test mule Miata NB2 #27

Re: 2003 VVT test mule Miata

Re: 2003 VVT test mule Miata

Re: 2003 VVT test mule Miata

Re: 2003 VVT test mule Miata

Re: 2003 VVT test mule Miata

Re: 2003 VVT test mule Miata

Re: 2003 VVT test mule Miata

Re: 2003 VVT test mule Miata

Re: 2003 VVT test mule Miata

Re: 2003 VVT test mule Miata

Re: 2003 VVT test mule Miata

Re: 2003 VVT test mule Miata

Re: 2003 VVT test mule Miata

Re: 2003 VVT test mule Miata

Re: 2003 VVT test mule Miata

Re: 2003 VVT test mule Miata

Re: 2003 VVT test mule Miata

Re: 2003 VVT test mule Miata

Re: 2003 VVT test mule Miata

Re: 2003 VVT test mule Miata

Re: 2003 VVT test mule Miata

Re: 2003 VVT test mule Miata #27

Re: 2003 VVT test mule Miata #27

Re: 2003 VVT test mule Miata #27

Re: 2003 VVT test mule Miata #27

Re: red 2003 VVT test mule Miata #27

Re: red 2003 VVT test mule Miata #27

Re: red 2003 VVT test mule Miata #27

Re: red 2003 VVT test mule Miata #27

Re: red 2003 VVT test mule Miata #27