Scroll up... posts 88 and 89.

 

Oh right. There it is. I'm an idiot.

 

Ok I will gladly be first in line to give him my money in exchange for the controller.


kcbhiw

What type of program are you using to set up the timing table and everything? Also how easy is this going to be to integrate with my megasquirt. Will I have to switch between the 2 programs to tune spark and fuel?

Also any chance that it is ready by May?

 

I've written my own application to tune a 12x12 table of RPM vs load. It's similar to the MT interface that is used with the MS. There are some screen shots a few pages back.

For the time being, you will have to switch between my application and whatever you use to tune your MS. That will hopefully change down the road, however.

Integration with your MS is straight forward. You will have the ability to use it either strictly as a standalone module or pass-through where NA CAS or NB2 trigger outputs are emulated and sent to the EMS. I'm currently using the CAS emulation in my car. There is no other interaction with any EMS aside from that.

My goal is to have it out soon. I know I keep saying that, but I want it more or less perfect before it goes anywhere.

 

Er... you'd be sending emulated crank position data to the EMS? That sounds... horrible. :-) Just delays and imprecise timing, etc. Getting info FROM the EMS would be awesome, since you don't really need timing, just RPM info, right?

 

It's actually very precise. It's not really emulation so much as the input signals trigger an interrupt, and the pulse width that is output is basically a modified form of the input. The rise and fall of the output pulses are directly related to the crank/cam wheels. The output trigger to the EMS is within a few nS of the input. It all happens through a couple lines of code.

I would need more than simply RPM from an EMS as I need to caluclate actualy camshaft advance in relation the crank. Timing IS critical here.

 

Just a quick bump....I plan to have the final board revision off to the PCB printer this week. If all goes well, there should be a short beta run afterward before it's released. Wish me luck, heh.

 

Good Luck, and great work !!

p.s. How do you get in on the beta run

 

Yah let me know about the Beta run. I am looking at the beginning of May to have my new motor built and installed. Will be looking for some way to control VVT after that until MS3 gets built in support.

 

shuiend put the vvt head in regardless. You can run it at full retard / actuator disconnected until you get the controller in. It'll just have weak midrange torque until you do.

 

I plan on putting on the VVT and either running an rpm switch or leaving it disabled until the VVT controller is done. My pistons just came in yesterday, so next week I hopefully take stuff to the machine shop.

 

Thanks for the interest guys. I have a couple folks lined up for the testing.

I'll be keeping you all in the loop.

 

I'd likely be a good tester, but, I'm whiny. :-) You certainly have more convincing to tell me that the accuracy of the spark timing has more error in it than cam timing. MS-II has a (rudimentary) cam phase as a reported value. And I'd rather be 1* off in cam timing than spark. How do you know that time it takes to get the signal out is conserved?

 

If you have an NB2 I expect that Kevin's circuit will simply share the crank and cam signals with the ECU. If you have an NB1 I think the factory ECU can accept the VVT cam signal as is. (the crank signals are the same)

If you have an ECU that expects NA style cam and crank signals, his controller will output NA style signals derived from the NB signals. This should be more accurate than an actual CAS because he derives the signals from the crank, in a similar manner to how ECU's interpolate crank position between pulses. CAS signals have more jitter and inaccuracy due to belt whip.

 

Oh, absolutely. That would be a help.

Is that true, then, that your controller actually passes through the signals directly (or, buffered but without an interrupt) to the ECU, on non-CAS cars?

If so, I'd be very interested - if not, I might put something upstream of your box to sniff the signals and then share them with both. Any fixed signal delay won't hurt your box (up to maybe 500 ms. :-P - but a variable delay would hurt the ignition timing of a crank tooth wheel.

I'd really like to clarify this. And then buy one. :-)

 

I just want to say you guys are way to smart.

 

Glad to here you got it up and running(well it is close anyway). I am with Abe on the delay issue. High RPM plus delayed position signals = a bit scary

 

I haven't implemented any circuitry to share the sensors with any other ECU, however, adding such if necessary wouldn't be beyond a DIYer.

Regarding the timing signals, this is correct. Through simple observation with a timing light on the crank pulley, the timing is significantly more stable than that of a car that is running from the OE CAS at a steady RPM.

The output timing signals are essentially passed through during the interrupt that was triggered by the input timing signals within the MCU. Essentially, the output signal that is generated occurs within a few microseconds of the input trigger -- basically enough time for a few instructions to be executed at 8MHz. I won't go into the nuances of execution time per MCU instruction, but you get the idea. There is no buffering of the signal.

Whether the user selects an NA CAS or NB timing output, the condition of the output is simply derived through a manipulation of the input within the interrupt routine.


I've been running the box for quite some time now, but have otherwise been cleaning up the rough edges.

 

No need for any circuitry, just connect them up and go.

 

Will the device still work if I've bolted an N/A CAS to the back of my engine and don't use the NB sensors