Open source 24x/1x signal generator

[AngelMarc]

EDIT:
833333 divided by TPS number equals RPM. Roughly, there's decimals not accounted for.
Edit sketch with the following to use RPM numbers directly

Code: Select all

int RPM = 9000;
int TPS = (2500000 / RPM) / 3;

Attached an updated version. Expect rounding errors in target vs measured. Those errors will get larger at higher RPM.

Original post:
https://www.youtube.com/watch?v=EXo97nUB3hk

Tested at over 9,000 RPM
I used a Pi Pico and a TC4452V.
It's all generic Arduino code; so grab your favorite micro controller and give it a try.
The oscilloscope is a VDS1022 if you care to know. They sell for $95.

[AngelMarc]

In the future I may look into some multi-threaded code so the signal isn't interrupted and could be sloped instead of jumping straight to the resulting speed, and the number sent could be the desired RPM. Need to look into sharing variables between threads with appropriate buffering and what not.

[pman92]

You dont need multithread to make the rpm slope to the desired.

Make the serial receiver set a "desiredTPS" value instead. At the end of each loop / engine revolution, if desiredTPS < TPS, decrement TPS. If it's above, increment.
If its sloping too fast, only do it every second, third, 4th rev.

Serial.parseInt is also blocking, so you'll have to switch to reading bytes only as they arrive, storing them and parsing them yourself once you get a new line.

Ideally use interrupts for the actual signal generation

[AngelMarc]

ECU looks very unhappy beyond 8,000. Spark instabillity big time.
It still tries at 20,000 RPM, but in the same way a toddler would try to beat a pro boxer.
Since scanner disconnects much beyond 9,000, I have to do math of 24 teeth times 3 per tooth (code base numbers) times 40 (number I sent over serial) = 0.00288 microseconds per crank revolution. Divide 60 by 0.00288 = 20,833.33333333333 RPM.
I have the scope reading crank signal and a coil control output.
Beyond 8,000 you see dwell periodically almost disappearing. At 20,000, makes me wonder if something wrapped in code and the startup cam phase hunting is active again; because it's dropping a lot.

[antus]

It may not support dwell overlap internally even though it has only one coil per cylinder and thus hit a hardware limit and not be usable beyond 8k.

[AngelMarc]

Hard to say what it is without the full decompile.

[antus]

There is some documentation here that might help explain it. I have not had the time to read it. viewtopic.php?p=131488#p131488

Having said that I just opened it and flicked a couple of pages at random and landed straight on a diagram describing overlapping dwell on page 31. Maybe I should buy a lottery ticket

[AngelMarc]

Just had a random thought. What if it's an interpollation error? Since the table ends at 8,000. Interpollating to some nonsense past the end of the table..

[antus]

Its not impossible but it is unlikely. These PCMs have been able to run off the end of the spark tables since they first existed in the late 80s. They usually either lock to the last value in the table, or some have a hard coded value table that can give some kind of rudimentary scaling beyond the edge. I don't know what this operating system does, but because its all library based I'd be surprised if it did something crazy and would expect it to do something sain. Would need to take a look at the code with some test values above 8000 rpm to know for sure though.

[AngelMarc]

I think there's a setting to turn off interpollation, maybe just for fuel though. I might test that at some point. Your guess about overlap is probably right though.