Dismiss Notice
Join Physics Forums Today!
The friendliest, high quality science and math community on the planet! Everyone who loves science is here!

C/++/# Reading 60-1 encoder wheel

  1. Nov 13, 2016 #1
    I am at a bit of a loss at how to deal with the logic of a 60-1 or 60-2 (60 tooth wheel missing 1 or 2 teeth as an indicator of position) read by a VR sensor.
    I'm currently employing an Arduino, though later I may change platform..

    I can have the sensor on an interrupt, but how do I detect the missing teeth? How would I trigger an event based on this?
     
  2. jcsd
  3. Nov 14, 2016 #2
    If the wheel spins at a constant rate, then you can use this information to your advantage (im assuming VR sensor means variable reluctance sensor, which i just looked up on wikipedia). If there is no steady state (wheel can spin at vastly different rates at any moment), then I'm not sure how to help you (somebody better at math probably would be of more use). You can record the time between teeth being detected between the interrupts (current time - time recorded by last interrupt stored in some shared variable). Most of the time you'll get the same time (+ or - any error in the recording of the times), but when the gap comes, the time between interrupts will be greater than usual (2 or 3 time depending on the number of teeth missing, + or - any error). Once you detect a big gap in time, then you can act on it. When you say trigger an even based on this, what do you mean? This requires more context, ie. programming language, goal, etc.
     
  4. Nov 14, 2016 #3
    The goal is to be able to control an output for ignition coils and fuel injectors.. programming would be in C, though at the stage I'm at, language isn't what I'm concerned with but rather the logic of it.

    Yes, the wheel will travel at different speeds as engine speed changes, and there could even be significant harmonic components to it, though the only way to know if they're relevant would be through testing...

    For ignition control, a 60 tooth wheel provides 6* per tooth, but the timing should be done to better than 1*... Injector control is usually time based... A lot of the details would have to be worked out by poring over the processor datasheet.. little steps at a time though
     
  5. Nov 14, 2016 #4

    Nidum

    User Avatar
    Science Advisor
    Gold Member

    You need another detection channel to reliably find the home position of the count wheel .

    One channel will just see your gap with the missing teeth as one ordinary count and in one complete rev the total count would be 58 . There would be errors in angular location , no detection of the home position and a cumulative error in the number of complete revs recorded .

    Leave the count wheel intact with the 60 teeth .

    Use a second wheel with one slot or a single hole in the main wheel and another detector to give the home position .
     
    Last edited: Nov 14, 2016
  6. Nov 14, 2016 #5

    Nidum

    User Avatar
    Science Advisor
    Gold Member

    You could use a wheel with the 60 teeth intact and two quadrature detectors for the actual count . This would improve resolution by a factor of four - ie from 60 to 240 counts/rev .

    Optionally use a count wheel with a lesser or more appropriate number of teeth .

    Home position detection needs to have the same resolution as the main count resolution .
     
  7. Nov 14, 2016 #6

    Nidum

    User Avatar
    Science Advisor
    Gold Member

    Just for interest - higher resolution can be obtained from simple teeth counting systems by analysing the detector signal waveform . This method is used in some types of DRO system with linear scales .
     
  8. Nov 14, 2016 #7
    @Nidium, I use 60-1 or 60-2 wheels because that's what the particular engine comes with and I don't have much say in that matter, and somehow the OEM's make it work just fine. I didn't really mention that before
    Good idea about analyzing the waveform.. though it may be challenging to get it done with limited processing power.. If the pickup is a hall effect it would be impossible
    Thanks for the ideas, definitely something for me to mull over through the day
     
  9. Nov 14, 2016 #8

    Nidum

    User Avatar
    Science Advisor
    Gold Member

    Ok. They could be doing something rather cruder than I envisaged .

    With one detector and a wheel with a section of missing teeth a pulse train can be generated . At any particular engine speed this pulse train is uniform except that it has a gap in it in one place . The pulses give you the average speed and the gap gives you the home position .

    Several different ways of doing the computations but basically :

    Calculate the time for one complete rev of pulses to get the speed . Count 59 or 58 pulses starting anywhere .

    Calculate the time for each successive pulse and test whether the current pulse is significantly longer than the previous one . A longer pulse gives you the home position .
     
  10. Nov 14, 2016 #9
    Yeah, that's the way I figure it, the tooth after the missing teeth is probably the home position, and I would guess it's well before any events need to occur

    a 60 tooth wheel at 6000 RPM is 6000 pulses per second.. I've taken apart some old ECM's and looked up the processor capabilities, they can do it on 8mhz and 8 bits, so an arduino (16mhz) should have no problem as long as attention is paid to performance. I am thinking of using an Arduino Due (84mhz 32bit) just because I'm not an expert optimizer.
     
Know someone interested in this topic? Share this thread via Reddit, Google+, Twitter, or Facebook

Have something to add?
Draft saved Draft deleted



Similar Discussions: Reading 60-1 encoder wheel
  1. Huffman encoding (Replies: 1)

Loading...