Challenge: add Audi "trigger wheel" to code

[jsmcortina]

As currently coded the I/O is as follows:

PT4 used for hi-speed flywheel teeth
"crank" tach-in used for single flywheel pin
"cam" tach-in used for hall cam

The choice of PT4 and "crank" for the two flywheel signals allows for code sharing with the Nissan CAS and Optispark modes. Presently the cam input is fixed on the "cam" input, but JS10 could be allowed if desired.

The high frequencies on the two flywheel sensors do present an issue and the VR conditions need to be up to the job as phase drift will likely lose sync.

I've been testing on the bench with the 135 tooth + 1 pin flywheel signals only (not re-written the JimStim for the tertiary cam tach) and so far it _appears_ to work up to the max speed I've generated on the stim = 5900rpm.

James

[elaw]

As currently coded the I/O is as follows:

PT4 used for hi-speed flywheel teeth
"crank" tach-in used for single flywheel pin
"cam" tach-in used for hall cam

I can probably test that way because I have Jean's board with the two VR conditioners on it. But as I'm sure you know, for this to work with minimal added circuitry, the two MS VR conditioners (on the V3 board and on the MS3X) would have to be used for the flywheel signals.

The choice of PT4 and "crank" for the two flywheel signals allows for code sharing with the Nissan CAS and Optispark modes. Presently the cam input is fixed on the "cam" input, but JS10 could be allowed if desired.

JS10 would be good for me since my MS is currently set up that way, but I can switch it if necessary.

I've been testing on the bench with the 135 tooth + 1 pin flywheel signals only (not re-written the JimStim for the tertiary cam tach) and so far it _appears_ to work up to the max speed I've generated on the stim = 5900rpm.

James

Great! FWIW, factory redline on the Audi 20-valve engines is 7200.

[jsmcortina]

Making the cam input JS10 instead is a trivial code change.

The trouble with using the existing cam tach input on the MS3X and likely the mainboard crank too is that the standard component values aren't designed for this many teeth and will need changing. That's all part of this alpha testing and development though.

James

[elaw]

Fair enough!

By the way, I think I probably overestimated the difficulty of making the changes to my system needed to test this. So whenever you have some code you think is usable, feel free to send it to me and I'll give it a try.

PS: if that code was based on alpha 13 it would be great, since that's what I'm currently running.

[racingmini_mtl]

Eric,

Let me know if you want to try a MAX9926-based solution for the VR signals.

Jean

[elaw]

Jean,

Thanks for the offer but for now I'm going to stick with what I have because it works! I haven't had anything that even remotely resembles a triggering problem in this car for months.

For testing the new code, I can easily grab the signals coming out of the LM1815s and route them to the appropriate places - I think I can do it in a way that will allow me to revert easily if the new code has any issues.

[jsmcortina]

Looking forward to seeing a workable "recipe" for using these wheels. If it works better with the inputs swapped around (e.g. a VR board inside the case) then the code can be changed.

James

[julian944]

Sorry for the question which is off topic, but I'm just thinking about my configuration.

Is it right that the amount of teeth on the flywheel divided by the number of cylinders must be an integer?

So I get a problem with my 130 teeth flywheel on a 4 cylinder engine right? (Porsche 944).

Thanks for your help

Julian

[jsmcortina]

Assuming we can get it working, because the code is custom then strange numbers can be supported too.

James

[jsmcortina]

Anyone tried out alpha 14 ?

James

[julian944]

Hello,
well I don't have tried it yet, I just got my ms3, but I'am thinking about my configuration and I need some help.

Porsche 944 with 130teeth wheel for crank speed and one single pin on crank for the position, and absolutely stock ms3 with ms3xboard from diyautotune.com

I've loaded alpha14, and I have seen flywheel tri-tach, I guess this is the right one?

PT4 used for hi-speed flywheel teeth
"crank" tach-in used for single flywheel pin
"cam" tach-in used for hall cam
ok so far?

PT4 is normally used for logic output, so do I have to make some internal hardware changes in my ms3, or is everything changed in the code?
Normally I thought I need a VR-conditioner ? Do I need to build this on the pt4 input?


So if I dont use any cam in, I just can choose "use cam signal if availible" OFF, and code is still working?
tertiary tach input belogs to the cam signal right?

@James, you said you tested it on the bench with the stim, ist the stim simulating VR or hall -sensors? you have been able to rev up to 5900, did you made any hardware changes on the tach-inputs?

Thank you very much for your help.
Julian

[jsmcortina]

You need to make an external VR conditioner circuit and connect to the PT4 pin on the MS3X. This is actually an input or an output. No change is needed on the MS3X.

Hopefully Eric will chime in with anything else that he has learned.

The processor itself does not know the difference between VR and hall inputs - they both look like a square wave one they arrive at the processor.

James

[julian944]

Ok, and when I have a hall-sensor which already delivers a square wave then I don't need such a condition right?

For my application I just need two vr-conditioners, is it possible to use the standard ms3x-board conditioner and connect this curcuit to the pt4 pin?

Regards Julian

[dontz125]

You always want to use a conditioner of some sort. Directly connecting the processor to a sensor "In the great outdoors' is a good way to buy a new processor - shorts, surges, loose wires, small animals, you name it, all of a sudden you've got 12+ volts coming down a wire into a pin that doesn't like anything over 5. Oops ...

[elaw]

Anyone tried out alpha 14 ?

James

James,

Well... finally... yes! Sadly, the addition of the noise filter doesn't seem to have changed the behavior on my car. The engine will only start on about 50% of attempts, but once it starts it always runs perfectly. I took a bunch of logs, I'll email them to you with the associated .msq.

[jsmcortina]

Spent some hours working on this today. I wrote a tri-tach mode on the JimStim and eventually found a couple of tiny but important bugs in the code.
a. MS3X cam wasn't working as the cam input and was screwing up the spark outputs in this mode.
b. The cam input wasn't actually being checked due to a code error. Hence 50% of the time it would start on the wrong phase.

So, as of now it appears to work ok on the bench, which it didn't earlier.
(In my previous testing I only had two tach inputs, so was unable to test it fully.)

James

[elaw]

James,

Just tested this out on Alpha 15, and it appears we have success!

I'll email you with the details, but I just wanted to thank you here for the effort you've put into this.

[savagerocco]

Have you run this long enough to get a feel for it?

[elaw]

It's still not 100%. It's working well enough that I actually drove the car for a few days using it. But every now and then (maybe 5 times in a 20-minute trip) the engine would "hiccup", as if it missed one injection pulse or ignition event, and the log would sometimes show a single point with zero RPM. So I switched back to using the divider board.

I'm a little reluctant to keep modding the hardware to switch back-and-forth between triple trigger and the divider board, so I've got a request in to James to be able to change one of the triple-trigger inputs so I can make a permanent wiring change that will support both modes. That way I can test just by changing settings in the software.

[jsmcortina]

This mode certainly proved and still proves to be hard work. I've been too busy of late to get to Eric's request.

James