Member Since: April 22, 2012

Country: United States

  • Very cool! I've also been working on a small joypad for the MicroView that pairs nicely with game programming. It's called MicroJoy, and you can build your own here. Hope it's useful to anyone wanting to build games with MicroView!

  • These require more force to push than I like. If you need a switch that requires less force (perfect for a gamepad), use Omron B3F-5050 (1.3 N operating force). The B3F-5050's also have a "long service life" according to the datasheet.

  • Yes, in the SparkFun Eagle library

  • Thanks a ton. So that makes for a diameter of 0.64mm * sqrt(2) = 0.9051mm. I'm trying to fit the MicroView onto my board with this pass through socket.

  • SparkFun, could you tell us the pin diameter (diagonal, since they're rectangular)? Is there any sort of data sheet that would contain this information?

  • Could someone tell me the average power consumption of this? (Say for code of average intensity). I know the OLED by itself pulls about 10-20mA. I'm trying to figure out the smallest LiPo that SparkFun offers that can run it for at least 4 hrs.

  • I bought a set of #2-56 screws here on SparkFun and tried them out with a circuit board designed using SparkFun's footprint of this part (according to it, the joystick holes are 2mm in diameter). They fit snugly (i.e. I could go without using a nut on the bottom side of the board), but they seem to work. If you want a looser fit, you'll need a hole bigger than 2mm in diameter on your board.

    Also, the #2-56 screws here have good clearance regarding the heads and the body of the joystick. Moreover, they don't stick out too far on the bottom side of the board.

    For a connection, I'm currently experimenting with copper tape. Optimally, you'd want conductive adhesive too. I bought this tape from SparkFun which apparently does not have conductive adhesive, and I am folding it over partially in order to have a fully conductive part and a part with adhesive on the underside, then placing it on the PCB pads. For an idea of the footprint, see TimmyTopHat's board from his comment above.

    I did find that I needed a small nylon washer/spacer to place between the mounting hole on the joystick and the PCB drill hole (you'll notice upon inspecting the pic that it's not going to be flush with the board otherwise). The best fit I found was here from DigiKey. The height of this spacer should optimally be between about 1mm to 1.5875mm (1/16"). The spacer I found on DigiKey was about 5mm, so I cut it into quarters to achieve the desired spacer height. However, the inner and outer diameters of this spacer work great.

    As a bonus, you could put a spacer on either side of the joystick mounting hole if you don't like how far the screw sticks out the back side of the PCB. Hope that helps!

  • I'm thinking of mounting this to a custom PCB using copper tape (with conductive adhesive) and screws. Anyone know the best screws to use for this? Also, any tape suggestions? Sparkfun sells copper tape, but it doesn't look like its adhesive is conductive.

  • These LED buttons would make an awesome DIY BCD clock kit! You could use the buttons as a nifty way to set the time in HH:MM:SS format. I submitted the project idea to your team via the Contact Us form last week ;)

  • Awesome to hear you had success with the randomSeed() call! You can also call randomSeed(millis()) at the start of a new game in cases where you have no unused pins (I use it on my Meggy Jr RGB). This would also work well since Binary Blaster has something analogous to a "startup screen", where the time spent there is indeterminate, and the time between games is indeterminate too.

    If I were to implement a random sorter, I would probably do something like what's below (to balance efficiency and readability):

    struct BinaryValue
        byte value;
        byte sorter;
        BinaryValue(byte val)
            value = val;
            sorter = random(99);
    BinaryValue valsToGuess[15];
    for (int i = 1; i < 16; i++)
        valsToGuess[i] = BinaryValue(i);
    QuickSort(valsToGuess, 15);

    where QuickSort is a standard in-place quick-sort algorithm, with the only modification being that the BinaryValue.sorter value is used in the comparisons instead of the binary value itself.

    In answer to your third question, I'm more thinking about getting reasonably far from less interesting cases like sorter = random(2), where two numbers have a higher chance of staying next to each other. I haven't validated the math but if you use random(x + 1), then the chance of two sorter numbers colliding (resulting in the binary values staying next to each other) would be (1 / x)^2, which is asymptotic in its plot. So eventually, for a large value of x, increasing x wouldn't have as much of an effect on randomness.

No public wish lists :(