rail.X : monitoring railroad crossings for you

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:)

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:)

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!

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.