Update post history - compilation

Time to update this thread, but I was surprised when going back that nothing noteworthy came up in the whole month of January. Anyway, we do have stuff in February:

February 3, 2020
We’re right now focused on new power management routines in new infrastructure firmware. Sleep current now testing at 900 nanoamps, (= awesome). Run time current improved too.

February 5, 2020
Target for sleep current is indeed set as proximate to self-discharge of cell, (which is the asymptote).
Cell mAh in SpaceBlade is >>> AirPod. So ==> years of shelf storage possible without degradation of cell.
new infrastructure firmware is a full reimplementation of the architecture from the ground up, to greatly expand free memory, and free-up cpu bandwidth. This makes the code much easier to maintain, and to extend - to accommodate user requests.
Hence the prior power management code was replaced to interface with all the new intelligent objects. New code does all the prior power functions, but now many more, and much smarter.
This allows much finer-grained control of which code runs at what points in time, and what hardware subsystems can be set to low-power standby, whenever catnaps are opportunistically desirable.
This gives great power leverage. The result is meaningfully better operating time per charge. The operating time is sort-of crazy-good for a 1.5 oz instrument.
The newly refined object architecture was aimed primarily at performance rather than power savings, but these too are now possible, so they are a favorable byproduct of the new build.

More detail on that in the update [DBK note: This refers to a question about how much longer the battery may last in normal use with the new changes].
here’s some high level insights -
There’s a new machine inference engine that observes user behavior and plans the best power profile.
Goal is to optimize battery life + low-latency for wakeup from catnaps.
Prior release did not do any opportunistic interleaved sleep intervals, so this is a significant opportunity to both save power, and make wake-up much faster.
Balancing those works by analysis of actual user activity data, so it involves characterization and tuning of the inference coefficients and rule set.
Early test data shows the opportunity for gain is quite significant. We’ll publish numbers with the deeper dive, and treg users will also be able to share anecdotal observations of the gains they see.
We’re working on that internally now, and we also have the ability to tune further with input from TREG user testing in field release.
The code space and cpu bandwidth gains are what make these new software objects possible.
The tuning of them is also made much easier and faster because of the new degree of high-level abstraction.
We couldn’t do any of this before we got the new firmware infrastructure platform up and running. It’s quite a boon to the functionality and robustness. We’re not fighting any memory space or cpu cycles issues any more. Lots of legroom to grow the platform now.

Btw - there is a lot more under the hood in this new release. Built specifically for -
“The people of code.”
Uniquenospacesshort -
You will see profound enhancements to the TextBlade release you currently use.

February 22, 2020 the wired mode is definitely nice, since it’s pretty bulletproof even in crazy radio noise environments.
Part of the firmware development we’re finishing right now is to also have the wired mode work even with a damaged or internally disconnected battery. There is new firmware that looks for this possibility, and dynamically reconfigures around it, to allow wired connection even with a broken battery solder joint.
The firmware for this is trickier than it sounds, since it must reconcile with all other charging scenarios. But the code we’re testing now confirms it can be done, and it looks good for this survivability case.
From current users, we found that these kinds of resilience measures are desirable because of how much they rely on the instrument daily.
We’re not aware of any other keyboard that can keep working on its wired connection if its internal battery fails in this way.
The new firmware infrastructure gave us this opportunity, so we grabbed it. It seems like the right thing to do to make it more resilient to whatever may happen in field use. Treg validation experience has shown real world scenarios exactly like this, so it’s not just hypothetical.

confirm that the new firmware infrastructure and latest Bluetooth stack allows us to use dongles that can be paired in the field, at will.
This means you can connect several dongles, and assign them to slots of choice, just as with any other Bluetooth host.
This eliminates any need for factory set-up for dongles, and lets users configure them however you like. It’s just a easy as pairing with your phone.
We had special requests from users to pair two dongles during treg validation, so we learned about this need, and have accommodated it with the new firmware architecture.

re additional jump slots -
Confirm as follows -

  1. New infrastructure intrinsically allows more jump slots
  2. Number of jump slots is now a parameter, and no longer hard-coded, thus simple to expand.
  3. Primary code work is around UI enhancements to manage user access.
  4. UI parsing is more parametric now too, so UI changes are much simpler than before.
    As a general rule of thumb, adding features adds complexity and test time. However, in the case where you rethink and improve the architecture, things can actually get simpler to maintain, and some new features are simply consequences of the new foundation, and require sometimes little or no material work to accommodate.
    The jump slot expansion here is thankfully the latter, more favorable case.
    That is not by accident, it was a known requirement in the creation of the new infrastructure, based on extensive input from users in the field.

we have a way to interface the cable that doesn’t change the design of the blades. [DBK note: This refers to a new wired mode for the TextBlade].
It’s kind of clever how it works. We’ll give details about it when we publish our TechTalk update describing the new firmware infrastructure in detail.

New BLE stack makes pairings with any host smoother. It’s an advanced Bluetooth stack. New code for our own dongle accessory has additional intelligence that also saves some manual steps through automation.

3 Likes

Been awhile since I updated this info so here is stuff from after February 22nd:

February 26, 2020
Re feature creep -
It’s always fair to advocate for focus on basics before fancier stuff.
And just to confirm, we’re not getting distracted with frills right now, we’re sticking to foundation requirements.
Obviously, now that we have this more robust new infrastructure firmware base, there’s certainly plenty of cool ideas and requests for new features that have now become feasible. So you constantly have to resist temptation, and make wise decisions about deferring those extras.
So we’re not doing those extras now, just noting them.
We’ll be able to add many new features at a pretty fast clip as general release TextBlades are in the field - precisely because of the inherent architectural advantages of the new firmware infrastructure.
What we spoke of earlier is a bit different.
The discussion about battery boot-up scenarios is a sort of a different animal.
Now that we have a new code foundation, it has its own unique requirements to make sure it boots coherently, and handles the known edge cases. You can’t just paste in the old routines, the functions are necessarily different. Any scenario that had surfaced in treg user experience must be handled, and this was one.
While you’re in there engineering the new boot procedures, that’s when you naturally confront and sort out how those nuts and bolts foundation details must work.
So there’s a natural divide between must-haves and mere niceties.

March 27, 2020
while all businesses have some hiccups from coronavirus, we can say that it does not dominate our release timing - firmware infrastructure is the main dynamic.
A few facts about our production -
We have some suppliers in China, and some of them went though outages, but they are gradually coming back online. China has made good progress controlling Covid19.
We have manufacturing lines in Malaysia, and just today, all plants were ordered to temporarily stop, to slow the spread of Covid19. They’ll likely restart next month.
We have some buffer inventory in the US, so we expect to ride it out while the Asian supply chain partners restore their capacity.
Our firmware work fortunately lends itself well to telecommuting so we’re doing a lot of that, and it does not materially affect our progress.
We’re sticking to the must-haves for feature parity with the units already working in the field.

March 24, 2020
In current TextBlade firmware, we send the option key when you apply it to an entry, like a letter key for example.
In the new firmware infrastructure, we can set this to send the option key even if you do not enter any character following it.
So you’ll likely want our newer release to play with 5 tap feature.
The normal cursor keys on your current TextBlade of course already send cursor commands to apps.
So at issue is the interaction with iPadOS’s virtual mode mode via a temporary mouse function map to the cursor keys.
New infrastructure gives us broad leeway to alter how control keys respond to your gestures so we can map this however is desirable, such as with this virtual mouse cursor mode inside iPadOS.
We think there’s some less awkward ways to get this rather than layers of abstraction in Apple’s 5-tap mouse-key mode. For example with new mouse support on iPadOS, it should be possible for us to issue mouse moves directly, without going through apple’s emulator.
Apple’s older mouse emulator keyboard shift mode has historically been a bit confusing for users, since they get stuck in it sometimes inadvertently and then don’t know why their character keys don’t work normally.
We can support it, but we think there’s likely a better way to serve the end-user’s objective.

Power-modes looking pretty good now.

March 25, 2020
We discussed working on the new power management and boot sequence code in recent posts. There were about a dozen discrete operating cases to handle. Each involve interactions between multiple cpu’s, power circuitry, and different battery and connectivity states - so there’s lots of permutations and combinations.
Each of those cases had to be coded, tested, and bench-characterized for validation.
When we last posted, we were mid-way through those. Now those cases are pretty well put to bed, and dev team members have moved onto other items needed to field the new firmware infrastructure release.
When you restructure your firmware architecture, these are lots of these kind of requirements that are emergent needs - not your primary objective, rather, they are consequential demands from the new foundation. But you still have to design, deploy and test that new code. If you don’t do that carefully, you can introduce bricking or other scenarios in your new architecture. The tests show our new methods are inherently more resilient, so we’re pretty happy with how it has turned out.
While these aren’t fancy features to crow about, they’re nonetheless critical for robust operation. The knowledge base from users like you, using the current firmware release in the field, showed us where these needs are, and prompted what we just built.
That power code part of the work began around fall, and looks to be fairly complete now. We haven’t been posting on this particular topic spanning years - we hadn’t even identified the need until after substantial Treg input from you all.

March 26, 2020
Now we’re > 90% done with this new gen2 code platform.

April 3, 2020
We also support things that are impossible for qmk mechanical hardware to do, like changing boundaries between individual keys.
We also provide velocity strike measurement, and several other kinds of criteria for customization, which is only possible with our multitouch-mechanical hybrid technology platform.

April 21, 2020
Team members are all in good health, though some of our families have been affected by the covid19.
As to logistics during lockdown here in Los Angeles, and also in our Malaysia plant, adapting to those logistics constraints has taken some bandwidth, hence the distraction from chat here.
But firmware work on new infrastructure has been moving full speed ahead, since our Dev team can work while sheltered in-place.

Plugs straight into USB port, charges and runs concurrently, presents as standard wired usb keyboard to host device. Optimum latency, and no possibility of rf interference.

April 22, 2020
You want to still be able jump to other hosts via Bluetooth, even while wired to the local host.
You also need ability to turn off Bluetooth completely, if you want TextBlade to go radio silent.
Both are supported by the new firmware infrastructure.

April 25, 2020
QMK presumes basic switch matrix hardware, and a generic single core controller.
So it won’t support our multi core controller architecture, multitouch keys, unlimited rollover, built-in display etc. The multiple cores give us 10X the compute power, and >100 i/o ports for direct dedicated sensors for each character, so there are no row-column matrix limitations like classical switches.
That said, we could see building a translator that could read qmk binaries and map them to our firmware platform automatically.
That way, code-savvy diy programmers who had a map from qmk could port it over. Need to ponder however, what percent of consumer market would want to write their own code builds vs. just using a consumer UI.
Probably easier to add qmk tap dance, leader, and other qmk specialty constructs to our firmware, to make them accessible to any non-coder consumer. Those are all open-source, so it would not be hard to replicate them.
As to finger reach, Planck is better than vanilla keyboards, since it’s ortholinear instead of staggered.
TextBlade is ortholinear, and takes it a step further with one-key-per-finger multitouch key tech.
So compared to Planck, TextBlade has greater finger spacing, yet easier reach to alternate characters. That combo is powerful and significantly reduces work for hands, and we have that patented worldwide.
Planck - 19mm finger spacing, 27mm diagonal reach
TextBlade - 21 mm finger spacing, 15mm diagonal reach.
So more room between fingers, but easier reach to non-home characters.
Note the 21 mm finger spacing is for the index and pinky fingers, which are high-demand. This gives a wider berth for keys we use most. The middle and ring fingers have the standard 19mm spacing that matches 2 foot long desktop keyboards.
To optimize ergonomics, you want generous finger spacing (21mm) together with easier cross-reach to alternate characters (15mm).
That combo, together with super low profile 5mm height from desktop, is particularly helpful to users who have carpal tunnel or rsi injuries. It’s much less physical stress than conventional keyswitches.

1 Like

Thanks dbk! Was needing my gleaned and garnered update fix. @waytools keep on keeping on and make sure to send dbk a check for all their work!