rail.X : monitoring railroad crossings with electron

Hi there,

I just wanted to share with you a project that I’m working on for quite some time now, and just recently entered Hackaday Prize 2018 contest with.

I would love any comments from you about it, since I’ve built it with your help (many questions about the power savings and data consumption were resolved by Particle Community and also reading the historical threads on this forum). You can read more on the project page, but here is the short description.

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.

If you prefer a VIDEO VERSION OF THE PITCH.

If you would like to start a discussion about this project or ask me any questions - please do it on the Hackaday project page if you can:) If not, of course I will monitor also this thread.

BTW - I would like to post it to the Hackster.io contest as well. I think that upgrading from Electron to Boron might add an additional feature to this project: I could easily (with Xenon) monitor all barriers on one railroad crossing making the solution not only do the primary job, but also help everybody by providing a new way for monitoring of the railroad crossings barrier failure (situation in which all barriers close as they should and one stays up, due to any failure)! (with the original design, I just monitor one barrier on one crossing to gather data).

7 Likes

Just poppin’ in to say I LOVE this! :sunglasses:

2 Likes

Thank’s Joe. Uplifting “pokes” like you did, give motivation to push the project forward. Keep your fingers crossed for us getting the approval to install the prototype on the barriers for testing:)

1 Like

Hi all, I have some doubts that I would like to discuss and I thought that this forum would be the best place - could you contribute with some ideas?

Since I want the device to be as accurate and rugged as possible - I would like to introduce a redundancy for the tilt switch sensor.
The tilt switch sensor has two different uses in this project:

  • Wakes up the ​board (Particle Electron) when the barrier changes state - here I use a filtering, debouncing circuit of my design which you can read more about in the “details” section of this project.

  • Is checked by the board for determining the actual state that the board woke up to.

Why redundancy is needed? The Tilt-switch sensor I’m using is an mechnical device​ - which is good because I can wake up the device this way, and does not consume power when in “open” state. Basically a tube with a steel ball inside - if the ball falls on two contact pins, we have “closed state”, and when you tilt the sensor the ball goes to another end, and we have “open state”. I think that it might be prone to mechanical wear or failure in extreme weather conditions (harsh frost for example?).

QUESTION:
What type of redundancy / double check system would you suggest? I have two ideas which I list below (please comment on these, or/and add your own ideas):

  1. Second, same type tilt switch sensor (of a different brand for example) with a logic gate, so that even when one gets “stuck” in one state, the other one could work. We could than compare the states in order to check for failure. Still not the best solution since in principle these would be vulnerable to the same type of failure in similar conditions.

  2. Some other mechanical solution, which is both robust and compact - I suppose such might be available but don’t have anything in particular for now in mind.

  3. Gyro, accelerometer, IMU or some other type of digital sensor with witch I could check the position after waking up. This gives me some headache since I would like the auxiliary sensor to “take place” of the original one in both tasks and in the same time be as low power as possible. Don’t know is it possible to check the position of these type sensors after deep sleep if the change in orientation happened during deep sleep and it’s stationary again when I check it? Also for power consumption optimization sake, I tend to detach all the sensors form power source when these are not used. I power these - check the state - and cut the power again. Don’t know if this could be used for such sensors. Don’t have much experience with these accel/gyro/9DOF/IMU/MEMS - could you suggest the best one if this approach is of any value?

If you see any flaws in my way of thinking, or have a better idea - please share this in comments section of this project

I’d go for the same accelerometer as the one used on the Particle AssetTracker (LIS3DH) which is very low power (IIRC 3µA in standby) and can also wake the device.

1 Like

@ScruffR is probably right. No moving parts is good.

If you need an alternative to augment what you already have, what about a hall-effect type sensor like on a garage door. The bad part is you would need a magnet to activate the sensor when either in the up or down state. If you’re looking to put a fully self contained device on the crossing arm, this might not be the best. If you had a plastic enclosure with a steel ball that rolls back and forth, a hall-effect sensor might help because it doesn’t have to make physical contact with the ball but could still sense its presence.

Also, when I first read your project the other day, I thought of the exact same legality problems that someone posted on your project site. In the US, the railroad owns everything on the rail line and so you would technically be trespassing by attaching anything to the barriers. But the US is quite backwards regarding railroad use… and in my city, backwards regarding public transportation in general.

1 Like

Thank you @ScruffR and @ninjatill for your attention and input.

@ScruffR thanks for pointing me in the right direction about choosing the right accelerometer. I will buy that LIS3DH breakout board and try it for myself. I have some doubts about it’s ability to wake the device - the barrier has got some serious wobble to it, and so we need to make a HARD CORE debouncing and filtering of it in order to get wakes only when the barrier changes state and not for example … with every stronger wind gust:) I think though, that this has to be checked in real world conditions, and so… I’m ordering one of those, and will check that.

@ninjatill - the hall effect sensor is a very neat idea. This would mean that I have to make some mechanical device with a ball to be incorporated inside the rail.X device and this might be a showstopper for the “open” nature of the project but - I have to investigate it some more to be sure.

LEGAL ISSUES OF THIS PROJECT: since many people are pointing to me the legality problem of attaching the device to the RR infrastructure. Rest assured - I know about it, I’ve written about it in my project details on Hackaday (in the lower section of that TLDR details page:). The state of this matter for now is - I’m arranging meetings with RR to get approval for installing first testing batch of devices on one line (3-5 devices). There will be no trespassing involved:slightly_smiling_face:

Thanks for these two ideas. Does anybody have some more ideas? The crazier the better, since we have already the sensible ones :slight_smile:

@ethelder do you have a picture of a typical gate you can share? It would help to better visualize a possible solution.

If you are using Electron it seems to me the bigger concern is power over the long term. You should be able to find some very reliable mechanical switch options that would provide many years of service. The mercury tilt switch in household thermostats can last 30+ years.

Crossing monitoring systems exist already, I guess that data just isn’t shared with anyone making good use of it (besides for the obvious rail, traffic & pedestrian safety)?

@peekay123 Good idea. The one I’m targeting (close to my house so one that was „the biggest inspiration”) is this one. The barrier is made of wood, but the newer ones are made of some light aluminum or plastic/fiber. Does it help?

@BulldogLowell I have some history with Electron and making it power efficient - rather good history:slight_smile: . So far I think this should be managable. The ultimate answer will emerge during testing. Too many factors to give definitive answers: weather, solar irradiance, how many trains pass daily etc. Regarding mercury tilt switch sensors. Don’t you think that the freezing point of Mercury might be an issue? This needs to be investigated, how often it gets this cold in places where people live? Regarding „crossings monitoring systems exist” - wow, great, could you name one? I’m very interested in such devices if you know any.

Thanks for all your ideas:)

yes, especially if you are monitoring train crossings on mountaintops or in Antarctica :wink:

there is a little company called Siemens that does some work with trains.

1 Like

I would stay away from mercury due to the classification as a hazardous material. Also Alexa tells me it’s freezing temp is -28.84°F.

Check out this Link. It talks about a self contained tilt sensor that operates by optical disruption.

That new type of tilt sensors is just great. Never heard of those:) This is exactly why I posted this question - new ideas that I never heard off, Thank you @ninjatill.

Unfortunately the sensor that you suggested has got the operating temp range going down to only -25 C:( Here is the datasheet. That is a much more common temp than the -34ish of mercury but…

…this made me check one thing - operating temp range for … Electron. It works till -20 according to the datasheet and so the minimum temp for the tilt switch is no more an issue. -20 C is a very common temp in winter at least for where I live.

Now I have to think about some solution to keep the device running as a whole in such conditions. Bummer:(

There has been some improvement in this project in recent weeks which I documented on hackaday.io project page. If you are interested visit the log in here.

In short:

  • greatly reduced data consumption
  • reduced power consumption
  • solar charging added
  • testing rig (60 trains a day)
  • meeting with officials connected to RR Companies
  • read more on hackaday

I also publish the data to google sheet which you can view (this is a total Work In Progress so sorry, if that is not clearly documented sheet). See it here.

I’m experiencing some issues with the solar panel charging in this project.

I’m using two 6V 1W solar panels in paralel stuck to the window glass on the outside. The panels are no-brand Chinese DIY products. To be exact, these.

I’m using code suggested by @RWB to setup the charging:

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.

I’m using INA219 sensor from Adafruit to read the bus voltage and power between the solar panel and Electron, and all of these information are collected in this google sheet.

Since the whole solution is using a deep.sleep procedure - it was discharging too slowly for my tests so I introduced a LED with 200 ohm resistor directly to the breadboard so that the discharge is more significant and I can check the solar panels:) This is just so you know, why the device is using this much power even though it should be more power efficient :slight_smile:

The problem:

  1. The power from the solar panels never gets above 190 ma even with clear blue sky, and sun perpendicular to panels. And from what I understand having two 1W panels in paralel should give me higher readings.
  2. The battery never goes above 86%. I understand that the charging curve gets steep around 90% but is it … so steep?

Or maybe with the given hardware and software, everything is working as it should, and I should change the panel to see any significant improvement? BTW - I’m also thinking about changing the battery to a similar so that I know is the 87% cap a problem from battery.

More on this can be found here and the last update is here.

@RWB (calling you out, since I know you have huge experience when it comes to powering particle devices from solar, could you drop in, and take a look at my setup?)

I believe it's common for the Particle Device to report a max SOC of 85-90%.
A Li-Po's performance curve is extremely flat and the Voltage is just an estimate of SOC.

Also, each 1 watt panel producing ~100 ma through the system isn't shocking to me....especially with the no-name brands.

In a perfect world, you're termination voltage would be a little higher - but I don't see anything to be concerned with your Spreadsheet results, even with your "additional" LED load.
Do you get a higher recharged battery voltage without the LED load?
If So, swapping to a Voltaic 3 watt panel may be beneficial.

Solar panels only produce on average 77% of their rated output when they are under direct sunlight because the sun heats the solar cells up to around 160F which causes the solar cells produce less than their rated power output. Solar panels output ratings are calculated based on perfect artificial sun and 72-degree room temp FYI.

So 2w worth of panels x 77% Heat loss = 1.54 watts of power output under perfect conditions.

0.912 watts from you 2 watt solar array under normal weather conditions which is probably to be expected if you're not seeing direct sunlight on the panels and the solar cells in the panels are probably not the best.

Sometimes the Electron can limit charge current depending on how charged the battery is.

You may be getting more current into your battery if the PMIC is down converting the higher input voltage to the lower battery voltage.

Its always better to go with a larger panel due to inefficiencies.

This is common to not 100% SOC due to the fuel gauge setup.

Hi, Thanks for your reply.

@Rftop - I shall change the the voltage a little. Thanks for pointing it out. The original code used 4.84V but it was supposed to be used with 5V solar panels. Mine are 6V so I can change the volatage indeed. Answering your quesiton - nope, the max SOC is the same no matter what load is attached (without additional LED or with). The purpose of the LED is to drain some more power from the battery during night so that there is anything to charge :slight_smile:

@RWB thanks for chiming in. Since you backed my data with solid theory - I’m not concerned any more. I will eventually change this panel to a 2W Voltaic panel, and this might help a little but it seems that the device should be pretty self-sustaining the way it is tuned right now. Could you please elaborate on the topic of “down converting”? From what I understand, that is exactly what I’m doing right now. The voltage is 4.84V on the panel, and ~4V on the battery so there is the drop that the converter is achieving. Do you suggest that I should set the lowest input voltage to a higher value (if so, could you suggest the value)?

BTW - I plan to make an extra test in the next week where the rail.X will be unplugged from the solar panel, until it will reach around 10% SOC and than I will connect the panel again, to see how fast it will recharge from such situation, and also how the setup will work as a whole.

Keep it at the 4.84v, it's perfect for your setup. The 6v panel operates in the 5v range when heated up, the 6v is only seen when the panel is cold and there is no load on it.

You're doing just fine with the setup you have. So no need to worry.

The max charge rate I ever saw was like 300mA from a Bench Supply, I was never able to get the battery to charge at 1 amp.

Correct, the input voltage can be as high as 17v while 12v is the max recommended by Particle due to heating issues. So the PMIC is converting the higher voltage to the lower voltage but I'm not sure if boost current or not like a DC to DC converter or if it's doing PWM. Either way it works and in your case where the voltage is right above battery charging voltage, it does not make much difference.

Put the Battery Check code to use from this Library to prevent the battery from going completely flat which could cause Electron memory loss.

Hi there,

I made two changes - one (thanks to my friends help) I switched to using Google Scripts instead of relying on IFTTT which proved itself to be VERY unstable.

The new sheet can be found here: LINK - check the “formatted” sheet to see normal data.

And secondly I did the test to check more hardcore charging conditions. I unplugged the the solar panel on 29 May, and waited until the SOC reached 14% on 3 June (yesterday). Than I plugged the solar panel back and two things happened:

  1. The current draw was at peak hight. ~360mA - which is great.
  2. When the SOC reached 85% - the current draw was “limited” to ~140mA.

My question is - why is that? Is it some kind of security feature on PMIC so that the battery is not overcharged? Why I can draw 360 mA from the solar panel when the battery is nearly empty, but when it comes up to 85%, the current gets limited? 85% is not “full”, or is it?

BTW - there are perfect weather conditions today, so the change is not due to a “cloud”. The best conditions for this panel are around 11:30 our time.