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.”
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 -
- New infrastructure intrinsically allows more jump slots
- Number of jump slots is now a parameter, and no longer hard-coded, thus simple to expand.
- Primary code work is around UI enhancements to manage user access.
- 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.