latigid on

You make changes in the MBSEQ_HW.V4 file located on the SD card. You can remove the card and edit on the computer or use the file browser in MIOS Studio.

Pimp My Keyboard is the "retailer" for Signature Plastics -- what I think happens is they supply bulk runs and put the excess on the shopfront. The little window is mainly designed for Cherry MX, which have the LED in this location. As said already, this limits the switch illumination to the "north" part (or the "south" if you rotate 180 as some keyboards do). I have a few of the Matias switches (and a "sampler" for Cherry MX) arriving today. The drawings don't show it, but if the switches have enough room on the bottom, I'd like to put a low-profile SMT LED right in the centre. The plunger/slider of the switch is opaque, which should mean the light is diffused around the internals of the switch.

Nice! Do you have acrylic windows installed/planned?

Just discussing with keycaps direct now. I'm leaning towards the DCS-type of switch as it sits just over 1mm lower and allows the front part to be labelled more cleanly. The angles are a bit shallower. Let's borrow some Sequentix images ;) here the switches are squeezed into the minimum spacing, and use quite high caps. There's no panel between switches (same as proposed for my layout). Alternative panel with DSA relegendables? Cirklon looks like it uses DSA (notice the "spherical tops") with bigger spacing this also gives an idea of relative heights; the encoders are sunken into the panel as the switches sit very high up. A grid of DSA looks like this: Whereas DCS are much smaller at the top: I imagine the cheapest way to go would be to order only one type of cap, so here's the side profiles: or, the variably angled profile as intended: maybe more ergonomic? Or weird?

Technically the MIDI outs are running on UARTs, so it should work within standard MIDI spec. The I2C module should be fairly close to the Core. Maybe the problem can be simplified on the other end: one or two DIN MIDI with a thru box on the other end. This depends on how much data you're sending and how important clocks latency etc. are. MIDI thrus seem to be done with some sort of CMOS buffer (inverter/NAND etc.). Or you could consider the KissBox and send over ETH.

If it's only MIDI outs that you need, you gain 4 just by wiring to the correct pins on the F4 disco board/J11E (+resistor), and adding a pull up to +5V for the MIDI- signal. Unless your diagram is incomplete and you're already maxed out on MIDI IO and Quad IIC...

Hi Jay, I don't have much experience with MIDIO or PIC8 stuff, but I think your "device_id_xx" hex files are simple ways to reset the Device ID to xx without reflashing via a PIC burner. Before uploading hex, make sure the MIDI communication works using "Query." It's only possible to communicate with PICs holding the same Device ID as selected at the left of screen. Pressing Query should tell you the application installed on that PIC. If it isn't MIDIO v2, you need to upload a new version: http://www.ucapps.de/mios/midio128_v2_2c.zip found on the "MIOS8 download" section of ucapps.de The following gives you info on MIDIO: http://www.ucapps.de/midio128_v2.html A useful config tool is integrated into the Tools menu of MIOS.

Great! Now you can do the "it's working dance" :). Thanks also for reporting back. Reflowing joints is always a good idea, and if you have intermittent behaviour often the problem can be solved by checking the ground/0V connection. Enjoy,

Good point about the red. You might be able to block it out with a type of collar or even a gel filter that cuts off ~700 nm. Anyway, looking forward to more info.

Nice work! What sort of layout were you going to do? An isomorphic or square grid? Presumably you'll need a clear housing the bottom (or holes drilled) to get the LED shining through, or do you plan to use other switches (e.g. Gateron)?

I asked Fentek, keycaps direct and X-keys if they have ALPS mount and different plastics available. I've ordered a few Matias and Cherry MX switches to test. FWIW, the keyboard above can take both Cherry MX and ALPS switches. The backlighting uses a kludge method of bending an LED into the hole normally holding the Cherry MX post. Ideally I'd prefer to have as few PCB holes as possible to make routing easier, so I'll first look at a topside LED under the switch. Other options are "dead bugging" an RGB LED, using "chiclets" holding an easily soldered 5050 mount + pin headers, or even columns of 4. PLCC would be great if only they had reverse-mount styles, but I can't find any in RGB. In this case it might work to use normal LEDs and attach them with cut resistor legs spanning across the "bottom" and making the solder connections. After the chip was secure, you'd carefully cut the wires apart as not to short the pins.

Seeing how it looks like we're going back to a shift register-driven RGB BLM in 8*4 config, I'm curious if you connected any current source/sink in this setup (if you remember).

Round and round and back again... ALPS/Matias seem to do a better job, because you can reverse-mount the LED right in the centre of the switch. Cherry MX have a stabilising pin there. (clicky one) https://www.youtube.com/watch?v=qfwJBpeT6TE A real pity about the fewer cap options though.

@ilmenator, it's a bit of a toss up, because the bleed likely doesn't come from the bottom (the mounting plate blocks most of the light) but spills over the whole clear switch top. By design the caps sit 3mm above meaning there's a lot of chance for wandering photons. For mech key dudes, I bet part of the appeal is having a coloured "skirt" of light at the base. The Gateron or Zelio switches have a large cutout lending themselves to other LED options, maybe a narrow angle THT RGB LED raised as high as possible. The downside being it makes hotspots more likely unless there's good diffusion. Cherry MX normal with LEDs https://geekhack.org/index.php?topic=54702.0

I found the following imgur album a good representation of X-keys clear caps: http://imgur.com/a/gTpfd Even a tight layout of 18mm works okay: without caps there's notable hotspots on the clear caps (could be the photo/camera settings): In the dark: From this angle you get the idea of the "switch mounting panel" The black painted keys with translucent "negative" labels look the best IMO. Apparently RS used to stock these, I can't find them anymore Back to X-keys, result isn't too bad with mostly black legends: Looks like quite a bit of colour bleed; fine for bling RGB where you want a rainbow effect, less so for individual indication.

Interested in how MIDIboxers use their memory. The main reason for asking is if interior SD cards are okay, or whether it's really needed to have a card on the rear or front panel. Thanks for participating.

It's got that familiar Hawkeye feel, many thanks for sharing :).

For AINSER64 you have the choice of a regulated power supply, then the only resistors in circuit are to current limit the LEDs. Notice the filter caps on the ADC Vref .

No problem with carbon, especially when they're pull ups/current limiting. Maybe an issue for analogue or where Tc becomes important. But even in AINSER, your pots will be carbon film. Metal used to be much more $$, now they can even work out cheaper.

Of course, migrating from 16F to 18F would be a lot of work, although an interesting challenge :). I'm actually in three minds about this. First is to simply redo 4* I2C in a smaller form factor. Easiest but not very creative. Second is to use the PIC18F25K22 with code edits. Swapping 4*DIP18 for 2*DIP28 doesn't make that much difference to PCB area: Third is to dive in and look at an extended I2C/UART system. Teensy 3.5 springs to mind, as it has 6 UARTs available and 5V compatible IO for $25 in a small package. Could be useful as it seems there's a lot of nice peripherals to be implemented these days.

Good plan.

You can try swapping U8 (74HC595). U7 would seem to be okay if the matrix responds to buttons. To confirm: this was working at one point? Also, ensure the CS is connected by J1, closer to the centre of the board, not J2 below it.

Yes. If unsure about the orientation of the IDC, (before applying power) test for continuity on the 5V line e.g. the power pins of the shift registers vs. 5V pin on the Discovery Board.

Hey, thanks for the update. As mentioned, it's looking like the switches will be Cherry MX or equivalent. Also, a recessed mount would be better (have a look at the panel spacing image above), but in any case, there won't be any "front panel" around the keys as there's no room. A good compromise I think would be to use black or dark PCBs for the "switch panel." Any thoughts on the "X-keys" linked above? They come out at 50c each, though that's without any bulk discounts requested. It'd be good to get proper dimensions of them, but they look to have a lower profile than other caps, also a few mm less in the x/y dimensions. As far as colour goes, that's a tricky question! How about a milky type of plastic in a neutral colour? The light would then be better diffused than with full transparency. Also, one could paint/spray paint a darker colour over the the translucent cap bottom -- the opposite of what the guy did in the video above. If possible, please get some pricing from them! Before big decisions are made it would be nice to test out a switch and check the illumination with a given LED. I've requested samples of the white on black OLED above. No luck with a vertical socket for SD Cards, although there is one for microSD. Hack approach: Same principle as using an old floppy cable, but not a great idea as you'd need the panel precise, one of the contacts removed and a plastic guide to align the pins properly. Does the SD have to come out to the panel? It would be easier and cheaper to have a microSD sitting in a normal or hinge type socket. Otherwise you get another PCB breaking out an SMT SD socket to header pins that are soldered or socketed on the main PCB. The following being the idea of socketed SD:

Something else to try is a bypass cap over the supply rails -- noise spikes might cause confusion for Mr. OLED. Edit: would suggest as close as possible to the pinheader on the display.