Discrete components VR decoder with zero firmware code
- AndreyB
- Site Admin
- Posts: 14373
- 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
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
Always looking for C/C++/Java/PHP developers! Please help us see https://rusefi.com/s/howtocontribute
-
- running engine in first post
- Posts: 1495
- Joined: Mon Jan 30, 2017 2:05 am
- Location: Seattle-ish
Re: Discrete components VR decoder with zero firmware code
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.
Fast iteration is great, so long as you actually learn something each iteration and can quantify that learning.
Re: Discrete components VR decoder with zero firmware code
There is no simulation of the complete circuit, it will be done for real. (in approx 20days )
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.
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.
-
- running engine in first post
- Posts: 1495
- Joined: Mon Jan 30, 2017 2:05 am
- Location: Seattle-ish
Re: Discrete components VR decoder with zero firmware code
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.Gepro wrote: ↑Sat Jan 02, 2021 10:38 amThere is no simulation of the complete circuit, it will be done for real. (in approx 20days )
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.
-
- running engine in first post
- Posts: 1495
- Joined: Mon Jan 30, 2017 2:05 am
- Location: Seattle-ish
Re: Discrete components VR decoder with zero firmware code
Also why are you using two halves of two MCP6002? Why not use both halves of a single...?
Re: Discrete components VR decoder with zero firmware code
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.
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
-
- running engine in first post
- Posts: 1495
- Joined: Mon Jan 30, 2017 2:05 am
- Location: Seattle-ish
Re: Discrete components VR decoder with zero firmware code
It already has a pwm/dac adjustable threshold.kb1gtt wrote: ↑Sat Jan 02, 2021 11:47 amPerhaps 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'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.
Re: Discrete components VR decoder with zero firmware code
PWM / DAC should be before the opamp.
Welcome to the friendlier side of internet crazy
Re: Discrete components VR decoder with zero firmware code
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 ? 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.
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.
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 ? 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.
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.
-
- running engine in first post
- Posts: 1495
- Joined: Mon Jan 30, 2017 2:05 am
- Location: Seattle-ish
Re: Discrete components VR decoder with zero firmware code
yes, gepro is right, he's trying to move ONLY the rising threshold, not the falling, and not the vmid offset
-
- running engine in first post
- Posts: 1495
- Joined: Mon Jan 30, 2017 2:05 am
- Location: Seattle-ish
Re: Discrete components VR decoder with zero firmware code
why are R17/19/20/21 47k instead of 100k to match the input resistors?
Re: Discrete components VR decoder with zero firmware code
It was a test for reducing the gain and work with more voltage input, but with the SRV05 it is certainly a bad thing
It allows less distortion to the output of the opamp, but it is probably a mistake.
Thanks, for the question
PS : in fact, the resistance and PWM values had to be divided by 2 :/ :/ 100K everywhere for the next board
It allows less distortion to the output of the opamp, but it is probably a mistake.
Thanks, for the question
PS : in fact, the resistance and PWM values had to be divided by 2 :/ :/ 100K everywhere for the next board
Last edited by Gepro on Sun Jan 03, 2021 10:29 am, edited 1 time in total.
-
- running engine in first post
- Posts: 1495
- Joined: Mon Jan 30, 2017 2:05 am
- Location: Seattle-ish
Re: Discrete components VR decoder with zero firmware code
got it - so probably switch those four to be 100k to match.
Next question: does this actually do what you want it to?
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).
Re: Discrete components VR decoder with zero firmware code
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.
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.
-
- running engine in first post
- Posts: 1495
- Joined: Mon Jan 30, 2017 2:05 am
- Location: Seattle-ish
Re: Discrete components VR decoder with zero firmware code
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.
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.
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.
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.
-
- running engine in first post
- Posts: 1495
- Joined: Mon Jan 30, 2017 2:05 am
- Location: Seattle-ish
Re: Discrete components VR decoder with zero firmware code
Ok, the above design is back from JLC and some initial testing is done!
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
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:
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).
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
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:
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).
Re: Discrete components VR decoder with zero firmware code
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 : (no signal)
With 100% PWM signal : (the threshold is 0V, so a lot of noise)
With 95% PWM signal : <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.
(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)
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 : (no signal)
With 100% PWM signal : (the threshold is 0V, so a lot of noise)
With 95% PWM signal : <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.
(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)
-
- 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
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.
-
- running engine in first post
- Posts: 1495
- Joined: Mon Jan 30, 2017 2:05 am
- Location: Seattle-ish
Re: Discrete components VR decoder with zero firmware code
Ok, I dead-bugged in a quad NOR chip (to fix the wrong quad NAND chip), and it works!
Look at that, almost as much noise as there is signal, and a perfectly clean output!
Here's a zoomed in view with somewhat less noise injected:
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.
Look at that, almost as much noise as there is signal, and a perfectly clean output!
Here's a zoomed in view with somewhat less noise injected:
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.
- AndreyB
- Site Admin
- Posts: 14373
- 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
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
Always looking for C/C++/Java/PHP developers! Please help us see https://rusefi.com/s/howtocontribute
Re: Discrete components VR decoder with zero firmware code
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?
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).
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.
@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?
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).
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.
Re: Discrete components VR decoder with zero firmware code
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.
-- 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
Re: Discrete components VR decoder with zero firmware code
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 281 times
-
- VR_inductor_reference_picture.PNG (46.96 KiB) Viewed 25355 times
Welcome to the friendlier side of internet crazy
Re: Discrete components VR decoder with zero firmware code
This rough simulation includes a pinch of noise.
- Attachments
-
- VR_inductor_reference_With_noise.PNG (33.86 KiB) Viewed 25355 times
-
- VR_inductor_reference_With_noise.7z
- (755 Bytes) Downloaded 304 times
Welcome to the friendlier side of internet crazy
-
- running engine in first post
- Posts: 1495
- Joined: Mon Jan 30, 2017 2:05 am
- Location: Seattle-ish
Re: Discrete components VR decoder with zero firmware code
That's the point of open source
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@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 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.
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.type111 wrote: ↑Wed Feb 17, 2021 8:36 amHere'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.
Like this:
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!
- AndreyB
- Site Admin
- Posts: 14373
- 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
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
Always looking for C/C++/Java/PHP developers! Please help us see https://rusefi.com/s/howtocontribute
-
- running engine in first post
- Posts: 1495
- Joined: Mon Jan 30, 2017 2:05 am
- Location: Seattle-ish
Re: Discrete components VR decoder with zero firmware code
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.
- AndreyB
- Site Admin
- Posts: 14373
- 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
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
Always looking for C/C++/Java/PHP developers! Please help us see https://rusefi.com/s/howtocontribute
-
- running engine in first post
- Posts: 1495
- Joined: Mon Jan 30, 2017 2:05 am
- Location: Seattle-ish
Re: Discrete components VR decoder with zero firmware code
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.
- AndreyB
- Site Admin
- Posts: 14373
- 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
Honda OBD1 test
- Attachments
-
- 2021-10-02_honda-obd1-discrete.zip
- (15.6 KiB) Downloaded 232 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
Always looking for C/C++/Java/PHP developers! Please help us see https://rusefi.com/s/howtocontribute