diepala / cantor Goto Github PK

Tried to insert some 0305 mill-max sockets to make the cantor hotswappable, but they don't fit. the metal rings for the connections make it a little too tight. maybe in the next iteration of the cantor this can be taken into account

Hello there:
I'm new to spilt keyboard. Your design is awesome and perfectly fits my needs.
Just a quick question, where can I find the firmware? I searched for qmk but no luck.
Please advise. thanks.

Hi!

A 36 key version of this would be great, are you planning on making this revision?

Hi.

Would you like to add this to https://github.com/jhelvy/splitKbCompare :)

Would like to compare to other keyboard. Especially Torn.

I want to set the master side defining the SPLIT_HAND_PIN as the documentation says.

Is this possible? and which pin of the microcontroller can be used to determine the master side?

best regards!

I have ordered a cantor PCB, and just waiting for the switches to be built. I noticed that you have heavily said that the controller must be face up.

But, in the PCB I noticed that there are 2 Pin arrays, It seems like they are mirror opposite of each other. Meaning I don't need to face down the PCB if I choose the one that has a square white mask around it.

My question is am I right?

Sorry if it doesn't feel like an issue, because I have no other way to ask this.

Could this board be built with an Elite-C or RP2040 Elite-Pi MCU that has the extra 5 pins on the bottom? Something like this:

https://d33wubrfki0l68.cloudfront.net/d42e46a6982528aa7328b87dc758414ebabc5dbf/22e62/assets/images/elite-pi_pinout-both-49caa4613444b03c72bc0c06bd622835.png

Or does the black pill provide something extra ?

Right now, there is no mention of which license the source falls under, if any. It would be nice if you would add a proper license so that there are no question marks for anyone building upon your work! See foostan/crkbd or TweetyDaBird/Lotus58 license for example.

Would it be possible to create a version of the Cantor whose TRRS ports are replaced by USB-C ports?

Is there a pin that is grounded for one of the blackpills and not for the other? It would allow determining if an instance of the firmware runs on the left or right half.

I wrote a keyberon-based firmware for the cantor, where I would like to use such a pin. The firmware can be found here: https://github.com/dariogoetz/cantor-firmware-keyberon

The readme says

"The Cantor keyboard uses the QMK firmware. Firmware for this keyboard is coming soon to the main QMK repository with qmk/qmk_firmware#16552."

In fact, this has been merged 2 years ago. It would be prudent to update this repository.

The zip release for the MX version contains the gerber files and another zip containing gerber files.

This causes jlcpcb to reject the board during review.

It'd be fantastic to have a version of Cantor that was compatible with MX switches.

MX compatible hot swap sockets would be ideal IMHO, they:

• Are easier to solder than switches themselves
• Allows exploring different switches

Related to #4 - release a 54 key version (number row on top added). Can this be done w/o diodes with the blackpill? How many unused pins remain?

Hi @diepala,

I'm trying to flash my cantor (not for the first time), and there is an error during the compilation. Even via docker, the error persists.

# ~/.config/qmk/qmk_firmware ❯ sh util/docker_build.sh cantor:default:flash
QMK Firmware 0.16.5
Making cantor with keymap default and target flash

arm-none-eabi-gcc (15:8-2019-q3-1+b1) 8.3.1 20190703 (release) [gcc-8-branch revision 273027]
Copyright (C) 2018 Free Software Foundation, Inc.
This is free software; see the source for copying conditions.  There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.

Size before:
   text    data     bss     dec     hex filename
      0   26776       0   26776    6898 cantor_default.bin

Compiling: .build/obj_cantor/src/default_keyboard.c                                                 [OK]
Compiling: quantum/keymap_introspection.c                                                          In file included from quantum/keymap_introspection.c:5:
./keyboards/cantor/keymaps/default/keymap.c:21:11: error: implicit declaration of function 'LAYOUT_split_3x6_3' [-Werror=implicit-function-declaration]
     [0] = LAYOUT_split_3x6_3(
           ^~~~~~~~~~~~~~~~~~
./keyboards/cantor/keymaps/default/keymap.c:21:11: error: initializer element is not constant
./keyboards/cantor/keymaps/default/keymap.c:21:11: note: (near initialization for 'keymaps[0][0][0]')
cc1: all warnings being treated as errors
 [ERRORS]
 | 
 | 
 | 
make[1]: *** [builddefs/common_rules.mk:360: .build/obj_cantor_default/quantum/keymap_introspection.o] Error 1
Make finished with errors
make: *** [Makefile:414: cantor:default:flash] Error 1

Sorry, but I don't know if this is the better place to report this problem.

I'd like to add Vial support for this keyboard. I've already got it working from my local machine and my Cantors. This would require a fork of vial-qmk and merging it back into their main. I could handle that, but since you designed the keyboard I thought it would be more appropriate if you forked vial-qmk and then I could make a PR to your fork and then it could be merged back into vial-qmk main.

What are your thoughts?

When using your fork of qmk-firmware and the qmk cli on OSX (12.2.1) I get the following error when compiling the included default keymap. Other keyboards build without problems.

$ bg:~ $ qmk compile -kb cantor -km default
Ψ Compiling keymap with gmake --jobs=1 cantor:default


QMK Firmware 0.16.0
Making cantor with keymap default

arm-none-eabi-gcc (GNU Tools for Arm Embedded Processors 8-2019-q3-update) 8.3.1 20190703 (release) [gcc-8-branch revision 273027]
Copyright (C) 2018 Free Software Foundation, Inc.
This is free software; see the source for copying conditions.  There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.

☒ Matrix data out of bounds for layout LAYOUT_split_3x6_3 at index 6 (k4A): 4, 0
gmake[1]: *** [builddefs/build_keyboard.mk:335: .build/obj_cantor/src/layouts.h] Error 1
gmake: *** [Makefile:413: cantor:default] Error 1
Make finished with errors

As a user who built the Cantor Keyboard as my first split keyboard, I have thoroughly enjoyed the experience, especially appreciating the simplicity of the build process and the clear assembly guide provided. Despite being new to the splitboard game, I found the Cantor Keyboard to be user-friendly and intuitive.

One feature that I believe would greatly enhance the Cantor Keyboard is the addition of RGB lighting to the PCB For a beginner like me, having RGB lighting on the Cantor Keyboard would provide visual cues for different functions, such as indicating which layer is currently active.

I believe that integrating RGB lighting into the Cantor Keyboard PCB would not only elevate its overall appeal but also provide practical benefits for users, especially those new to split keyboards. Thank you for your attention to this request.

Is it possible to control the LEDs of the blackpill?

For example I'd love to completely turn the red LEDs off. Or better yet, turn them on when I'm switching layers.

Would you consider generating an XKB geometry file so that linux users could get a nice graphical representation of their keyboard in various gui tools?

Cantor does not work if connect while booting into the OS. I need to replug it to make it work. I have another custom keyboard - corne and it does not have this problem. Any ideas?

I have a fork with minimal changes, and am using the same QMK software and have discovered an issue with pressing multiple modifiers.

It turns out that the order I press the modifiers is important. If I press say Shift on the left half and then some other mod on the right half and then the actual key, everything is working as expected.

But if I press the modifiers in the reverse order, it doesn't work.

Is this something you have experienced? Is this a QMK issue?

Would it be possible for you to add support for splitkb's tenting puck? This would add to the Comfort aspect of the design philosophy while not hurting the Ease of build since it is optional to use.

I am sorry if this is not the right place to ask this, but I don't know where else to ask:

One half of my Cantor doesn't type. The Blackpill seems to be in bootloader mode constantly, even after flashing. After I disconnect the cable, and replug, I can instantly flash with qmk, without having to press the BOOT0 NRST nrst boot0 combo.

I had to resolder some parts on that side (I'm bad at this), so I suspect it's because of bad soldering somewhere. What pins (or switches?) should I take a look at? What could cause the Blackpill to be in Bootloader mode all the time? I tried to read the Documentation of the board, but I'm afraid all of it went right over my head...

Thanks in advance!

Just built this great keyboard, have an issue with 4 keys not working on the right-side though.

They correspond on the default mapping to the [, n, m and , keys. So the top-right key, and the bottom left-three (within the main block).

QMK key tester:

I suspect the issue is with the controller, not the switches. If I swap the controller with the one on the other side, then the same mirror-positions stop working on that side.

I'm new to keyboards and hope to get some help in troubleshooting this.

1. Could it be something simple like one or more improperly soldered pins on the controller?
2. Is it easy to determine which pins govern these keys, so I can adjust the soldering on those pins?
3. What would be sufficient criteria to determine if I should just buy a new blackpill?

Thanks for any help.

Hello 👋
Long time corne low profile user here. I recently built a corne with ZMK firmware and nice!nano v2 MCU and don’t want to go back having canbles.

I love your pcb design (especially the stagger) and the diodeless approach. Do you think it is possible build a wireless variant of the cantor?