I think I've gotten the concept to a place where I want it to be. You may notice that the colour scheme is different, and that's so that the enclosure doesn't clash with LED colours. I like how it looks somewhat futuristic from its simplicity. In an ideal world, the black would be black marble:

Ironically, I've decided not to include the tenting display idea I've had, whereby the display and speakers would revolve out and create a ∧-shaped configuration. There's already a lot of features that have to go right, and I've seen the kinds of engineering that needs to go into laptop or folding-phone hinges.

This means that the solution is going to be a bit Magic-Mouse-esque for the time being as the screen would be on the bottom of the device. The current expectation is that I'd only get the Settings app done anyway, and that it's possible to create an external tenting solution that has a mirror as the base, allowing me to see the screen via it.

As one of the unvocal population of people that liked the live-tiles of Windows and Windows Phone, the expectation for the Tetent UI is to take this even further by designing entire apps as tile-shaped widgets, with the sizes being 400*200px and 400*400px (and potentially a 200*200px). These sizes are chosen because of the portrait-mounted 640*400px display prizm I'm planning for #Tetinerary [gd0151]. 

I'm planning for the sound of the speakers to come from the same gap that the Tetrinsics go into, to make them more discrete. Ideally, I can find a way to do this whilst ensuring that stray UV-C radiation makes its way out. This also means that the USBC is most likely to go on the side. Another reason for its placement is that Teti uses 90-degree USBC cables for the portable monitors.

Renders

You may have noticed that "water resistant" has started showing up on Tetent projects:

This is because I'm going to "double or nothing" and pursue water resistance. 

Part of the reason is because I read somewhere that waterproofing had to be implemented "at the design stage", part of the reason is the "#showerthoughts" phenomenon, part of the reason is the BOM price and the largest share of the reason is because the market is quite dry when it comes to water-resistant options (pun intended). Oh, and I watched the following video where an Apple executive mentioned how failure rates dropped substantially when they started adding water resistance to the iPhone.

I believe there is something called a "feature parity threshold", under which there was little reason to invent a custom solution because something else already exists and is accessible. Water resistance crosses this threshold when compared to the vast amount of input peripherals and instruments. It also puts it on parity to a bluetooth keyboard in a plastic bag, which is not possible to do with Tetent.

It also means that it's much easier to clean and can be deployed in more real-world environments, though UV-C sterilisation might be more difficult to achieve. This is because virtually all plastics are opaque under 300nm, and the ideal range for germicidal efficiency is around 265 - 275nm:

On JLC, it seems that the best (and cheapest) UV-C LED is 275nm. It also seems every LED in this category uses 6V.

The waterproof UV-C lamps use quartz as the transparent medium. There's also "UV Grade Fused Silica".

It sounds like Renesas is coming out with a chip specifically to "bridge the gap between MCUs and MPUs" with their RA8D1 which achieves 6.4 CoreMark/Mhz using Cortex-M85 (so more likely to have embedded Rust support). On its single 480MHz core, it eclipses the ESP32P4 and allegedly gets 3000 CoreMark. It also has a (relatively large) 176-pin QFP alongside its smaller BGA:

I wish these chip manufacturers also bridged the gap between QFN and BGA with something like a dual-perimeter BGA:

Even a 3-perimeter BGA seems fanout-able with 2 layers: 

Anyway, it does actually exist on Digikey in the same price range as the U5G7 and it seems that they're fresh on shelves because practically 0 data has been added for them meaning that they would've been insta-filtered out during my searches:

There's no mention of vector support, but the datasheet does say:

The 2D Drawing Engine (DRW) provides flexible functions that can support almost any object geometry rather than being bound to only a few specific geometries such as lines, triangles, or circles.

That sounds like pseudo vector support.

There's only 1MB of on-chip RAM and, for the as-yet-unavailable 2MB Flash + MIPI DSI BGA version (highlighted in green below), the extra 1MB of flash will cost £1 more than it's otherwise identical counterpart (right at the bottom of the list). Considering that I was planning to just put the firmware assets on the MicroSD card like Linux for a Raspberry Pi, the 1MB flash option is likely fine (as long as it's actually cheaper, which currently isn't the case for the available options).

Since the RAM is a bit low, the best Octo-SPI options are £1.70 for 8MB and £3.80 for 32MB, both of which are BGA.

Dropping down to Quad-SPI has many more options and at lower price points, such as 

• 8SOP
  • 20p for 2MB
  • 27p for 4MB
  • 52p for 8MB
  • 70p for 16MB
• 24BGA
  • 59p for 16MB 
  • 98p for 32MB
• 8WSON
  • 230p for 128MB

Considering that this is partially serving as a testbench, it makes the most sense to go with the 8WSON packages:

The 32MB BGA does make some sense too though, again considering that I just have to place the chip on the pad and heat it to solder it, skipping a step.

From what I can understand, Octo-SPI is more ideal as an entire byte can be transferred. Because of this, I suspect that it also has different names such as "Parallel" and "HyperBus". Searching using that, I get cheaper and larger options

• 125p for 4MB - HyperBus 24BGA (1.8V)
• 133p for 128MB - Parallel 63BGA  (3.0V)

The latter of which has a copious amount of unused pins:

Why have chip manufacturers done this???

Anyway, I've also noticed that the QSPI is clocked at 104 - 133MHz but the OSPI is usually 200MHz, so there's probably a large speed difference between them. This is confirmed in an ISSI leaflet:

ISSI’s Octal flash delivers 400 MB/s of read bandwidth, which is over 4x times faster than a Quad SPI Flash.

Anyway, it's only because of the leaflet that I found out that there's Octo FLASH in addition to Octo RAM, and it seems most of the chips I just found are of the FLASH variety. The 4MB HyperBus is indeed RAM though. The next cheapest option is some 64MB DDR2 for 198p:

Int the STM32 application note, it sounds like it doesn't really matter if it's FLASH or RAM:

Not all too sure about how it's done in the RA8 though. Meanwhile in the U5Gx, the interface can even accept a 16-bit bus at up to 160MHz. I think it's Double Data Rate too, meaning that it would be as fast as on-chip, 32-bit SRAM. There's seemingly only 2 chips that do this at Mouser:

Conclusions

All this research has given me even more confidence to just stick with the U5G7 (or potentially the BGA U5G9 if I'm feeling daring). Literally every option vs the U5Gx looks like:

Essentially, all the other options either have uncertainties (P4: release date, vector performance) or only performance benefits that I'd need to know Tetent needs in advanced beforehand to justify the drawbacks.

[June 9] 

I was thinking of the potential to use the U5Gx as the "main MCU" and a chip like the RA1 as a "discrete accelerator MCU" after thinking about the "over 3000 Coremark" claim. For a point of reference, the Raspberry Pi 3 gets 3800 single-core CoreMark points.

Currently on Digikey, it seems that only the 176-pin is available, with a different but slower 400MHz 144-pin chip £1 cheaper (that I don't think has MIPI). Coremark points would be 3067 and 2556 respectively, and it seems that, with cache on, the current consumption is 318 uA/MHz, or 152.6mA. There is another measurement in the datasheet under "Calculation guide of maximum current" that says that the current is 147mA for CoreMark.

The thing is that there's also the STM32H7 series, and the H7R3 is essentially the 2976 CoreMark cousin of the U5G7 without the conveniently large storage nor vector accelerator. It's £6.88. It also consumes 71mA. Half price, half power, same performance (specifically on CoreMark). From what I understand, the Cortex M85 is much faster than the Cortex M7 in machine learning and digital signal processing applications.

Ideally, I'd just use the H7R3 as memory is probably straightforward enough to add via dual OSPI (allowing for an addressable space of 4.7MB RAM, 8MB FLASH for £3), but the VG is doing quite a lot:

• Vector graphic acceleration
  – Path drawing (lines, polygons, rectangles, arcs, ellipses, circles)
  – Bezier curves (cubic and quadratic)
  – Path transformation (3x3 matrix)
  – Path stroking
  – Filling (event-odd and non-zero with 8x MSAA anti-aliasing)
  – Gradient generation (linear, radial, conic)

It's also still much more likely that I only get Tetent finished to a MVP status and hastily redirect my attention to other things, meaning that there is a low probability that I'd ever get to program anything that would actually use the performance.

This strategy is the idea that I can go with the U5Gx for everything I need and then extend the performance with whatever chip is suitable where, by that time, ST might have already come out with an M85 (or better) chip.

[June 11] 

If I search Hyperbus only, there's actually a 16MB HSPI-compatible RAM chip for not much more than the 4MB OSPI-compatible:

Since these RAM chips and the display prism both run at 1.8V, and the MCU current consumption is unaffected by the input voltage, it seems to make most sense to use a 1.8V main logic rail.

Another thing to note is that, even with the lower power consumption of HyperRAM, the power envelope is still in the mW range:

Thus, I looked in the 128Mbit datasheet and the read/writes are 13mA, so 23.4mW at 1.8V. This current consumption is the same as the entire U5Gx running at 140Mhz (peripherals disabled, SRAM enabled).

Since I don't need MIPI-DSI for either Tetent, Tetrescent or Tetinerary, and 2.4MB of application RAM (see image below) being relatively huge for embedded systems, it sounds like the STM32U5G7 has won this.

[June 13] I'm looking through an ST presentation and found this:

I looked into why 2 framebuffers are used and the TouchGFX site and the LTDC application note says it's to prevent screen tearing:

Double buffering is a technique that uses double framebuffers to avoid displaying what is being written to the framebuffer.

Additionally, there is talk of a "partial frame buffer" requiring RAM on the display itself. Since I'm targetting 400 x 480 (a 400x400 square-widget-like GUI and 400x80 header/footer for things like a clock), it means that a good chunk of the frame buffers might be black space.

So I'm now reading. A cool thing is that it supports resolutions up to 4096 across and 2048 down with a 83MHz pixel clock (so max resolution is 9.8Hz). The 3.5" display supports up to 27MHz, typically 19.8MHz. 

However, it doesn't seem that there are any exposed pins on the display to configure anything, so it's not like I can tell the screen to expect a lower resolution.

Also, the RAM needs to be "contiguous". Considering that ST's demo kit is 800 x 480 at 24bpp, I assume that it doesn't mean that the entire framebuffer needs to fit in a single SRAM block because that would be 1,152KB per each.

For the first point, it seems that ST is already ahead of me; a quick search soon lead me to the GFXMMU application note, which deals with this black-unused-screen stuff, even for circular displays:

• Lower memory usage according to display shape
• Fully configurable display shape
• Transparent integration
• Works with any memory of the system

So I can probably assume that 2 framebuffers at 18bpp (which is the max colour depth the 3.5" supports, and if it looks good on that then I doubt I'd need 24bpp on Tetinerary) would be 864KB of RAM and there'd be 2.1MB left available for the system. Since the first and last visible pixel per line is input to set up this peripheral, rounded corners (and probably even a PearPhone) should work to shave just a little bit more off.

Unfortunately, there's "granularity" meaning that I might not save much:

There's also this in the HSPI application note:

HSPI addressable space is from 0xA000 0000 to 0xAFFF FFFF.

This seems to imply that the max RAM supported is 268 million... something. It might be 256MB, or perhaps it's 16-bit words, thus 512MB. In practice, it's basically 256MB. Why? Well this article says:

But if your Flash chip is larger than the 256MB of internal memory space dedicated to the QSPI peripheral, you’ll need to use the indirect read mode to read data which is located after the first 256MB.

and the errata sheet says:

In indirect write mode, if the address is greater than 256 Mbytes, the indirect write is not performed at the targeted address {...} Actually, this write operation takes place within the 256-Mbyte memory space, thus corrupting
the memory content.

Indirect read operations are not impacted.

RAM you can only read to is useless. Good thing I stumbled on an errata sheet for some other chip to find out such a document even exists.

Considering the maker of #SDA - The best new PDA managed with only 0.2MB of RAM, I think I don't need to worry as much:

On a side note, I've now got to look into using removable phone batteries to see if I can replace the non-removable lipo I was planning on.

I had initially expected the copper part to be the bit that protruded by 2mm, but it didn't look right:

By making the white slot the one that extends further, it makes the top look more balanced as well as making the design look more open / spacious. It also made the RC vehicle mode look better:

The plan going forward is to add the USBC port and a 3D texture to the white side faces, which is an idea I got from the cheap USBC charger I bought a few months ago:

Additionally, I want to improve the render LEDs to signify that the LED strip is addressable not a continuous white.

The spacing between Tetrinsics is 17mm, just like Concept1.

Surprisingly, this is what it looks like next to an iPhone 14 Pro Max:

[June 19] Going to skip on the camera. It ruins the symmetry, the range would likely be so short that line of sight would suffice and the U5Gx doesn't support the nice 13MP sensor.

So while reading a tutorial to find out how many pins an SD card needs (to start totalling up how many pins I need), I found out that there's software called STM32CubeMX that conveniently does all this:

As you may be able to tell, this is the U5G7. The reason why it's not the U5G9 is because I was configuring the pinout and found out that the 100-pin package only supported either parallel or MIPI display-out. This software was very helpful in seeing all the details I missed and skimmed (and wouldn't've even bother reading until I needed to make a schematic) as well as not only knowing how many pins I have left, but the distribution of used pins.

The software has a power consumption calculator and seems to imply that 16mA is the max it would consume:

The reason I started all this was because the ESP32P4 might exist sometime this quarter (heard in Binaris discord) or sometime 2025 (heard in the ESP discord) and that has a 104-pin package, so I had the idea to use the U5Gx to get an estimate on if there would be enough pins:

One of the things I don't think the P4 has that the U5G does is a USB Type-C + Power Delivery controller, meaning that a separate chip would be needed for that. On the other hand, the dual-core clock speeds and 32MB of in-chip PSRAM means that the P4 sounds to be comparable to a Sony PSP in the compute department:

If I use a package with more pins, I could use the OctoSPI peripheral on the U5G9 to get more memory if needed. However, considering Palm PDAs shipped with 2MB and that the display buffer for Tetent/Tetinerary likely needs ~1MB, I think 3MB should be enough for now.

I also did some research into what others did when they were considering what MCU to use, and it usually boiled down to "use the highest powered chip in the series and then scale down", implying that projects rarely exceed the performance of sub-200MHz microcontrollers. One user made extensive work of the peripherals, resulting in the CPU predominantly doing nothing:

I did this by strapping together an ADC, comparator, a couple of DMA channels, bunch of timers and an intricate scheme of event/task connections of peripherals. CPU did absolutely nothing aside from starting monitoring and receiving a single interrupt after impulse was detected and recorded in RAM buffer.

Speaking of speed, I did find out about the Renesas RXv3 CPU core, which has obtains 5.8 CoreMark/MHz. The U5G is 4.1, the ESP32C6 is 2.9 and the ESP32P4 seems to do 3.0 if it's getting 2400 across both cores:

Unfortunately, even though the RXv3 core came out in 2018 and the chips it's in feature a double floating point unit (that I probably won't use), the (Rust) toolchain for it seems to be non-existent in 2024. This is another concern point for the P4 which, since it's not out yet, toolchain support would lag further behind.

Anyway, I only decided to do that research after looking into potential leads in the MPU side of things. From what I gather, the lines between MCUs and MPUs are starting to blur these days, with the only notable difference from my point of view being that they usually only come in BGA packages and support DDR memory controllers.

One of the first things I did was look into SoM's like the i.MX 8 but the lowest was still over 1000mW:

I looked into what processors are used for smartwatches and Cortex-M33 makes an appearance here, just like in the U5G:

One of the MPUs on Digikey was the STM32MP1. I can't really understand this table, but the note at the bottom does seem to reflect the sentiment (from Reddit research) that one would usually be fighting against Linux when it comes to low power consumption.

It was at this time that I decided to look into DDR costs. IIRC, the MP1 accepts up to 1GB, otherwise known in the RAM industry as 8Gbits. I looked at the options and the 2 that made financial sense was a 64MB and 512MB chip:

Considering that the PSP used 32MB and the ZGPAX S8 smartwatch I used to own ran the entirety of Android 4.4 just fine on 512MB, I think the cheaper option would be best unless something like an embedded CAD software needs more than 64MB.

Anyway, the actual price and package of the MP1 means that it's not really an option; it costs £15 alone so would be £16.50 with 64MB of RAM and it has 448 balls in it's package. Instead, what makes more sense would be the SAMA5D22, an £7.60 chip that supports up to 512MB of RAM and 196 balls that are spaced 0.75mm apart:

When it comes to BGAs, what I really have an issue with is the fanout, not really soldering the thing. If anything, it's easier because I theoretically could just line the package onto the pad and heat up. 

The SAMA5D2 Series uses sub 150mW peak and has support for 3D graphics with the NEON Media Processing Engine. Still, I don't think it's worth the effort over using the U5G7, which seems to have everything I need in a single package at the moment.

[June 8] 

There's also a new Apollo510 "System on Chip" that sounds like it's on its way. From my perspective, it looks and acts like your typical BGA (0.35mm) MCU, but its older Apollo 4 chip is also in the "SoC" section of Digikey.

Notably, it's also got a 2.5D GPU with vector acceleration and 3MB of SRAM, as well as a MIPI DSI that can transfer data faster, but has a max resolution smaller, than the U5G9 for some reason.

It has bluetooth connectivity, so hopefully this SoC gets put into a BT module similar to the ESP32 or nRF52 modules.

You may be wondering why a peripheral input device such as a mouse or keyboard would need to have a remote control. It probably doesn't, yet might only add up to £20 to the BOM of each Tetent depending on how fancy a camera (if any) one wants to install, and it adds quite a bit of fun and excitement to an otherwise engineered-from-necessity project.

I've been imagining things ranging from potential promotional videos to  proposed features over the past day or so, such that unless it's infeasible to manufacture, my next Tetent Concept will be a set of Tetrinsics on a 12mm thick curve:

I've been part of that 2-in-1 Laptop club for years, remote controlled scene for even longer, and liked that one Eggman scene in The Sonic Movie where a single vehicle had multiple smaller ones in it.

This tangent is based on the following observations:

• The MVP solution already has almost everything needed, physically speaking.
  • As a vehicle:
    • Motorised tracks that use FOC to allow for full torque generation.
    • Pressure sensitive to allow for adaptive traction control.
    • LEDs for headlights, tail lights and indicator lights.
    • Speakers to emulate vehicle sounds.
    • An SD card reader to store music (and can also store video)
    • 2.4GHz connectivity.
    • USB Type-C that could be used to connect additional hardware.
  • As a controller:
    • An outdoor-readable screen for viewing a camera feed.
    • A way to emulate one-dimensional analog sticks and even a gear shifter.
    • Speakers to emulate either vehicle sounds or police chatter.
    • 2.4GHz connectivity.
• A small camera is the only notable omission from the vehicle mentioned yesterday.
• Mounting hardware is the only notable omission compared to a motorised camera dolly for photography equipment.
• The U5G9 (and P4) has a camera peripheral and USB OTG.

This could be like the "pro" priced, advanced incarnation of the Hot Wheels stealth rides that I owned more than a decade ago:

I looked into the widest-angle, autofocus cameras I could find on AliExpress and I found 2 options:

There's a 5MP OV5640 and a 13MP IMX258, with the latter also having a larger field of view. The latter also sounds to have an ultra-fast autofocusing method. The following 2 videos are with the feature off, then on:

Considering how expensive Tetent is already estimated to cost, and how time consuming it would be to even add the feature, I'd most likely just go with the IMX258 because of the aformentioned features and that "13MP 4K" sounds cooler on paper, I'm planning to use Tetent for years so the £30ish BOM difference is easier to swallow, and HDR is supported. One of the drawbacks is that the datasheet isn't easily available, unlike the 5MP camera. Another one is that it uses a MIPI-CSI interface, which is just one more reason to wait for the ESP32P4 over using the STM32U5G9 today.

The camera would be mounted on the 45-degree bend of the curve mainly so it fits in the first place, but also so that 50% of the feed isn't the (out-of-focus) floor. One of my ideas was to have an inverse "Centre Stage" feature from iPads, where moving the controller (or the head with Tetinerary) would smoothly pan around the frame, instead of trying to stuff the entire view into a 400x400 area. I'm planning to leverage the "proprietary 2.4GHz" feature of the nF52833 for sending camera data if BT is too slow.

Additionally, I've got to find space for (camera) mounting hardware so that things can be mounted to Tetent, but also so that Tetent can be mounted to things (e.g. a chair or desk):

I'm also wondering if the "angle of attack" feature that the bluetooth modules used in Tetoroidiv can be used to emulate a kind of Blur IRL game mode.

This feature-tree of ideas also adds even more incentive to make the design water resistant. Imagine this: an ad that switches between someone calmly using Tetent as intended in a window-lit library on a wooden desk and it driving in the rain and mud at night whilst glowing like a snake in slither.io and sounding like a line in powerline.io.

Speaking of glowing, I found some 300 led/m strip, but it's £25/m and doesn't come in a diffused option:

Whilst the 2.7mm COB visibly has gaps in light intensity, it looks good enough and is 1/5th the price per metre.

Screen shortlist

I tried to find some options that could fit on the side of Tetent (like many of the past concepts) but it makes little sense from both an ergonomics and bundle adjustment perspective.

I'm going to be designing a square GUI for a better Tetinerary solution, and that allows for these options:

Coming in at the same price as the first transflective screen, but without the £7 delivery charge, the 3.5in Blanview is the best available in LCD technology, featuring all the benefits and little of the drawbacks:

Looking at the top graph, it seems that the backlight uses 40mW in bright ambient lighting conditions. In stark contrast, the transmissive, 1000 nits 480x480 panel (KD034WXFPD002) uses 768mW and the transflective 480x640 panel (FS035VG083-C035A) uses 372mW. Both these values are right on point to what the graph shows.

One of the benefits of the 480x480 is that the GUI would look slightly larger, and that 2 panels is the same price as a single Blanview panel. However, as mentioned in the Bundle Adjustment log, I could develop with the entire 640x400 resolution found in the prism with the Blanview.

Considering that my (not so temporary) "temporary" keyboard has now been in use for about 3 years, I think it's in my best interest to just go with the better panel upfront.

Slide out screen?

So this is all well and good, but the issue is actually placing the screen somewhere. As I've said in a Tetrinsic log somewhere, I had a "sigma" character inspired design. What I haven't yet mentioned was that I found a new belt type (5PH) and considered a 15x150mm Tetrinsic (with a 15mm diameter body, 46mm rotor length, custom motor), but there is only one type of 0 - 500g FSR available on the market and all the 15mm strip ones are 20 - 10000g, so much less likely to work well for this application. That 0 - 500g FSR has a max sense length of 85mm. The 5PH284 belt is the most ideal.

In pursuit of thinness, I made the bracket-style design. The main benefit is so that it can fit in a pocket. The easter-egg benefit is so that I can design an RC tracked vehicle mode:

Since Tetent was also a bit of a stop-gap to Tetinerary, I did consider doing things the Apple Magic Mouse way and mount the screen on the bottom:

However, there may be a way to do the inverse of the PSP Go, where the screen slides out from under the input panel instead of sliding out to reveal the input panel. If I decide to focus on the 1 : 1 GUI, I could also employ a LG Wing strategy, where the screen swivels out.

The engineering challenge is going to be to fit a screen, 3Ah battery, 2 speakers and a PCB into a thin formfactor.

Currently reading the comments in the below video to get more user insights as to what expectations and notable mentions come up for a peripheral that aims to replace the keyboard.

What commenters were saying

• Accents / other languages
  • This understandably comes up a lot, and I specifically saw "spanish" more than once.
  • Considering that the original Tetent idea was to chord bigrams and me-in-the-past considered it fast enough to start the project, the idea I've got for all the accents is to dedicate 2 fingers to characters and one to accent modifiers.
  • I've also got to look into what is required for non-latin languages like Japanese / Chinese / Korean / Arabic. 
• Ambidextrous / one-handed support
  • This is one of the reasons I personally decided to start the Tetent project without first trying out Charachorder.
  • I looked into their discord after seeing a few of these comments and there is a 1-handed layout but it seems that users would like a foot-pedal so that they can access modifiers on the other side more easily than the current method.
  • Unfortunately, the Master Forge seems to only have thumb buttons on one side so it's still not ambidextrous.
• Game compatibility
  • I'm hoping that the macropad and Xbox inspired layouts addresses this.
• Learning curve
  • Also mentioned quite a bit.
  • I also noticed when the creator said "I have chords for every single thing here" when he got to the words section of the online teacher, implying that you manually have to set up chords still. This is the other reason I started the Tetent project.
  • Other than moving the user's fingers to exactly where they need to go and applying the haptics they should feel when pressing, I don't think there's more that can physically be done to ease the learning curve. Tetent needs to be able to do this.
• Accessibility
  • This ties in with one-handedness, but they also mentioned about missing fingers and poor motor control. 
  • I don't think Tetent could reasonably do anything about poor motor control, but typing in english should only need one finely-controllable finger and one kinda-ok-controllable finger. 
    • This also ties in with the learning curve, as users can start off with just 2 fingers and scale up if they feel comfortable.
• Wireless
  • I also agree. As I've previously mentioned, I usually don't work at a desk, and so my mouse and keyboard wires are more tedious than I initially expected.
• Younger generation
  • I read a quote a few months (maybe years) ago; "get them in when they're young and impressionable".
  • It's understandable that users wouldn't want to learn something new that might or might not be better than what they already know. It's a very different calculation when "what they already know" is (near) 0.
    • (This is part of the reason why I'm planning on programming Tetent with Rust; I don't know enough about C/C++ to make an entire FW so, from a learning curve point of view, those languages are approximately on equal footing.)
  • For this reason, I'm trying for a 16mm wide #Tetrinsic [gd0041] to accomodate for smaller hands.
  • It would be even better if I could design some mechanism where a user could turn an allen key to fine-tune the spacing, or perhaps just mount the Tetrinsics onto user-accessible slots,
• Price
  • This is probably the main thing that keeps on getting worse the more I engineer a solution. 
  • I think a Tetent-like device would have to be sub-£60 to have any sort of "mkay, perhaps I should try it" appeal and, due to the prices I've been quoted for #Tetoroidiv [gd0152] motors, Tetent's unfortunately never going to come close.
    • I'm designing this for the hypothetical user that are unsatisfied with the keyboard+mouse combo anyway, so maybe £90 instead of buying a £60 keyboard and £30 mouse?
    • I'm starting to understand why AliExpress robotics kits with decent motors instead of shaky-and-loud hobby servos cost what they do.

Introduction

In computer vision, Bundle Adjustment takes multiple images and refines the estimated camera pose between them.

I've been spending the past few days manually doing something similar with the projects Tetoroidiv, Tetrinsic, Tetent, Tetrescent and the newly renamed Tetinerary (which has been renamed from Itinervate as a direct consequence of this Bundle Adjustment).

I've decided to write everything in this log so that I can refer to it in subsequent logs in their respective projects.

Considering the phrase "Form vs Function", I'm designating that Tetent = Form and Tetrescent = Function, in that the aesthetics would be prioritised in Tetent and the functionality will be prioritised in Tetrescent.

Transflective Screen

The bundle adjustment started when I started searching for screen options when bundle adjusting for Tetent and Tetrescent. Tetent would be fine with a small square screen, but Tetrescent needs to be large enough to reasonably be used as a typing tool, such as Freewrite. 

I also had the idea of having a similar design for Tetrescent, where instead of a sigma, the side profile would be closer to '>_', resulting in the screen having a 30 degree angle up from the desk plane.

Not wanting to have to create UIs for two drastically different screens, I decided that Tetent would also use the same screen that Tetrescent used. 

Since Tetrescent is obviously designed to be used outside (where the sun is), A transmissive screen could not be used. I also strongly oppose sub 60Hz framerates, so an e-paper display wouldn't suffice either. It's possible to design a monochrome UI, but colour would be preferable. Noting some of the complaints people had with the Playdate and the LED mods implemented into the Alphasmart devices, I also needed something that could illuminate in low lighting conditions.

The first option I decided on was the Asumo 3.4" colour which is £63 on Digikey, which is higher than the £50 I budgeted for the screen but it had the dimensions I was looking for and front-lit. 

Then I found out that a 3.5", 640 x 480, transflective screen existed. It uses MIPI though, so not exactly ideal. What was ideal though, was the resolution. Tetinerary, formerly Itinervate, uses 640 x 400px optical modules, and this resolution is also very prevailent in the AR glasses industry. If I could implement this transfelctive screen into Tetent/Tetrescent, it would mean that I could then port things over to Tetinerary very easily with minimal circuit changes. It also meant that I could develop, test and validate the software (and battery life) on cheaper hardware before committing to creating Tetinerary.

The optical module uses RGB888, and I was able to find a similar RGB666 transflective screen from the same supplier, only it's out of stock:

Eventually, I was able to find a practically identical panel on AliExpress, and it's within my budget too:

Next, I looked to see if there were any YouTube videos of the panel and there is one that shows that it surprisingly has excellent viewing angles, which is important for Tetent as the screen will be aligned with the desk plane (i.e. facing straight up).

As the panel was 3mm thick, it made more sense aesthetically for the top part of the sigma to go over the Tetrinsics (instead of the Tetrinsics cutting into it). This then opened up the possibility of putting a 3Ah battery under the panel and small stereo speakers (the same ones that have been featured in concepts in the past) facing towards the user. I'm going to be using dual speakers per ear for Tetinerary, partially because there likely won't be any space for a single speaker over the ear and partially to obtain planar 360 degree audio. 

The battery move was important, as I hadn't gotten the power performance I wanted out of initial Tetoroidiv simulations and a good solution needs more space than what a 238mm belt can provide. Conveniently, there is a 268mm v-ribbed belt available in both orange PU and black rubber. I've never felt either, but the black rubber belt is more aesthetically pleasing so I'm using it on Tetent. Tetrescent requires 340mm long belts, which only comes in PU.

Microcontroller and OS

A VGA screen needs an input video signal, and this the hurdle I was at with Tetinerary. Typically, microcontrollers (ESP32S3, RP2040) can't run particularly high framerates, especially for something like 18-bit 640 x 480. There have been some 3-bit solutions written. I also had concern about actually making the UI look nice and have fluid animations. I worried that, due to the low hardware performance of MCUs, the libraries that exist would only allow for basic graphics.

On the other side of the spectrum, something that can run Linux or Android would open Tetent to a large suite of already-written apps, as well as MAUI support. One potential issue is power consumption, but "full android" smartwatches exist and get about 6hrs of runtime on a 600mAh battery. The bigger issue is dealling with such huge software projects. The options that exist are for general purpose hardware, and Tetent is quite the opposite. There is a chance that implementing all the changes needed to make Tetent work well would actually be more labour intensive than writing firmware and all the applications for a micrcontroller. Similarly, many of the apps that I want on Tetent don't even exist on these platforms anyway.

One thing that makes the MCU route more palatable is the existence of Tock, which is a Rust-written project that claims that I can write 3rd party apps (like a more traditional OS) and used to run smartwatches. I've been reading about embedded Rust recently and it sounds more beneficial than C++, so I'm planning to use it as my "backend" language and have C bindings so that I could use F# + MAUI for other targets. In this way, I could develop applications that can run on microcontrollers, microprocessors and standard processors with a shared core codebase.

I then rediscovered the STM32U5 series, with the STM32U5G9VJ sounding quite ideal. It's a low-power MCU that can output RGB888 or 2-lane MIPI DSI, and they've tested it on a 800 x 480px display. This chip also has enough ADC channels for 5 Tetrinsics, with loads of channels to spare! There are 2x 14-bit ADCs that have 20 multiplexed channels each and have a nifty-sounding dual mode feature, and all this can run at 2.5MSPS. This means that I could sample all 10 current sense inputs, and then all 5 force sense inputs, and do it at 250kHz. It makes sense to use the 512x oversampling feature to get a final read speed of 480Hz. There's conveniently even battery voltage monitoring, which could be read from the additional 12-bit ADC. 

There's also some fancy sounding "multi-function digital filter", where "motor control" is one of its target applications. This brings me onto my next point, which is that it sounds like MCUs typically struggle with generating the PWM frequencies for BLDC control. For example, for SimpleFOC, many microcontrollers support 3PWM output but much less support 6PWM. I looked into it, and it turns out that 3PWM drivers are more ideal, but cost more than 6PWM drivers. Well, I think something even more ideal would be for the MCU to just tell the controller over SPI what PWM it should be driving and it handles it. I believe that's what the DRV8311 does. With this, I hope it's possible to drive 5 motors from the single ARM-M33 core of the U5G9 chip.

Recently, a motor with an integrated absolute encoder was discovered and posted on the SmartKnob discord, and its specs are great. The TLE5012B E3005 has got a 16-bit ADC and can communicate with an SPI compatible protocol. It's also £1.15/ea on AliExpress.

With all this in mind, and in an effort to reduce the PCB space requirements of Tetoroidiv, reduce costs, simplify PCB manufacture and minimise the toolchain complexity of this entire project suite (e.g. flashing firmware), I've decided that Tetoroidiv won't include an MCU and the U5G9 will (attempt to) run everything.

I'm finally starting to revamp and equalize all my details pages so that the projects can be better understood and information hidden within the depths of logs can be more easily found. The below is the old Details page.

---

Notable Tetent projects, sorted by project log count:

• Input element: #Tetrinsic [gd0041] 
• For Teti: #Tetent [gd0090] 
• Wearable: #Tetent TimerSpy [gd0136] 
• x86 PC Handheld: #Tetent UMPC [gd0149] 
• Desktop: #Tetent TestCut [gd0139] 
• Solar Powered: #Tetrescent [gd0150] 

Tetent is primarily for #Teti [gd0022], and it's a good idea to think of Tetent as an input device for Teti similar to how the PS5 Dualsense Controller is an input device for the PS5. 

I'm looking to control my PC from the perspective of a console. Most games designed for a specific console can be fully controlled using the standard controller. Playing Forza with a steering wheel controller feels more suited to the game, but the game can still be fully played with the standard controller.

Input devices I'm trying to consolidate into a "PC controller"

• My keyboard
  • My WPM is 60 and it seems like it'll take many years of continued effort to double that. Even if I got to 120WPM, it still would be too slow. After thinking of the R.O.I. of the continued practice, it just doesn't make any "time-finacial" sense.
• My mouse
  • I'm almost never on a hard, flat surface anyway.
  • Even if I was looking for a new mouse, there's no ambidextrous 12-side-button "gaming" mice.
• The 3D mouse that doesn't exist yet
  • I'd like to be able to select UI elements that are behind other elements, such as shapes in PowerPoint or edges in Fusion 360.
  • Likely more suited for Mixed Reality experiences.
• My Spacemouse / 6-axis mouse
  • I've got an old Space Explorer and it takes up my limited desk/table/lap/reachable-floor space and I constantly have to be switching between it and the keyboard.
  • I've also tried to use this as a 2D mouse, and wrote about my experience here.
• The touch input of my touchscreens
  • I really like touchscreens but the issue with them is the lack of precision, occlusion and the abundance of fingerprints.
  • The lack of precision means that I need to spend more time retrying to press a UI element.
• My drawing tablet I rarely use
  • I mainly got it as a touchscreen input alternative for Teti for when in triple monitor mode and for writing digital maths notes.
  • Being able to sketch out design ideas with pen pressure is also ideal.
• My MIDI keyboard I rarely use
  • It's even larger than my keyboard, and I didn't like the key travel distance.
  • I'd like to be able to capture melody ideas wherever inspiration may strike.
• The XBox controller I rarely use / PS5 controller I never had
  • I think it'll be nice to bring over some of those DualSense controller haptics over to Tetent. 
    • It's unlikely to be as sensory as haptics across the entire palm, but it's likely better than 0 haptics at all.
  • Ideally, Tetent will be able to control some racing game or Minecraft ergonomically. Additionally, whilst I don't play any FPS games, being able to quickly and accurately click on GUI elements seems similar.
• The finger massager I never had
  • Every slider is motorised; might as well also use them to try and mitigate any fatigue while typing.
• The ASUS laptop dial / Surface Studio dial I thought was really cool but have never used.
• The high bandwidth VR controller that doesn't seem to exist on the market (as of 2023) for working in virtual reality.
  • I've got to be ready for when a Pimax 24K or similar headset finally drops.

Fast typing method

I like to think of Tetent's default layout as the next Pokemon evolution of chording keyboards: "parallel entry". 

For a normal keyboard, which would be "serial entry", you'd have to make sure all fingers are perfectly timed so that the characters appear in the correct locations of the word/sentence. Failure to do this causes a few typos ("hte", "ot", "wit hthe", etc) and also makes it somewhat difficult to increase speed. For "chorded entry", pressing more than one specific set of keys results in a new character, dictionary phrase or action. 

For parallel entry, the same layout exists under each finger (except one of them for modifiers / layers). For Tetent, different characters are selected by changing the position and force of a finger. Therefore, while "eee" or "..." might have to be some custom, seemingly arbritrary chord on stenography or CharaChorder, on Tetent it'll be the same position and force on 3 fingers. 

Any gaps (eg "e" was pressed Finger2 and 4) will be merged (to produce "ee")  and the same can be said about the left and right Tetents ("hom" on Tetent-L and "e" on Tetent-R will result in "home" being sent to the host device). 

Note: The thumb = "Thumb1" / "Finger1" and the smallest finger is "Finger5".

Example

To write "a.keyboard.readChar() {", this is what will be seen on the host device, entering 4 - 6 characters per chord:

•  
• a.key
• a.keyboard.
• a.keyboard.readCh
• a.keyboard.readChar() 
• a.keyboard.readChar() {

I've also put modifier keys (ctrl, alt...) in the default layout, so if you know you're going to be doing multiple keyboard shortcuts at once (for example, ctrl+a, ctrl+c, alt+tab), you can just do that as 1 chord. 

• Tetent-L: CTRL |   A   |  CTRL
• Tetent-R:    C    | ALT |   TAB

To get a better look at how entire sentences are written and the motions of fingers, I recommend to see this Tetrinsic log.

Flattening the learning curve

From researching stenography and CharaChorder, I've learned that a fast layout is near useless if the learning time is very slow, so I've had learn-ability as the top requirement. 

If you're a person that only uses 1 finger and 1 thumb, Tetent is still perfectly usable. More fingers just means more speed, but they are optional additions.

Moving on, the dual reflective LCDs (with backlights) are used to show:

• Finger positions
  • Due to ergonomics, the user likely won't be able to see see finger placement.
  • Even with mirrors, the distance the fingers actually move is rather small and so isn't really all that obvious that they're in a specific location.
• A force list of characters at the last moved finger position
  • For example, if you moved Finger2 and only Finger2, you'd see all the "keys" mapped underneath Finger2's current position. 
• Search results for looking for a specific key / macro. 
  • I had a "Let's Split" ortho. I couldn't remember where anything was in my keymap.

I think that the feature that's really going to cut down the learning curve are the motors in each #Tetrinsic [gd0041] that will be able to move a users fingers to the correct position, as well as send haptic feedback that the user should expect to feel when pressing the virtual key. I also hope to implement things like Simon Says and typing ghost games/features.

The layout could be a bit like a rotary phone, where the Tetrinsics exert a spring-back force to the "home row" so that the user only has to concentrate on the haptic events leading up to the virtual key press. To put it another way, the user can think 

• "I know [insert character here] is [x] detents from [character E] and [y] haptic clicks down" 

instead of 

• "Ok my finger is at column [w] which was [z] detents from [character E] so I've got to move [a] amount to be at colum [b]..."

where [character E] is the equivalent "home row" position.

You can start practicing by pressing "426" and then "153" simultaneously on the numberpad to get used to the finger motions, though I'd imagine Taipo to be a more accurate representation.

Tetent's initial requirements

Even before writing all these Hackaday logs, I knew my future was going to be full of typing. What I needed was a new character input solution that satisfied most or all of the requirements:

• Easy to learn 
  • Research revealed that stenography and CharaChorder is slow to learn to a speed of >150wpm.
• Small enough for use with a smartphone
  • So that I didn't have to learn a mini and regular layout.
• Theoretical speed ceiling of over 240wpm, ideally 320wpm
• 1 handed typing at speed (>100wpm)
• Wireless and wired connectivity
• Usable with fingernails (5mm length)
• Screens for knowing what character/command will be input
• Higher bass speaker than what is available in Teti's (EQ-tuned) portable monitors
• Ideally LED backlit.

Conceptually and hypothetically, I've addressed or exceeded the requirements. 

Tetent can be used single-handedly or dual-wielded. It is also ambidexterous and reversible (like USBC). It uses #Tetrinsic [gd0041] slide encoders which allows for software adjustable actuation force, haptic feedback and appearance. For the mechanical keyboard enthusiasts reading, it means the look, weight and tactile feel can be changed when desired for each finger, though I should mention that the travel distance is measured in microns. 

The Tetrinsics also physically move your fingers to ease the learning process, as well as allowing for a handful of different behaviors like momentum, detents, free scroll and spring to center. Due to the stainless steel ball chain, there should be less slippage than flat, plastic keycaps, further reducing typos. Also, the finger doesn't need to be lifted at all, unlike traditional keyboards.

I only need to perform at least 1 chord per second to equal my QWERTY typing speed of 65 - 80wpm. If I can get a consistent 3 chords per second, I could be typing at up to 260wpm for a good amount of time and not the <15 second bursts I've seen on YouTube. I consider 4 chords / second as "full speed", typing in sync with 120/240bpm music, for an estimated average of 312wpm (max is 32 characters per second (384wpm), or 24 without a single space (288wpm)).

Now I just need to make Tetent a reality.