If you have an older piece of hardware (that's still DVT 1.4.1.): connect device -> "Firmware update" -> "Load test firmware" - this way, you will have the firmware with which the new sabre mode is available. Each time, you connect your pocket boxes with this firmware, a message box will inform you that it does not match the latest publicly available version. You can ignore this and go on with the test version.
This tutorial will be updated soon...
Use Calibur on PC/Mac
Until we release the designated desktop version of our system here's a quick guide on how to to run the Calibur mobile app on computers. This tutorial will guide you through on setting up the Android system and Calibur app on your computer. Don't worry if you're not tech-savvy; just follow the instructions, and you'll have the Calibur system running on your PC.
We've tested this process on various PCs with successful results, but cannot guarantee perfect operation for every computer model due to the third-party nature of Android-x86. Please check our list of tested and verified computers.
You can download the manual in a handy PDF or follow the steps below:
Mac/MacBook with MacOS 11.0 (or later) and an Apple M1 chip
On a MacBook:
Launch the App Store app on your Mac.
Search for the app or the type of app you want like you normally do.
After performing the search, look at the tabs under the “Results for” heading. By default the button on the left ,”Mac Apps” will be selected. Select ”iPhone & iPad Apps”.
Épée test was going as planned and we will share the results in a follow-up post. Foil test was not so smooth and was delayed on a broad basis because of a hardware change. We have tested on those slightly modified devices in a local clubs and the results were similar to épée. So we decided that it is what will go into production. Few more non-critical tests remain to be done but production is finally in eyesight. So here's the latest production roadmap.
Production is set to start in less than 2 weeks and we will ship the preorders as soon as the first boxes got ready.
How did the system work so far?
According to the feedback and the data the pocket boxes worked pretty much as expected. For all the things that can vary from one training venue to another it is hard to find a measurable pattern that's true in Florida and Sweden on new, state of the art blades and on rusty old ones. We still have a lot to polish on the software side but it's very clear now which direction to go. So there will be only minor changes to the underlying hardware, like:
One thing that affected consistency is the level of wireless noise. In most training venues it’s not really a problem. However in busy places, where there are a lot of WiFi routers, antennas, the noise can create inconsistent results. Since we always fence in the office, we’d need to solve this issue at least for ourselves :).To be honest nothing beats a well designed hardware filter in that area. We have already built and tested it and it significantly improves performance in noisy areas.
It wasn't surprising that fencers would want fast feedback and we put a lot of emphasis on its development. That's why we have stripped down the test app to the bare minimum to make sure nothing affects latency. What was surprising where latency resides. There are 3 steps included: measuring on pocket box, wireless sending, processing on the phone. We have guessed that sending will be the bottleneck but as it turned out the processing is what takes the lion's share. We have developed during the past weeks a new method and it will be released to testers.
To make consistently good quality enclosures without tooling for mass production is a different kind of sorcery. To make a few hundred for testing was really a mess. We put in a lot of work to improve the process of making the boxes and their design was also slightly changed. Ultimately the solution will be to level up the manufacturing toolset to the next level. We can start production manually but eventually we would need to automate the process.
After a long and challenging development process it is good to see some light at the end of the tunnel. To be honest it's both exciting and a bit frightening. Stay tuned, as we are preparing an announcement for the occasion.
The last beta test started!
After a rather long break the blog is back. Let's summarise what has happened recently.
What has happened?
We had coming a broad test that was planned on épée and foil before final production. It is the last big milestone before actual production. (fingers crossed)
We have two main groups for testing. First we cooperate with clubs who could dedicate time and resources for testing. Second the clubs and fencers in the early preorders. The orders in the first 100 could request a set of test devices in advance and get their order later once production is ready.
In march the final design was revealed and the preorder started.
Fortunately the orders were placed rather quickly. So we focused all our attention on developing and actually making a few hundred of the pocket boxes. Due to our previous experiences it wasn’t really shocking that to materialise a concept will probably result in some unpleasant surprises. What we did not anticipate is that all steps will do so. Tackling one minor issue after another added up pretty quickly and we clearly underestimated how much delay together they will cause. Long story short, we will definitely need to revisit our timeline in the next post.
What are we doing now?
We assembled, tested and shipped these units. Since last week around 80 clubs received their test sets. Pandemic-normally a majority of the packages were delayed and a few temporarily lost in transit. Though most of them arrived by now just in time for the easing restrictions.
What will happen next?
First of all due to the delays in production integrating foil with epee was also put on hold for a while. So most of the clubs have now epee only devices but in the coming weeks we will enable foil via a software update. It’s one of the top priorities now.
Second, we will have a detailed roadmap of what exactly is being developed and when to expect them. This would help all the testers know what they can expect and it will come handy grasping the capabilities of the system for the rest.
Third, we will release tutorial and test videos on a regular basis on how the features work and about the things under development.
Now production is projected to start by the end of June. It’s admittedly the most optimistic scenario and there are a handful of things that could still go wrong. But that goal is now pretty much in sight and we want to make the process as transparent as possible for everyone involved.
Lessons from the first broad testing #1
Last week we introduced the Calibur pocket box. It is once again a major leap in product design and features. Testing it is the last step before actual production.
The plan is something like this: 1.Build a very reliable, stable and accurate device 2. Use that basis to build on all the smart features in the application.
We ran a broad épée test back in November which served as a way to pinpoint the weaknesses, analyze the data and incorporate it into a new device. It’s worth summarizing the major takeaways. Today we’ll cover technical issues and how we addressed them:
Let’s jump start to connectivity. Connectivity is the bread and butter of a wireless system. You can only make wireless as good as the quality of connection is. It is judged by 2 factors: stability and latency. To put it more simply how often the connection drops and how much time it takes for a hit to display. The boxes we shipped in November had inconsistencies in both fields, so we put a lot of effort in fixing it.
A simple way to measure it is how far you can get without disconnecting? Mark a 15 meters strip every 5 meters (having the scoring at the middle of the strip means not any of the fencers would get farther away than 7m and in most cases, even much less), put the devices at each mark and note the results, then repeat with the device in the backpocket, then again while covering it, then with walls in between, then underwater in a tin suit… on each and every phone.
In general Apple devices disconnected much sooner than the ones with Android, but we were able to improve on both systems. The development is pretty obvious on this part, we were able to drive down drops to practically 0. Tested on a dozen different, low-end to high-end phones and tablets connection always remained active. The challenge is now to find an otherwise well-functioning phone that fails this test and I’m happy to tell that we haven't find one.
The latency is a bit more complex issue. How long is good enough actually? We found that the threshold for unnoticeable delay to be around 100ms.
Latency consists of 2 parts: how long does it take to send the data and how long does it take for the phone to process it. Let’s check the first part, so back to the marked strip. Put 2 synchronous clocks to the pocket box and the phone and repeat the stability test but this time at each mark sending the same data packet.
The results are again very promising. The delay dropped significantly and stayed low up until around 15 meters. So now it is up to the phone to process it.
Getting the phone's processing time down proved to be harder to optimise than anticipated. But it’s clear that the delay is mainly caused by the application now which will perform much better after restructuring. More on that later.
The idea that accuracy is based on the utilization of the data pool is a sort of chicken-egg problem. To have people using the devices they need to be enjoyable. To be enjoyable people need to use it. So the deal with the broad épée test was that people would be using them even when it’s not so enjoyable and we will quickly follow-on with updates and by the end of the test they will become quasi-replacement for any system on épée.
After a very strong start, restrictions started to kick in in December basically everywhere and the incoming data started to slow down. But we still managed to get thousands of bouts and tens of thousands of touch data. Huge thanks to our testers for keeping up despite all the hurdles! Two things became clear: 1. That the data will be not sufficiently big with the current model (it's not just a matter of the total volume but the constant flow, to make comparison after every version) and 2. that we certainly underestimated how much work it will be to maintain a system and to develop a new one parallel. So we moved forward and put the focus on incorporating the existing data into the next version.
The goal was to make accuracy high enough so that fencers will enjoy using the devices in training sessions and the rest of the data will come much easier. The 2 major questions in accuracy are: does it go off when it shouldn’t and do we need calibration to avoid that? We were able to improve tremendously on both aspects.
How-it-works grey box:This is actually the most complicated part. The touches are validated by a model dependent on the electric properties on the weapon. To put it simply we measure these properties, gather them in the cloud where machine learning algorithms process them. Then the validation model is updated based on the new data and feeded back to devices through the application. Instead of measuring one property in the previous iteration now we do 3 and the machine learning fetches those together.
TLDR: The general direction is very clear latency is down, accuracy is up. We are getting through the 3rd wave (so far) of the pandemic and with local clubs shut down, it's more tricky to find the ways for sufficient testing. In our testing the system works well in 90-95% of the cases. So the job for the AI is to close the remaining gap particularly on rare cases. Global testing will start next month with the goal of finding the outlier cases. As soon as the data feed start to improve again so will the system.
In the next posts we will cover the general feedback and future features but for ending watch this video of a short bouting in the office.
Product evolution #2
We nicknamed the project “wire eater” among ourselves so I will refer to the devices asWE versions. The plan was set in motion: ship WE-1, incorporate feedback and develop WE-2 within 3 months. The goals for WE-2: make the app cross-platform (Android and iOS), get bellguard-grounding-accuracy to 90-95% on épée and deliver over 100 devices for the clubs to test. In other words a broad beta test for WE-2. We planned the testing to take place in November.
The sprint started by mid-August and the first clubs buying WE-1 planned to restart fencing in September. We agreed to deliver for the reopening. For the first few weeks development and production went simultaneously, but delivering a product for actual customers was very exciting. We finished just in time:
Some pictures from a training session @ PSE. The kids had fun, and we gathered valuable insights.
Néhány kép a PSE edzéséről. A gyerekek jól érezték magukat mi pedig sűrűn jegyzeteltünk.
The kids intuitively started to use our products really enjoyedthemselves
In the meantime we made a detailed roadmap for WE-2 with the 3 goals in mind as above. Let’s get through them one by one.
Making the app cross platform
It shouldn’t take particularly precise planning. We take what we have for Android and replicate it for iPhones, right? Well, Apple strictly controls everything and why wouldn’t that be true for wireless devices. If we want to connect something to iPhones we need to use a wireless chip approved by Apple. If you had to guess whether we used one like that or not, where would you put your money, and why on not? WE-1 only supports épée and does not have any grounding capacity, but it has a very stable and fast connection with the phones. That part was fine tuned already. Changing the chip means to throw all that away, and restart.
Getting accuracy over 95%
Bellguard grounding should work 9+ times out of 10 in test environment. Our model is based on that a larger data pool is needed to operate. How would we get that? Obviously it’s not an option to gather that at the clubs every time we change something. So a lot of nights went like this:
999 green bottles on the wall, if one green bottle should accidentally fall, 998 green bottles on the wall…
Both of the goals turned out to be an uphill battle especially in the given timeframe. All the new wireless chips turned out to be either too slow or dropped connection too easily with the phones. Every time we tested out something in the lab and took it to a real training session it completely failed. Special thanks to OSC and their fencers for letting us do our it-worked-yesterday-I-swear show twice a week. The connection drop proved to be a very stubborn issue, basically disrupting every other test we tried to run.
OSC helped a lot, sharing their space to test
Producing 100 pieces
We were approaching the end of October. The clubs who signed up for testing were all set, waiting for their devices, we just finished the new enclosure design and for the 1st time the application was approved on both platforms.
It's much more convenient to connect the yellow penguin than a QR code
But the connection issues still stayed with us. We had only a week left to finish and we put our bets on a last resort solution in changing the antenna design. We urgently needed a plan B and getting the devices out of the pockets made the connection slightly better.
Desperate times call desperate measures
I shouldn’t get into details about the things we tried on the last weekend in a rush to find a way to attach them to the body. The new antenna design, though far from perfect proved to be above the threshold and we decided to give it a go.
We’ve made everything ready and after an intensely laborious week with 3 hours of sleep on average we tested, packed and labelled all the packages ready for shipping. And the épée beta started.
Final touches before sending out beta test packages. (Nov.11.)
Utolsó simítások mielőtt kiküldtük a beta teszt csomagokat.
As I mentioned, I think it’s worth getting a brief look back on the evolution how we got towhere we are today. Picking up the story from where we left off: Our team had just formed. More or less with the skillset diverse enough to build a hardware we had a lot of questions. What should we focus on? What are the milestones to set? Who are the customers?
We decided that we should enter a startup competition and present the concept to a jury. It would provide 2 things for the project: Firstly, it’s an external commitment that forces us to build and deliver something in time. Secondly, there will be some guiding feedback. So we did exactly that, we built “something”.
Meet the “thing”, our very first prototype. Banana for scale
I shouldn’t get into nuances, like the main board being cardboard or the fine crafted details of the blue duct tape keeping the whole thing together. However it did prove a few things. It was able to send a signal to a phone whenever the tip was pushed. In other words: we’ve built a scoring machine on very basic terms. And it was enough to push us to the second round of the competition. More importantly, what we’ve learnt from this experience is that you’ll always have additional features or fixes you want to finish before you “launch”, but actually putting something out there is really what starts momentum.
So preparing for the second round we needed to “commercialize” the thing. Shrinking it in size to fit in a box and basically to be usable for some sort of fencing. We’ve actually designed 2 models for this round. The better one was much smaller, had a rechargeable battery and had far better chips on it however it was so unstable we used the more basic but stable one. (Note that by stable I mean we needed to connect a headset to the phone because the device randomly scored sometimes. So the plan was to disconnect the headset while presenting, pray that it wouldn’t make any sound randomly, then reconnect the headset when we were done. Please don’t tell the jury).
Somewhere in the distance an industrial designer starts to cry
Our chances were weaker than the quick binder on the money clip holding the box together, but it worked! Or at least did not fail during the presentation. The performance earned us third place in the competition which gave us a great push. More importantly we had something that we could start to test on actual fencers.
Real life testing
So the next months were spent on incremental improvements, shrinking the size, going to fencing clubs and collecting feedback.
We visited 2 clubs a week, sometimes even more. Fortunately everyone was very welcoming and the general feedback was very enthusiastic. We got proof that the old way of scoring was really the pain that we understood it to be. Our two main goals were set:to shrink it to the size of 2 matchboxes, and to lay the ground for data gathering. We started to test basic AI models on the data. We went through a handful of iterations not very different from each other.
I'm glad we left the small coffin design on the left
Even though the app was only for Android it only worked for épée and no grounding feature was available, we had our first customer. A small club next to Budapest decided to order 10 pieces. Sadly we didn’t have too much time to celebrate as it coincided with the worldwide spread of Covid-19. With the clubs closed and most of the indoor activities restricted we didn’t see any other option but to suspend developments.
Few months went by, the restrictions eased and the world started to adapt to the new reality. We started to get more and more messages that wireless sets could be really helpful in order to maintain health standards. So we decided it was time to get back on the project.
First we put together a comprehensive plan. In 3 months we want to achieve 3 key goals: make the app available on Android and iOS, get bellguard grounding over 95% accuracy on épée, produce and send over 100 pieces of it to clubs. We will cover that in the next post.
Getting to test our devices
As the next stage of testing is approaching we are looking for avid testers on foil and épée. You can take part in 2 main ways: by signing up or by preordering. (For more info, see at the bottom).
How is the testing planned?
Due to COVID there are still many uncertainties around development: First, most of the fencing venues are forced to be closed so it’s hard to test in real-life conditions. Second packages are very often delayed, for some parts we needed to wait nearly 2 months to arrive. Moreover shortages occur much more often and sometimes even basic parts can be missing. Third, in case someone in the family or friends got symptoms associated with the virus we also need to take measures. And it is not really an option to do hardware development remotely.
These factors make planning significantly more complicated. However we do as much as possible to keep the development on track. So we a more detailed addition (below) to the public roadmap leading to product release. For understanding the roadmap let's get some background knowledge on testing stages. We can split testing into 2 major parts: alpha and beta-testing.
We test mostly in-house. It usually goes like this: we build something, get into fencing gear, try it out, fail miserably then start over. The goal is to get a proof of concept. We get through a wide range of ideas and possible features. (We have a small desk dedicated to our trials what we call the Calibur museum. In a future post we will get through some of them.) When we do this part enough times and start to feel the need to share the experience we go out to local fencing venues. This phase is the
We can also split it into 2 steps: narrow and broad beta-testing. In narrow beta-testing we get to local venues and test some specific part of the device, like connection or certain types of situations during bouts. We have 2 goals while doing this: get the concept accurate and stable enough. As soon as we cross the threshold we set up we can start broad beta-testing. In this phase we send out devices to all our partners to use them as they would during normal fencing. The goal is to have broad usage feedback and to collect data.
As you can imagine the broad testing is the most resource hungry part of the testing and since there are 3 disciplines in fencing we would need to do it 3 times.
Good thing that we set up a model that takes much of that burden off of this phase. Since the product will constantly adapt to the data it gets, in some way if you will buy the device you will be a broad beta tester and help all the other fencers to have a better product. Thanks for your great work!
Testing roadmap for the latest version of the device
On the bigger scale we conducted beta testing on 3 versions already. Last time in November a broad beta on 100+ devices for épée. That went well and since then we've rebuilt the system from the ground up to be better suited for 3 weapons. We plan product release in April so the devices will be very close to the actual products in this run. If things go as planned we will need to adjust only the software after that. The red lines just before product release represent the final broad beta-test.
How can you participate?
First, sign up below. Second, hop on a video call with us. We try to have the most diverse set of testers so we will send out video call invitations so we can get through the details. Third, receive your package and fence. The base requirements are to use each device at least 5+ hours/week and to be able to take weekly/bi-weekly feedback calls for around 4-8 weeks.
Another way for participating can be if you preorder a set and request a testing device. In that case you will receive a test set before and later your final set as well. So anyone in the first batch of preorder can request test devices. Preorder will start this month.
The third way is to receive one in a give away. We will give away for the most active members of the community and to university clubs etc. The give aways will be announced by e-mail, to receive it just sign up below.
So, please sign up if you didn't already and help us getting out the word by sharing this article.
How to make wireless scoring for fencers?
We set our goals to change fencing by making it truly wireless.
The current systems are cumbersome, have a lot of parts - even worse they are moving parts- meaning there are a lot of things likely to fail. Yet they play a very important part in fencing.
Presumably, there are very few people who don't have some hard feelings toward reels after repairing one
However if someone wants portability it’s not possible without a serious trade-off between price and accuracy. But why is it necessary to make such a compromise? What are the limiting factors to have both? Let’s see one by one:
- Make it accurate
The first major challenge in wireless scoring the lack of common ground. When 2 fencers are wired-in, they basically form big electric circuits. Put simply the fencers act like switches; when there’s a valid hit, the fencer closes a circuit and the scoring board makes a signal, when there’s an invalid hit (e.g. bellguard) a different circuit is closed and the scoreboard remains silent. However if you take away the wires, there is no circle to close hence it gets challenging to get that information. This is more widely known in fencing as the common ground problem.
Fortunately there are a few ways to get around this issue. Without getting deeply into technical details, all electric systems have quantifiable characteristics. We just need to find a metric that’s different enough when a valid touch occurs, then measure it the right way. If we can get it precise enough we can tell valid and invalid hits apart, right? This immediately leads to the next problem: the vast variety of equipment. It’s not enough to separate valid and invalid hits, we must do it consistently on all the different fencing equipment. Weapons, lamés, masks, bellguards, conductive strips, regardless of age, maintenance, material composition and so on. It’s like you need to design a bullet but it needs to fit perfectly in all the possible guns and rifles.
How could we tackle that?
There are 2 options to develop such a system. The traditional way: is to develop everything in-house trying to replicate all real-life scenarios. First, find a method to overcome the common ground problem. Second test and fine-tune it to the point of acceptable margin of error. Third make it into a commercial device and hope every possible setup was tested before the product release. It’s not hard to see the problem with this method: it gets increasingly harder to approach something close to full accuracy. In reality it’s more likely to get in the neighbourhood of 90-95% and then nearly impossible to get to 99.9% accuracy within reasonable time and cost.
So what if we could design a system that adapts to the environment? A scoring method that gest more and more accurate by usage? To achieve this we need to develop a machine learning method and feed a big pool of touch data into it. So we need to store and access the data, analyse it and finally use it to perfect the model validating. Once it’s up and running the development cycle never stops. With each update, you’ll have a better product in the morning than it was the night before.
- Make it affordable
For lowering costs there are 2 obvious ways to go: make development cheaper, and make production cheaper. Fortunately development gets much faster once the machine learning model runs thus driving it’s cost down.
How can we make production cheaper?
Well, lowering the parts needed would come handy, wouldn’t it? We already got rid of the reels and their wires and we need the body wires and the weapons - at least for the time being - so all fingers point to the scoreboard. Depending on the brand and the functionality, it can cost between 200$-1000$ for a decent training setup, so we also need to get rid of it.
- Make it trusted
There’s a third hidden factor that should be taken care of, a key advantage the old systems have: history. Since they are around for nearly 100 years there’s a level of trust that a wired system will work as it should. A wireless scoring system adds a layer of uncertainty which undermines faith in it. Why? Because it’s hard to know for sure if the fencer failed or the wireless. And people tend to blame the latter. To put it another way, it’s not enough to be accurate but it’s also crucial to appear that way. How can we overcome this hurdle? It turns out the most frequent source of equipment failures are the tips and the body wires. We need to make sure that those are in suitable conditions, and need to notify the fencer of the current condition of her equipment. In short: we need to make it smart.
Neat, isn't it?
TLDR: we need a device which can store and send data wirelessly, is smart, and everyone already has it. I guess you already figured it out, but all these factors are perfectly aligned in smartphones and tablets. And this is just the surface of it, utilising smartphones does not stop at monitoring the condition of the equipment. Not using all that data is such a waste of opportunity, and building useful features around them would make fencing so much easier for clubs and the fencers, but that's up to a future post.
Why are we doing this project?
It started around 2 years ago as a side project for Tibi (/Thee-bee) at his university. He has been nurturing the idea for quite some time during his training sessions.
Tibi presenting the idea, (or running for governor)
Tibi also used to be an épée fencer himself and won the nationals with his club’s team in 2010. Although he drifted away from competitions, he remained an active fencer during his university years. Being a Computer Science major in a time when everything in the world was “smarted up” fromegg holders toflip-flops he started to question why fencing seems to have stuck in the last century so much? Why did all the scoring equipment need to be stored and carried and set up and disassembled and repaired and taken care of and repaired again… so on?
Guess which one is him
Also, could that be a reason in why fencing stayed relatively unpopular compared to some other sports? Take tennis for example. A sport similar to fencing in terms of a dedicated place and special equipment being required to play, yet some18 million people play it in the US alone. One of the driving factor behind it's popularity might be that you don’t need a hawk-eye system to compete against someone. Meanwhile fencing loses much of it’s competitive edge without an accurate scoring system.
So, combining his skills with the spirit of our historical baggage and the prospect of popularising the sport, he started working on the project. It soon became clear why the problem hasn't been addressed properly so far.
It turned out to be a heavy technological challenge and the market is under the radar for most of the sportech companies. The FIE tried to tackle the problem since the beginning of 2000s, however those initiatives never came to fruition. On the other end of the spectrum individual projects were hindered by technological hurdles, mainly the lack of common ground.
So he started to gather the team for the project, and chose the best recruiting process known to mankind, asked a friend for a beer. The beers got more frequent and Adam, a data scientist, Andrew, an electrical engineer and Valentin, an experienced startupper got on board. We all shared the how-was-this-not-solved-already attitude and a we-could-easily-do-it overconfidence about the project we formed a team for this project.
We set our goals to build an affordable yet accurate portable scoring device, but that's up to our next post.