Subscribe with RSS to keep up with the latest changes.
New Website
January 04, 2019
We have a new website! We've moved from Blogger to a custom domain at ThwackTimingGate.com. This new website makes it easier to accompany text with code and organize our resources in a way that is more conducive to proper documentation. The hope is this furthers the open-source goal of the project and makes it even easier for others to see the work we're doing and build on it. Check out all the cool new parts of the site by using the sidebar to the left.Making an App for Retrieving Results
December 03, 2018
To retrieve results from the finish line, we've developed an app that fetches results via HTTP and allows configuration of the devices settings. It's coded in Dart, using the Flutter framework.Results View
This is the primary view of the app. If the phone is connected to the finish line and the finish line is operational, a downward swipe will retrieve results from the Pi and display them in an easy to read format. In the future, this view will allow you to sort results and view results from one specific racer, but for now it only provides a basic view of results.
Settings View
This is the second main view of the app, which can be reached through a navigation bar at the bottom of the display. It exposes status information, such as if all devices and connection are properly configured, as well as allowing configuration of the app and timing system. For instance, the user can select what IP the Pi is located at, so results can be configured properly. In the future this functionality will auto configure itself, but for now it is manual. Additionally, the user can configure the table that keeps track of the ID number of each racer. This is what allows the IDs that racers input at the start line to be converted into names when the results are displayed. The next section discusses its configuration.
Table Configuration View
This is a secondary view that allows the configuration of a table for mapping racer IDs to racer names. Since this table is stored on the finish line, when the view is initiated the table is fetched. Then, the user can configure the table by swiping to delete unwanted entries and creating new ones using the button in the bottom right. The table can also be sorted by number or name for ease of configuration using the buttons in the top right. When the check button int he top left is pressed, the table is pushed back to the finish line and the view is dismissed.
Working Prototype Demonstration
November 05, 2018
Here’s a video that demonstrates progress on the prototype so far.
A video used to be here demonstrating an older prototype of the Thwack Timing Gate. It has since been lost. For the most up to date demo, see the website’s landing page here
This video shows the following features functioning properly
Basic Software - Both the Arduino and Pi are running infinite loops to check for button presses and received packets, as well as writing data to files if the need arises.
Custom Communication Protocol transmitted via Xbee - the start signal was transmitted from the Arduino in a custom designed packet that was then decoded by the finish line. This packet included a checksum to verify the packet’s integrity
Flask Web Server - the Pi is hosting a web server that successfully responds to GET requests made to it with JSON files that represent racing results so far.
App for Retrieving Results - The Android phone is running a custom made app that makes http requests to the pi and then formats the results to display racer results so far.
Flask: A Simple Python Web Server
November 05, 2018
One of the issues we have been dealing with is how to retrieve results from the Pi. The initial idea was to host the results on a RESTful web server that could be retrieved from an app. After some searching, we've decided on using Flask, a micro web framework for Python.
A Simple Flask Web Server
Setting up a simple web server that accepts GET http requests and returns a JSON file is simple. The above is an example. After some imports and boilerplate, we define our first route with the @app.route decoration. The arguments indicate that GET requests to "[server's url]/results" will return the value of the following function, which in our case loads in a JSON file from memory and returns it.
The primary advantage of this method is it loads the file into memory each time a request is made, so if a separate program is updating the file (say the python program running simultaneously that records times) each request will return the most up to date version, not just the version that existed when the server was started.
This server was tested both with the bash utility Curl and with an app making http requests pointed at the server. Both performed flawlessly and the Flask server is now integrated into our working prototype.
Developing a Custom Communication Protocol
October 18, 2018
One of the biggest challenges in this project is ensuring the start signal is reliable and timely—that is, the finish line (which keeps track of timing) is informed by the start line when a racer enters the course in a manner that works 100% of the time and is not heavily delayed, as this could reduce the accuracy of timing.The Xbees are good for basic wireless transmission, but simply using them in transparent mode guarantees very little. There is no guarantee data will make it to the receiver, no guarantee that data that does arrive is fully intact, and no guarantee data will arrive quickly. If these features are needed as is true in our project, they must be implemented in software. For the timing gate, we are developing a custom communication protocol to include just the features we need. A preliminary specification is given below.
Overview
Data is packetized for transmission. In our protocol, packets are anywhere from 16-32 bits. Each packet can serve one of two purposes: data or control. The data packets are those that accomplish the devices primary function—starting a timer. Control packets ensure the start and finish lines are connected and properly calibrated to ensure times are accurate. Each type of packet will use its fields differently
Data Packet Contents
Length- The length field specifies how many bits are in the content field. It ranges from 1 to 16.
Type- The type field is a binary number from 0000-1111 (0-15). This is what indicates the purpose of a packet. The packet could be a signal to start a timer because a racer has entered the course, or it could be a packet requesting an acknowledgment from the finish line as soon as possible to calculate the delay in the connection, or it could simply be a packet requesting a response to ensure a reliable connection is established.
Content- The content field holds data relevant to the packet type. For a data packet, it could be empty, as there is no data to send beyond the fact that a racer has started. For a control packet, it could contain the delay that has been calculated between the start and finish lines so the finish line can take this into account when calculating times.
CRC (cyclic redundancy check)- A CRC is a type of checksum that ensures the integrity of the data in the packet. It comes from a mathematical calculation performed on the binary representation of the packet. If the packet changes, the CRC will change. When the packet is received, the CRC is performed again. If it doesn't match the transmitted CRC, the packet is discarded. In a more complicated protocol, the packet might be requested again if dropped, but for the purpose of our lightweight protocol, this is unnecessary. The only vital packets in our system are the packets that start the timer, and their transmission can be near guaranteed simply by sending them multiple times.
Delay Calculation Process
Throughout this post, I have hinted at a system to synchronize the start and finish line. It is quite difficult to have millisecond precision wirelessly, since packets take time to transmit. Instead, the device will periodically determine the delay between the start and finish lines. Then, the finish line will add this delay to the finish times to make them accurate. Below is a rough outline of how this delay will be calculated.
Start Line illuminates a red LED to inform user to wait for sync process to finish before continuing. Then, a packet is sent to the finish line, requesting a response as soon as possible. The start line simultaneously starts a timer
Finish Line receives packet, and sends a response packet as quickly as possible back to start line
Start Line receives response packet and stops timer. Start line divides the timer value in half and stores this value. This is the approximate time it takes a packet to travel from the start line to the finish line. Start line illuminates green line to show device is ready for racers to start
Every time the Finish Line receives a racer start packet, the approximate delay is sent along as well. The finish line adds this delay time to the racer's final time to ensure all times are accurate.
This process is redone periodically to ensure timing is accurate. The hope is that even with this rudimentary calculation will improve the accuracy of the device to the point where it is a valid option for timing alpine ski races.
Configuring XBees to Work in Transparent Mode
September 12, 2018
The challenge to take on today was one that is at the center of the functionality of the timing gate: wireless communication between two remote hosts.An easy way to do this on small scales is with XBees, a small device made by Digi. Xbees allow simple wireless communication and can interface with a wide variety devices, making them an indispensable tool in many projects. As with the Arduino and Raspberry Pi, a further part of the convenience of using Xbees is how much documentation and support is available. For instance, interfacing an Arduino and Xbee is as simple as buying the Xbee shield pictured below to make plugging your Xbee into your Arduino a breeze.
Arduino Xbee Shield
For devices other than the Arduino, the Xbee can plug into USB ports with an Xbee explorer made by Sparkfun. See image below.
Xbee USB Explorer
Configuring Xbees
Xbees are highly customizable. They can work in one of two modes. In transparent mode, they simply act as a wireless serial communication (for an introduction to serial communication see here). Whatever is sent into the TX pin of one Xbee is sent out of the RX pin of the opposite Xbee. This means transparent mode is best for communication between only two devices. Neither host devices is aware of the Xbee, it simply sees a serial interface, thus the name "transparent." The other operation mode is API mode. When Xbees are configured in API mode, they act more like hosts and routers on a traditional TCP/IP network. Packets are sent wrapped in a proprietary version of the Zigbee protocol created by Digi. This allows for far more advanced network features, such as choosing destinations for individual packets, diagnostic tests such as pings to see if hosts are operational, and more. API mode is good for networks with many hosts that each need to communicate and are not in a permanent configuration.
We ended up going with transparent mode. Transparent mode works perfect for us since once we configure the two Xbees to point at each other, they need no additional configuration. How does one configure the Xbees to begin with? Using a piece of software called XCTU.
Using XCTU
The first step is to get XCTU to recognize your Xbees. XCTU runs on desktop OSs so you'll need a computer and an Xbee explorer so you can plug your Xbee in via USB. When first opening the program, you'll see an interface like the one below. Click the button in the upper left with a "+" on it.
In the dialog box that appears, note the devices listed under "Select the Serial/USB port." Then, plug in your Xbee and hit "refresh list." Click on the device that appears and select "finish." A message saying "discovering radio modules connected to your machine" will appear for a period, after which you will be returned the main XCTU screen, except now your Xbee is added to the list on the left. Repeat for your second Xbee.
From here, there is some slight configuration to ensure that your Xbees are pointed at each other, but from then on you should never need to configure your Xbees again as long as they're used for the same purpose.
Below is a list of fields that may need changing. To configure an Xbee, click on it on the left and edit values on the right.
ID - this value needs to be the same for both devices. Leaving it at 7FFF will work fine.
DH/DL - These two strings determine where the Xbee is configured to send packets. For the Xbees to work properly, each should have their DH and DL set to the SH and SL of the opposite Xbee. For an example of this, see the below screenshot.
 |
| The DH of Xbee A is set to the SH of Xbee B. The same is done for DL and SL. |
Testing
After completing this configuration, your Xbees should be ready to communicate. To test, attach them both to your computer with Xbee explorers and switch the right side of your XCTU interface to console mode. This is done by clicking the console icon in the top right. You'll now be presented with a terminal like window that represents bytes sent and received by your selected Xbee. You can switch which Xbee's terminal is viewed by clicking on a device on the left. Click the white open button for both Xbees, then start typing in the left console window. Sent characters are in blue. Switch over to the second Xbee and you'll see your message relayed. The red indicates the characters have been received, as opposed to transmitted. Congratulations, you now have fully working bidirectional, wireless communication.
 |
| "hello world" transmitted on Xbee A |
 |
| "hello world" received on Xbee B |
The Biggest Challenges
May 23, 2018
Many parts of this project are well chartered territory and will be relatively easy to accomplish. For instance, the issue of wireless communication between two microcontrollers is well documented and easy to implement given enough research. However, there are other issues that are more specific to our project and the solution will not be readily available online. These will require lots of brainstorming to come up with possible ideas, then even more brainstorming to figure out how to implement those solutions.Here are some examples of those problems and possible solutions we have come up with so far.
The "Temperature" Problem
One of the principle obstacles our design will face is sub-zero temperatures. The start and finish line sensors will have to operate at high elevations well into the night to be viable for use at ski practices. Most microcontrollers and electronics components can operate regardless of temperature, so this is almost a non-issue. But, there is one component which is equally as vital as it is unlikely to work in low temperatures: the battery. Almost all commercial rechargeable and non-rechargeable batteries either don't work at all, or have harshly reduced capacities when exposed to low temperatures. This means the conventional method of powering microcontrollers, rechargeable LI-POs, is out.
Possible Solution: the only battery we've found that's been advertised to work at low temperatures is Energizer's Ultimate Lithium line. These are rated to work down to -40F, but they aren't rechargeable which increases cost and is overall not ideal. This issue definitely needs more thought.
The "Finish Line" Problem
Commercial break beam sensors are quite widely available. They combine an infrared light source and an infrared receiver. They set a pin high when the receiver isn't receiving the light source. This would be perfect for sensing racers cross the finish line. The issue is, they are usually only used for no more than 2 feet. Not ideal for our case. This means we'll have to assemble the most powerful IR LED and IR receiver we can find into an assembly for the finish line and program our own code to check when racers cross. Not a monumental task, but certainly a difficult one considering how integral this functionality is to the overall project, and how temperamental our implementation will be.
The "Fetching Results" Problem
The last issue is one of less importance but certainly needs solving if we plan on making this device easy to use for the public. There needs to be an easy way to get results at the finish line. Preferably from a mobile device. There are only a few protocols that all mobile phones and the Raspberry Pi have in common and could use to communicate: Bluetooth and IEEE 802.11 (Wi-Fi) will be the easiest to use. However, designing a clean interface for the retrieval of results will still be a challenge
Possible Solution: The Raspberry Pi could host a wireless network that isn't connected to the internet, but does contain a web page hosted from the Pi that updates with the notes. This way, anyone could connect to the Pi's Wi-Fi and access the web page with their browser to retrieve results. This is a possible solution but the implementation will not be easy.
Which Microcontroller to Use?
April 27, 2018
Since this project requires gathering and relaying data while maintaining a relatively small form factor, the obvious choice to control it all is a microcontroller.Microcontrollers range from the small devices found inside point of sale system all the way up to systems controlling intricate assembly lines. Essentially, they are like desktop computers or laptops, except far smaller, less powerful, and more ready to interface with whatever sensors you require.
There are a variety of microcontrollers available for commercial use. Three of the most common brands are Arduino, Raspberry Pi, and Beaglebone. It's not entirely fair to group them together, as they each make a variety of different products that serve different needs. However, we had to decide which one to use somehow, so we looked at the most general purpose, entry level models from each brand.
Raspberry Pi 3 Model B+
$35
Raspberry Pi's are some of the oldest names in the microcontoller business and therefore are the name most often mentioned for projects requiring lots of power in a small form-factor. What makes them so powerful? Well, a Raspberry Pi contains all the ports necessary to plug into a monitor, keyboard and, mouse. This allows the Raspberry Pi to be used as a traditional desktop computer, with a graphical desktop, web browser and all. This provides a user friendly way to set-up and interface with the Raspberry Pi. This makes the Raspberry Pi perfect for beginners, that want to experiment with embedded devices but don't want to deal with the often esoteric interfaces. However, the Raspberry Pi is also well suited for more advanced users. The easiest way to access it is to connect to a LAN and then SSH in the Raspberry Pi.
The limitations of the Raspberry Pi often come down to depth, not breadth. It can do lots of things very well, but when you start getting into tasks requiring an excessive amount of GPIO pins or processing power, the Beaglebone Black below is better suited. An example of the features that make the Raspberry Pi so versatile include: wireless networking, 40 pins (28 GPIO), 4 USB ports, 5V and 3.3V output, and power via a microUSB port. The large amount of pins and wireless networking capability make the Raspberry Pi perfect for IoT utilizations.
The limitations of the Raspberry Pi often come down to depth, not breadth. It can do lots of things very well, but when you start getting into tasks requiring an excessive amount of GPIO pins or processing power, the Beaglebone Black below is better suited. An example of the features that make the Raspberry Pi so versatile include: wireless networking, 40 pins (28 GPIO), 4 USB ports, 5V and 3.3V output, and power via a microUSB port. The large amount of pins and wireless networking capability make the Raspberry Pi perfect for IoT utilizations.
Beaglebone Black
$54.95
In many ways, the Beaglebone Black is a Raspberry Pi on steroids. It is a credit card sized computer, just like the Raspberry Pi, that allows you to access a desktop, run programs and manipulate files in all the ways a laptop or normal desktop computer would. The real changes over the Raspberry Pi are under the hood. For instance, the Raspberry Pi requires an SD card to run, as it keeps all files there. The Beaglebone Black has permanent on board memory that a system image can be written to. Additionally, the Beaglebone has a faster processor and more GPIO pins. This allows for interfacing with more sensors and outputs, although it does come at the cost of having half as many USB ports as the Raspberry Pi.
The Beaglebone Black also has some smaller improvements that can make it easier to use, for instance being able to power it from a standard 5V barrel jack, and being able to easily SSH into it even when not connected to WiFi by utilizing the Beaglebone Black's ingenious network over USB system. Simply plug the Beaglebone Black into your computer with a male-to-male USB and it will show up on your local network, giving you SSH access.
Arduino Uno
$22
Arduinos are a relatively different beast than the two other microcontrollers mentioned so far. Arduino makes a wide variety of boards, but the Uno is the original and the most popular. These are true embedded devices, with a low price, a small form factor and a single-thread processor. Further, they have quite limited standard I/O. The primary method for connecting sensors and peripherals is expansion capes that attach to the pins and expose greater functionality. What does all this mean in practice? Uno's are great for doing one specific task consistently for an extended period. If you need to collect humidity information every 15 minutes for 3 days, an Uno and a humidity sensor will do that perfectly. If you want to collect humidity information and push it to a web server running on the Uno, you're out of luck.
Arduino's have become as popular as Raspberry Pi's due to their low cost and ease of use (the Arduino foundation provides a very straightforward IDE for developing and cross compiling for Arduino boards). They also have the widest range of expansion capes available of any microcontroller, making setup for any task you can think of a breeze.
Which to Use for Our Project?
We decided to use an Arduino Uno for the start gate, and a Raspberry Pi Model 3+ B for the finish line. This choice came from the idea that the start gate should be fairly bare bones, with most of the hard work done by the finish line. The start gate will simply be an Arduino listening for a button to be pressed by the start wand, which will trigger the sending of a packet through an Xbee to the finish line.
The finish line will be a Raspberry Pi with an Xbee listening for packets. The start signal will be received which will start a timer on the Pi. The timer will be stopped when an IR break beam sensor at the finish is tripped. While the Pi is doing all this, it will also be running a local area network and a web server hosted on said network. This will allow users to connect to the Pi and then retrieve results through an app or a web browser.
What is This?
April 10, 2018
This blog will host the progress of a couple high school students—Paul Biberstein, Liam Grogan, and Jacob Selian—on their path to bring a product concept from inception to full realization.What product exactly? Well, the idea started back in the Winter of 2018. The three high school students, each avid members of Freeport High School's alpine ski race team, found themselves training late into the night at Lost Valley ski mountain. Nocturnal practices were required, as the few days of the week the team could secure a bus to make the 40 minute journey to the mountain needed to be maximized, so they would spend hours on the mountain, skiing a set of slalom gates, then going back up the lift and doing it again.
 |
| The arduous journey from Freeport to Lost Valley |
Somewhere along the way, an idea came into being. If our opportunities to train are so few and far between, why not make the most of the times when we can train. Specifically, why don't we time our runs down the practice course so we can see which techniques improve our time and which ones make us slower.
Surely a brilliant idea, but the logistical problems of watches and phone stopwatches mounted up and the trio soon realized that this was no small task. In fact, many larger corporations had made just such consumer grade wireless timing systems in the past. However, these kits would go for somewhere in the range of a few thousand dollars or more.
The boys were convinced they could do it for less and were further encouraged as time progressed. Other team's coaches expressed interest, and as the track and field season began it became clear that a similar timing system would be indispensable to dedicated sprinters as well as skiers.
So, as many enterprising entrepreneurs had done before them, they set out with he noble cause of making a cheaper product for a stagnant industry, and to hopefully provide a blog along the way to help future young engineers to understand the more esoteric parts of microcontrollers, engineering, and design.