Waytools: What’s the latest info on updates?

PM sent.

Best wishes for a speedy and complete recovery of all affected! I assume it’s not easy to focus on work while loved ones have to deal with covid19.

And thanks for this sign of life! I really appreciate hearing from you and I would be even happier if you could give us a hint regarding that order status page. Has it already been updated and is “winter” the new status?
Also, as you mentioned that new infrastructure in your message, could you let us know what is your schedule for completing work on the new firmware?

1 Like

Just to keep my interest in TB active; are you still willing to do s “show-and-tell”? :wink:

@waytools I don’t think there are enough TREG users in the EU/NL. This really hurts my (and any other UTC-UTC+5 users’) sleep-profile since I (we) have to stay awake longer to match up timezones :wink:

1 Like

Yes, Would love to. I have no issues setting up several sessions to cover multiple time zones. Within the next few days I will start a new thread and have an entry for each meeting time. This way I can collect specific questions for each call but will try to answer all questions in all calls. I will also post an base outline I would cover at the beginning of each call. FYI, I will specifically send the agenda to WayTools so I do not cross any NDA boundaries and still share as much as possible.

My plan would be for calls at 6am, 12pm, 6pm, 12am for up to 2 hours each, All in US Boise, ID timezone MDT (UTC/GMT -6:00 hours).

Would most likely be on a Saturday, May 9. Could also split across a couple days


Awesome! Count me in(terested)!

1 Like





Tlrogers: I won’t be able to attend, but I certainly look forward to the video. Thanks for doing this. I only hope it isn’t too much longer before I can finally get a TextBlade…

1 Like

Hi @waytools
It’s been a tough month for everyone and I hope everyone from the team is safe and doing well!
I wanted to know where we stand in terms of overall firmware progress.

In Nov '19, you gave this update:

So, in terms of feature parity with gen1, are we at >95%?
It doesn’t need to be precise, I understand that especially in these last stages, it’s difficult to quantify how many nooks and crannies are left to navigate. But can you try to put a rough number to it?
Perhaps a better question to ask will be: Are we at a stage where you’re able to give us a timeline for TREG release of gen2 (:crossed_fingers:)? If yes, what is the timeline?

The last update in March was that the power and boot sequence firmware are done. So what areas are you focussing on now?

Thanks and stay safe!


Perhaps WayTools can replace my previous textblade when the G2 release comes out. (I am the guy who left his in a plane in Spain).

Don’t forget the 80/20 rule: The first 80% of the work takes the first 80% of the time. The remaining 20% of the work takes the second 80% of the time. :wink:


1 Like

I hate to bring this up, but we are two weeks from when WayTools said they needed one more day to finish the big status update - a year ago!

I guess we are all in the “We’ll just wait and see if it ever ships” stage at this point. And I’m lucky that I’ve certainly gotten more than $100 use out of my treg units. Still, I’d like that big update.


Based on the last TREG video, the textblade looks like it is in good shape for general use.
I think that 99% of those on the forum would be happy enough if waytools were to simply ship it with that firmware that looks to be working well. Instead we are waiting for firmware v2, with no firm completion date.

It’s so frustrating that Waytools won’t clearly describe the status of the firmware in development.
For example, “we think that we’re about 80% through, and we estimate that it will take us another 6-12 months to complete this development before we can roll it out to the beta testers.
There are currently no other outstanding hardware or other issues that would stop us from shipping.”

I would also like to know how many people are writing the firmware, e.g. “We have one person writing the firmware part-time”, or “We have 3 people writing the firmware full-time.”

I am guessing that the software developer(s) have changed since the start of the project and that may be one of the motivating factors behind the rewrite. Perhaps the current software developer is taking a break or quit and development has been suspended until a new developer(s) can been found?
Before someone (justifiably) points out that this is baseless speculation, Waytools could easily put this matter to rest by providing some transparency.

This complete lack of transparency begs the question is it really only the firmware that is delaying shipping or is something else going on?


Linux4ever - understand your question -

FYI all the developers completing the new firmware infrastructure are original team members that developed the current release that’s been successfully in use by treg users.

These developers‘ personal knowledge and experience through delivering and servicing a real product to treg users is key. It is in fact what drives their motivation to build and validate the new infrastructure release. It answers the wishlist latent needs surfaced by our users’ experiences.

Nothing compares to daily use by real world customers to learn the refinements required. More companies introducing new technology would benefit from similar efforts.


Agreed. Which is why I really think you should look at your records from treg users and identify just a few who had particularly difficult issues, especially since the last firmware, and have them involved in testing now. After all, if they continued to have problems all this time, it would mean you can’t be sure you have solved them with the new firmware unless they test it and report back positively! To me, it could mean that whatever steps you are taking in the new firmware to fix their problems may turn out NOT to be the solution!

Just seems it would be best to double check with those people now. I’m pretty sure these would be in very limited areas - probably mainly to do with connection/lagging issues some have had in apparently difficult environments. At least I don’t recall much from people reporting other potentially serious issues over the past nearly 2 years. They could be testing those aspects as you continue with any other areas in need of completion.

1 Like

Careful what you ask for, you’re riding a slippery slope here.

Short of shipping you a Faraday cage to install in your environment, how do they determine that the problem is with the hardware, the new firmware, or just your environment?

But to play devil’s advocate here for a bit, lets say the WayTolls decides that you are right and ships the new firmware to a select few who have had connection/lagging issues. Also, for easy of this example, when I say you I mean all those sent the firmware to test. So you are happily typing away, testing the new firmware and have major issues but these are totally random and not repeatable or at least you haven’t found the pattern yet,.

Where is the issue?

  • Is it in the current hardware?
    So, in talking back and forth with Tech Support, you seem to determine that this is a hardware issue on your end and WayTools send you new hardware to continue testing with. You get it and proceed to continue testing. The problem is better but still happening way too much. With another week or more of back and forth with WayTools, you finally determine that it is not a hardware issue.
  • Is it in the new firmware?
    Next step (these work the same in any order btw) is that it must be a firmware issue. So you and Tech Support are back and forth, them asking questions, you telling what you are seeing and when it seems to happen, again, there is no rhyme or reason to when it occurs that you have found that makes it repeatable. WayTools are taking the time to troubleshoot this issue by scrutinizing the new code line by line, trying to find the reason for your problem. After several more weeks, it is determined that it is in no way related to the new firmware.

We’ve now wasted at minimum about a month (or more) of development time that could possibly have been spent completing other areas of the new firmware.

  • Is it in your environment?
    Ok, so after a month or more, it is found that the problem is in your environment. I realize that this would most likely have been brought up sometime through the previous month but maybe not seriously. So now you have Tech Support trying to help you determine what, if anything you directly control, is causing the interference. You’ve said before that you live in a condo complex. The interference could be coming from your neighbors and therefore nothing you can control and not a problem with the hardware or firmware. But because Mark and the other Tech Support guys are so nice, they keep trying to help out. We’re not at a minimum of a month and a half, most likely more trying to fix a problem that can’t be fixed (unless of course they send you a prototype of the new wired USB adapter).

WayTools have already spent a ridiculous amount of time troubleshooting Bluetooth issues that are not theirs, not caused by the hardware, not caused by their firmware, but are in fact a result of sloppy support on the part of Apple, Windows and others in their software. These seem to keep coming back in newer software releases from these vendors as well, so it’s not something that you can permanently make off as fixed.

That’s just one scenario. Don’t get me wrong, I’d LOVE to get the new firmware for testing now as well. But for now, all I can do is beg WayTools to please hurry!!!


I just want an update and an estimated release time frame!!!


Dbk - Definitely smart to start validation with a cohort of current treg users. That’s exactly our game plan.

JMacRury - Insightful engineering observations, thank you. One of the major upgrades is to the breadth and depth of diagnostic logs on the new firmware infrastructure platform. This makes it far faster and easier to find and fix any bugs with much less human labor from users and developers.

Ergo we want all that new diagnostic power in the first releases to the testing cohort. It provides great leverage to complete polishing much faster.

Like most investments in stronger infrastructure, the advances are not perceptible until you’re suddenly standing on them. While it’s fun to taste the incremental progress, it’s more efficient to focus on finishing the new foundation and then shift bandwidth toward users exercising it.

Industrial-strength diagnostics are the winning strategy here. TextBlade is a network of many processors and machine intelligence inference engines, and it has grown much smarter through user validation. The infrastructure for quick software response to user observations - better than what you see even from major players - that is the defining strength that will widen our lead over others. No one has made this same level of investment for keyboards. The strengthening of the infrastructure was more work than we expected to tackle, but it is already now quite powerful, and we think it will prove its worth.


My proposal would be to start with providing new TBs to TREGers with the new firmware to begin with to give a before and after for comparisons. IF this is possible and we can toggle between old firmware and new firmware on the old and new devices we can compare and contrast in the wild and also toggle between old and new firmware on each old and new device. This would allow for the widest range of testing across the TREG participants and hopefully lead to a faster diagnosis and repairs when new firmware is found to have some issues as I would expect with a complete rewrite.


Good idea to provide for direct comparison between new and old firmware by current TREG participants. This would help rule out or at least diagnose whether old issues are solved or new ones created using the old and new TBs with the same hardware platforms. Makes for a more robust test and quicker resolution of issues.


I’m reminded of debugging software from a major player, many years ago in the days of big iron, where turning on the debugging function made the problem we encountered disappear. The bug only raised its head when we had debugging turned off! … Debugging code itself can have bugs too.

1 Like