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