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:

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:

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.

  1. 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.
  2. 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 on the monitored lines and thus possibility to give very accurate short term forecasting. (by short term I mean 5-35 min ahead of time)
  3. Obtaining non-public train schedules which includes cargo and most up to date (most often this is updated on a daily basis) information available. Yup, such things exist and are used by the railroad companies inhouse - I learned this on the way.
  4. Obtaining data directly from the railroad company - maybe these companies do have a nation-wide database with the information we would like to have for forecasting - I was talking with many people connected and working for railroad companies and so far, no luck with finding such data. 
  5. GPS monitoring of trains - many trains have GPS systems on board. If we could have that data, it would make for a perfect adjustment method.

The first method is doable easily but provides a very corrupted data ending up in a very "noisy" forecasting. (At least in my country, few trains departure or arrive "by the book").

Second method is where rail.X devices would come in handy being rather cheap to build and not interfering with the railroad infrastructure. After researching the problem for over 3 months and many discussions i decided that this is the fastest and easiest way to gather reliable data and in the same time making  it local for the communities interested. Without rail.X mesh of sensor nodes, I find the possible forecasts for specific railroad crossings almost impossible to make. The open hardware nature of such a node, could ultimately work in a system like Weather Underground works. WU works in such a way, that if you install Private Weather Station of any kind and send them data - they provide you with a forecast for your exact location. Win-win situation - the whole mesh gets bigger and more dense hence the data gets richer and more accurate, and the local community gets the forecast for the mere price of the hardware and GSM monthly data bill. It should be stated that in such a model - the more nodes are installed the more accurate the forecast will be.

The third and fourth possibilities are relying on strong cooperation with railroad companies. This is hard for both us and them. Railroad infrastructure was and in many cases still is an infrastructure of a military importance for every nation. Hence the possibilities to use their power or internet connection on site is very hard (this is why I went with GSM and solar power) not to mention their database records (heavens know what we could find there:). Secondly in order to have this data on a international scale - we would have to convince very many governments (some railroad companies are nationally owned) and private companies which would make the solution very labor intensive and non-consistent.

The fifth is pretty self explanatory: communities have no reason in investing in such devices for the trains that don't have a GPS system already since these are owned by train companies. Train companies are not interested in making their vehicles location public due to the safety, and legal reasons - so I've been told. If one train (international cargo vehicle for example) comes, it slips "under the radar" and there are many trains in every country. This method also doesn't give us the information about "when the barrier will close, and how long willi take for the barier to be up again".

It should be understood, that besides a good PR stunt, and possibility of monitoring their barriers for failure, the railroad companies are not interested in this problem (I say this without any accusation of wrongdoing on their site). It doesn't make their service better, or their job any easier. The problem affects mostly the communities living close to a railroad line. Just like the noise levels in close proximity to an airport are not a real problem for the airport, and thus the airport can't and won't do much about it if not made to. These companies sort of produce these problems as a side effect of delivering their services.

In the end, I would like to gather as many streams of data as possible and feed all of them into the forecasting system.

THE FORECASTING SYSTEM

The forecasting system would be a "Machine Learning algorithm" crunching through the available data and learning on the historical data sets. Also the idea is that it's predictions would be updated and adjusted for the sensor readings that happen in real time. In essence - whenever the train crosses one railroad crossing with a rail.X device installed - we have it on our radar, and when it crosses the second one, we even know of what type it is (due to the time difference between those sensor nodes)

This area is out of my bounds but I already talked to some people who are into data analysis about the possibility of cooperation during prototyping.  Maybe somebody here would like to give such data a shot and try to come up with the best forecasting algorithm possible?

PROTOTYPE - next stage

Here are some basic specifications that I would like to incorporate into the second version:

I would like to make at least three to five of those and deploy them on the same train line about 3 railroad crossings apart - covering about 6 - 12 railroad crossings in total. I would like to also gather the train schedule data for this line and feed all of this into one database for analysis. 

I must address the possible problem for this stage - railroad crossings are owned by railroad companies, and their approval of such equipment installation might be of an issue. We need their permission to make any (even semi-permanent) installation of rail.X node on the barrier. This is also what I'm working on as we speak - keep your fingers crossed.

During this stage I would like to check three things:

  1. Hardware design in real life conditions.
  2. Data quality and the accuracy of the forecast.
  3. (if the forecast accuracy is of value) Community reaction to this solution.

I hope you can see that there has been some thought put into this:) Thanks to my friend Maciej for brainstorming and hope to see him on the team when we "take flight" into the next stage of this project:)