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.