Member Since: April 30, 2010

Country: United States


Spoken Languages


Programming Languages



Lego Technic and Mindstorms Robots, and electronics.


Electronics, Lego, Traxxas, HO Trains.

  • That is the distance sensor. It has a laser distance sensor in the center (along with support components), and the eyes on the sides are for fun :)

    The distance sensor can be mounted on the servo to "look" left and right.

  • I would agree, except, read the "FYI:" section above at the end of the description.

  • false equals 0.
    true equals not 0 (typically 1 is used).
    ! means not. If 'a' is true, !a is false. If 'a' is false, !a is true.
    && means and. (a && b) will only be true if both 'a' and 'b' are true.
    || means or. (a || b) will be true if 'a' and/or 'b' is true.
  • Since you listed =, it would be good to add a description for ==. For anyone who doesn't know, (a == b) will be true (or 1) if a is equal to b, otherwise it will be false (or 0). And you might as well add at least !, &&, and || (maybe also bit-wise operators). And again for anyone reading this who doesn't know, you can use these in assignments, not just for conditional statements.

    int a = 3;        // set a to 3
    int b = 10 / a;   // set b to 10 / 3 (which is 3 when using integer math)
    int c = (a == b); // c equals a==b, so since a and b are each 3, c is true or 1
  • Programming for 8, 32, and 64 bit systems, I personally prefer to use names such as "uint8_t", "int64_t", etc. so that it's clear if it's signed or unsigned, and the number of bits is consistent regardless of the CPU/compiler. Not all compilers support this naming scheme, but most C/C++ compilers seem to support it.

  • The datasheet states 32 due to the impedance of the MAX481 (it isn't an arbitrary number). In my experience with the MAX485 (almost identical) there is a lot of room for things not being perfect. RS485 is significantly over-engineered for most applications, making it extremely robust. I don't think you'll damage anything using 35 devices, but being out of spec, I wouldn't guarantee anything either.

    If you need more than 32 devices, and want to remain in spec, check out the MAX487 or the MAX1487, with similar specs, and a maximum of 128 devices (those and others are in the datasheet linked to above).

  • As plagued the previous versions, the data direction is controlled by the Tx line of the RPi, and without a capacitor. Therefore it will only transmit the zeros, not the ones. Theoretically you could add in a capacitor to maintain transmitting, but then it might hold control of the bus for too long (it would depend primarily on the baud rate, but also on the data itself).

    Unless I'm missing something in the schematic, this is a very serious issue.

    What I personally decided to do was use a separate GPIO to control the direction. It works fine, but requires software to determine when it has finished transmitting, to control the direction. I did this in C, but it should also be possible with python.

  • Honestly that was my first thought. I decided is was very unlikely though. The changing camera angles make it only occasionally visible. Furthermore, most video has been edited to be played back in a non-chronological manner, and most video has been cut (I'm assuming this is no exception). It seems unlikely for there to be a discernible message hidden.

  • In the background of these videos is that cool looking sparkfun sign with individually controlled LEDs (something like WS2812/B). It changes one LED at a time from red to white, and when it gets though it repeats, changing to red again. However, the data/buffer stream seems to be off sync with the time cycle. It should update in the order 1R 1G 1B short delay 2R 2G 2B short delay 3R 3G 3B ... short delay nR nG nB long delay (start the cycle over with the other color). However, the last LED's blue channel doesn't get updated until after the long delay (when number 1 gets updated). It ends up being in the order nB 1R 1G 1B short delay 2R 2G 2B short delay 3R 3G 3B ... short delay nR nG (nB is NOT updated yet!!!) long delay (start the cycle over with the other color, beginning with nB). It is apparent in that after going from red to white, the last LED is yellow, and when going from white to red, the last LED is purple. It doesn't seem to do it always, but fairly regularly. Does anyone ever intend to fix it?

  • As plagued the first version, this version has the RE and DE controlled by the Tx line. How is this supposed to work? I don't see a decay capacitor on the gate of Q1, so best I can tell, the MAX485 will only transmit zeroes (when tx is low), and be in receiving mode when trying to transmit ones (when tx is high).

No public wish lists :(