Cue2Keys History: Development Start to Initial Sales (Part 2)

"Cue2Keys" is a custom keyboard that I developed and started selling from early 2024 to March 2025, spanning over a year. Development continues today, but I wanted to record the development history up to the initial sales as a milestone.

https://cue2keys.esplo.net/

This article series provides a detailed account of the trial-and-error process from prototype to production version. Due to the article's length, I've divided it into two parts: Part 1 summarizes the overall story including motivation and concepts, while Part 2 details the evolution and technical details of each module.

Part 1 is here:

https://www.esplo.net/en/posts/2025/08/cue2keys_history_1

From here, let's examine the evolution and details of each module.

Key Module Edition

The key module is the core module of Cue2Keys. Its development went through four major stages to reach its current form.

Prototype: Breadboard

Verifying I2C connection with breadboard

First, I verified the I2C connection on a breadboard. The ICs used are the Pro Micro (ATmega32U4) and I/O expander MCP23017. I simultaneously verified passing I2C through a USB cable. USB cables have a total of 4 wires: two data lines (D+ and D-) and VCC/GND, which exactly covers the minimum lines needed for I2C. I also used QMK at this point to verify that the keyboard functions including firmware would work. This can truly be called the oldest Cue2Keys.

Alpha Version: TRRS Cable Board

After verifying the circuit on the breadboard, I first considered the actual connection method. I was considering two options: a daisy chain method connecting key modules with cables, and a hub method connecting each module to a hub. While the current system uses the hub method, my initial decision was to adopt the daisy chain method based on the reasoning that "I don't want to increase hub modules" and "key modules will be placed adjacent to each other."

Circuit and board design were also necessary. Cue2Keys has particularly strict component placement constraints among keyboard boards. This is because it packs ICs and DIP switches for every 4 keys, resulting in many components, and needs to be built so that key modules can be arranged with 19.05mm (1 key size = 1U) spacing. Since this includes the case width, the board can use at most 17mm after cutting 1mm from each side. While meeting this constraint, I needed to arrange two connectors for daisy chaining. Although connectors could be placed at the beginning and end of the board, this would reduce placement flexibility and prevent building row stagger, so I decided to place connectors only at the beginning. First, I thought that if it's the familiar TRRS jack from audio and custom keyboards, maybe two could be arranged side by side, so I tried prototyping.

From this stage, I started ordering printed circuit boards (PCBs) from JLCPCB, which I would rely on throughout the project. Since I had already completed verification of JLCPCB itself (testing board ordering), I was already using PCBA for verification from this point. The shape was already quite close to the current version.

4-key module board with TRRS connection

With PCBA, various parts supported by JLCPCB can be used. The MCP23017 was problematically large, but searching revealed various I2C-compatible I/O expanders, and I adopted the PCA9555 here. 16 bits is excessive since I don't need that many, but since the price didn't change much with different bit counts and it was small with a QFN package, I remember trying it. The DIP switch is 4-bit, different from the current version. Since the IC only supports up to 3 bits, 1 bit is wasted, but I remember the 4-bit version being cheaper. Hot-swappable key switches were already supported at this point, with the standard Kailh Switch Socket attached. I remember hand-soldering these along with the TRRS jack.

As an aside, part selection for Cue2Keys heavily emphasizes PCBA capability. The main reason is the strict size constraints, but the difficulty of soldering is also a major factor. If I did it myself, I'd likely mass-produce defective products, so I'm developing with PCBA in mind to minimize hand soldering.

While I initially tried TRRS cables in this early stage, the problem of interference with many cables when arranging two 4-key modules side by side became apparent. Additionally, TRRS cables were surprisingly difficult to obtain, and there was the problem of confusing them with TRS cables. While searching for different connectors, I eventually settled on the idea that USB cables, which I had used on the breadboard, would work fine. Although there's concern about accidentally connecting to a PC, their very high availability, low cost, and robust nature led to their adoption.

Beta Version: USB Cable Board

A concern with USB cables was that the connector part might be large and cause interference. However, the width was surprisingly narrow, and there was plenty of room to arrange two vertically. Since I found right-angle connectors at JLCPCB that could be PCBA'd, I was able to make them function well. At this point, I also prepared the case and base with the Bambu Lab A1 mini, completing the foundational form.

Base and 4-key without switches. The difficulty of printing is glimpsed

USB version 4-key and 5-key

Many connected together. Keycaps are also 3D printed

As they look, USB cables have high reliability and the advantage of easy insertion and removal. On the other hand, they have height (width) and the cables are stiff and bulky. When there's height, what happens is that the connection with the base becomes unstable. In essence, the force moment becomes large. For key modules where base connection is important, lower height is better for improved stability. There was also the problem that if modules weren't adjacent, cables couldn't reach, reducing placement freedom. Making them longer would make them cumbersome, creating a dilemma.

At this stage, I was making various working things

Joystick prototype too

At this point, wanting to create something working, I manufactured many PCBs. I used JLCPCB's panelization, but V-Cut would be expensive, so I prepared board data with Mouse Bites arranged myself and vigorously ordered a total of 100 PCBA key module boards (20 pieces x 5 panels). Mouse Bites themselves were easily separated with nippers, and although there were burrs, they worked well. At this time, I never thought the shape would change from here. Naturally, 100 pieces were unnecessary, and they became almost waste due to the shape change. Such things happen.

Panelization I worked hard on. And it became waste

Production Version: HY Cable Board

The cable search journey continued from there. Since right-angle connectors are surprisingly few, I was thinking of arranging two connectors horizontally to fit in 1U. For this, one connector needed to fit in about 8mm. However, there are few things that can be arranged at this size. So I decided to switch from the daisy chain method and try making a hub. This allowed me to prepare one connector horizontally on the board side, greatly reducing height. It also increased the freedom of usable cables. While adding hub modules was a minus in terms of management, it increased placement freedom and could be used for tilting and tenting, so I think it was ultimately good.

What I adopted here was a 20cm 4-pin HY cable. HY cables are also known as Grove cables and are also adopted by M5Stack. I adopted them as 4-pin cables with reasonable availability and easy-to-operate size.

Current form

Note that the I/O expander used has also been changed to the more cost-effective TCA9535. Limited to Texas Instruments products, they provide graphical spec comparisons with tables like this, which is helpful. I continued the life of searching sites like Digikey, then checking availability and prices at JLCPCB. The current constraint of up to 8 keys per channel also comes from the TCA9535. TI's I/O expanders typically allow setting about 1-8 addresses, and I settled on this specification thinking that 8 key modules would be sufficient for one-handed keys.

I/O expander comparison example

Currently, what contributes to height are the DIP switch and HY connector. Both are important components, so removing them requires much ingenuity.

Note that the 4 pins of the HY cable are assigned in the order GND, VCC, SDA, SCL. Since the opposite module has the same order, they connect with a reverse cable.

I2C connector pin assignment

For production version manufacturing, there was absolutely no time and a certain number could be expected, so I tried using V-Cut panelization. Using V-Cut results in Standard PCBA, which is overspec manufacturing, but since it was cheaper than anticipated, I proceeded as is. Just snapping creates clean boards, making it very convenient for boards like key modules where case placement is critical.

Key Case Edition

The case that houses the key module boards has also gone through various changes.

Prototype Version: Left-Right Connection Method

The earliest case had no base, with a left-right connection form under the assumption that key modules would be adjacent. At this time, the bottom was still flat, and I was thinking of connecting and fixing with adjacent key cases using screws or similar. I worked on this for a while, but due to the following problems, I changed to a method of creating the base and case separately.

• The sides are less than 1mm, causing strength problems with holes
• Strong fixing between cases is difficult (additionally, rotation occurs if not fixed at multiple points)
• Small size makes it difficult for hands to fit, making attachment of fixtures difficult
• Low freedom (must be adjacent left and right)

Earliest key case

Alpha Version: Block Assembly Method

Receiving advice that "When it comes to fixing blocks, isn't it LEGO®?", I switched to a method of combining protrusions for fixing. This is a form where protrusions surrounded by edges are placed on a protruding base. This change dramatically improved placement freedom. Dimensions are described later.

Early version of block assembly method

At this point, the difficulty of accurately printing protrusions and circles emerges. Depending on which direction is printed downward, circles tend to have burrs. These burrs sometimes helped with fixing and were welcome, and sometimes were obstructive and wouldn't fit, but in any case, strong fixing like LEGO® couldn't be achieved. Since the standard isn't identical to LEGO® and was changed to fit 1U size and allow fine movement, it inevitably becomes a size that can't be molded well.

Despite problems, the rough shape and mechanism are the same as the production version at this point. The board is fixed in height by passing through the pedestal at the entrance and the slit at the end. I prepared internal gaps to allow connectors and Hotswap Sockets to pass through, using a method of inserting and fixing key switches. The design was complex, but somehow it fixed well. Due to this mechanism, the typing feel is on the harder side, so I think it would be interesting if it could be adjusted.

Slit section

Beta Version: Minor Changes

Thinking of ways to strengthen fixing, I tried this method where I removed the edge grooves after all. The strength improved slightly, but the issues still weren't resolved. The base isn't printed well either.

Minor changes. Base printing is still difficult

Production Version: Protrusions and Depressions

As seen in the key module board, switching to the hub method allowed height reduction. Ultimately, the case height was reduced by a full 8mm. With this much difference, the visual impression changes too.

Case height comparison (side)

Case height comparison (front)

Still unsatisfied and thinking of ways to make fixing even stronger, after days of worrying, divine inspiration came.

"Why combine protrusions with protrusions?"

Since LEGO combines protrusions with each other, I was trapped by that preconception. However, I realized that if one side is a protrusion, the other side can be a depression. This led to the current form where the key case side has depressions and the base has protrusions. Height can't be reduced so it's the same, but fixing could be made slightly stronger.

After testing the production version design with FDM (Fused Deposition Modeling) A1 mini, since mass production with maintained precision was difficult, I'm creating with photopolymerization using JLC3DP. Very high molding precision is achieved, but conversely, since there's no variation, fixing could be weak with the same values as FDM. I ordered several times to verify different hole sizes, and somehow reached a size combination that fixes well. Considerable fine-tuning was necessary, and slight molding variations inevitably occur, so I want to explore fixing methods that don't require such precision, continuing to this day.

Base Edition

I started making the base at the same time as the key modules. While LEGO®'s standards are publicly available, they don't match key size (19.05mm square) as is. Therefore, I arranged holes spaced 4.75mm apart, which is 19mm divided by 4.

In the current version, protrusions and depressions are combined, each with 2mm height. Since holes won't fit if sizes match perfectly, the protrusion part is set to 3.05mm diameter and the depression part to 3.07mm diameter. However, this is for high precision like photopolymerization; for FDM methods, I added about 0.2mm margin.

The base part required considerable attention to adjustment, so let's look at the changes that led to this form.

Alpha Version: Triangular Pyramid

Early triangular pyramid base design

The early base was a triangular pyramid with fixed tilting/tenting angles. Ambitiously assuming placement sideways too, I placed protrusions on the top and left/right surfaces. When printed with a 3D printer and used, it worked as expected, but the issues were fixed angles, high printing difficulty with frequent failures, and large filament consumption per print. Note that the inside was hollow and could store cables, which was convenient.

Could store cables in the hollow part

Beta Version: Plate Combination Method

The attempt to create flat plates and layer angled chips as needed to make triangular pyramids came naturally from the idea of block combinations. The printing difficulty itself remained high but was easier than triangular pyramids. Angle adjustment also became possible through chip combinations. The same ability to attach chips with anti-slip features, but one side of the chips has no protrusions/depressions. At this point, both top and bottom surfaces had protrusions.

Base that appears to be printed well

Bottom of the same base. This side isn't printed well in places

With any base, when printing, precision dropped sharply toward the edges and plate adhesion worsened, causing headaches. The base is close to A1 mini's limit size and has a long shape, so it seems susceptible to shrinkage and warping effects. On top of that, there are many circles requiring precision, making it really troublesome. Even with various first layer settings, it couldn't print well, so at this stage I decided to use JLC3DP resin. As mentioned earlier, I tested several hole sizes to verify patterns that work well.

Production Version: Optimization Through Perforated Design

Since the base is large, filament consumption is inevitably large, directly affecting cost. So, inspired by weight reduction in Mini 4WD and similar, I decided to make holes. Modules are at least 1U or larger in size, and there's no need to fix with all holes, so it functions without problems. Even with random holes, sufficient strength is obtained, and as a side effect, cable management by routing to the bottom side became possible.

Early production version base. Current version is a bit larger

Note that the production version has been revised once, slightly increasing the width. While multiple bases can be combined to make them larger, fixing is difficult so I enlarged the base itself. I'd like to modularize the base to handle various shapes, but there are issues with connection parts and rigidity, and since there are currently no good solutions, research days continue.

Rotary Encoder Edition

This has relatively straightforward design and form, so there's not much to write about. I verified with the rotary encoder sold at Akizuki and found a suitable EC12D1524403 from the EC12 series.

One point had an unexpected trap. I used TCA9534A for the IC to avoid I2C address conflicts with key modules, but the settable addresses are from 0x38 to 0x3F. If you immediately noticed this, that's amazing. I'm using SSD1306-equipped displays in the pendant, but this address is fixed at 0x3C. In other words, they collide depending on settings. Since the rotary encoder was straightforward and I started manufacturing late in the process, changing ICs after realizing this was difficult. As a result, I limited changeable addresses to only the lower 2 bits to avoid this. This created the restriction of only 4 units per channel, but it was unavoidable so I released it as is.

Why only 2 DIP switches can be used

Pendant Edition: System Brain

The pendant is the brain part that connects to the PC and runs firmware. Since I conducted much verification with development boards, I started circuit design in the latter half, and there were no major changes from the initial version. Therefore, rather than history, I'll record the current state. The characteristic ICs used are as follows:

• MCU: RP2040
• Flash Memory (12MB): W25Q128JVSIQ
• I2C Switch/Multiplexer: PCA9546A
• OLED Display: HS96L03W2C03

MCU Selection

I adopted RP2040 (Raspberry Pi Pico's MCU) at an early stage. It's a very convenient MCU with ease of use, high functionality, many proven results, abundant design examples in official documentation, and low cost.

Generally when making modules, you must choose between soldering a Raspberry Pi Pico for use or creating circuits using RP2040 itself. Since the Pico is very inexpensive, using it directly would likely be more stable and reduce total cost. However, to avoid hand soldering and also for learning purposes, I decided to design circuits using RP2040.

RP2040 has reference circuits in the official Raspberry Pi Pico datasheet, and by aligning placement with official recommendations, it could be designed relatively easily. Very helpful indeed. While I once created a board that didn't work for unknown reasons, the second attempt worked well. While not originally intended, an advantage over the Pico was being able to mount 12MB flash memory. This ultimately became very important for improving usability, allowing 160 keys across 8+ layers to be remapped in VIA and storing various parameters.

I2C Switch/Multiplexer

The I/O expander (PCA9555) used in key modules can only take 8 types of addresses. That is, it can only handle a maximum of 5*8=40 keys, making it impossible to even build a 60% keyboard. I remember thinking "I'm stuck" at the time. After researching various things, I discovered I2C switches/multiplexers. As the name suggests, these allow switching one I2C bus to multiple channels, alleviating address collision problems.

I2C switch/multiplexer concept diagram

https://www.ti.com/ja-jp/product-category/interface/i2c-i3c-ics/i2c-i3c-switches-multiplexers/overview.html

The IC I used is PCA9546A. This itself becomes an I2C device and can control which channel to use. I mounted this on the pendant to create the current 4-channel type. As mentioned earlier, since one channel can handle up to 8 key modules, I judged 4 channels to be sufficient.

OLED Display

The pendant has a display for information display. I tested the standard SSD1306-equipped OLED display bought from Akizuki and am using HS96L03W2C03 via PCBA. Like the mouse sensor, OLED drivers are also available, making implementation very easy. Since it's independent as a pendant, I decided to mount a relatively large display. Cue2Keys has many dynamic parameters, so I implemented them with OLED page switching. I also display FW version and other information that seems useful for debugging.

Case

The case hasn't changed much, but initially it was a cylindrical I-shape with clearer claws on bottom and top surfaces. Later, I changed to a T-shape to make direction easier to understand, and the claws became loose fixing that relies on lamination marks. While claws are less likely to break, the fixing being too loose was an issue. Note that the text on the case was prepared as emboss and printed. While prepared as a bonus, it seems better to have it, and since it's readable or not readable depending on lighting, I think I'll make it easier to read with multi-color printing eventually.

Trackball Edition

The trackball was a module that caused struggles in various aspects of development. The particularly troublesome points were the following two:

First was IC speciality. Mouse sensors have poor availability regardless of which is used, and for scales of several dozen units, acquisition through resale on AliExpress etc. is necessary. Official wholesale is also impossible at small scales, and since there are no sensors^[1] that can be purchased or PCBA'd at JLCPCB, I resigned to soldering. Furthermore, most seem to be SPI connection, requiring different mechanisms and cables from other modules. Second was case design. Even slight misalignment could prevent motion recognition, requiring delicate adjustment. Moreover, the ball needs to fit properly and rotate while not falling out.

Due to various differences from other modules, this became a module utilizing the wide range of JLC group companies: JLCPCB, LCSC (Custom Cables), and JLCMC.

ADNS-5050 and Ball

The trackball module was designed referencing the meishi trackball I had on hand. I selected the same ADNS-5050 sensor. Since QMK also provides drivers, there's a sense of security. The ball uses the reliable Perixx 34mm Pearl White.

ADNS-5050 requires preparing an LED separate from the sensor. I had trouble since the one used in meishi trackball couldn't be found, but somehow discovered a likely right-angle LED in JLCPCB's ocean (XL-C4040UBC). Also, I adopted a blue LED this time. I tried it based on information seen somewhere that blue might improve reading precision over common red.

However, actual use revealed that red balls aren't recognized. I should have noticed this before implementation, but considering datasheet content and color characteristics, it makes sense. First, looking at the blue LED (XL-C4040UBC) datasheet, the wavelength peak is 460nm. Around indigo to blue. This light is irradiated, hits the trackball, and reflects to be recognized by ADNS-5050. The fact that colors are visible means the object reflects wavelengths it didn't absorb. For example, red balls roughly absorb wavelengths other than red. Therefore, using red balls with the blue LED I used results in much absorption. Also, ADNS-5050 has recognition peak around 680nm with about 60% response rate at 460nm. That is, since it's specialized for red, much light is absorbed and sufficient light quantity for response can't be obtained.

Light wavelength and color relationship ref: http://ene.ed.akita-u.ac.jp/~ueda/education/sentan/photochemistry/principle.htm

ADNS-5050 wavelength response characteristics

In the production version, I used nearly white balls and successfully achieved response with blue LEDs. The faint glow through the case is an interesting point.

Faintly glowing ball

As an aside, I realized that trackball balls being traditionally red was related to red LEDs being widespread and inexpensive. Note that recent high-function sensors often use infrared, not bound by visible light constraints. While response depends on materials and various conditions, usable balls generally increase and considerations decrease.

ZH 6-Pin Connection

I originally wanted to process with I2C like key modules, but ADNS-5050 and most mouse sensors use SPI communication. And for some reason, many are 3-wire (MOSI/MISO shared). That is, 4-pin cables used for I2C lack sufficient wires. While I considered using ICs that bridge SPI and I2C, this became a very expensive solution for what I wanted to do. Therefore, I adopted 6-pin ZH connectors as different connectors. Also, due to SPI connection, direct connection from the pendant was necessary.

The 6 pins are assigned in the order GND, VCC, SDIO, SCLK, NCS, NRESET. The pendant side has the same order, connecting with reverse cables. I actually didn't use NRESET. Since there was no occasion to reset only the trackball, assigning MOTION would be more useful.

Trackball cable pin assignment

ZH connectors are 1.5mm pitch, smaller than 2.0mm pitch HY, but fix securely. However, ZH connectors have poor finished cable availability. ZH 6-pin with terminals on both ends, reverse cable, and reasonable length couldn't be found at all, but I somehow discovered A06ZR06ZR28H305A, a 30cm cable at Marutsu Online.

While I thought distance from the pendant wouldn't be too far, feedback indicated it was actually short, so I ultimately used LCSC's Custom Cable. Without going into details, this is a service that creates cables to your specifications. While I failed several times (due to my specification errors), I successfully manufactured them, and the cable currently included with trackballs is 100cm. The price also became slightly cheaper than the original cable (when making a certain quantity).

Challenge with Bearings

Since I'm custom-making a trackball, I wanted to try bearings! This feeling existed from the design beginning, so using bearings was decided from the start. Having been a trackball user in the past, I had longing for smooth startup and maintenance ease. While bearings have an image of expensive parts, and actually searching in stores showed 150-300 yen per piece as common, searching JLCMC revealed some under 50 yen. Therefore, I searched JLCMC for small bearings and decided to try designing with them. When they actually arrived, the bearing I chose thinking it was quite small (BCTA-P-605) was surprisingly large, making design difficult.

Related to case design, since making shafts with 3D printers is difficult, I use round brass spacers as shafts, combining them with washers and screws to fix them for rotation.

Parts needed to fix one bearing

Case Design

The trackball module case was the area I struggled with most. Adjusting the distance between lens and ball was particularly difficult, with slight height differences often causing no response. The design difficulty was that adding bearings changes height. Even if it responds well without bearings, adding them often changes height and prevents response. I needed to meet conditions of suppressing overall height while maintaining appropriate distance without interfering with sensors, supporting the ball with claws so it doesn't fly out while properly contacting bearings, and struggled for a long period. The current form somehow works.

Also, the case is divided into lower base part and upper rest part. Combination is done with claws on the lower part, snapping into place. While basically not removed, I adjusted the balance so claws don't break even if removed.

Hub Edition

Currently, the hub just has connectors lined up, so there are no particular design ingenuities for circuits. Also, the case has a relatively straightforward form. There are no notable development episodes.

Note that 3D models appearing in the text so far are published on Github.

https://github.com/esplo/cue2keys_resources/tree/main/3D

Firmware

The firmware forks QMK with modifications only to user parts, published on Github. It supports full modular method and VIA (REMAP), supporting the system. Also, to realize the concept, I prepared very finely adjustable parameters for trackball and auto mouse layer adjustment, rotary encoder resolution, etc.

https://github.com/esplo/cue2keys_resources/blob/main/docs/firmware_guide.md

To realize such mechanisms, I need to dive into and understand QMK's internal processing to some extent.
First, since essential key input arrives via I2C, it can't be realized with default processing. Details are written in detail in "Custom Keyboard Introduction: How to Make Separated Keyboards", so I'll omit details, but the key input part is easily modifiable, so I modified it to suit the system.
Also, I ultimately created a trackball driver. This is because there's no consideration for states where "two or more" trackballs "may or may not be connected." While this is never a problem with normal keyboards, handling is necessary for Cue2Keys where modules are connected and disconnected. I separately created recognition parts and drivers that process multiple trackballs individually and merge movements. Processing for sensors themselves could mostly use existing code as is.
Furthermore, encoder resolution changing is also a stumbling point. While 25keys' article writes about it in detail, it's currently difficult to realize without touching core parts. In this firmware development, to maintain easy correspondence with latest versions, I forcibly realized it only with userland modifications. While behavior is somewhat questionable, it moves seemingly correctly.

Generally, famous keyboard firmware requires end users to build somewhere and generate binary files for writing when wanting more than a certain level of adjustment. This doesn't match the concept of "dynamic" adjustment, causing quite worrying days. Since QMK has many weak functions that users can rewrite and high flexibility, I'm somehow managing without touching core parts for now, but it's unclear what will happen in the future.

Summary

Writing the article too late required archaeological investigation. Development logs must be published regularly.

Keyboard development spanning over a year was a more challenging and demanding project than imagined. At each stage from prototype to production version, new issues were discovered, and I had anxious days wondering if it would really be completed. It ultimately worked out somehow, and I was able to gain much technical knowledge in the process of solving issues. Particularly impressive was the experience that constraints generate creativity. In the process of finding optimal solutions within various constraints like height limits, size limits, and cost limits, solutions I hadn't expected were born.

Being able to actually operate the modular system that was only conceptual, including key separation and fixing mechanisms, firmware modifications, was a major achievement. All basic functions were realized, and additionally, concept-supporting functions like firmware parameter adjustment could be added, which was good. On the other hand, there are still many points that can be pursued as a keyboard, with many features that can be added, constraints that can be removed, and manufacturing improvements visible. Cue2Keys is still a developing product, and precisely because of that, there's large room for improvement, and I hope it can grow into an even more attractive product.

Development is progressing little by little at present, but with many new initiatives, release as a product will likely be next year. I'd be happy if you could check Cue2Keys SNS etc. for future information. Note that major announcements are planned for (self-proclaimed) Cue2Keys Day, 9/29 (Add announcement day to Google Calendar).

脚注

1. I tried quoting products with product pages but failed. Consign Parts where parts are obtained and sent to JLCPCB for PCBA is possible ↩︎