Clicker & Scoreboard Overview
The Reps Ahead Clicker and Scoreboard is a project that demonstrates & tests the capabilities of PBJ Results. This project supports REPS AHEAD which is a newly created 1 on 1 knockout fitness competition. The founders story is inspiring and the competition is fun to watch, I look forward to seeing it take off.
The Reps Ahead clicker, is a simple single hand controller with a two button design that allows you to change a scoreboard for a specific athlete. Each clicker communicates via Bluetooth to a computer that displays the score. The clickers are battery powered and virtually identical except for the program loaded onto the Arduino Nano RP2040 connect board they each contain.
The scoreboard is written in LabView and utilizes the same producer consumer architecture of the Gravity Lab software.
The first fully functioning hardware and software product was created in two weeks. The initial scoreboard and hardware design was a demo of what could be done to improve the scoring methodology for Reps Ahead.
The fist competition that tested the use of the clicker and scoreboard was successful. There was a computer failure unrelated to the hardware, but everything functions as it should.
After this competition I took input from the Reps Ahead founder and developed a new scoreboard design. This new design successfully met the needs of Reps Ahead and took 3 business days to implement.
During the next competition a hardware connectivity issue occurred which forced them to resort to their old method of scoring. The current hardware design is expected to fix what appeared to be a connectivity issue by the addition of a second battery.
This post details the history of the software and hardware that has been implemented to meet the needs of Reps Ahead.
The LabView software has gone through two major versions. Both have the same software architecture described in Gravity Lab – LabView Design.
Version 1 uses pictures and numbers to display the score on two separate scoreboards. This version was my initial scoreboard Idea, that I used to demonstrate what PBJ Results could provide for the Reps Ahead events.
Version 2 uses only text to display the score on one scoreboard. This design was created from input of the Reps Ahead founder, after using it for one event. This design took about 3 days to fully implement and e-mail to the founder as an executable.
Version 3 has the same scoreboard format as Version 2 but the connection method has been simplified. I removed the auto connect option and connection tab. The connection controls were moved above the tab controls and the connection timeout was added as a control. Three indicators were added below the tab to show the most recent command executed with a timestamp and execution time.
The “Version 1 Simple Demo” video is a 3minute demonstration of the operation of the software executable, when it is first launched. There are two scoreboards, one for Athlete A and one for Athlete B. Pictures are used to display the current Athlete and the current movement. When the software is shutdown, and restarted the sizing settings, pictures and repetition counts are saved and re-used.
When recording this demo, I found two small bugs. First, the button to “Refresh A Pic” did not work after re-launching the competitor A Screen. Second, if an error occurred, the error banner did not fully close at software shutdown. The second error was fixed in version 2 and the first error does not exist in version 2 because the button no longer exists.
The “Version 2 Initial Startup” Video demonstrates the software operation when the RepsAhead.exe is initially run with no configuration folder or file. The default values for each control are briefly shown as well as the initial scoreboard and newly created “RepsAhead_config.ini” file.
The “Version 2 Setup Demo & Excel” Video demonstrate how to change the scoreboard format as well as the shortcuts for setting up the athlete names.
The “Version 2 Change Color, Bar position, and Open & Close” video demonstrates how to change the formatting of the scoreboard and shows that these settings are saved when the software is closed and re-opened.
Version 3 has the same scoreboard format as Version 2 but the connection method has been simplified. The auto connect option in version 1 and 2 has now been forced to manual.
Versions 1 & 2 used had a periodic search option that was defaulted to on the first launch. This option asynchronously launched a VI that periodically enqueued commands to look for the server on all available serial ports. This worked but had the side effect of essentially “locking” the loop every time the the server was searched for since the search timeout was set at 5seconds a port. This dead time can be very large if a computer has multiple serial ports. In addition to a large dead time each port is sent a string command that has an expected response from the Reps Ahead Server. I would hope that most software can handle an unexpected string showing up on its port, but I could imagine software where this is problematic.
To minimize the potential for error and make it clear that the software is running, I decided to remove the auto-search option, and show each state that is executing with a timestamp and an execution time. The timestamp, state name and execution time are displayed below the main tab control.
Connection in Version 3 now requires the user to push the “Connect Server” button”. When this is done there are two modes of operation depending on what is contained in the “Reps Ahead Server” pull down menu.
- If there is no serial port selected in the “Reps Ahead Server” pull down control, each available serial port will be searched one after the other until the “timeout” value is reached for each serial port or the Server returns the expected response and is found.
- If the is a serial port is selected in the “Reps Ahead Server” pull down control, only that serial port will be searched until a connection occurs or the “timeout” value is reached.
The “Asynchronous – Serial_Communication.vi” was improved in in Version 3 in three ways:
- An “activity check” timer was added that sends the GET_NAME command to the server. This is generally not needed because when the server is disconnected the port becomes inactive, and this vi will close, since it is continually listening to the port. I added this as an extra layer of security to simply check on the servers functionality. The GET_NAME command will only be sent when no communication with the server has occurred for the user designated amount of time. This time count resets after clicking either controller or when the GET_NAME command is sent. The default value is 60 seconds, and should not interfere with a competition.
- A timestamp was added to each clicker command received.
- The most recent command is placed on top of the list of commands and telemetry instead of on the bottom. This top down order keeps the most recent command or telemetry visible in this string control. This is because the default scroll bar action is to keep at the beginning of this string.
The Arduino code uses the ArduinoBLE library to communicate over bluetooth in a low energy mode. The code implementation was influenced by the Gravity Lab Arduino software. The Gravity Lab Arduino code was written such that the “Drop Tower” Arduino acted as a server (or Peripheral Device) over bluetooth while the computer connected Arduino was the client (or Central Device).
I initially chose to make each clicker a server and the computer a client. Having two servers and one client is not the intended use of the ArduinoBLE library. Therefore, I struggled for a several days until I reversed course and made each clicker a unique client and the computer the server. This course reversal is obvious in hindsight but in reality it was like Chinese finger traps where the solution is simple but it goes against your initial intuition.
Versions 1 and 2 both use the same Arduino Code, but Version 3 has the addition of a LED.
The momentary button push code uses “input pull-up resistors” for pins connected to the momentary push buttons. Therefore, when the button is pressed the pin is pulled-down to ground.
To prevent false Reps from a “bouncy” button, the Arduino code only records a button press if the button is held down for a period of time greater than 0.1 seconds. From extended controller use, clicking the button for a period less then 0.1 seconds is not a common event, but this could easily be shortened if the need arises.
The Reps Ahead clicker, is a simple single hand controller with a two button design that allows you to change a scoreboard for a specific athlete. Each clicker communicates via Bluetooth to a computer that displays the score. The clickers are battery powered and visually identical except for the program loaded onto the Arduino Nano RP2040 connect board they each contain. The program differentiates between the athlete being scored.
The first clicker design, took a few iterations before a functional design was created using PLA plastic.
Both versions 1A and 1B have the same design for the battery and Arduino covers. The battery cover slides into place while the Arduino cover is held down with four M2 screws.
Version 1A uses a rectangular toggle switch to handle the repetition counting. But, after inserting the toggle switch into the controllers the pressure on the sides of the switch made it way too difficult to toggle.
One solution was to increase the width of the sides, but after reflecting on common gaming controllers I decided to go to a circular button design instead.
The first circular button type I tested was a latching button. I quickly realized this functionality was not Ideal for two reasons. First, the button motion is to small, and second, if the latch mechanism fails to keep the button depressed this could cause an unwanted score increase. Therefore, Version 1B was finalized with a momentary button.
In the pictures for design 1B there are five details worth noting.
First, the black and white coloring for controller A was purely out of a “waist not want not” philosophy for prototyping. When printing controller A, I ran out of black PLA and used some white PLA I was had on hand.
Second, the M2 screw inserts for holding the Arduino cover keep people from quickly & easily opening the controller, but the insertion is a little bit of a pain. For a future lesson, a “blind insert” needs a large void opening behind the screw insert so the melted plastic does not flow into the insert threads.
Third, the buttons are not fully seated because the hole was designed for a latching button with a different diameter. I used hot-glue to keep the buttons in place but this quick solution failed over time.
Fourth, the battery terminals were kept in place with gorilla glue, but this took a while to dry and had the potential issue of insulating the contact if I was not careful.
Finally, the ridges on the side of the controller and the bottom cover were made to help the user hold the controller.
Hardware version 2 is expected to solve the the unexpected clicker connectivity issue as well as improve its general functionality. There are 5 functional changes to the design.
- A battery was added
- A LED was added
- The Arduino cover improved
- The battery cover was improved
- Two XHP connectors were used
Adding a second battery solves the connectivity issue. The Arduino hardware was under powered according to the hardware specification and going into a low voltage condition as battery was being drained. This has been postulated as causing the Arduino to shutdown & reboot until it did not turn on at all.
Adding a LED now allows the user to see when the clicker is powered on, and when it is connected to the server. When powered on the LED emits a steady green light. When the server is connected, the LED blinks at a 1Hz rate, with a 50% duty cycle. This blinking feature is very useful for determining how far the clicker can be from the server before losing connection.
The Arduino cover no longer uses screws to hold it in place , and can only be inserted from one side. The cover is locked into place with a separate plastic tab that is removed by inserting a standard flat head screwdriver into the access hole on the side of the clicker.
The battery cover design has three basic improvements. First, the “W” shaped design of the edge was turned into a “V” shaped design. Second, the main clicker body was thickened where it held the cover. Third, the lid insertion was restricted to one side side which improves the clicker body strength and reduces the possibility of the cover sliding out.
Using JST XHP connectors meant a change from only soldered connections to a mainly crimped SXH-001 connections. This design greatly improved the assembly process.
The crimp terminal is pictured well in this JST link and a good 2D and 3d model of this crimp terminal can be found at this SolidWorks link.
- For creating the ability to connect to all 15 pins of the Arduino I used two JST XHP-15 rectangular connectors. These 15 female sockets are on a 2.5mm pitch that just worked for the headers that were already soldered to the Arduino.
The modeling of the XHP-15 rectangular connectors missed the detail that the pins were not centered, therefore one of them had to be modified to make up for this difference. The modification required the removal of the “clips” on the side of one XHP-15 connectors with a sharp wire cutter. This modification, actually became an improvement in the design for two reasons.
- The insertion of the modified XHP-15 connector is now easier because it can be inserted from above
- The insertion and removal of the Arduino is now easier because only one 15pin header side has to be inserted at a time.
This in turn makes it easier to assemble the wiring, and remove or insert the Arduino Nano when needed for programming updates etc.
An XHP-2 plug and a top entry header B2B-XH-A was used for the power connection between the battery and the toggle switch. The 2 pins of the B2B-XH-A header were soldered directly to the wire coming from the toggle switch. While the positive end of the batteries in series was crimped and inserted into the XHP-2 plug.
An XHP-3 and B3B-XH-A was used for the ground connections. A single pined ground wire from the 15pin connector was soldered to this B3B-XH-A header and the crimped wire connections from the LED and both buttons were inserted into the XHP-3 plug.
An XHP-4 was used like a breadboard to connect to the 220Ohm resistor used for the LED to the power terminal.
There are 4 visual and ergonomic changes to the Version 2 Clicker:
- The Reps Ahead Logo was added for style
- A plus and minus sign were added inside the battery slots for clarity
- The finger holding “ridges” on the edge of the clicker were removed
- A larger toggle switch was added since that is what I had on hand
The printing and assembly of the Version 2 clicker had 3 main changes:
- The clicker was printed in PETG instead of PLA, which had the effect of changing the battery cover design margin. In other words, the PLA margin of 0.15mm was too small for the cover design in PETG which made it impossible to slide the cover into place until I gave it a margin of 0.25mm.
- I printed a sizing check for the toggle button and push buttons before I printed the full clicker.
- I printed an tool for holding the battery terminals at the right distance from each other when soldering them together.
Finally to improve the robustness of the of the Arduino Nano Server connected to the computer, a protective cover was printed to house the Arduino and USB connector. This cover was designed to remove any forces between the cable and Arduino that could cause the hardware failure pictured.
The hardware connection failure was unexpected and disheartening when it occurred during the Reps Ahead competition. It is possible that this occurred once before but the circumstances involved in the failure were not well understood or repeatable. There was not an obvious issue with the LabView software or the Arduino code, but when an unexpected failure occurs everything is thrown into doubt. To tackle this problem I decided to first improve the hardware design since it seemed to be the low hanging fruit.
My first thought was that the controller was bumped and maybe the battery disconnected temporarily and caused the Arduino to reset. I had seen this behavior before when I had powered an Arduino nano with multiple coin batteries with a poor connection. So I decided to add an LED to make it obvious when the Arduino was powered, and I figured I would add an additional battery for good measure.
As I was looking at the datasheet for the ARDUINO NANO RP2040 CONNECT to make sure adding an additional battery was within spec I came to the realization that I was under-powering hardware. I am now 99% certain that this is the smoking gun for the bluetooth connection loss. Page 7 of the datasheet has a table that clearly indicates the Vin voltage should be from 5V to 18V with a 4V minimum value and a 20V maximum value.
Hardware version 1 was using a single 3.7V Li-ion 400mAh rechargeable battery which has a max charging voltage of 4.2V and end of discharge voltage of 2.75V. Therefore, the controllers were meeting the minimum voltage requirements of 4V when fully charged and overtime went below the requirement causing unpredictable behavior as well as simply turning off.
In trying to understand how I missed this, I noticed on page 12 of the datasheet there is a power tree labeled 3.10 which has a VIN value going from 3V to 20V. I believe I used this to specify a single 3.7V battery. Seeing the value of 3V also helps explain why the controller could last for so long on a 3.7V battery without turning off.
These first version of the clickers and software were used at two events, one where the computer died, and another where one of my clickers failed. I am glad that Reps Ahead was still able to pull off successful competitions with these issues, but I look forward to a rock solid performance with the Version 2 Hardware and Version 3 software.
Hardware checks & improvement ideas:
- A switch on the control to change from competitor A to B. But, the switch should probably be hidden to prevent accidental switching during a competition.
- A charge level indicator, this could be communicated over Bluetooth or on the clicker. This requires added hardware and is not something I have built before, but I believe is possible.
- It would be cool to charge the batteries without removing them from the controller.
- Increase the size of the battery holder for easier insertion
- Add a pullout string to the battery holder for easier extraction
- Look into different battery terminals that solder easier or have crimp connections
- Verify the slight offset oddity of the second hardware print near the battery holders was a 3D printer problem and not a Fusion 360 design issue.
Software improvement ideas:
- Add auto-scale button or right click option for auto scaling the text in the scoreboard
- Add font changing ability, which will mess with the auto-scale option of idea 3.