CommonSense: matrix LCR meter with a HID interface

[DMA]

Diode conversion is for 2 AEKs I made as gifts to friends.

Have not touched KLL - and it doesn't matter. What matters is ScanModule. OutputModule "uartOut" is so I can see keypresses in serial console.

Looks like BluePill is capable of scanning fast enough with a bit more handholding (you'll need to trigger ADC from MCU (unless you find some sort of a timer block in MCU)). As for "how good those ADCs are" - you'll never know until you try.

And stop complaining about "widows only tool" - VirtualBox is TEN YEARS old.

..also you won't get normal USB descriptors anywhere else - for some strange reason everybody else uses those clowny "NKRO" descriptors which make a effing gamepad out of a keyboard, and have bios problems on one platform or another, KVM problems, OS problems if they won't guess the exact moment to go "into NKRO mode" etc etc.

[cryham]

Right. Thanks for info.
I fixed kll issues by getting an older version of kll repo (with ver 0.5c).
But now I have this weird error, at start of building:
make[2]: *** No rule to make target '/matrix.h', needed by 'CMakeFiles/kiibohd.elf.dir/Scan/MatrixARM/matrix_scan.c.obj'. Stop.
Not sure why, is MatrixARM common and also used with CommonSense?
Hmm. Maybe I'll just pick your ADC code and put into my working code with LCD.

There is a return 0; Here, right at start of

Code: Select all

inline uint8_t Scan_loop()

This is because scan is triggered just once in cliFunc_T ?

[DMA]

There is a return 0; Here, right at start of

Code: Select all

inline uint8_t Scan_loop()

This is because scan is triggered just once in cliFunc_T ?

You are asking a person that does not exist.
2016.. I have great trouble remembering 2018. At this point you and me know exactly the same amount about that code. In fact, you may know more.

Looked at the code - everything is in CLI functions. Also it doesn't seem to dump sampling capacitor between measurements, so keypress will cause echoes downwards (press of the key in col 3 will trigger cols 4, 5 and so on).
You'll need some creativity (or a lot of pins) to make this working with standard "scanning ADC". Doing it without scan mode should be possible on teensy4 because of sheer clockspeed, not sure about BluePill (yes, 72MHz, but I had to tweak things for speed @36MHz with all scanning outsourced). OTOH everything depends on your expectations. If you feel you don't need 30k rows/s (and you need that, for debouncing) - you might try driving everything from MCU.

If you'll find a way to keep input pins in high-Z until you're ready to read them, you won't even need stable latencies (i.e. capability to drive the GPIO up and kick off ADC exactly 3 microseconds apart). If you won't - you'll need capability to delay things with nuclear weapon firing controller precision (kidding but not much - you'll need precision on order of 50ns).

Good luck!

[cryham]

I see. Thanks.
I will learn from code and try stuff. I got just a 3x3 matrix to start with.

[DMA]

I see. Thanks.
I will learn from code and try stuff. I got just a 3x3 matrix to start with.

My first was 2x2, but I'd go with a single sensor these days. Then expand in sense dimension, not too fast - 2x1 first, and once that works, 4x1 should be a final prototype. If it works with 4 columns, you can put however many you like.

Scope will help greatly - but if you don't have it, just have insanely long discharge delay.
Another thing is - never leave sense GPIOs floating - when not sensing they must be grounded - my choice was to use OE pins on GPIOs and setting output to zero. How would you achieve that depends on your hardware.

[DMA]

https://github.com/dmaone/CommonSense/r ... g/v1.0.1.0

* Fixes random keypresses for empty layout cells
* Added noisy keys indicator for when scanner trips the sanity check (open thresholds or matrix monitor, you'll see those on red background in couple of seconds. If nothing is red - upload config while threshold/matrix monitor window is open, wait 10s.)
* Significantly expanded MagValve documentation - got another board and discovered that half of the Important Things are not mentioned in previous doc. Now they are.

"Solenoid" now blinks in all modes, not only solenoid. On a protoboard that pin is wired to the blue LED, so..
This makes CS expansion header incompatible with xwhatsit's in LED mode - but if it ever gets to real device ExpHeader will be different anyway - in particular, it will be either immune to inserting it upside down or keyed to prevent that.
CS version bumped to 1.1 to "celebrate" that, FC to 1.0.1.0

[Anakey]

do the 3 capacitors need to be desoldered if having only 8 rows for mag valve? I am getting an error when connecting the dev board after soldering on the rows/columnns as well as the references so is that why the capacitors need to be removed?

[DMA]

If the pins are not used - you're free to leave the caps connected. The reason - I don't want them to be there, life is hard enough.

Seriously tho - they significantly alter the signal. I wasn't curious enough to look how - but the possibilities to fuck up are endless there, including inadvertently creating a resonant circuit which will fry the GPIO if not whole chip with a voltage spike.

[Anakey]

ok I am getting this error from the PSoC when trying to aquire ports

There was an error running port acquire: PSoC device is not acquired! Check connection of the chip to the programmer

This same error i get with 2 controllers when they are soldered with rows/colums. The 1st board after desoldered would program fine, as would the 2nd before soldering to the keyboard.

Below is the layout of connections on keyboard and also pins on the contrioller, please could someone tell me where i am going wrong, thanks.

pinout.png (2.76 MiB) Viewed 10522 times

RG = Row Ground each row is connected together CG = Column Ground

[snacksthecat]

ok I am getting this error from the PSoC when trying to aquire ports

Wiring looks good, I believe. Are you by any chance using a USB hub? I had trouble with USB hub (even a powered one) when trying to connect/write to the board. Only plugging it into a dedicated port on my PC did the trick.

Also did you try aquire port at all before you did your wiring? Just to make sure it wasn't faulty. If not, I know it doesn't help now but that's what I first started checking the second time I did a commonsense project.

[Anakey]

Hi Snack, i was able to flash the bootloader perfectly fine before soldering the rows/columns first thing i did with the new controller to check it was not a software issue

tried different cables and ports on the motherboard still same issue

[snacksthecat]

I should have checked better. Didn't realize you had the full thing pinned out.

I know that 3.2 is skipped. Try disconnecting that maybe? I'm not sure what the pin is used for but it's skipped in the documentation. https://github.com/dmaone/CommonSense

[Anakey]

was following this



I did remove the capacitor that was connected to that pin.
i will try just moving the row pins down one and see if that works

[DMA]

You can only program from the KitProg end **once** - KitProg will fail to acquire port after programming because programming pins are reused as GPIOs. This is fine - use the other end and FlightController.

If you _seriously_ screw up something - USB pins can be used as programming pins, but this is a bit trickier to do.
You can't fry the chip by swapping SWDIO and SWDCK - but make sure that Vbus, ground, and reset pin are connected properly. Swapping ground and Vbus is obviously fatal.

Your PCB looks significantly different from 4 ITWs I've seen. Like, _completely_ different. Post the full keyboard pic, top and bottom. Doesn't have to be 12MP, but decent resolution so pads are 3+ pixels across.

[snacksthecat]

You can only program from the KitProg end **once** - KitProg will fail to acquire port after programming because programming pins are reused as GPIOs.

Wait, I feel like I'm taking crazy pills here.

I know that I've programmed a board several times (I make a lot of mistakes). Or am I totally misunderstanding?

[DMA]

You can only program from the KitProg end **once** - KitProg will fail to acquire port after programming because programming pins are reused as GPIOs.

Wait, I feel like I'm taking crazy pills here.

I know that I've programmed a board several times (I make a lot of mistakes). Or am I totally misunderstanding?

I am not sure tbh.

I helped kralcifer with his ITW conversion recently and there was a problem acqiuring the port after initial flashing. All my KitProgs are snapped off, so it takes an effort to test this. But even if - would be better to check on a virgin kit (becaues who knows how EEPROM contents affect the behavior..). If anybody wants to test and report the results - that would be good.

It _might_ be MagValve-only - inductive has pretty tight loops inside and is running at full 80MHz allowed by hardware (technically 79.99 because digital routing goes all mad at you for setting clock to 80.00). But then again, who knows, all variants _may_ be affected.

Another thing to try is plugging in kitprog side, then press (no need to hold) the button near the blue LED to put chip into bootloader mode and see if port acquisition succeeds. Chip should be more receptive to external stimuli in bootloader as it's running on like 12MHz.

[Anakey]

Hi DMA, i made a thread on this perticular board here viewtopic.php?f=7&t=22722 where there is a shot of the full pcb bfrom the front side

here is from the back

DSCF1612.JPG (3.98 MiB) Viewed 10352 times

[DMA]

Sorry, I don't really exist here - I'm summoned by PMs and couple topic's notifications and miss a lot of things.

Interesting - matrix PCB completely devoid of active components.

You have BIG cojones or an access to a good desoldering tool or both, Sir.
Do not do that at home, kids, especially with intermediates. Those ferrite rings are brittle as hell and, in intermediate magvalve, the leads are hanging off the ring with virtually nothing to support them. One unlucky pull is all it takes to break that ring.

It's hard to trace the PCB without colored pens - but it looks like you're driving by the long trace (the one that gets from entry point to the far end of the row.
I did it the other way - primarily because that long trace was shared by 2 (sometimes more) rows and they are shorted together at the driver. Might be important - but then again, might be not.

I guess you have access to a scope. Go here, look at *_clk_pulse_*.png and compare with your favorite row and column at PCB edge. I would recommend starting with one that doesn't go via the daughterboard.

If you don't - well, good luck, I guess.

If your problem is acquiring the port tho - you are not expected to program more than once, as everything is configurable via FC. But even if you want to remap pins or change code - FlightController has "Update FW" button. If you change the code enough to crash firmware - the button on the kit resets it to bootloader, which you can program with either FC or "Bootloader Host" utility (in creator's menu somewhere)

PS: Oh, and another thing. Columns usually have diodes between column traces and common point. Are you sure the CG is directly connected to the far end of the column switch chain?

[Anakey]

Sorry, I don't really exist here - I'm summoned by PMs and couple topic's notifications and miss a lot of things.

Interesting - matrix PCB completely devoid of active components.

You have BIG cojones or an access to a good desoldering tool or both, Sir.
Do not do that at home, kids, especially with intermediates. Those ferrite rings are brittle as hell and, in intermediate magvalve, the leads are hanging off the ring with virtually nothing to support them. One unlucky pull is all it takes to break that ring.

Hi DMA, this was all hand desoldered using a ss02 engineer though i did get a desoldering gun for christmas so if i ever need to do something as complex in the future it would be a lot easier.

It's hard to trace the PCB without colored pens - but it looks like you're driving by the long trace (the one that gets from entry point to the far end of the row.
I did it the other way - primarily because that long trace was shared by 2 (sometimes more) rows and they are shorted together at the driver. Might be important - but then again, might be not.

I guess you have access to a scope. Go here, look at *_clk_pulse_*.png and compare with your favorite row and column at PCB edge. I would recommend starting with one that doesn't go via the daughterboard.

If you don't - well, good luck, I guess.

yes you are correct the rows are starting all the way to the far right of the pcb. not sure about what to drive, as i have not got to programming with flight controller yet, still trying to work this out given its frirst time i have used capsense, as i am more used to programming contact switch boards using a teensy and QMK.

PS: Oh, and another thing. Columns usually have diodes between column traces and common point. Are you sure the CG is directly connected to the far end of the column switch chain?

If you have a look at the back picture i posed above you can see the wide trace to the right of the daughterboard, this is where all the columns are joined to and if you follow it up you can just see if you look closely where the solder point is just above where the kitprog part of the controller is. If you then look at the front of the pcb, that solder point was a through hole connection between the back and front of the board, with the only thing after it being the 4 diodes/resistors as can be seen in my earlier pic a few posts up. I guess as this pcb is very old in terms of mag valve, that is why the layoout and setup with the logic being on a seperate controller board looks so different compared to the more recent versions of the switch.

[DMA]

given its frirst time i have used capsense

This is inductive, not capacitive. This makes things much, much worse. Capacitive is walk in the park compared to inductive. You're at the edge of this hardware's capabilities.

As for QMK vs FC configuration - just forget about reflashing, ever. Set number of rows in config.h, flash firmware, you're done with reflashing for the kit's lifetime (unless there are serious bugs in firmware).
All settings are applied as soon as you upload them, without firmware restart even. If you did something you regret doing, and lost connection - pull out, plug in, you're back to EEPROM config.

I do not know why, in 2020, you must reflash QMK without any changes to hardware. This is plain stupid.

It wasn't an option for capacitive boards because you need to _fiddle_ with thresholds and good luck doing that with reflash at every iteration, so I did it the way I did - but also because requiring people to reflash because they wanted to remap a key is plain disrespect for your users' time.

About logic being on a separate board - here's the thing: on other magvalves columns have diodes and those are connected to this common point which has approximately the same diodes/resistors arrangement. I might have missed something, that's why I was asking.

[Anakey]

I am having a problem, flight controller does not see the controller board so can't connect to it connecting it from the micro usb side

[DMA]

I am having a problem, flight controller does not see the controller board so can't connect to it connecting it from the micro usb side

Platform, screenshot of main window?

[Anakey]

Windows 64

Screenshot_1.png (4.3 MiB) Viewed 10103 times

[DMA]

OK. Looks like it's in bootloader for some reason. update fw - navigate to project dir/Compiled, find .cyacd there. It should program the device and after that it will likely boot up.

Do you by chance have the button on the kit pressed by something?

[Anakey]

Thank you for that, managed to flash the board and get it into safe mode now i have the seemingly impossible task to get the keys registering which is going to take a few hours to do. i may need to look at replacing the magnet wire i have used possibly with shielded wire to reduce interferance

[DMA]

try defaults from the doc. thresholds 10 to 15, increase discharge delay to 10-15 (shorter one)

[shine]

This is a very very interesting project, tomorrow arrives the CY8CKIT-059 and i already have built the firmware for my 3276 Beamspring.

What i couldn't compile was hidapi, but i don't think it's really needed so.. wish me luck!

Great job, DMA

[DMA]

What i couldn't compile was hidapi, but i don't think it's really needed so.. wish me luck!

You don't need to - unless you want to modify the utility _and_ do it on non-linux. There are precompiled versions in "Releases" section of repo.

Great job, DMA

Thanks!

[shine]

I succeeded! Did a messy soldering job but it worked just fine.

Currently typyng on my Beamspring, can't be happier about this. I ran over some issues with some keys actuating multiple times, in particular the "M" key. Without even full pressing the key it triggered 20 M's, atm everything works perfect.

My 3276 data entry has a 20x4 matrix, I want to share the thresholds because i think they are really low numbers. All of them between 1 and 3.

Thanks to everyone involved in this project!!

[DMA]

I want to share the thresholds because i think they are really low numbers. All of them between 1 and 3.

Hardware -> ADC resolution, bit -> 12
That should pull you into 40-ish-at-rest territory, so you can set thresholds to like 15 and forget about key spam.

Wiring is fine but kek try to get xwhatsit working with that