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.