To fulfill the hackathon's safety theme, we decided to use one of our team member's familiarity of end of train (EOT) signals to develop an app capable of reducing railroad crossing accidents. The idea was that we'd use an antenna capable of detecting EOT signals to send an alert to a raspberry pi whenever a train was approaching. The pi would then send a beacon to nearby iPhones alerting the users of rapidly approaching trains. Our app also displayed a map denoting railroad crossings close to the user.
Our EE team member was responsible for working with the antenna, the other worked with the iPhone app, and I was the gofer (AKA I did whatever no one else wanted to do).
My responsibilities included:
-Parsing a very hefty csv file containing railroad terminal information
-Generating JSON objects with train terminal locations
-Determining when the antenna was capable of detecting an approaching train
-Using bash scripts to send alerts to the raspberry Pi
Considering my lack of experience at the time, I made several unecessarily "hacky" descisions. Whenever the antenna detected EOT signals, it generated a binary file with the signals' information. My idea was to detect the creation of that binary file and to send an "alert" to the raspberry pi in the form of a text file, notifying it that the antenna had captured an approaching train. I wasn't familiar with sockets at the time, so my solution was to write bash scripts to use Dropbox to transfer files over. It wasn't pretty, but it worked.
Our hackathon project began with the idea of creating a chrome extension that would bring new functionalities to Access Plus, a website used by my university to help control student information.
The general idea was to bring 4 new functionalities:
-> Rate My Professor integration on the schedule page
-> The display of the student's schedule on the registration page, allowing for a real time update as the student registers for classes
-> A meal tracker that can keep track of how many meals the student is above/below budget on a daily/weekly/monthly basis
-> The exportation of the student's calendar to an .ics format (compatible with Google Calendar, Outlook, iCal, and most calendar applications) with a single click
We received some enthusiatic responses during the judging period, and my friend and I decided to finish the project and release it to the student population. There was a lot of work to be done still, since a great big chunk of the project was hard coded or bearing dubious results.
Four months or so later we finally managed to release the extension to the google app store, and it is currently being used by students.
For more information on the project, click here
This hackathon was somewhat strange considering the company gave us 3 very specific projects with requirements. Since we had an EE student on board, we had to pick the only electrical engineering project available, which was the one dealing with train signals. The basic idea was that we had to use an antenna to capture nearby train signals, generate a binary file with the signals' information, interpret the file, and display it in a meaningful fashion.
Naturally the EE student was responsible for working with the antenna, I was responsible for the backend, and my other coleague was responsible for the front end.
Considering how we each had very specific jobs, I decided to develop a type of "three way system".
Computer A would receive the radio signals and would generate a binary file and send it to Computer B.
Computer B would receive the file, parse it, and generate an html file that would be sent over to Computer C.
Computer C would then get the html file and dynamically append it to our website.
To perform such a task, I used sockets to transfer the files from one computer to the other. When the file reached my computer (computer B) I would run it though my parser and search for strong enough signals to scrape information from.
The signal strength could be detected by a patern which included a series of 'C's followed by a lone 'F'. The problem was that the amount of 'C's varied, and since we were working in a "turbulent" area, we ended up with several false positives. Considering we only had 24hrs, I ended up deciding to calculate the average number of 'C's found in "strong" signals, and use that average as a way to determine whether a signal was strong or not.
Whenever a decently strong signal was found, the parser would scrape off the necessary information such as packet type, signal ID, yard Id, ect...; and append it to an html file.
Whenever the signal was cut off, the parser would stop adding information to the html file, and would send it over to Computer C.
We decided to use "heat maps" in order to demonstrate the quantity of signals received from a specific area in the US. Due to the lack of time we ended up having to hard code parts of the Radio Heat Map, but every other information was capable of being generated live.
To view our project presentation, click here