Possible option for generating VR sensor signals

Hardware inside and outside of the ECU
Post Reply
User avatar
abecedarian
Posts: 386
Joined: Fri Nov 15, 2013 10:49 am

Re: stimulator board

Post by abecedarian »

I've been holding out but want to chime in with my idea for simulating VR sensors.

Since RPM's will vary from around 200 to up to 20000, I did some calculations at the extremes. At 200 RPM with a 4 tooth trigger, that works out to 13.3 signals per second (13.3Hz). At 20000 RPM with a 60 tooth trigger, that works out to 20000 signals per second (20KHz). Both extremes are arguably within the definition of 'sound' frequencies, so why not use an audio frequency generation method to generate the signals?

Using an MCU timer with appropriate abilities, a square wave of 50% duty cycle can be generated covering everything between those extremes. Feed the output from that into a low-pass filter in order to give it more analog-like traits- more sine wave than square for instance. Take that output and feed it into the reference voltage of a rail-to-rail DAC (MCP4922 comes to mind), and now you can control the amplitude as well as frequency, albeit within the amplitude of the source, i.e. 3v3 or 5v0 depending on the MCU. Take the output from the DAC and feed that into a programmable gain amplifier, Linear has a few with gain ranges from 0 to 100V/V gain, and feed that output into a suitable audio transformer. Now you could theoretically generate a signal with a frequency and amplitude of your choosing, and no worries about common grounds as the transformer will effectively isolate your circuit from the ECU.

A similar technique for the camshaft triggers could also be used.

Then, there'd be no need for using an RS232 interface chip to generate voltages, and you could, with some programming, actually have the VR output increase in frequency while increasing the amplitude as well, just as an actual VR sensor would.

I've actually got an MSP430F5529 simulating up to 12000 RPM with a 36 tooth wheel while simultaneously outputting to a serial terminal and IIC/I2C LCD. What's missing is missing tooth (pun intended) decoding, and actually building the circuit- waiting for parts to arrive.

I'd like to hear everyone's opinion of this.
You can lead the horticulture but you can't make them think.
User avatar
kb1gtt
contributor
contributor
Posts: 3758
Joined: Tue Sep 10, 2013 1:42 am
Location: ME of USA

Re: stimulator board

Post by kb1gtt »

Keep in mind that 20k pluses per second will probably need around 100KHz bandwidth to generate the signal. At min you'll need 40kHz for Nyquist, however you really need more for good reproduction and anti-aliasing of the signal.
Welcome to the friendlier side of internet crazy :)
User avatar
abecedarian
Posts: 386
Joined: Fri Nov 15, 2013 10:49 am

Re: stimulator board

Post by abecedarian »

kb1gtt wrote:Keep in mind that 20k pluses per second will probably need around 100KHz bandwidth to generate the signal. At min you'll need 40kHz for Nyquist, however you really need more for good reproduction and anti-aliasing of the signal.
Okay, I'm not as well educated as yourself. So care to elaborate?

The MCP4922 has 400-450 KHz bandwidth on it's reference input with Vref @ 2.5v, and a settling time of ~2.5uS.

The PGA I was looking at had > 200 MHz gain bandwidth, if I remember correctly.


*edit to add PGA info.
You can lead the horticulture but you can't make them think.
User avatar
kb1gtt
contributor
contributor
Posts: 3758
Joined: Tue Sep 10, 2013 1:42 am
Location: ME of USA

Re: stimulator board

Post by kb1gtt »

The bandwidth of those components should work. The circuit would likely need some low pass filters to prevent aliasing / fold back. Here's an article that explains it in terms of sampling. http://www.sandv.com/downloads/0212wela.pdf Many of the concepts apply to signal generation as well as sampling. I would wager a guess you've had to deal with that for cell towers. So perhaps I'm not understanding the question. The big thing I was point out was that it's not 20kHz, it's 20k pulses/S, which needs around 100kHz of bandwidth to generate a signal that looks at least kind of like a VR signal.
Welcome to the friendlier side of internet crazy :)
User avatar
abecedarian
Posts: 386
Joined: Fri Nov 15, 2013 10:49 am

Re: stimulator board

Post by abecedarian »

Good info, Jared.

So basically, the concept is 'sound' (pun intended), but more thought needs to go into the conversion from the digital to analog domain, correct?

I did mention using low-pass filter on the output from the MCU. Perhaps this would be better off moved to after the PGA output and ahead of transformer? My thought being there is going to be some slew involved so that itself will do some 'rounding' off the edges of the square wave from the MCU, and the transformer will similarly round off the edges due to its properties.
You can lead the horticulture but you can't make them think.
User avatar
kb1gtt
contributor
contributor
Posts: 3758
Joined: Tue Sep 10, 2013 1:42 am
Location: ME of USA

Re: stimulator board

Post by kb1gtt »

I haven't looked into the chip details, but I think you have a sound choice of chips. Why would we need the PGA, why not just make the DAC with a smaller signal? Perhaps you were thinking of clocking a square wave into the DAC SPI. If so I think you would go to 50% scale and stay there. I think I'm missing something here. Well I know I'm missing something, I mean I think I'm missing something in the concept of your design.

I expect you'll want a min of about 100kHz bandwidth, the DAC is capable 400kHz. At 100kHz, you need something like 10 bits per DAC output, so you need a SPI capable of around 1MHz to 10MHz, which is fed a number once every .000,01 seconds. If you have the PGA you'll want a low pass just to prevent noise and high end ringing after the DAC and before the PGA, as well you would probably want one on the output as well. The output of the PGA would probably be a bit excessive.

As an example, and I know this is NOT what you suggested. If you had a 30kHz bandwidth on the PGA after the DAC, then the DAC generates some signal at say 40kHz, it would likely show up on the output as 20kHz. This is caused by fold back. The signal above 30kHz folds back around 30kHz and what would be above 30kHz, is seen folded back under the 30kHz. So 40kHz - 30kHz = 10kHz. Then to find where it folds back to, you take 30kHz - 10kHz = 20kHz. Also it's common that a DAC will have digital components that leak through. So it's common there will be noise from the DAC that is above the DAC's bandwidth. Which makes it common to need a low pass filter just to clean it up a bit.

Also this can't be done with a sound card. Hmm what could be expected from a sound card? I'd bet you can get 3kRPM to 6kRPM with most wheel patterns. However I haven't bothered to the do calcs.
Welcome to the friendlier side of internet crazy :)
User avatar
abecedarian
Posts: 386
Joined: Fri Nov 15, 2013 10:49 am

Re: stimulator board

Post by abecedarian »

Yeah, you're missing something. ;)

The DAC reference voltage establishes the range over which the DAC voltage output can appear. So with a 12 bit DAC and the output set to "4095", the DAC outputs the reference voltage, in this case 3v3. If the reference voltage was 1/2 3v3, or 1.65v, and the DAC was programmed to full scale, its output would be 1.65v. If the DAC were programmed to 1/2 scale, i.e. with "2047", with a 3v3 reference, the output would be 1/2 3v3, or 1.65v, and with a reference of 1.65v the output would be 0.825.

For S&Giggles... here's the code I'm using (Serial and LCD removed):
(60 teeth glitches somewhere above 15000 RPM equivalence)

Code: Select all

// Using TI MSP430F5529 launchpad at the moment; may migrate to TM4C in the future so the following
// pin assignments will likely change, as well they should change if using an Arduino or similar board

#define crankTrigger 12            // LP pin to output crank trigger signal
#define camTrigger 39              // LP pin to output camshaft trigger signal
#define tachOut 40                 // LP pin to output tachometer signal <= non-essential to operation

uint8_t crankToothCount = 0;       // counts number of tooth signals generated, rolls to 0 after 2 * number of crank teeth
uint8_t numberOfCrankTeeth = 36;   // number of crank trigger teeth, influences cam and tach-out triggers
uint8_t numberOfCamTeeth = 1;      // number of cam trigger teeth, used to generate cam output signals
uint16_t revPerSecond = 1;         // this * numberOfCrankTeeth determines the number of tooth events per second
uint32_t toothFreq = 0;            // number of tooth events to generate per second <- will probably remove this later

void crank() {
  // trigger cam event when the tooth count divided by number of teeth results in 0 remainder
  digitalWrite(camTrigger, (crankToothCount % ((numberOfCrankTeeth * 2) / numberOfCamTeeth)) == 0);
  // trigger tach event when the tooth count divided by number of teeth results in 0 remainder
  digitalWrite(tachOut, (crankToothCount % numberOfCrankTeeth) == 0);
  if (crankToothCount++ == numberOfCrankTeeth * 2) crankToothCount = 0;
}

void setup()
{
  // Set up pins and default states, configure interrupt for generating cam / tach events
  pinMode(crankTrigger, OUTPUT);
  digitalWrite(crankTrigger, LOW);
  pinMode(tachOut, OUTPUT);
  digitalWrite(tachOut, LOW);
  pinMode(camTrigger, OUTPUT);
  digitalWrite(camTrigger, LOW);
  attachInterrupt(crankTrigger, crank, FALLING); // 

  // initial tooth frequency calculation
  toothFreq = revPerSecond * numberOfCrankTeeth;

  // Start crank trigger output on 'crankTrigger' pin
  // signal is a 50% duty square wave output at the specified frequency in Hertz
  tone(crankTrigger, toothFreq);
  // note- this uses the 'tone' function because:
  // a) it's easy- the framework sets up the timer and toggles the output automatically
  // b) all the signals to be generated can be represented within the range of human hearing

  for (revPerSecond=0; revPerSecond < 320; revPerSecond++) {
    // calculate the frequency of tooth events based on revolutions per second
    toothFreq = numberOfCrankTeeth * revPerSecond;
    // I chose this method instead of converting RPM to RPS to keep division and floats out of the MCU
    // note: 320 RPS = 19200 RPM = 19840 teeth per second

    tone(crankTrigger, toothFreq);  // set crank output frequency to tooth frequency calculated above
    delay(2);
  }
  tone(crankTrigger, numberOfCrankTeeth * 2); // set crank output frequency to equivalent of 1 RPM
}

void loop()
{  
}
Do note that once setup() has run through, nothing else is running and everything keeps going off in interrupt land. ;)
So any change to the 'crankTrigger' frequency via the tone() function within loop() affects the cam and tach outputs automagically.
You can lead the horticulture but you can't make them think.
User avatar
kb1gtt
contributor
contributor
Posts: 3758
Joined: Tue Sep 10, 2013 1:42 am
Location: ME of USA

Re: stimulator board

Post by kb1gtt »

I still don't follow. I expect you'll need a stream of numbers, but I think you are saying you are using a single digital 1 or 0 as your VR signal. Lets ignore differential + and - outputs. I haven't looked, but I think that's why you had the PGA. Also lets assume you have a virtual ground at 1.5V and DAC value 0 is 0V and 2047 = 3V. I would expect the steam to be something similar to this.

1024, 1024, 2047, 1700, 1300, 1100, 1024, 1024, 1024, 0, 300, 700, 900, 1024, 1024,

That's a steep spike to + rail with a decay back to virtual ground, then a steep spike to - rail with a decay to virtual ground. At fast RPM the decays make it look like a sine wave. At slow RPM you'll see something like what I describe above. I'm not seeing how you're generating a signal like that. Can you setup a piece of memory that DMA's to the SPI in a circular buffer topology? Or are you smashing it out with CPU cycles? Perhaps I'm still not grasping a core concept, or perhaps you are expecting the output signal to look differently than described above.
Welcome to the friendlier side of internet crazy :)
User avatar
abecedarian
Posts: 386
Joined: Fri Nov 15, 2013 10:49 am

Re: stimulator board

Post by abecedarian »

A) I don't have a virtual ground so no assumption to be made.
B) There is no digital stream involved.
C) The only data sent by the MCU is changing the DAC output:
- - - put DAC at FFF output and its output is equal to Vref.
- - - put DAC at 7FF output and its output is equal to Vref / 2.
- - - put DAC at 3FF output and its output is equal to Vref / 4.
- - - put DAC at 000 output and its output is 0v regardless of Vref.


So, what are you having problems following?

And don't make me go into decoding a PCM file for audio output.
You can lead the horticulture but you can't make them think.
User avatar
kb1gtt
contributor
contributor
Posts: 3758
Joined: Tue Sep 10, 2013 1:42 am
Location: ME of USA

Re: stimulator board

Post by kb1gtt »

How are you changing the DAC with out a digital stream? Can you perhaps draw a rough block diagram or something?
Welcome to the friendlier side of internet crazy :)
User avatar
abecedarian
Posts: 386
Joined: Fri Nov 15, 2013 10:49 am

Re: stimulator board

Post by abecedarian »

VR_Emu.png
VR_Emu.png (12.15 KiB) Viewed 21363 times
*note- the PGA is not included here. It would go between the DAC and the transformers, in the final design schematic.
R1/C1 and R2/C2 are rudimentary low-pass filters- note I didn't give them any particular values.

The only 'data stream' would be the MCU changing the DAC's output level, thus affecting the amplitude. The MCU could command the DAC to 100% output and thus cause CRANK_OUT and/or CAM_OUT to full scale. This means that whatever voltage is present on the DAC's reference is passed through to the output. If the DAC were commanded to 50% output, i.e. by sending it "2047", the DAC would output whatever is on the references, divided by 2.

So, by modulating the reference voltage, changing the amplitude of the output is possible.

Since it's a dual DAC, affecting the CRANK and CAM signals independently is possible as well.
You can lead the horticulture but you can't make them think.
User avatar
abecedarian
Posts: 386
Joined: Fri Nov 15, 2013 10:49 am

Re: Possible option for generating VR sensor signals

Post by abecedarian »

To expand a bit....

The MCU is generating a square wave with 50% duty at some frequency.

The DAC would be controlled by the MCU such that at lower frequencies, the DAC output would be limited to some level, i.e. 5%, thus causing the DAC to output 0-0.16 volts. As the frequency increases, the DAC output would be increased incrementally so that at some frequency the DAC would be at full output, or allowing 3v3 out. To get beyond this voltage, the MCU would increase the PGA's output to 2x or 4x for instance, and then simultaneously drop the DAC output to 1/2 to 1/4 the original level. This would continue on, raising the PGA gain and dropping the DAC output level as necessary in order to provide a somewhat smooth output from low RPM simulation with low output voltage to high RPM with a commensurate increase in voltage.

The actual values written to the DAC and PGA could possibly be stored in an array, correlated to RPM equivalence such that for any given RPM, the DAC and PGA values to be sent to them is known in advance. The MSP430F5529 mentioned earlier has 128KB flash so could provide sufficient storage to accommodate this.

Now, we're left with simulating the MAP, TPS and temperature sensors. The former two could be simulated easily with voltage-output DACs, like the MCP4922 mentioned already. The latter would probably be best served as digital potentiometers, though it's possible that DAC's such as what's already been mentioned could be called in for this purpose, provided the ECU is the source of the reference output voltage for the DAC's and the MCU is programmed appropriately.
You can lead the horticulture but you can't make them think.
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: Possible option for generating VR sensor signals

Post by AndreyB »

One way or another we would need a synchronization point - either it would be the skipped tooth in the 60/2 case or a separate signal on a separate line in case of 1+4+24 Honda. How would this be implemented with the proposed approach?
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
User avatar
kb1gtt
contributor
contributor
Posts: 3758
Joined: Tue Sep 10, 2013 1:42 am
Location: ME of USA

Re: Possible option for generating VR sensor signals

Post by kb1gtt »

Ah, I see it now. Thanks for the schematic, that really helps fill in the concept.
Welcome to the friendlier side of internet crazy :)
User avatar
rus084
contributor
contributor
Posts: 678
Joined: Sun Dec 01, 2013 1:40 pm
Location: Russia , Stavropol

Re: Possible option for generating VR sensor signals

Post by rus084 »

it can generate only "ideal" VR signals ?
User avatar
abecedarian
Posts: 386
Joined: Fri Nov 15, 2013 10:49 am

Re: Possible option for generating VR sensor signals

Post by abecedarian »

russian wrote:One way or another we would need a synchronization point - either it would be the skipped tooth in the 60/2 case or a separate signal on a separate line in case of 1+4+24 Honda. How would this be implemented with the proposed approach?
I'm working on that at the moment. Have the basic algorithm worked out but am still working on getting the crank VR output to properly transition from high to low.
kb1gtt wrote:Ah, I see it now. Thanks for the schematic, that really helps fill in the concept.
So makes sense and could be viable?
rus084 wrote:it can generate only "ideal" VR signals ?
By "ideal" if you mean a relatively symmetrical sine wave, excepting for missing teeth, it hopefully would do that. So therefore, if you needed say 24 narrow pulses, you should be able define the total teeth as 48, then make alternating teeth 'missing' so no output would be generated.
You can lead the horticulture but you can't make them think.
User avatar
abecedarian
Posts: 386
Joined: Fri Nov 15, 2013 10:49 am

Re: Possible option for generating VR sensor signals

Post by abecedarian »

Code reworked a bit:
Serial / LCD bits removed.
CAM trigger can be set with an offset to correspond with a particular crank tooth.
Incorporated one idea I had for trigger tooth pattern generation- see 'triggerPattern' variable below.

If anyone has a similar TI launchpad with Energia, or an Arduino, and an oscilloscope, feel free to check for jitter / missed signals.
I'm lacking a scope at the moment so can't verify beyond what some blinking LED's can convey.

Code: Select all

#define triggerReference 12        // Crank trigger reference output- other outputs derive from this
#define crankTrigger 40            // pin to output crank trigger signal on
#define camTrigger 39              // pin to output camshaft trigger signal on
#define tachOut 38                 // pin to output tachometer signal on <= non-essential to operation
// current hardware is MSP430F5529 Launchpad from TI. change the pins if using different hardware


// Crank trigger wheel definition:
// tooth pattern starts with the first value and continues on
// each value represents a tooth: 0 = missing, 1 = present
// 64 'teeth' are allocated because I'm lazy. ;)
// numberOfCrankTeeth variable below will allow you
// to limit the number of teeth actually synthesized.
volatile byte triggerPattern[] = {
  0,0,1,1,1,1,1,1,
  1,1,1,1,1,1,1,1,
  1,1,1,1,1,1,1,1,
  1,1,1,1,1,1,1,1,
  0,0,1,1,1,1,1,1,
  1,1,1,1,1,1,1,1,
  1,1,1,1,1,1,1,1,
  1,1,1,1,1,1,1,1
}; 


// Working variables:
volatile uint8_t numberOfCrankTeeth = 60;   // number of crank trigger teeth, influences cam and tach-out triggers
volatile uint8_t numberOfCamTeeth = 1;      // number of cam trigger teeth, used to generate cam output signals
volatile uint8_t crankToothCount = 0;       // counts number of tooth signals generated, rolls to 0 after 2 * count
volatile uint32_t toothFreq = 0;            // number of tooth events to generate per second <- will probably remove this later
volatile uint16_t revPerSecond = 20;         // this with numberOfCrankTeeth determines the number of tooth events per second
volatile uint8_t camTriggerOffset = 0;      // set this equal to the crank tooth (minus one) the cam would trigger with

uint8_t crankTriggerState = 0;              // used to toggle the generated crank signal output
uint8_t camTriggerState = 0;                // used to toggle the generated cam signal output

void crank() {
  // triger crank event on rising edge of the synthetic signal generator
  // turn it off on the falling edge of the synthetic signal generator pulse
  // i.e. on startup "crankTriggerState" is '0' thus the crank trigger is off
  // i.e. with each transition of the trigger, crankTriggerState inverts, thus
  // goes from 0 to 1 to 0 to 1 ... et cetera.
  digitalWrite(crankTrigger, triggerPattern[crankToothCount] && crankTriggerState);
  crankTriggerState = !crankTriggerState;

  // trigger cam event every second revolution; 
  digitalWrite(camTrigger, camTriggerState && (crankToothCount == camTriggerOffset));

  // trigger tach event when the tooth count divided by number of teeth results in 0 remainder
  digitalWrite(tachOut, (crankToothCount % numberOfCrankTeeth) == 0);

  // increment the crankToothCount based on the value of crankTriggerState so that
  // it increments by one every other trip into this ISR, and roll it back to 0
  // when after the total teeth have been counted: count starts at 0 so it rolls over
  // when it equals the number of teeth.
  // also toggle cam trigger state
  if ((crankToothCount += crankTriggerState) == (numberOfCrankTeeth)) {
    crankToothCount = 0;
    camTriggerState = !camTriggerState;
  }
}

void setup()
{
  // Set up pins and default states, configure interrupt for generating cam / tach events
  pinMode(triggerReference, OUTPUT);
  digitalWrite(triggerReference,LOW);
  pinMode(crankTrigger, OUTPUT);
  digitalWrite(crankTrigger, HIGH);
  pinMode(camTrigger, OUTPUT);
  digitalWrite(camTrigger, LOW);
  pinMode(tachOut, OUTPUT);
  digitalWrite(tachOut, LOW);
  attachInterrupt(triggerReference, crank, CHANGE);
}

void loop()
{  
  for (revPerSecond = 1; revPerSecond < 180; revPerSecond += 5) {
  toothFreq = revPerSecond * numberOfCrankTeeth;

  // Start trigger reference output; signal is a 50% duty
  // square wave output at the specified frequency in Hertz
  tone(triggerReference, toothFreq);
  delay(100);
  }
  revPerSecond = 5;
  tone(triggerReference, revPerSecond * numberOfCrankTeeth); // go to 5 RPS
  while(1); // and enter infinite loop.
}
Last edited by abecedarian on Wed Sep 10, 2014 3:43 am, edited 1 time in total.
You can lead the horticulture but you can't make them think.
User avatar
abecedarian
Posts: 386
Joined: Fri Nov 15, 2013 10:49 am

Re: Possible option for generating VR sensor signals

Post by abecedarian »

There are still some issues to work out with the code. I'll leave it up though, for anyone to look over and maybe suggest fixes.
You can lead the horticulture but you can't make them think.
User avatar
kb1gtt
contributor
contributor
Posts: 3758
Joined: Tue Sep 10, 2013 1:42 am
Location: ME of USA

Re: Possible option for generating VR sensor signals

Post by kb1gtt »

Hmmm, you are providing a variable voltage to the DAC, the DAC is driving a potentially significant load. Those low cost RC DAC's often don't play nice with a variable impedance. Is the DAC going to be a variable impedance? If so you might find that PWM = blah and voltage = blah. Then the voltage might = blah at blah RPM, but will = a different blah at a different RPM.

Might be worth while to plan for some snubbing diodes across the inputs and outputs of the TR1. I'm not sure if you'll need them, but better safe than sorry. Probably good to have some pads if they are needed.
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: Possible option for generating VR sensor signals

Post by kb1gtt »

Often those RC DAC's are followed by an voltage follower op-amp. The op-amp can drive several mA of current and they keep a consistent impedance to the RC DAC.
Welcome to the friendlier side of internet crazy :)
Sudo
Posts: 92
Joined: Mon Mar 17, 2014 12:53 am

Re: Possible option for generating VR sensor signals

Post by Sudo »

In reality you will not find a non symmetrical high count wheel. You only see that with 1-4 ish, in that range. They are not only harder to manufacture, they provide no real advantage at higher speed. Its just not practical especially for automotive application. I'd be damned if you can find a non symmetrical 24 teeth wheel in used somewhere. Odds would be similar to winning the lottery.
User avatar
abecedarian
Posts: 386
Joined: Fri Nov 15, 2013 10:49 am

Re: Possible option for generating VR sensor signals

Post by abecedarian »

kb1gtt wrote:Often those RC DAC's are followed by an voltage follower op-amp. The op-amp can drive several mA of current and they keep a consistent impedance to the RC DAC.
Not sure how relevant this is to your statement but the MCP4922 can source ~10mA per output. Also, there would be a PGA between the DAC and the transformer, which would likely address this concern as well.
Sudo wrote:In reality you will not find a non symmetrical high count wheel. You only see that with 1-4 ish, in that range. They are not only harder to manufacture, they provide no real advantage at higher speed. Its just not practical especially for automotive application. I'd be damned if you can find a non symmetrical 24 teeth wheel in used somewhere. Odds would be similar to winning the lottery.
I'd hate to write the algorithm for this: GM LS3, 24 tooth-
Image
Image
You can lead the horticulture but you can't make them think.
Sudo
Posts: 92
Joined: Mon Mar 17, 2014 12:53 am

Re: Possible option for generating VR sensor signals

Post by Sudo »

Technically that's a symmetrical wheel that have different zones. Not any different from missing tooth. That's not the non-symmetry I was referring to, like the 1 tooth wheel you showed in the previous thread where it will product no symetrical signal. This wheel one will actually produce a symmetrical but varying signal.

But yea, there is the reason why people swap this complex wheel out to the 58 teeth version.
Image
Kavabanga
Posts: 66
Joined: Sat Apr 13, 2019 9:07 pm

Re: Possible option for generating VR sensor signals

Post by Kavabanga »

I play with an MCP4922 just for fun. If we just put one gate of a DAC to transformer, the gate will be shorted to GND and we'll se nothing on the secondary coil of transformer. But if we put a capacitor between the transformer and the DAC, everything will great (we'll receive a signal on the secondary coil). But we'll have a good signal on some frequences only. On other frequences a signal will be damaged like this
Attachments
tr.jpg
tr.jpg (10.35 KiB) Viewed 13006 times
puff
contributor
contributor
Posts: 2961
Joined: Mon Nov 11, 2013 11:28 am
Location: Moskau

Re: Possible option for generating VR sensor signals

Post by puff »

Something like ADAU1701 is yet another option :D
+ not sure if there is enough speed in mcu, but probably mcu's DAC itself can be used to generate arbitrary form signal..
Post Reply