Member Since: April 6, 2010

Country: United States



  • I'm trying to understand the schematic. Can anyone point me to a data sheet for U4, which the schematic says is an LT1651? My search skills have come up short.

  • If you're trying to seal something that's not flat, you might consider a vacuum sealer for food, like the Seal-a-Meal. It would definitely lack the fun factor of running something through rollers that has no business going through rollers. On the other hand, maybe pouring a nonconductive fluid (canola oil?) around a circuit, evacuating the rest of the air, and sealing it might let it function deep underwater.

  • I just ran some tests with a scope to get a sense of the jitter. The test rig had a 56K pull-up resistor (roughly what Atmel claims for the internal pull-ups on an Atmega328) to a 5V supply. Here's what I found:

    • With no debouncing cap, I got a lot of jitter when turning the knob slowly, especially when a line transitioned low-to-high. The amount was inconsistent but often bounced 800uS or longer.

    • The recommended 0.01uF caps debounced nicely, with a fairly smooth 1 ms rise to 4V even when turning the knob slowly (which is very close to the 0.9 ms you'd expect from the RC time constant). They were also able to keep up with a quick spin of the knob. I used Kemet C320C103K1R5TA caps for this test.

    • Using a standard 0.1uF decoupling cap led to voltage drops when I turned the knob quickly. The weak pull-up resistor couldn't charge the cap quickly enough to keep up with the pulses.

    Edited to add:

    I also got pure software debouncing to work last night. Here's how. The firmware I'm writing has a system-wide 1ms clock. When a pin change interrupt fires for one of the encoder's lines, it starts a 4-tick (3-4ms) timer for that pin, but only if the pin's timer isn't already running. (If the pin's timer is already running, it ignores the interrupt.) When the timer expires, the code samples the pin's value. It ignores any cases in which A and B both change or where A and B both have the original value. If only one of the two has changed, it declares a rotation event which is clockwise if old B != new A and otherwise counterclockwise. We'll see how the scheme holds up as the encoder wears.

  • Just a thought: if you wind up doing another rev of this board, it might be worth including through-hole footprints for debouncing caps on the A and B terminals, in case the user would like to add them. From the .brd file it looks like you could fit a CAP-PTH-SMALL package on each side of JP1.

  • So we got the database back online and right about here's where I told him, "You're crazy. You can't possibly drive a server hard enough to give off radiation." And then here, maybe 10 minutes later, you can see us hitting Free Day's peak load.

  • One of the really cool aspects of the Arduino phenomenon is the way it's leading people to really push the limits of the hardware. In a commercial environment, you'd often reach for a beefier microcontroller, sacrificing increased parts cost to gain time to market and room for the code to grow, but Arduino users have a natural boundary in how powerful their tools can be, so they're rediscovering old techniques and inventing new ones to accomplish impressive feats like handling video with an atmega328.

  • This technique could lend itself well to synchronizing a musical soundtrack to a game in real time. Don't some video games do that? If done well, it could enhance the game while requiring a minimum of setup: wireless sensors on rackets, if the players are already wearing bluetooth-equipped heart rate monitors or shoes, pull information from them, embedded computer with mp3 player and music loops, and wireless (bluetooth?) connection to an amp and speakers.

  • Thanks for doing free day! Ever since, I've been thinking about how to architect a server farm if you know it's going to get slammed to the point that something's going to melt.

  • That could be a lot of fun on a bike wheel.

No public wish lists :(