Discrete components VR decoder with zero firmware code

Hardware inside and outside of the ECU
User avatar
AndreyB
Site Admin
Posts: 14292
Joined: Wed Aug 28, 2013 1:28 am
Location: Jersey City
Github Username: rusefillc
Slack: Andrey B

Re: Discrete components VR decoder with zero firmware code

Post by AndreyB »

Looking forward!
Very limited telepathic abilities - please post logs & tunes where appropriate - http://rusefi.com/s/questions

Always looking for C/C++/Java/PHP developers! Please help us see https://rusefi.com/s/howtocontribute
mck1117
running engine in first post
running engine in first post
Posts: 1493
Joined: Mon Jan 30, 2017 2:05 am
Location: Seattle-ish

Re: Discrete components VR decoder with zero firmware code

Post by mck1117 »

Have you performed any simulations with that design to determine if the output has any delay/lag with the input waveform? The big selling point of the MAX992x and the TLE8888 is that the output is always perfectly aligned to the zero crossing, which perfectly aligns with the physical center of the tooth/gap on the trigger wheel.

Fast iteration is great, so long as you actually learn something each iteration and can quantify that learning.
Gepro
Posts: 100
Joined: Sun Nov 01, 2020 2:15 pm
Location: France

Re: Discrete components VR decoder with zero firmware code

Post by Gepro »

There is no simulation of the complete circuit, it will be done for real. (in approx 20days :roll: )
In theory, there is no delay/lag for an engine. (the comparator has 10us latency and the amp works in MHz)
The zero crossing detection works as the MAX992x.

There is a delay with PWM control, less than 100ms, but the value is set before the peak. There is no watchdog here.
mck1117
running engine in first post
running engine in first post
Posts: 1493
Joined: Mon Jan 30, 2017 2:05 am
Location: Seattle-ish

Re: Discrete components VR decoder with zero firmware code

Post by mck1117 »

Gepro wrote:
Sat Jan 02, 2021 10:38 am
There is no simulation of the complete circuit, it will be done for real. (in approx 20days :roll: )

In theory, there is no delay/lag for an engine. (the comparator has 10us latency and the amp works in MHz)
The zero crossing detection works as the MAX992x.

There is a delay with PWM control, less than 100ms, but the value is set before the peak. There is no watchdog here.
After a closer look at the schematic, that's actually an interesting setup. Adjustable threshold for the rising edge, and zero crossing on the fall. With a little more digital logic you could actually have it "arm" on the peaks, and get BOTH zero crossings, so that the wiring isn't sensitive to the sensor polarity, and it can be inverted in software.
mck1117
running engine in first post
running engine in first post
Posts: 1493
Joined: Mon Jan 30, 2017 2:05 am
Location: Seattle-ish

Re: Discrete components VR decoder with zero firmware code

Post by mck1117 »

Also why are you using two halves of two MCP6002? Why not use both halves of a single...?
User avatar
kb1gtt
contributor
contributor
Posts: 3758
Joined: Tue Sep 10, 2013 1:42 am
Location: ME of USA

Re: Discrete components VR decoder with zero firmware code

Post by kb1gtt »

Perhaps vref source could be optional PWM / DAC input? I know the goal is no firmware, but having a software adjustable threshold is likely a desirable feature. These PWM / DAC are handy as you can PWM digitally or if you have a DAC you can just DAC the thing. This would allow for an adjustable threshold if so required. PWM / DAC reference below.
https://www.instructables.com/Arduino-RC-Circuit-PWM-to-analog-DC/

You have some signal delays from the 10k and 1nf. It's not much but it still exists. Remember the slew rate of the tooth edge has lots of higher frequency content. This is a handy with page for calculating lrc filters.
http://sim.okawa-denshi.jp/en/CRtool.php

I recall you can find analog crack angle sensors. Could we make a fixture with an absolute crank angle sensor and check the crank angle accuracy vs real angle at various rpms. Also do we care about accuracy or repeatability? If it's repeatable your timing table will compensate.
Welcome to the friendlier side of internet crazy :)
mck1117
running engine in first post
running engine in first post
Posts: 1493
Joined: Mon Jan 30, 2017 2:05 am
Location: Seattle-ish

Re: Discrete components VR decoder with zero firmware code

Post by mck1117 »

kb1gtt wrote:
Sat Jan 02, 2021 11:47 am
Perhaps vref source could be optional PWM / DAC input? I know the goal is no firmware, but having a software adjustable threshold is likely a desirable feature. These PWM / DAC are handy as you can PWM digitally or if you have a DAC you can just DAC the thing. This would allow for an adjustable threshold if so required. PWM / DAC reference below.
https://www.instructables.com/Arduino-RC-Circuit-PWM-to-analog-DC/

You have some signal delays from the 10k and 1nf. It's not much but it still exists. Remember the slew rate of the tooth edge has lots of higher frequency content. This is a handy with page for calculating lrc filters.
http://sim.okawa-denshi.jp/en/CRtool.php

I recall you can find analog crack angle sensors. Could we make a fixture with an absolute crank angle sensor and check the crank angle accuracy vs real angle at various rpms. Also do we care about accuracy or repeatability? If it's repeatable your timing table will compensate.
It already has a pwm/dac adjustable threshold.

It's easy to check the accuracy/threshold position by just scoping the (analog) VR signal and digital output at the same time. No mechanical checking needed. You can even do it with a synthetic signal from a function gen, no real sensor required.
User avatar
kb1gtt
contributor
contributor
Posts: 3758
Joined: Tue Sep 10, 2013 1:42 am
Location: ME of USA

Re: Discrete components VR decoder with zero firmware code

Post by kb1gtt »

PWM / DAC should be before the opamp.
Welcome to the friendlier side of internet crazy :)
Gepro
Posts: 100
Joined: Sun Nov 01, 2020 2:15 pm
Location: France

Re: Discrete components VR decoder with zero firmware code

Post by Gepro »

mck1117, there is only one MCP6002, it isn't clear with the schematic, but it is U1.1 and U1.2, it is the same.

kb1gtt, there is already a DAC in order to change the Vmin threshold, if you put it before the opamp, don't you change the zero crossing point ?
MAX9925.jpg
MAX9925.jpg (24.02 KiB) Viewed 23794 times
The MAX changes the threshold, and the zero crossing in mode A, it probably adjusts the delay when the threshold is too high, but I am not sure. I don't understand this part from the MAX. :oops:

I have to know the delay. I will take a look with a oscilloscope, a friend had one with old measures of my MAX9924. The MAX had a lot of troubles with my one tooth cam.
mck1117
running engine in first post
running engine in first post
Posts: 1493
Joined: Mon Jan 30, 2017 2:05 am
Location: Seattle-ish

Re: Discrete components VR decoder with zero firmware code

Post by mck1117 »

kb1gtt wrote:
Sat Jan 02, 2021 12:32 pm
PWM / DAC should be before the opamp.
Gepro wrote:
Sat Jan 02, 2021 7:35 pm
kb1gtt, there is already a DAC in order to change the Vmin threshold, if you put it before the opamp, don't you change the zero crossing point ?
yes, gepro is right, he's trying to move ONLY the rising threshold, not the falling, and not the vmid offset
mck1117
running engine in first post
running engine in first post
Posts: 1493
Joined: Mon Jan 30, 2017 2:05 am
Location: Seattle-ish

Re: Discrete components VR decoder with zero firmware code

Post by mck1117 »

why are R17/19/20/21 47k instead of 100k to match the input resistors?
Gepro
Posts: 100
Joined: Sun Nov 01, 2020 2:15 pm
Location: France

Re: Discrete components VR decoder with zero firmware code

Post by Gepro »

It was a test for reducing the gain and work with more voltage input, but with the SRV05 it is certainly a bad thing :oops:

It allows less distortion to the output of the opamp, but it is probably a mistake.

Thanks, for the question :lol:

PS : in fact, the resistance and PWM values had to be divided by 2 :/ :/ 100K everywhere for the next board :lol: :lol:
Last edited by Gepro on Sun Jan 03, 2021 10:29 am, edited 1 time in total.
mck1117
running engine in first post
running engine in first post
Posts: 1493
Joined: Mon Jan 30, 2017 2:05 am
Location: Seattle-ish

Re: Discrete components VR decoder with zero firmware code

Post by mck1117 »

Gepro wrote:
Sun Jan 03, 2021 10:21 am
It was a test for reducing the gain and work with more voltage input, but with the SRV05 it is certainly a bad thing :oops:

It allows less distortion to the output of the opamp, but it is probably a mistake.

Thanks, for the question :lol:
got it - so probably switch those four to be 100k to match.

Next question: does this actually do what you want it to?
image.png
image.png (30.38 KiB) Viewed 23767 times
I don't think it does, because 5v input -> 5v threshold, 1v input -> 1v threshold, etc. The STM32 can only generate voltages in the 0-3.3v range, so you're limited to a VERY narrow range of rising thresholds between 2.5 and 3.3 volts. I'd switch U1 to instead be an MCP6004 or similar, and use the extra two channels to sum the inputs with vref so that you get the full range of 2.5 to 5 volts instead of 2.5 to 3.3 (with less resolution since a bunch is useless in the 0 to 2.5 range).
Gepro
Posts: 100
Joined: Sun Nov 01, 2020 2:15 pm
Location: France

Re: Discrete components VR decoder with zero firmware code

Post by Gepro »

Wow fast response !

There is no voltage input in the DAC without resistors, it is only when there is resistors, it is why there is a 100K / 310K divider before STM, it sends 0-2.5v.

The "threshold" in the schematics is a room to solder resistor when STM pins not plugged. It allows to have custom Vmin threshold.

But with the 47K, it isn't possible to go under 50% PWM :/

PS : It is inverted, that's why it doesn't work without PWM signal. It is probably not user friendly, but more simple.
mck1117
running engine in first post
running engine in first post
Posts: 1493
Joined: Mon Jan 30, 2017 2:05 am
Location: Seattle-ish

Re: Discrete components VR decoder with zero firmware code

Post by mck1117 »

Ok, I ran with @Gepro's design, and came up with a circuit that will output edges exactly aligned with the zero crossing (like a bare comparator), but will ALSO reject noise on the input by requiring an "arming" state before the zero crossing is allowed. Gepro's design did this only in one direction (rising edges were late, falling edges were zero-aligned), and mine adds the second direction plus some digital logic on the output to combine the two internal signals in to one output with zero aligned edges.

The two arming thresholds are generated by another circuit that converts a 0-3.3v input to two outputs: one from 0-2.5v, and the other from 5-2.5v so that the arming thresholds are the same in both directions.
image.png
image.png (157.06 KiB) Viewed 23729 times
It requires a few more components (a second switch IC, consumes one full dual comparator per channel, plus the NAND gates), but has the huge benefit that it is impossible to wire the sensor backwards, which is currently possible even with the venerable MAX992x chips. Those chips behave like Gepro's design - reject noise well, but have different behavior in each direction (rising edges are late, falling edges aren't). The TLE8888's integrated VR interface, on the other hand, is perfectly bipolar and outputs perfect zero crossings in both directions.

I also had to upgrade the comparator since the LM393 is pretty slow, and doesn't guarantee operation when the inputs are within 1.5-2 volts of the positive supply rail, which is close enough to cause problems for a high noise rejection threshold. The max9142 works all the way to within ~0.2v of the rails, and is two orders of magnitude faster.
mck1117
running engine in first post
running engine in first post
Posts: 1493
Joined: Mon Jan 30, 2017 2:05 am
Location: Seattle-ish

Re: Discrete components VR decoder with zero firmware code

Post by mck1117 »

Ok, the above design is back from JLC and some initial testing is done!
image.png
image.png (1.06 MiB) Viewed 23415 times
The good news: The comparators and threshold changing logic work mostly ok (after removing C9 and C10 from the board). There's a bit of noise and occasionally an iffy edge, but I think some added decoupling should help with that.

Pink: single ended output (aka difference between VR+ and VR-)
Yellow: falling pulse generator, right side of C2
image.png
image.png (45.72 KiB) Viewed 23415 times
Looks great, right!? A nice pulse on every negative zero crossing, and a small negative pulse when the signal passes the threshold and re-arms for the next falling edge. The symmetrical rising edge pulse generator functions great too (but only falling edge shown here).

Here's the threshold changing in real time:
image.png
image.png (33.49 KiB) Viewed 23415 times
This is on the rising edge of the input signal (pink), so the comparator output snaps high, then the threshold is switched low to add hysteresis.

The bad news: See those two NAND gates? Yeah, they should've been NOR gates instead. The only chip with the same pinout that swaps NAND for NOR is the 4001, introduced all the way back in 1968 (!). I've ordered a few of those to test it out, and changed the design to use the 74HC02 (quad 2-input NOR).
Gepro
Posts: 100
Joined: Sun Nov 01, 2020 2:15 pm
Location: France

Re: Discrete components VR decoder with zero firmware code

Post by Gepro »

I forgot to share on the forum !

I tested the board on my MRE, with crank and cam input.
My cam is more interesting, because of single tooth. (lot of noise, and more than 85ms between two signals at low RPM, it is a problem with MAX)

I used "AUX J2 PB9" from the "general purpose PWM" in order to set the threshold. (I put a 10K resistor for the crank, there is no missing tooth, so not a lot of noise)

Without PWM signal :
10K crank 0V cam.jpg
10K crank 0V cam.jpg (92.46 KiB) Viewed 23355 times
(no signal)

With 100% PWM signal :
10K crank 100% cam.jpg
10K crank 100% cam.jpg (98.03 KiB) Viewed 23355 times
(the threshold is 0V, so a lot of noise)

With 95% PWM signal :
10K crank 95% cam.jpg
10K crank 95% cam.jpg (89.43 KiB) Viewed 23355 times
<3 <3

But I had too much troubles with the filtering of the MicroRusEFI (there is a 100nF capacitor in the cam input circuit and the AV2 I use for testing)
It doesn't look possible to send a crank signal to the cam input. (without removing capacitors)

After that, I go with a 36-2 crank pulley and tested the scope on the signal. It is with a 20K resistor, I didn't try the PWM, like the 36-2 can't rev without trouble.

https://www.youtube.com/watch?v=O0e3rz7Sx6c

Here is a movie of the screen. It is VR+ and the output. (no cam)
The 2.5v is the zero crossing.
The signal goes high when the VR pass the threshold sets with 20K, and the signal goes low during the zero crossing of the falling edge.
Movie.jpg
Movie.jpg (85.5 KiB) Viewed 23355 times
(sorry about the movie, it isn't my scope and I don't have access to the log)

The polarity of the VR has to be set like the MAX992x, rising before falling. But the output is inverted compared to the MAX (the MAX is high when there is no signal)
blundar
contributor
contributor
Posts: 141
Joined: Tue Jan 07, 2014 4:38 am
Location: Cincinnati, Ohio
Github Username: blundar
Slack: Dave B.
Contact:

Re: Discrete components VR decoder with zero firmware code

Post by blundar »

This is the schematic of the triple VR decoder used in the Honda ECUs. Literally millions of this circuit were in production - every Civic and integra produced from 1992 to 2000 used this.
1992 Honda discrete VR decoder
1992 Honda discrete VR decoder
honda VR 1992.png (575.53 KiB) Viewed 23282 times
mck1117
running engine in first post
running engine in first post
Posts: 1493
Joined: Mon Jan 30, 2017 2:05 am
Location: Seattle-ish

Re: Discrete components VR decoder with zero firmware code

Post by mck1117 »

Ok, I dead-bugged in a quad NOR chip (to fix the wrong quad NAND chip), and it works!
image.png
image.png (577.22 KiB) Viewed 23236 times
Look at that, almost as much noise as there is signal, and a perfectly clean output!
SDS00036.png
SDS00036.png (23.84 KiB) Viewed 23236 times
Here's a zoomed in view with somewhat less noise injected:
SDS00031.png
SDS00031.png (24.01 KiB) Viewed 23236 times
Note how the output flips exactly when the analog trace (green) goes above the zero point (dotted green cursor line), but when it briefly goes back below it doesn't flip because the signal hasn't yet exceeded the arming threshold.
User avatar
AndreyB
Site Admin
Posts: 14292
Joined: Wed Aug 28, 2013 1:28 am
Location: Jersey City
Github Username: rusefillc
Slack: Andrey B

Re: Discrete components VR decoder with zero firmware code

Post by AndreyB »

Cool step towards 3-VR Honda :)
Very limited telepathic abilities - please post logs & tunes where appropriate - http://rusefi.com/s/questions

Always looking for C/C++/Java/PHP developers! Please help us see https://rusefi.com/s/howtocontribute
type111
Posts: 1
Joined: Wed Feb 17, 2021 2:35 am

Re: Discrete components VR decoder with zero firmware code

Post by type111 »

Hi guys, just signed up after reading here a couple of days and seeing all the interesting work going on. I've been working on a VR solution for my own ECU project. It's not rusefi but hopefully I'm still allowed here.

@mck1117 Your circuit looks just like the interface circuit given in the max992x data sheet with the 1n cap and all. I've simulated this circuit and can't figure out how it does NOT introduce a phase shift because of that cap which is acting like a low pass filter. I'm seeing near 20us at 4500hz (7500 rpm on a 36-1) which is a full degree. 100p cuts it by a factor of 10 which is in the realm of acceptable, but I'd rather cheap discrete solution than a $7 chip that's almost too small to see let alone solder by hand.

Your zoomed in test was at 500hz, how does it look at 5000hz?
vr_phase_0.png
vr_phase_0.png (45.5 KiB) Viewed 23211 times
How exactly are you probing this thing? I'm struggling to measure the phase shift on my scope because I have to manually centre the input waveform which could be all off.

Here's a circuit I spent a few hours on yesterday that's similar to the one in the original post but it clamps to the rails rather than to the 2.5V centre. Values yet to be optimised but the phase shift gets better the higher the frequency because of the series cap rather than parallel. Can be tuned to pass through full voltage range at idle. With another small cap can tune the phase shift to be zero at any point (and still < 1/50 degree everywhere else that it matters).
vr_interface_0.png
vr_interface_0.png (6.58 KiB) Viewed 23211 times
Plan is to pipe the two outputs into the analog comparator of my microcontroller whose datasheet says the comparator is good for 50ns.

I'm still a beginner at this sort of stuff. I've been doing software my whole life and only recently got into analog electronics so some back and forth here would be great. I'd love to know where my thinking is good and where it's totally off base.
User avatar
kb1gtt
contributor
contributor
Posts: 3758
Joined: Tue Sep 10, 2013 1:42 am
Location: ME of USA

Re: Discrete components VR decoder with zero firmware code

Post by kb1gtt »

Some comments
-- Yes you can talk other ECU's here, even MS. However please do it in an "on topic" forum post. Is your ECU open source, can you share, several of us like to see other approaches.
-- If you tune with a set phase shift, do you really care about the phase shift? I think your tune table will compensate for these and other variations.
-- I would like to see a circuit that identifies the noise as +/- XX mV then changes the 0 crossing threshold based on the noise. This would help remove noise inducted jitter.
-- I think your lower phase shift circuit lacks CMR I would suggest attempting to stay with a differential op-amp input to increase your CMR.
-- I think jitter is more important than a continuous phase shift.
-- I also wonder about how the phase shift varies with temperature. If you start cold in the mountains with snow, then race out into the desert, will this induce a detection tolerance issue?

Some where I had posted a LTSpice simulation, I used mutual inductance and a current source that changed it's current based currents listed in a file. This allowed for a circuit that produced a signal that is very similar to a real VR signal. If I find that simulation, I'll post it again.
Welcome to the friendlier side of internet crazy :)
User avatar
kb1gtt
contributor
contributor
Posts: 3758
Joined: Tue Sep 10, 2013 1:42 am
Location: ME of USA

Re: Discrete components VR decoder with zero firmware code

Post by kb1gtt »

I found the very rough VR simulation. Of course a better wave form can be obtained if you add more data points to the PWL.
Attachments
VR_inductor_reference.7z
(706 Bytes) Downloaded 236 times
VR_inductor_reference_picture.PNG
VR_inductor_reference_picture.PNG (46.96 KiB) Viewed 23200 times
Welcome to the friendlier side of internet crazy :)
User avatar
kb1gtt
contributor
contributor
Posts: 3758
Joined: Tue Sep 10, 2013 1:42 am
Location: ME of USA

Re: Discrete components VR decoder with zero firmware code

Post by kb1gtt »

This rough simulation includes a pinch of noise.
Attachments
VR_inductor_reference_With_noise.PNG
VR_inductor_reference_With_noise.PNG (33.86 KiB) Viewed 23200 times
VR_inductor_reference_With_noise.7z
(755 Bytes) Downloaded 256 times
Welcome to the friendlier side of internet crazy :)
mck1117
running engine in first post
running engine in first post
Posts: 1493
Joined: Mon Jan 30, 2017 2:05 am
Location: Seattle-ish

Re: Discrete components VR decoder with zero firmware code

Post by mck1117 »

type111 wrote:
Wed Feb 17, 2021 8:36 am
Hi guys, just signed up after reading here a couple of days and seeing all the interesting work going on. I've been working on a VR solution for my own ECU project. It's not rusefi but hopefully I'm still allowed here.
That's the point of open source :)
type111 wrote:
Wed Feb 17, 2021 8:36 am
@mck1117 Your circuit looks just like the interface circuit given in the max992x data sheet with the 1n cap and all. I've simulated this circuit and can't figure out how it does NOT introduce a phase shift because of that cap which is acting like a low pass filter. I'm seeing near 20us at 4500hz (7500 rpm on a 36-1) which is a full degree. 100p cuts it by a factor of 10 which is in the realm of acceptable, but I'd rather cheap discrete solution than a $7 chip that's almost too small to see let alone solder by hand.

Your zoomed in test was at 500hz, how does it look at 5000hz?
The 1n cap is a tradeoff between delay and noise rejection. I measured a pretty flat 10-15us delay across a wide range of speeds. I don't really want to make the cap any smaller, because the lowpass behavior of the 2x10k + 1n is exactly what we want to reject noise but minimize phase shift on fast signals (60-2 at high RPM, for example).
type111 wrote:
Wed Feb 17, 2021 8:36 am
How exactly are you probing this thing? I'm struggling to measure the phase shift on my scope because I have to manually centre the input waveform which could be all off.
The screenshots with a white trace are a differential measurement directly at VR+ and VR-, subtracted in a math channel on the scope. Screenshots with a green trace are the analog output from the differential -> single ended converter.

type111 wrote:
Wed Feb 17, 2021 8:36 am
Here's a circuit I spent a few hours on yesterday that's similar to the one in the original post but it clamps to the rails rather than to the 2.5V centre. Values yet to be optimised but the phase shift gets better the higher the frequency because of the series cap rather than parallel. Can be tuned to pass through full voltage range at idle. With another small cap can tune the phase shift to be zero at any point (and still < 1/50 degree everywhere else that it matters).

Plan is to pipe the two outputs into the analog comparator of my microcontroller whose datasheet says the comparator is good for 50ns.
Part of the goal of this circuit is to handle low tooth count wheels - they spend a lot of time sitting near 0 volts, then have a big positive then negative pulse.

Like this:
image.png
image.png (43.9 KiB) Viewed 23187 times
Those little spikes are induced noise from the ignition system. A simple comparator will switch on those - and even on the little ripple in the signal too. The point of the (maybe insane) bipolar thresholding is to only actually output a fast edge on the one we care about, and ignore those little pulses because they aren't loud enough to trip the arming threshold.

Plain hysteresis on the comparator (positive feedback) would work to reject the noise, but then the output isn't zero-aligned to the input!
User avatar
AndreyB
Site Admin
Posts: 14292
Joined: Wed Aug 28, 2013 1:28 am
Location: Jersey City
Github Username: rusefillc
Slack: Andrey B

Re: Discrete components VR decoder with zero firmware code

Post by AndreyB »

mck1117 wrote:
Tue Feb 16, 2021 9:41 am
Ok, I dead-bugged in a quad NOR chip
Any pictures of https://github.com/mck1117/vr-interface rev B?

Does it require any communication with firmware to control gain or is it completely self-contained?
Very limited telepathic abilities - please post logs & tunes where appropriate - http://rusefi.com/s/questions

Always looking for C/C++/Java/PHP developers! Please help us see https://rusefi.com/s/howtocontribute
mck1117
running engine in first post
running engine in first post
Posts: 1493
Joined: Mon Jan 30, 2017 2:05 am
Location: Seattle-ish

Re: Discrete components VR decoder with zero firmware code

Post by mck1117 »

Yes, it requires "communication" with the firmware. The firmware just has to output PWM that sets the threshold (filtered internally to a DC voltage). The board has a processed analog output that can be routed back to the firmware for oscilloscope purposes, but no software exits for that yet.
User avatar
AndreyB
Site Admin
Posts: 14292
Joined: Wed Aug 28, 2013 1:28 am
Location: Jersey City
Github Username: rusefillc
Slack: Andrey B

Re: Discrete components VR decoder with zero firmware code

Post by AndreyB »

mck1117 wrote:
Tue May 04, 2021 3:20 am
The firmware just has to output PWM that sets the threshold
Do you plan to use GPPWM to begin with or keep it GPPWM forever?

Did you have a chance to drive with that VR input?
Very limited telepathic abilities - please post logs & tunes where appropriate - http://rusefi.com/s/questions

Always looking for C/C++/Java/PHP developers! Please help us see https://rusefi.com/s/howtocontribute
mck1117
running engine in first post
running engine in first post
Posts: 1493
Joined: Mon Jan 30, 2017 2:05 am
Location: Seattle-ish

Re: Discrete components VR decoder with zero firmware code

Post by mck1117 »

AndreyB wrote:
Tue May 04, 2021 3:23 am
Do you plan to use GPPWM to begin with or keep it GPPWM forever?

Did you have a chance to drive with that VR input?
Planning to do initial testing with gppwm, but then it can become a simple rpm-vs-threshold 2d table.

My one VR sensor engine is currently taken apart, then will be busy racing. Probably won't run on new VR interface until mid June, but I can probably test with my VR bench setup before then.

Already tested with a function generator, and that seemed to work ok.
User avatar
AndreyB
Site Admin
Posts: 14292
Joined: Wed Aug 28, 2013 1:28 am
Location: Jersey City
Github Username: rusefillc
Slack: Andrey B

Re: Discrete components VR decoder with zero firmware code

Post by AndreyB »

Honda OBD1 test

Attachments
2021-10-02_honda-obd1-discrete.zip
(15.6 KiB) Downloaded 202 times
Very limited telepathic abilities - please post logs & tunes where appropriate - http://rusefi.com/s/questions

Always looking for C/C++/Java/PHP developers! Please help us see https://rusefi.com/s/howtocontribute
Post Reply