Right

Skardel

Skardel (not sure why/how I landed on that name, or what it means really) is a low profile (ish) split wireless keyboard, with a 3x5+3 layout inspired by the likes of Corne and similar.

Description

MCU

Skardel is built around the Nordic nRF54L15. It is related to the exceedingly common nRF52840, with very similar wireless capabilities, but improves upon both performance and power draw. The nRF54L15 does forego a USB peripheral, however this isn't strictly necessary for a wireless board. As this keyboard was going to be a new design, and the 54 series wasn't more costly, It made the choice clear over the 52840. As for packaging, I initially implemented Nordic's reference design, intending to get the whole board assembled by JLCPCB, but the costs and complexity associated were more than was necessary. After some research, I landed on the Ezurio 453-00001R, which nicely packages the module and a PCB antenna in a tested and proven design. Measuring only 14x10mm, it is still tiny, and certainly not a mechanical constraint. There are other similar modules in the same Ezurio family with the same chip, and those in others, but I picked this one for its availability from DigiKey, and the good documentation attached to it.

Power

The next constraint is power. The nRF54L15 can operate between 1.7 and 3.6v, which is a pretty generous window. Initially, a coin-cell battery was the primary choice, given a nominal voltage of 3v and ease of replacement. A coin cell would be optimal in the sense that the voltage would not need to be regulated, however the internal resistance could potentially constrain further choices with the display and radio transmissions. After some deliberation, I decided to drop the coin-cell architecture, as suitably-sized cells such as the CR2450 end up being rather large, while being restricted in the aforementioned sense. Hence, I ended up going with a LiPo architecture. Given that a LiPo's nominal voltage is 3.7v (up to 4.2v charged), I'd need to regulate it. I could have gone for a buck-boost module, however the extra power draw and complexity was unwarranted, given how low the MCU could go in terms of voltage. After some research I settled on the TPS628438DRLR from Texas Instruments. It is a small, ultra-low-power buck regulator, with an input voltage from 1.8-5.5v, and an output between 1.8-3.6v. This fits nicely within the range of the LiPo, and given a quiescent current of 275nA, there would be almost no impact to battery life. With a max current of 600mA, it would have no problem for this design. I chose to configure it at 3.2v, for reasons to be explained later. As for measuring the voltage for battery life estimations, the MCU supports measuring input voltage on the VDD rail. However, given that the input voltage would be regulated, this would be meaningless for most of the battery's life. Hence, I needed a way to measure voltage across the battery. The easiest way would be to use a high-value resistor between the battery positive and an ADC pin on the MCU. However, this would have some amount of losses, dependent on the resistor. As I don't need constant voltage readings, and in aims to make this board as low-powered as possible, this wasn't the best solution. Instead, I opted for a single-channel load switch. The voltage would be measured in the same way; with a high-voltage resistor (plus some capacitance) to an ADC pin, but with this the load can be switched from a GPIO pin. I picked the TPS22919DCKR, again from Texas Instruments. Essentially, it acts as a very low-power switch. With a shutdown current of 2nA, it also has negligible impact on battery life. Periodically, the MCU can trigger the switch to allow current to pass, and then read the ADC pin's voltage after some time, which can be used to provide an estimate on the battery life. These methods aren't perfect though. A fuel-gauge IC would provide more accurate battery readings, as it can continuously monitor power in and out of the battery, but I couldn't find one that met the low power requirements enough. For the massive 2200mAh cells I intended to use, estimates would suffice anyways. As for charging the cell, to avoid placing any connectors on the board, I decided to omit charging circuitry from the halves. I figured it wasn't worth the extra complexity, given how massive the batteries are relative to the power draw. Instead, the dongle in future could support charging the cells outside of the case.

Matrix

Most keyboards use a diode-matrix key arrangement. With this, the keyboard is arranged according to columns and rows, such that with each key press a column is connected to a row, which the MCU can detect. There is more to it, but the reason for this is that it greatly saves on the amount of GPIO pins are required. For large keyboards, this is pretty much a requirement, as almost no MCU's have 80+ GPIO pins. There are other ways to handle many inputs, such as multiplexers and shift-registers, but these all add unnecessary complexity. The main problem with a matrix is that it needs to scan through all rows to determine which key has been pressed. This is fine in 99% of cases, and it happens fast enough to not be noticeable. Because my layout only requires 18 keys per half, the MCU can comfortably spare enough GPIO pins for all the keys. This saves on complexity both in software and hardware, at the expense of more difficult routing. For the lowest possible power draw, it would be optimal for the keyboard to only send a radio transmission when a key is pressed, and to do nothing otherwise. This can be accomplished with hardware GPIO interrupts. On the nRF54L15, GPIO pins fall under a few groupings, namely 0, 1 and 2. 0 and 1 can wake the MCU from system-off, while 2 can't. Due to other constraints, the three thumb keys had to be put on group 2, while the rest can be on group 1 or 0. This means that any key can wake the board, except for the thumb keys. These will still work, but cannot wake the board.

Display

I wanted to put displays on the keyboard halves, as with a small layout it would probably be useful to view layer states, battery health and connection status. I had used many small OLED displays, namely the SSD1306 and similar. They are cheap, easy to work with and look quite slick. However, the idle power draw is rather high, at up to 10µA. This is with the screen completely off, and with it being full white at 20–30mA. This dwarfs the power draw of the MCU. The next option that would likely come to mind is E-Paper. Because it moves actual physical pigments, it doesn't need any power to retain its state, unlike OLED. However, it requires a decent amount of current to change state, and takes some time to refresh. A better option is MIP, or memory-in-pixel. Similar to LCD, it consists of an array of pixels, but unlike LCD there is no backlight by default, and each pixel has its own memory. Because each pixel can remember if it is off or on, it requires very little current to retain a state, and can still refresh quite fast. Updates can be done via deltas (differences) to save further power. Unlike E-Paper, it does require some power to maintain its picture, as similar to computer memory the pixel's state needs to be refreshed periodically.The display I chose was the Sharp LS013B7DH03, a 128x128 MIP display. It can hold a static image at approximately 4µA, and at 1Hz it would only require approximately 17µA. This is far, far below that of OLED. Besides the small constant power draw, it has a requirement for the VCOM (LCD common-electrode) to be inverted periodically to prevent damage to the liquid crystals. Sharp specifies this to occur between 54 and 65Hz. This could be driven by a GPIO pin from the MCU, however this would require the MCU to be outside of system-off, and would use unnecessary power for nothing. After some research, I found the MicroCrystal RV-3028-C7. It is a tiny real-time-clock that can be programmed via I2C, and supports a clock output in a range, but specifically supports 64Hz output. At a typical power draw of 45nA, it is a no-brainer to use this to drive the inversion. The additional RTC features such as calendar wake and similar are useful, and with ±1ppm time accuracy, it would serve as a very good clock source in future.