Member Since: April 22, 2012

Country: United States

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

  • Thanks for the response :) I haven’t looked at the code yet, but it seems at first glance to be a random seed issue. As far as a random sorting algorithm, I wonder if you could try assigning a random number (seeded, of course) from some large range (say 0 to 99; larger than [0, 15] to reduce probability of duplicates) to each of the decimal values 0-15, then sort on their random sorter value (we’ll see how this formatting comes out):

    // Sample unsorted data { <binaryValue>, <sorterValue> }
    { 0, 45 }
    { 1, 12 }
    { 2, 88 }
    { 3, 27 }
    { 4, 97 }
    { 5, 32 }
    { 6, 90 }
    { 7, 18 }
    { 8, 41 }
    { 9, 65 }
    { 10, 17 }
    { 11, 23 }
    { 12, 76 }
    { 13, 53 }
    { 14, 10 }
    { 15, 67 }
  • Anyone else notice that the numbers always come in the same order on a power cycle?

No public wish lists :(