Ok, so after reading the description and watching the video you've got probably the idea what kind of problem am I facing. I think that it is real and that many aspects of our life could change if we improved on that:
- 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, higher standards 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: optimizing 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 at 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 be also 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 a 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 spreaded 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...
Great! Good to know that somebody met this problem and try to resolve it.
I've tried to resolve it using open/close door sensor, talked with RR and they explained that it will be very hard to implement. Then I changed my focus to IP cameras and neuronets.
As a result, created a project Rail-X (https://rail-x.com/, sorry, it's on Ukrainian only by now). The idea is:
- monitor railroad crossings barriers over IP camera
- make analyze and notify users over Telegram bot
Four cities are already connected and two ones are on waiting status. The main issue is to install IP-camera in the right place.
I'm interested on collaboration - we can connect your local railroad crossings, the question is at cameras.
Write to me if it interesting for you as well