It’s certainly been a while since v0.0.4 was posted and confession, nothing really changed for most of it. By contrast in the last month or two, four releases have been pushed in quick succession. We’re now at v0.0.8 and shucks howdy have things come on.
v0.0.5 – This is the cleanest house ever.
There have been …three complete “code cleanup” merges since v0.0.4? The agent (now called robin) has become a semi-separate library instanced from combadged, a lot of things have been renamed, refactored and generally tidied up. The code is a lot more readable than it was, quite literally.
There’s still more to come on that, but where the code is now now is a pretty good place to build from. Which leads on to functional changes.
Most of those were not in this release. In some ways this was a step back – v0.0.5 did have simultaneous agent handling for multiple badges, but it didn’t (and as of v0.0.8 still doesn’t) support bidirectional RDP. That’s actually one of the official blockers for v0.1.0, what will officially be Spindoctor’s first semi-major release. However, it’s certainly easier to test the project now, without needing to launch multiple parallel scripts independently of each other.
v0.0.7 – Log in, Log out, Shake it all about.
The major change of v0.0.6 was a simple REST api in combadged that allowed you to change the currently logged-in user. Then v0.0.7 hit the repo, and the ability to log out a badge joined it’s sibling. That means that you can get your name onto an idle badge, as well as push the badge into the less power hungry (due to slower pings) “LOGGED OUT” state. Bonus, it turns out if a B2000 badge is in the dock when it’s logged out: it will shut down entirely. Given the energy crisis facing the world in 2022/23, that’s probably no bad thing.
v0.0.8 – This is now a Combadge server.
Please forgive my first person prose here. I started playing with my first eBay B1000A in about 2009. I moved onto B2000 badges around 2012, when I finally couldn’t justify running an AP in 802.11B mode anymore. The first time I was able to communicate with any of the badges was in May 2021, where after a feverish three-day coding sprint with a stack of packet captures, finally, between badge and server – I was able to respond to the initial ping. It was a long 12 years. Now, 18 months later – anyone can download Spindoctor on Github, and if you manage to configure a pair of badges using the on-board menus, and have the right open network – you can make a call between them.
As of right now, it’s a bit of a pathetic process – once the badges have registered on the Spindoctor server, you can use the web API to trigger a call between them – and hang up with the buttons when you’re done. You can’t trigger them with speech recognition (the agent transcribes, badly – and nothing else). The displays don’t change to reflect the call state (there is code for that, but it’s not been used in the call process). Hanging up one badge doesn’t hang up the other, it sits there with it’s RTP port open, dumping audio packets onto the network that will never be heard. And it’s honestly a little unstable, while my all-B2000 test lab works, my mixed B3000/B3000N lab drops calls quite eagerly. Whether that’s the badges or the wifi in that room is yet to be determined.
Looking ahead to v0.1.0
It’s an exciting point to reach after 13 years, but there’s also a lot more to do. There’s a few specific tasks in the short term, and some bigger long term goals.
Short term, believe it or not, speech recognition isn’t a priority. It’s complex, there isn’t developer expertise in the project for it and while the coolest feature on the badges – it’s not necessarily the most useful feature for anyone trying to recycle these. For now, the goals are:
- 2-way audio between server and badge.
- A more comprehensive and persistent concept of a “user”.
2-way audio and the chamber of scope creep.
To date, while trying to get 2-way audio working (it still doesn’t), two libraries have been written. One, a terrible fork of an old commonjs project, is an (way faster but buggy as all get-out) ECMAScript function generator to play simple audio tones and chirps. The other, is a (woefully incomplete) pure-ECMAScript RTP library. This is meant to push all of the audio transcoding and UDP wrangling for audio into a semi-independent library. Development of this is currently the main focus as part of #13. Once that’s “done”, robin should be able to just push audio into a stack in the RTP library which will handle feeding it to the badge, and the library will also listen for, transcode and feed audio into robin in turn.
I am Worf, son of Mogh.
Worf has become the go-to demo account for the log-in code, and is used as the example in the README.md. And being able to define yourself as the user of a badge is one of the more important (and frankly, easier) things to implement. Plus, v0.0.6 and v0.0.7 put in most of the important code for this at a badge protocol level.
What’s lacking is a properly structured concept of what a “user” is, and it turns out that can be a little complicated to do, especially if you want people to be able to autogenerate this from some CARDDAV or LDAP set-up down the line (which does seem sensible). So, that’s the next thing to do after the RTP service – a best effort best faith first-pass attempt to properly design a User object, and make it persistent to disk (probably with a simple “write to JSON” for now). #12 if you’re curious.
Seasonal Pumpkin Pie in the Sky~
Ok, it’s pretty obvious that there has to be at least some speech recognition and generation in place for whatever v1.0.0 looks like. There are some other important steps before that though, such as getting V5000 Smartbadges working, as well as (once they start ending up on eBay), the C1000 Minibadge if at all possible – especially since the Minibadge is the closest product to a TV Combadge yet.
I also think that a “1.0” release should handle all the basic functions of a badge. That might not mean every feature of the current gen, such as centrally-provisioned Bluetooth, but it will mean basic message handling and the ability to configure a blank badge for your wireless network without having to use an unencrypted network.
Beyond that, I’m more interested in implementing the cool things that the commercial server never will. For one, the “on-screen” command to transfer calls to an external display with video features. For another, links with home automation software – and especially coffee makers.
I don’t think it can be said enough times that Spindoctor is not meant to replace the commercial software. It’s a hobby project for hackers to run in places like Berlin’s C-Base (canonically, a crashed space station – functionally, it’s a hackerspace) or in their own homes. So, a lot of what makes sense for a Hospital is meaningless for this software. But fingers crossed it gives some entertainment, and helps slow down the sand-waste lifecycle for this hardware. Given that most of my original badges still work 13 years later – it seems like that has a lot of scope.
For now:
For now, you can finally run your own Combadge server – limited as it is. You can get the code on the Combadge project Github, and follow the instructions in the README.md file to get started. After that, if you know your way around ECMAScript and NodeJS, feel free to start throwing up a few PR’s, either against our Mantissa branch, or against my own incomplete PR branches. If that’s not you, bug reports are also welcome – the code is deliberately prioritising simplicity over resilience at this point, but where problems arise, I’d like to fix them all the same. Finally, use the same link if you have a genius concept you think would fit the project.