Keys swapped
Closed this issue · 17 comments
It seems like there is something not quite right with the config.
I am writing from the Sofle Pico right now, so, working it is!
However, at least for my board, it looks like two keys are swapped. Specifically the two keys on the right thumbcluster, left side - the big one and the one next to it. SW26 and 27. Whatever button press is configured for SW26 happens on SW27 and vice versa. Only happens on the right side. Any idea why? Do you have the same behaviour?
Interesting! I've been using keymaps from the jellytitan folder - but i vaguely remember something like that happening, and switching the keys. I'll recheck the keymap matrix today and let you know what i find.
The physical connection looks fine as far as I can tell. The issue seems to be somewhere in the config.
I found and fixed a switched matrix config:
I just pushed up the fix to my QMK sofle_pico.
I haven't updated the Uf2 files in this repo though - so the drag and drop config is still outdated. If you want to try that method of flashing - i'll update them now.
Since your OLED's are soldered - do you still have access to the BOOT buttons on the PCB? Or are you entering boot mode some other way? (Asking because i pulled out BOOTMAGIC during cleanup, and i haven't added it back in yet).
That was it!
I have my own config going already at https://github.com/uberrice/qmk_firmware . Just updated it to all the last week's changes.
Still learning how to handle QMK config as I go, but it's going well!
My current setup.
One thing I noticed - the new QMK logo you added, at least on my screen, seems like it has lines that are too long. it seems like it's overflowing, making 'jaggies'. Is that something in-progress?
By the way, I properly socketed the OLEDs now - if you try to solder them in directly, the pins are awfully short anyways.
Your setups looking great so far!
Was the OLED issue with the socket it was plugged into? I'm a little worried that there is no relationship between the corner circles and the pin sequence . . .
I cribbed that qmk logo from another board - i think it's formatted for a 128x32 OLED. I'll paw through the repo and see if somebody else made one of the appropriate size.
I'm having intermittent issues with B key registering keypresses. Is it working ok for you? It's not the switch, and i don't think it's the hotswop socket. I'm not having issues with the opposite side "H" key, so i'm down to maybe a bad diode?
The OLED issue was simply me not understanding you actually need to add it to your config ;) the 'noise screen' is the startup sequence, the screen being updated chunk by chunk.
I noticed that if right is the usb-connected keyboard, the menu is upside down.
Also, the qmk logo periodically appears on my right screen - is that on purpose?
As for intermittent issues - I also had that problem with other keys, in my case simply touching up the soldering somewhat fixed it (those solder joints were ugly!)
Oh. Also - no need to set a max RGB value - I changed it back to 255 and my board is not even getting warm with all of them on full blast for hours.
For the intermittent QMK logo - the root cause it the startup/sleep behavior. I haven't quite figured out how to resolve that.
The screens used to timeout after a few minutes, then turn off. Now when they timeout, I'm seeing the startup screen behavior instead. I'll dig through the OLED API to figure out the correct way to handle that. I think OLED's are the last big dev chunk. (I'd like to include Bongo cat at 128x64, as well as improve the UI legability for layer state).
Thanks for checking on the max brightness of the LED's - I"ll crank that setting to max in the config, but leave it in there. (I expect it may be needed if the level shifter is bypassed).
Took a look at the config - seems like what is causing the 'startup behaviour repeating itself' is a fairly simple bug that you have introduced.
bool oled_task_user(void) {
static bool finished_logo = false;
if ((timer_elapsed(startup_timer) < OLED_LOGO_TIMEOUT) && !finished_logo) {
// Display the logo for 5 seconds on boot.
if (is_keyboard_master()) {
render_logo();
} else {
render_qmk_logo();
}
} else {
// Display the current keyboard state.
if (!finished_logo) {
// Clears the OLED.
oled_clear();
} else {
finished_logo = true;
}
if (is_keyboard_master()) {
render_status(); // Renders the current keyboard state (layer, lock, caps, scroll, etc)
} else {
render_logo();
}
return false;
}
return true;
}The whole 'finished logo = true' thing needs to be in in the 'if(!finished_logo)' part. Also I don't get why you have the return true at the bottom - if you want to show errors, you would also need a return false in your if statement - but it is always going to be if or true, so you can just remove the return false above and change the return true at the bottom to false.
The screen then go to sleep as wanted.
I have nothing to contribute but just read through the three issues you 2 have been discussing this on and it's great to see the collaboration.
I'm a relative newbie to custom keyboards having only built a macropad so far but I hope to build this Sofle-Pico keyboard soon.
Would it be mostly OK for me to order the current PCBs in their current state or should I continue waiting for more testing/revisions?
Hi @LoopControl. I ordered my own revision (that got merged in at some point I think) - that definitely worked for me without any hw patches - the voltage shifter components are not needed, so you need to bridge the solder jumper on the board. I'd recommend using 6/7mm spacers or something. I used 8mm I think, which causes the board itself to be 'suspended' between the 3d printed plates. Other option would be to make the bottom plate thicker, with slots for the spacers to fit into down to the 'original height'. Once the switches are installed, it's no real issue anymore, however.
I don't know what @JellyTitan changed since then other than the LED cutouts, he'll have to comment on that.
@LoopControl I'm delighted that you're interested! While the v3.5 release is working - I'd recommend waiting another week.
There's some changes I'd like to validate. Everything after 3.5.2 has not been tested yet. (v3.5.4 came in yesterday, I'm hoping to put them together this weekend).
I refactored the LED footprint again, added a 'handedness pin' as well as tweaked the power circuit based on what I learned about routing from @ubberices' contrib, and I pulled the vbus/vsys diode after checking the board variants with a thermal imager. There's a hotspot on that diode. I cribbed that part of the circuit from the Junco, and I think it can probably be removed, but I won't know until i test the board. I did open an issue with Junco to see if there's some data that I'm missing, or if there's any additional insight to be had.
Thanks for the responses. I'll wait for the newer revision before ordering the PCB.
I've been looking at keycaps/switches and am thinking of these "low-profile" keys from Nuphy. Would these be compatible with this PCB?
@LoopControl
The first link are for "Gateron low profile" switches which have a different footprint.
The Sofle Pico currently uses MX footprints, so those won't work.
However - it's not a heavy lift to swap out footprints. Probably a few hours worth of work to swap em in, then update the traces.
Right now the two 'hot' footprint styes are MX and Choc. Boards that support other styles are rare because the demand is low.
Last year KiCad 7 was released, and it made it easier to make custom footprints. I tried to make a footprint for the Cantor that accommodates 7 different types of switches, including MX, Choc, and Gateron low profile. The pins on the footprints are all just a little different, so it comes out looking like swiss cheese, and really not working well at all. Ultimately i found that without three solid points of contact, the switches would be 'jiggly'. The jiggle would require keyplates, and the keyplates added cost & complexity. I abandoned the project.
If you feel strongly about the gateron low profile footprint, I'd recommend waiting until the Sofle Pico is released and then forking the branch and adding the footprints yourself, or opening an issue with a feature request label so that it can be worked on someday.
I'm not attached that much to the low-profile version and will pay more attention to make sure I get the non-LP keycaps/switches, thanks!