Time Circuit

This is the proof of concept build blog for the Arduino based, wireless connected timing system for different sporting events.

[timecircuit]

I have been lazy

There are many excuses I could use right now and all of them are real and legitimate, but the fact is, I have been lazy in updating this site.  

The good news is that I am no longer waiting on parts.  The bad news is that I have added another project to my list of projects that I need to start and finish.  

In the recent weeks I have received a number of IR distance sensors with the beast being able to detect distances over 5 metres.  The challenge is that tech sheet recommends that it is not powered by the USB port.  This makes simple testing a little more difficult but nothing I cant handle with my Bluetooth modules.

The idea is to run the 1 metre to 5+ metre module and the 20cm to 150cm module at the finish line.  This will allow the device to be setup on a course that meets the UCI safety standards for events.

I have also been designing a way to send and transmit all the data when it is not real time. The best way I have found so far to do this is to use special characters to represent the start and end of a long string of variables.  This means it wont process the whole string until it receives the start and stop characters.  Testing this will commence soon and nailing this function is quite important. The new project added to my list is a button box for my iRacing simulator.  Imagine a driving simulator with a centre console full of buttons and each button works.  That is the basic idea.  I would have a switch for pit lane speed limiter, another to turn on lights or the windscreen wipers, that sort of thing.

[timecircuit]

The race to the finish line

The finish line triggers have changes somewhat over the past 2 weeks.  The new design makes use of 2 IR sensors (20cm to 150cm and 100cm to 550cm).  The bad news about extending the range at the finish line to 550cm is that SharpIR library I am using does not support it, so I will fork the current library to allow it to be compatible with the Sharp GP2Y0A710K0F sensor.

I have also been focusing on coding interrupts on the analogue pins.  This has become even more important given that the finish line device will now contain two IR distance sensors attempting to detect a competitor finishing.

There is not much to show given my current focus, so I will see if I can take a few photos of something more interesting tonight.

[timecircuit]

A better way = more parts required

Working through the idea of having a way to manually input competitor details has made me realise that a simple 6 button matrix isn't enough.  After thinking about the best way to add buttons and researching readily available products that already exist, I have decided to order a 4 by 4 button matrix off of eBay to test this theory.  The good news is that they only cost $1.19 and they offer free postage.

The buttons layout I have come up with is quite simple. A standard telephone number system starting with 1 in the top left, bottom left (S13) is reset, under the 9 and next to 0 is OK (S15), and the right column of buttons will be used as up and down arrows.  These up and down arrows will have the same functionality as my current button matrix.

So until these parts arrive, I will be focusing on writing better interrupt code for when the IR sensors are tripped and then sending the date/time stamp of the RF transceivers to the other end.

[timecircuit]

That Startup Show - Episode 02

[timecircuit]

Finish order could be different to the start order

Recently I have been asking myself 2 very simple questions that require an elegant solution; How do you start the system for the very first rider and what happens when a rider doesn't finish, stops on course or gets overtaken putting the start order out of sync?

The first question is quite simple.  The system will wait for a button press before starting the 30 second interval between competitors.  The same button press would be required for each wave or category of competitors.

The second question is a little more difficult. I have been thinking about having a user input panel attached to the end device where a marshal can enter a competitors number and when they cross the line, the triggered time is attached to the riders unique number.

This also raises additional questions regard the start order of competitors.  I can simplify the code and solution in the PoC stage by simply having a competitor input panel at the start and finish lines.  This allows for a running order to be printed or not required in a self-seeding situation.

In this scenario, the competitors line up and before each run starts, the marshal enters the riders number on the panel during the interval and when the rider triggers the start timer, the riders number and time is sent wirelessly to the finish line.

Doing it this way means that it is quite flexible and simple and might be the best way to do it for the proof of concept.  It also means that a running order isn't being sent up and down the course over the wireless mesh network which has been set up.  

This all needs more thought and will be my focus after I have finished coding the start sequence mentioned in my previous posts.

[timecircuit]

Start Sequence - Part II

Having had a little more time to research and think about the starting sequence, I am starting to think that this could potentially be set by the laptop or at the start line as part of the startup sequence and then updated wirelessly by the laptop if needed.  For PoC purposes, I am going to have a number of screens in the boot sequence to configure the following settings and worry about updating the settings remotely at a later point in the project.

Settings:

Interval between competitors - Default: 30 seconds

1st warning tone - Default 10 seconds from start

1st warning tone length - Default: 1 second

2nd warning tone - Default: off

2nd warning tone length - Default: 0 seconds

1st Start tone - Default 5 seconds from start

Start tone length - Default: 0.2 seconds

Play tone for each of the last 5 seconds - Default: Yes

Last tone length - Default: 2 seconds

The competitor is allowed to start at any point they are ready in the last 5 seconds and the last tone indicates that the timing has started even the competitor has not left the start line.

If there is a reason that the competitor order changes and the scheduled rider does not start, I am not sure if I should have a way to skip the rider on the start line or if this would mean that there is simply a minute gap between competitors and the original rider gets a DNS (Did Not Start) which is controlled manually by the event system on the laptop located at and connected to the finish line.

[timecircuit]

Start Sequence

I haven't had much time to actually sit down and write code this week, but it doesn't mean that I haven't been thinking or capturing ideas and requirements for my yet to be name sports timer project.

The start sequence is one particular area that I need to configure as part of the boot sequence, but I need to make it as flexible as possible.  So far I have thought about setting the following variables as part of the initial start line boot setup screens.

The setup screens will ask the following questions after the first two setup screens have been completed.

Warning beep sounds how many seconds before the start sequence?

How many beeps?

How long is the window where a rider can start?

Do you want the last beep to be longer?

Answering these simple questions will give the following start sequence.

The rider will hear 5 beeps over 6 seconds which indicates the start timer is active and ready.  Every second a tone will sound with the last tone lasting 2 seconds.  If the IR sensor has not been tripped before the end of the last, longer tone, the start time is automatically recorded for the rider.

I have been searching the internet for an official start sequence that will help me ensure that the sequence is correct, however my documentation as a commissaire does not have it and the UCI documentation does not mention it either.

This Youtube link shows the start sequence for a UCI downhill race.

[timecircuit]

Another quick photo showing my current display collection.

Back left: TFT Back right: 20x2 LCD shield with buttons Front: 20x4 LCD

[timecircuit]

Here is a quick photo of some of the items I am working with.  In the background is an Arduino Uno with SD card + RTC shield and in the foreground is two differential air pressure sensors with silicon tubing attached.

I have a two TFT touch screens that I would like to use on one of my projects but they require an Arduino Mega which is yet to arrive.  Once I have one to play with I can decide if it is worth using on my sports timing project or if I should continue with a standard 20x4 LCD screen as seen in my previous posts.  The TFT could be used and remove the need for the button matrix I created, but using the screen and the required Mega does add significant cost to the proof of concept for not a great deal of benefit.

[timecircuit]

Good news everybody!

After waiting what seemed like months, but in reality was only a few weeks, my real time clocks (in shield form) have finally arrived.  I didn't get a whole lot working with them last night, but I did get the time and date set and completed a few simple time calculations that would be similar to what might be seen in the final code.  As expected the RTC on the board is not the high precision version that a final product would require, but for the proof of concept, it is more than enough.

Setting the time on an Arduino is one of those things that requires separate code to be compiled and uploaded to each Arduino.  This causes issues when the clock battery goes flat and needs replacement.  I have started thinking about ways to update the date and time on remote devices and the possibility of building a board with two clock batteries allowing for the replacement of one, and then the other and (hopefully) never losing the settings.  This is a long way down the road so now I will just focus on sending the time stamp from the start line over the RF radio modules to the finish line and to a laptop over a Bluetooth connection.

[timecircuit]

One of my original ideas was to use a pressure sensor and tubing at the finish line as a trigger, but questions around the reliability of using a pressure sensor as a trigger and the durability of the hoses in an outdoor sport like a mountain biking have come up.  

I decided that a good way to test both of these concerns was to make a speed trap.  I will be using two of the differential pressure sensors (MPXV7002DP) shown above by connecting them to analog pins and recording the times they are tripped.  

Two 3 metre (9 feet) silicon tubes connected to the pressure sensors will be placed on the ground a certain distance apart.  Using the known distance between the two tubes and the time it took for both sensors to be tripped, I can easily calculate the speed at which the rider was travelling.

Simply recording the speed isn't doing anyone any favors, so I will use a spare LED matrix I have to show the speed of last rider.

I plan to share the sketch, circuits, photos and video of this device in action this weekend, so check back here in the next few days.

[timecircuit]

RTC, where are you?

My real time clock order still has not been delivered so I spent the night polishing the start line boot sequence, initial setup and triggering code.  The good news is that this is in a state that I am quite happy with for the PoC.

Given that the buttons are only required for the initial setup phase, I am thinking of making them external to the device and just plugging them in when needed.  The downside of this is that if the buttons are not near the device and it reboots, the system cant be used.  It also allows for them to be misplaced which also makes the system useless.

Option B is to use a touch screen TFT and a Arduino Mega which I have.  I think it might be overkill for this project, but we will see how we go with the proof of concept.  It might be that I go down the TFT touch screen path in the prototyping reiteration stages.

[timecircuit]

Start Line Device

Last night I focused on simplifying the start line device.  This basically meant removing components that were not required such as the Bluetooth module, adding the long range transceiver to transmit data to the finish, simplifying and polishing of the code.  I also spent some time documenting the current circuit in Fritzing.

The good news is that when the IR sensor is tripped, it sends simple data wirelessly to the start line Arduino.  The finish line Arduino right now is a wireless receiver and Bluetooth connected serial monitor.  I am still waiting for the delivery of of the RTC (real time clock) I am using in my PoC which is why I am only sending simple data instead of date time stamp.  Once this arrives I can integrate the sending of this data and work on the finish line device components required to calculate the overall time.

I still have a few noticeable bugs in the setup screens which I will work on tonight if my RTC does not arrive today.

[timecircuit]

Start line device boot sequence, initial setup and a few triggers thrown in for good measure.

[timecircuit]

The updated start finish model has removed the need to use a phone/tablets cellular network to connect each node.  The XRF wireless transceiver I am testing has a 300m range but has been tested up to 3km line of sight.  These are quite cheap devices and hopefully with further testing and tweaking, I can use these in the final product.

Once I have a fully functioning IR trip wire that is working reliably for the start gate, I will look into making a physical gate similar to how they are used in professional systems and skiing events.

[timecircuit]

A quick drive around the block to test the range of the wireless transceiver. 

[timecircuit]

It may not seem like much, but this LED is being told to turn on and off wirelessly from a device I put outside.  Since taking this photo, I am successfully transferring strings from one Arduino to another without the need for a PC.