Member Since: April 30, 2010

Country: United States


Spoken Languages


Programming Languages



Lego Technic and Mindstorms Robots, and electronics.


Electronics, Lego, Traxxas, HO Trains.

  • 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).

  • What is the event date?

  • (*edit: what DonW said)

  • Yes it is in Sparkfun’s Eagle library. Note the small eagle icon to the right of the product number, just below the title.

  • A large majority of NXT I2C sensors use address 0x02. If all the sensor ports shared the same I2C bus, you would be very limited in the number of I2C sensors you could use. Some of the analog sensors use the “I2C” pins (5 and 6) as signal pins (e.g. to control the LED on the NXT light sensor). The NXT color sensor uses a custom communication protocol (that mixes analog and digital on pins 5 and 6).

  • Because the bus can only be driven low, the pullups determine the bus voltage. As long as you use pullups to 3v3 (and you don’t have any other pullups on the bus to a higher voltage), it is safe to use with a 5v Arduino.

No public wish lists :(