OK Keyboard version 2(3) part 1

Another blog entry which is incomplete so I will keep adding to it as my schedule allows.

This is technically the third revision of the One Key Per GPIO Keyboard OKPGK since there is an APA102 2020 and a SK6812 version of the original. I’m still using the APA102 2020s. I added thicker traces, USB C and a few more caps to help with the very last LED in the chain, i can hopefully double the speed the LEDs are updated, though they’re fast as it is and we’ll run into the limits of the LED itself hopefully, if not already there.

This isn’t an article about the creation of they keyboard, its more of a board log/process thing.

Switches and LEDS


Added bluetooth with the MDBT 50 module


Setting it up for the PNP


I like to put the boards in the orientation they end up on the PNP if possible.

Building the BOM with BOM-XS.ulp


Prepping for export to the Neoden4 Software NEODEN-4.ulp


BOM-Xs.ulp for getting a parts list and order together


At this point its worth going back over the schematic and making sure you’re using the same device for parts that are used more than once. The 10K resistors didn’t get grouped since I used one device from the sparkfun lbr and one from microbuilder. Which happened because I imported the Bluetooth module from another one of my designs.

After using the replace feature of Eagle they are now properly grouped. Adding ATTRIBUTES from Mouser and Digikey parts helps a lot here, we normally try to use a common library where the footprints are verified and the attributes already exist. The more  data you can add here, the less work you have to do when you start to buy/build.



Prepping the Pick and Place

Magnetic bars hold it place and am using the fixed board method here.


Cataloging Parts

I decide to catalogue all the parts on the PNP since it has been a while since we did a run, which took a while! All the reels photographed and documented, it is so much easier to do as you’re going along. We usually keep the NSL default stack updated in the default ULP but as you change the reels you can export/import the previous stack from each different setup so there is a .USS file that is usually newer than the default stack, and we’re still working out what our default stack is.

I made a Google Sheet so we can track the changes, I plan to tie this into the export scripts so it builds up either a USS or the default stack automatically from this spreadsheet.



Next is setting up the fiducials, basically what I’m doing is locating where the fiducuals are physically on the PNP, then look at where eagle thinks they are, then using the difference between the two points (x1-x2) (y1-y2) and entering that into the Eagle Export section, which means the board is placed at the correct physical location. The machine then will run the auto fiducial finder and adjust everything automatically for any small differences during mounting or such.

I have yet to annotate this video.

Doing that gives me the XY offset for this, and entering the Xd/Yd into the X and Y boxes the outputted CSV file will contain the physical coordinates on the PNP. I’d have taken more photos of the process, but the fish pump in the PNP gets annoying to listen too (and they’re all in the video linked above)


Some of the components don’t fit in reels so I’ll make  a custom tray..

One of the issues we have with lack of storage space is sometimes its easier to buy new components than find them, especially if it is tiny parts. Placed an order for the CPUs and also picked up a few extra MBDT50 with the external antenna and a suitable antenna, ended up being arrow and mouser, can never seem to find an order that is from one place. It’ll also give an opportunity to check the antennas with the VNA which is always fun.


Another App

I threw together a quick MFC application that OAuths to the Google Sheets API and can pull the data down, then we write the USS file to the local folder for the Eagle ULP to use. I’d liked to have embedded it all into the ULP but the Oauth part is trickier there.  Alternatively publishing the sheet to the Web and then just get/json etc but I prefer this since its a two way process.


The idea here is you can keep a master spreadsheet with the state of the current Pick and Place setup. Data can also be edited here and pushed back to the spreadsheet. For different machines, can have different spreadsheets.

The push back is for things like Nozzle ID and X and Y of pickup, place/pickup height etc which is often fine tuned on the machine.

I haven’t pulled the images yet, not sure if I will. Rather than getting crazy on support applications I want MVP (Minimum Viable Product) the idea is to cut down spent in preparation

May also output a script that updates or adds ATTRIBUTES for the OEM Part numbers in the sch/brd file.

One thought on “OK Keyboard version 2(3) part 1

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out /  Change )

Google photo

You are commenting using your Google account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s

This site uses Akismet to reduce spam. Learn how your comment data is processed.