tom jennings

Member Since: April 18, 2006

Country: United States

  • i concur!! wtf is with the dearth of real high-side, high power (>> 1A) drivers? it's weird. not just sparkfun.

    my favorite power driver chip is the STelectronics VN series (VN02, VN920, etc), 5 - 30 amp, CMOS logic in, 30+V, high side, inductive back EMF-eating, current-monitoring, reverse-battery protection, milliohm output, etc etc. alas, as the auto industry mutates to higher voltages and lower currents for things even these grow scarce. they drive the nastiest loads without a complaint. short-circuit proof too. i've been using the 5-pin "TO-220" packages but there's SM parts too. i keep thinking i should lay out a board for them myself. i may have to.

    a board with 8 of these (on a SR or not) would be great.

  • oh great! the 5V buss touches the metal can of the USB connector. seriously i am actually going to throw out the three i bought (GRRR) and buy one from Adafruit for $2 less, then stock up on some from (20 day ship time but $5/shield).

    it's more work to use these than to buy replacements.

  • yeah -- DO NOT BUY THIS SHIELD. it's terrible, and tbh, a bit crappy that you are still selling it after three years of complaints.

    the IO pins need to have double holes so you can actually CONNECT TO THEM. seriously, it's such an obvious thing it is hard to imagine it wasn't done in the first pass FOUR YEARS AGO. also, it's way too expensive.

    i'm buying Funduinos (MEGA 2560's, $15) and shields for $5 that are far, far better, from China. I really want to support hobbiest-friendly business, and i am willing (and do) pay more for the privilege,l but sheesh, the stuff has to work.

    all shields have some frustration or other (they're all compromises) so "only top board" and lack of cutout over USB etc dont bother me much. but the basics need to be present at least.

    sorry to gripe but this product is terrible and should be withdrawn.

  • certainly not by itself -- i think you mean, generate a sinusoidal voltage by pointing this thing at a printed pattern and having it output an analog sine wave? it's just a transistor; the output is not linear, and wildly more-or-less square-law dependent on distance to paper, paper/ink density, etc. it needs much processing.

    (btw, i ended up, of course, pitching my crap amp and installing Schmitt trigger gates and now i get sub-1% accuracy. sometimes laziness does not pay off. :)

    (lol, your idea is actually a fairly ancient technique, often called a photoformer, or function generator, to create an arbitrary waveform using an opaque mask (paper, etc) a light source and a detector, one of those being movable as a control input.)

  • thanks for the reply, i forgot to update my experience -- which is more or less as yours. i ended up with a 16 sector wheel, and a crappy 2n3904 amplifier with 10K load. Because i didn't have a schottky device in the drawer, but it needs the hysteresis. Mine's in the dark, spacing is about 3/32". I'm running the LED at recommended current (20mA; 180@5V).

  • oh, and glue that code above below this and you have a sample program that demo's it.

    const int RPINA = 6;
    const int RPINB = 7;
    void setup () {
      Serial.begin (9600);
    void loop () {
      switch (readRotEnc()) {
        case 1:  Serial.write ("+");  break;
        case -1: Serial.write ("-");  break;
  • The code to read a rotary encoder is very very simple if you look at the pattern of bits produced. Code below. The main problem with these things is the incredible amount of switch bounce; when i spin one as quick as i can i get a quadrature event every 2 - 5 mS and bouncing out past 1mS.

    While i prefer to debounce in software, in this case it's better done in hardware -- nearly all the bounce can be removed with a resistor and capacitor. 10K pullup to 5V and .1uF to ground. Don't rely on the Arduino's internal pullup.

    I hate dedicating the only two interrupt pins to the encoder, so i run this code in loop() up at the top. This may not work for you -- i NEVER use delay() in my code, only millis() and a "timer" (eg. unsigned long T) and if (millis() > T) ... for timing things, so the top of my loop() comes around multiple times a millisecond for most programs.

           a  b  c  d    e  f  g  h    i  j  k  l ...
      CW  01 00 10 11   01 00 10 11   01 00 10 11 ...
      CCW 10 00 01 11   10 00 01 11   10 00 01 11 ...

    Looking at any pair of reads (ab, bc, fg, gh, etc), adjacent bits will always be different for CW, always the same for CCW.

    The core code is this:

     /* Poll the rotary encoder; returns 1 for CW rotation, -1 for CCW,
      else 0. */
      int readRotEnc () {
      static char pR;                    // previous read; two bits, AB
      char m;                            // MS bit of current read (A)
      char R;                            // current read (two bits, AB)
      R= ((m= digitalRead (RPINA)) < < 1) | digitalRead (RPINB);
      if (R == pR) return (0);         // no change since last time
      m ^= (pR & 1);                   // m is 0 for CCW, 1 for CW
      pR= R;                           // current read is now "previous"
      return (m ? 1 : -1);

    NOTE: the website comment editor has a bug! it deletes all text following a double-less-than! which is of course the *nix input redirect. doh, it probably means this page has some serious vulnerabilities.

  • the values you are getting are within the specs in the datasheet. datasheets can be daunting, but once you get the hang of them they are a wealth of data. Most specs have a MIN, TYPICAL, MAXIMUM column. Real-world manufacturing tolerances mean that there is almost always small variations from unit to unit.

    You really can't expect any product to always be the "typical" value, that's just a seat of the pants, rule of thumb value. you really have to plan on parts being between MIN and MAX. For parts like this, that put out values that represent "change" rather than an absolute, you can't simply take the value as 'truth'. the general technique is something like read the chip repeatedly, and in a known environment (steady on a table, etc) take an average of the values and call that average "level" or "zero" or whateveryoucallit. then check for deviations from THAT, + or -, etc.

  • Sparkfun might consider adding opamp voltage followers, as the output impedance of the chip is very high, so the common use of input to the variable-impedance Arduino analog-in will cause a lot of error.

  • oh bummer -- doesn't work as a sensor for a laser-printed encoder wheel. datasheet seemed to indicate it would (Ic vs. distance) but in by-hand tests with a piece of paper, optimum distance for a black-sharpie-square-on-white-paper seemed to be about .75". it may be that my encoder wheel's marks are too small; 512 of them, 200mm diameter, so the marks are about 1/8" wide. Wheel to sensor distance is 50 - 100 mils. I'll do the physical experiments (focusing tube, 16 segments/circle, etc) but has anyone used this thing for an encoder wheel?

No public wish lists :(