check out the log in here!
The rail.X is a device for monitoring the "open-closed" state of the railroad crossing barrier. It puts the data into a (common for all nodes) database which in turn provides the community with a short term forecast of the barrier state. This forecast, just like the "traffic forecast" from Google Maps, can be used by everybody who plans to go through this railroad crossing - emergency vehicles, public transportation, trucks and daily commuters.
The rail.X node should be a rugged open source device consisting of a tilt-switch with proper filtering, a GSM module, battery and a solar panel, prepared to be installed on the barrier of the railroad crossing.
Please watch the PITCH VIDEO (in the details section) for more information and my reasoning on this topic.
Ok, so after reading the description and watching the video you've got probably the idea what kind of problem I am facing. I think that it is real and that many aspects of our lives could change if we improved it, such as:
- faster arrival times for emergency services
- smaller traffic jams
- extra railroad barriers monitoring for barrier failure
- smarter public transportation scheduling
- improved logistics
...in a nutshell, a higher standard of living.
HOW TO HANDLE THE PROBLEM
In order to solve the problem we need to gather data about the barriers being closed (in the end this is what we are interested in - not the trains). If we have such data and it is reliable, we can analyze it to provide the communities with a short term forecast of the barrier state.
Side note: Why a short term forecast and not a long term? Because I believe this is what is important for each of the parties benefiting and what is usable from the point of view of forecasting analysis.
PROTOTYPE - as is right now
I've done the first prototype about 2 months ago. It consists of:
- Particle Electron
- 2000 mah Li-ion battery
- tilt switch
For data gathering we have a Google spreadsheet connected via IFTTT and a secondary Blynk app for real time monitoring of the state change.
This prototype gave me the possibility to do two things: optimize battery life and data amount (GSM data isn't cheap). For now my estimates are that it should be possible to run a node for more than one month on the battery without a problem, and that it should take about 4-8 mb of data (we need to send a message on the "close" and on the "open" action, for the system to be real time, plus Particle connections are encrypted which eats up the data, yet adding security of the data transfer). Thanks to these above I find the ultimate goal for this device (a working node installed on a railroad barrier) obtainable.
BTW: the tilt switch (in contra to the accelerometer, digital tilt sensor or any digital gyro) is also great due to the fact, that it can wake up the microcontroller board hence being of double value. It gives us the information we need, and in the same time let's us save on energy.
It should also be noted that I need to send two states. When the barrier closes and later on when the barrier goes up again. But the barrier can be closed for a pretty long period of time (1-7 minutes from my experience). The biggest power savings come from using the deep sleep mode of the board. I can wake it up, when the tilt-switch goes from low to high. But the problem is that if I want to put the board to sleep during the "low" period (let's say, the barrier is down in this state)- it will not wake up the board when the tilt-switch goes up - from LOW to HIGH. So I need to change the signal as explained on the picture below.
Thanks to the help of some folks from the community forum Electroda.pl I've come up with a simple circuit that does exactly this providing also some hardware debouncing on the way. It's tested and works. Now I can wake up the board with a state change on the tilt-switch.
THE DATA - and ways to gather it
The data we need for analysis can be obtained in many ways. SPOILER ALERT - I would like to test and bind all of the data streams mentioned below and feed this into the algorithm/AI for forecasting, if that would be possible - but I doubt that.
- Analyzing train schedules - easiest one, but due to the delays and cargo traffic not really the most bulletproof data for forecasting. This method also doesn't give us the information about "when the barrier will close, and how long will it take for the barier to be up again". This is about the trains, not specifically the barriers.
- Gathering the real time data on a wide spread mesh of devices (here we go rail.X) - Every railroad line would have to be monitored on significant railroad crossing barriers. This would give us enough data to make a real time "map" of the current situation.