Close
0%
0%

rail.X : monitoring railroad crossings for you

Mesh of open devices monitoring railway crossings "open-closed" status.

Public Chat
Similar projects worth following
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 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.

  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...
Read more »

  • It's still here.

    jan.marcinowski11/09/2018 at 11:15 0 comments

    Just to write a short update.

    The project is evolving. Slow moving indeed but keeping the direction forward.

    In short what happened during last 3 months.

    1. The negotiations with Polish RR Companies are moving foreward. If everything goes as planned we should get the legal permission for test run installation. Can't say any more, but ... fingers crossed.


    2. We have a PCB version of the prototype.

    3. The first  "art of the bodge" prototype is still running. 171 days non-stop and counting. It's just unbreakable:)

  • Over 50 days of prototype testing!

    jan.marcinowski06/29/2018 at 14:47 0 comments

    We've reached a milestone - over 50 days of non-stop work with solar power and 60 simulated trains every day!

    Yup, rail.X prototype 1.3 attached to a device simulating a railroad barrier is a legit long runner.

    The version 1.3 is by now working non-stop for a period of more than 50 days. We gather data from it to monitor the "state of charge", the power of solar cell, and also the temp, so that we don't charge the Li-po when it get's too hot (over 40 C). Oh, and the state of the barrier of course:)

    one random day table example
    one random day table example

    The maximum Soc for our Li-po is around 87-88% even during a fully sunny days, but I consulted this with Particle Community, and was assured that this is in fact a "by design" feature. See the conversation here.

    I've also confirmed that the device is using in such conditions (60 trains a day) about 1.2 mb a month - on Particle SIM.

    My friend (Maciej) is helping me with the PCB design, and we have (the 0.3 version) ready to be printed. You can see the schematics (and some renders) below.

    Keep your fingers crossed. We hope, that when we get the PCB prototypes, the possibility of "real life" tests will be much closer!

    Thanks for support I've been given. You're great!

  • Prototype 1.3

    jan.marcinowski05/14/2018 at 14:00 0 comments

    I've developed 3 prototype versions in the last 3 weeks or so (1 hardware, and 3 software iterations) and here you can read about what this changed in the project.

    1. GSM data - Greatly reduced GSM data consumption (over 0.19 mb per day in the first version). By now, for 60 trains a day  (120 connections to Cloud), rail.X will consume around 1.2 mb A MONTH, which is very good, but we can improve on this on a later stage even further (by now we send some diagnostics data, every time the barrier changes it's state, and I would like to gather this kind of data in the final version only about 3-4 times a day). BTW: The data is encrypted.

    2. Battery consumption - By now the device is estimated to work for at least 14 days without any other power source than the battery and log 60 trains (120 connections to Cloud). The battery I use now is 2000 mAh. Deep sleep is king. 

    Thanks to my friend Maciej, for analyzing power drainage and finding out it was caused by logic gates freefloating inputs. After grounding those, we cut the power consumption during "tilt switch open state" from about 0.205 mA to ... 0 mA (not measurable by me multimeter):)

    3. Solar power - I am successfully charging rail.X from the solar panel. Unfortunately we are seeing some inconsistency, and problems here so this one needs improvement. I can not charge the battery above 87%. This might be due to the battery fault - need a new battery to check this. Or the power from the solar panels is too small (around 140 ma in full sun) and the charging curve get's very steep around 87% SoC. 

    If you are interested, and would like to help:

    • I'm using these solar panels for now - 6V 1W. Two of those connected in parralel, and stuck outside the window.
    • The code for charging I use is:
      pmic.setChargeCurrent(0,0,1,0,0,0); //Set charging current to 1024mA (512 + 512 offset)
      pmic.setInputVoltageLimit(4840);   //Set the lowest input voltage to 4.84 volts. This keeps my solar panel from operating below 4.84 volts.
    • Excel data (in a form of google sheets) to wrap your head around can be viewed in here (please consider that this is a total Work in Progress).

    Other updates:

    1. I developed a test rig, and called it "the terrorist" since it is designed to stress test rail.X :) It is based on a small WioLink board (later on we plan to use the connectivity provided by ESP8266), and a servo. The program is bound to generate 60 barrier cycles a day, in intervals: ~21 min barrier opened followed by ~3 minutes closed. We are using "the terrorist" to compare prototypes, and to push the development on.

    2. rail.X was packed inside a lunch box, to provide some mobility.

    rail.X current prototype (here you can see a small solar panel behind window - now I have two of those, attached to the window from outside):

    3. I met with officials connected to RR Company in Poland. No declarations for now, but some interesting possibilities are emerging. For example I've been informed that the "standard" minimum temperature, that the railroad equipment has to be tested against is -25 C. Good to know:)

    4. I sketched the schematic for rail.X

    5. There has been a very fruitful discussion on Particle Community forum about redundancy of the tilt switch sensor. Read more about that here.

    6. The IFTTT integration stopped working 2 days ago (you can see this in the Google Sheet that is under the link above in the section about solar power). Tried every trick from "the book", but couldn't fix that. I'm thinking about using a Google Script to pull the data from Particle Cloud directly.

    Next steps (not in order):

    1. Further improving on solar charging and also power and data consumption.

    2. Outdoor proofing rail.X and "the terrorist" to be fitted for outdoor tests.

    3. More negotiations and talks with RR Companies in order to get the necessary permissions, to install 3-5 rail.X prototypes on one train line.

    4. Fixing the "google sheets/ifttt/particle cloud", data collection method.

View all 3 project logs

Enjoy this project?

Share

Discussions

Ihor wrote 06/24/2019 at 11:37 point

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

  Are you sure? yes | no

manta103g wrote 07/26/2018 at 21:54 point

The idea is not new but RR and public roads administration don't cooperate in any cuntry ( US, Germany, UK, Canada ... ), so as a driver, you are not entitled to get access to train crossing the road data for a specified railroad barrier and for the same security reasons, such data are not distributed in public over the Internet. All you can access is passenger trains' timetable. To build a working technology solution to the problem you need to contact EU railway administration in Brussels, to implement new legislation and standard for all railway crossings in Europe.

  Are you sure? yes | no

Douglas Miller wrote 04/22/2018 at 22:52 point

In the US you WILL be arrested for attaching anything at all to a crossing gate. 1: It's private property, and 2: It's a safety device and they take that kind of thing seriously. I'd have to do some digging, but I'd just about bet it would be a federal offense, too. For a railroad and/or the feds to give you permission you'd have to do tons of studies to prove it wouldn't hurt anything, which we all know it won't, of course. But I'd bet you wouldn't even be allowed to do the study on their equipment.

You do have a point, though. I solved this problem here locally a year ago with an optical system that is not in any way on railroad property. HackaDay even did a writeup on it: https://hackaday.com/2017/11/06/trainspotting-with-junk-for-science/ We have around 90 freight trains go through town every day, and police and fire are 'railroaded', as they call it, all the time. I've made the data available to anyone, including the city, that's wants it. I'm currently working on an phone app to give everyone a heads-up on what crossings are blocked and which are not.

I agree with your goal. I just urge caution before you attach anything to a crossing gate. I don't know where you live, but I'd bet the law's not going to be kind to you in almost any country.

  Are you sure? yes | no

jan.marcinowski wrote 04/22/2018 at 23:28 point

Hi there Douglas, first - it's great to hear that people struggle with this problem everywhere and come up with solutions. 

Your solution has some true "makers vibe" to it! Nicely done:) I was thinking about a Raspberry Pi with a camera and a optical recognition algorithm some time ago, but decided that to make it affordable and rugged I have to go for cheaper and more universal approach. I'm trying to deliver a "node-system" if you will, that could be implemented easily everywhere in the world. Given, that it would be legal and the permissions would be granted. I just hope, that if the study goes well, the other countries and companies will be more willing in future.

I know that my details page is a little TLDR. Sorry for that:) But in it you can read "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." 

So to be perfectly clear, I am and was well aware of this problem. I'm now discussing the possibilities with government authorities in order to perform this study. In the end, this equipment is from their perspective a screw in a barrier:) Things look promising for now. We'll see.  Keep your fingers crossed:)

  Are you sure? yes | no

Similar Projects

Does this project spark your interest?

Become a member to follow this project and never miss any updates