Author Topic: openhab-trains  (Read 673 times)

0 Members and 1 Guest are viewing this topic.

Offline Gavin_B

openhab-trains
« on: Dec 14 2018 18:27 »
Introducing openhab-trains an open source project combining the power of home automation systems and cheap arduinos to provide open source modules for running model trains.

Designed for Garden railways where dcc running over tracks proves problematic but will work with smaller scales. The wifi modules have been tested at over 200 feet (60 metres) both inside and outside. All modules are designed to run off 12v stepped down to 5v on board. Most modules could also be modified to run on battery power.

Using the home automation system allows for complex rules to be set up, allowing electronic interlocking to be used for route setting.

The Aim for this project is for people to be able to build simple cheap modules to control their layout and develop and add other modules to expand the system.

The code and schematics and all info to build your own modules are freely available at.
https://github.com/thegavs/openhab-trains

3 modules are published now,  one to read the position of signal box levers, another to work semaphore signals and the last to move points.

Am hoping that other people will add modules to expand the system. 

Interested in views, thoughts and feedback.

Offline cabbage

Re: openhab-trains
« Reply #1 on: Dec 14 2018 19:07 »
That is more than interesting!

Regards

Ralph

Offline IanT

Re: openhab-trains
« Reply #2 on: Dec 14 2018 23:03 »
I like the wireless aspect Gavin - but the existing MERG CBus system is very capable of controlling a large layout in terms of both turnouts and signalling. It is of course a four-wire system - two of those wires being for power (+12v and Ground) - but is capable of long transmission lengths. It is also very well supported by a large and active railway modelling community. CBus users already routinely use JMRI to control their layouts with their phones/tablets via RPi + wifi.

In terms of 'interlocking' - two members of my local MERG group demonstrated an Arduino based CBus board earlier this month that can control up to [currently] 64 devices (signals, lights, turnouts etc) and provide a complete interlock solution - emulating a large signal box. This is provided by exporting an Excel spreadsheet (in CVS format) to an onboard SD card - which is read by the Arduino and translated into Cbus events - to respond (or not) to lever 'events' depending on how the logic of the Excel table is set.

Now - as I said - I do like the wireless aspect. Amongst the regular 15 or so MERG members who attend my local group regularly, I am the only large scale modeller (the majority would be N gauge I'd guess). So some aspects of CBus (DCC etc) are of little interest/use to me - but it is still a very powerful signalling system in its own right - that also happens to be reliable and affordable. So you asked for feedback and I think mine would be that rather than starting from scratch (even based on home automation) it might be better to piggyback on an existing system and explore ways to make it more useful to garden railway modellers.

A CBus-MIO (an £11 kit) can control quite a mix of inputs or outputs (including Servos) - and I'm pretty sure I could hook up a wireless link to a remote device using one, assuming I had the time and motivation. So if I need complexity - then at the moment - CBus is my choice of (easy/available/affordable) railway control tech. If I need a one-off 'remote' solution - a very simple MM solution would be my current choice - using either IR or a (serial) wireless link. I think I am probably a bit more familiar with some of the micro-tech than many here - although I know very little about Linux/Web/Wi-fi systems - so I'm obvously biased by my existing/current experience (and lack of it in other areas).

Very interested to see how you manage to progress your ideas though - and certainly wish you well - but you asked for feedback - and ths is mine at this time.     
   
Regards,

IanT
 


Nothing's ever Easy - At least the first time around.

Offline cabbage

Re: openhab-trains
« Reply #3 on: Dec 16 2018 15:02 »
The OS appears to be a port of Debian release 8.0... Debian has a reputation for being "Ye Olde Fashionende Linux" and also rock solid!!! I use Debian 9.6 on my Linux Engine. It has all the "toys" that a full Debian system has -so it is going to be very interesting as far as I am concerned.

regards

ralph

Offline Gavin_B

Re: openhab-trains
« Reply #4 on: Dec 16 2018 20:08 »
Thanks for the feed back both.

Ian I totally agree that MERG is capable of running a large layout as are other solutions.     I think the systems can co-exist and even work together  It looks like arduinos are being used in many forms such as MERG and opendcc.  Going forward I have plans to use the arduinos on board locos and then using RFID chips to allow automation.

Ralph I do believe you are right about openhabian being debian based.  I run it on a raspberry pi3 with no problems but there is a pine port to run on more powerful boards, and it can be run on any linux system.

In theory it should be possible to link in a 2.4mhz transmitter module and control radio control locos.   It is even possible to mimic the revolution system that many use.

Gavin


Offline Doddy

Re: openhab-trains
« Reply #5 on: Dec 16 2018 20:44 »

"Going forward I have plans to use the arduinos on board locos and then using RFID chips to allow automation."

"In theory it should be possible to link in a 2.4mhz transmitter module and control radio control locos. It is even possible to mimic the revolution system that many use."

Gavin
Now you have caught my interest as well Gavin.
DCC and Revolution technology has to my mind never advanced beyond the very basics of locomotive operation. I'd like to see the following features...
  • Manually operated Braking rates with synchronised sound effects.
  • Manually alterable acceleration profiles (10).
  • Manually alterable decceleration profiles (10).
  • Selectable sound banks based upon those 10 profiles.
  • Multiple Locomotive Selection.
  • Swiss type lighting sequences (will cover BR and almost all European lighting types).
  • Operational Pantographs for Electric Locomotives (Servo Driven) with synchronised sound effects.
  • Operational Radiator actuation based upon length of time running at high engine speeds (Servos)
  • Operational Radiator Fan RPM based upon engine usage.
  • Operational Brake Cylinder movement
  • Servo driven Steam effects - including
  • Cylinder cocks with synchronised sound effects.
  • Whistle(s) with synchronised sound effects.
  • Brake Linkage with synchronised sound effects.
  • Safety Valves with synchronised sound effects.
  • Exhaust Beats with synchronised sound effects.
  • Blower with synchronised sound effects.
And much more besides...
I look forward to reading further installments. . .


"You don't know what you don't know"

Offline cabbage

Re: openhab-trains
« Reply #6 on: Dec 16 2018 22:01 »
Robert, due to there being a linux kernal... Choosing ten options is awkward, eight or sixteen would be dead easy!

Regards

Ralph

Offline Doddy

Re: openhab-trains
« Reply #7 on: Dec 17 2018 05:15 »
Ten options would be dynamically selectable in the software, nothing to do the Kernel.
"You don't know what you don't know"

Offline cabbage

Re: openhab-trains
« Reply #8 on: Dec 17 2018 10:14 »
Robert,

I was refering to the way that linux handles multi tasking. Eight simultaneous operations or sixteen.

Regards

Ralph

Offline Doddy

Re: openhab-trains
« Reply #9 on: Dec 17 2018 15:11 »
If there are ten options and only one is selected in any instance, then that equals one.
"You don't know what you don't know"

Offline Gavin_B

Re: openhab-trains
« Reply #10 on: Dec 17 2018 15:45 »
Hi Doddy,
I would agree that the original revolution system is limited.  The latest version is impressive and can do some of the things on your wish list, however at £470 for a hand set and boards for one loco is eye watering expensive.
What you are describing  is basically a robot control several servos, motors, lights and sounds all of which is very achievable using the arduino based system.  I have not played with ardunios and sound but there are sound boards that will play sounds of a micro SD card so it should be possible to do.
Lots of fun things to try.
Gavin

Offline IanT

Re: openhab-trains
« Reply #11 on: Dec 17 2018 16:53 »
Just to further comment what 'others' in the hobby are up to at the moment (in terms of electronics).

A large 2mm exhibition layout was shown at the same meeting this month and it is fully CBus'd - the interesting thing to me was that they had built in two complete CBus networks - such that if one failed the other could be switched by the throw of a single switch. Parts of each network could be isolated (leaving the rest of the layout still functional) and all point servos could be 'dropped' (and replaced if required) within a minute or two. A very impressive project that I don't think I've seen the like of before.

This 'redundant' approach needed some very clever electronics and connections/terminations - all achieved by custom PCB boards. A few samples were passed around - mostly 50mm x 50mm - which can apparently be purchased (Qty 10) for about £11 from several Chinese vendors.

I assume Gavin is using 'built' Arduino components (Uno/Nano/Mega boards etc) - but to keep things compact, they have 'designed-in' their Arduino component - using an Atmel chip directly on their own PCBs and then loading the Arduino software into this (e.g. there are no separate Arduino boards and therefore none of the inter-board connections this normally requires).

It was all very impressive - and for a system built by "amateurs" - certainly looked completely professional in finish and function.

Regards,

IanT
Nothing's ever Easy - At least the first time around.

Offline Doddy

Re: openhab-trains
« Reply #12 on: Dec 20 2018 05:39 »
Hi Doddy,
I would agree that the original revolution system is limited.  The latest version is impressive and can do some of the things on your wish list, however at £470 for a hand set and boards for one loco is eye watering expensive.
Apart from multiple locomotive selection and the possibility to use a couple of servos with extensive external electronics I don't see much else that the Revo can do from my list. If you know otherwise then please spill the beans as I have two brand new controllers in unopened boxes which could be upgraded.
"You don't know what you don't know"

Offline IanT

Re: openhab-trains
« Reply #13 on: Dec 20 2018 10:28 »
Just had a look at the US 'Revo' site to see what they currently offer - and it might interest some that they have a sale on at the moment. Still not cheap and the dollar/pound rate is not that good at the moment but there you go...

Anyway - as Gavin has already indicated, there are plenty of powerful 'platforms' capable of doing what Doddy wants, it is simply that someone has to sit down and write the software for them. I think my view is that any 'proprietary' system can only cover the basics of what Doddy wants - although it may well provide some 'hooks' to enable customisation (which Revo appears to do). However, to get a fully tailored system that emulates the real thing, I think it would require a level of custom programming by the builder. I suspect that by their very nature (being proprietary) this is less likely to come from a commercial source (such as Revo) than an 'open' one.

Now in software terms, what I've been describing is a High Level Language (HLL) - in that much of the low-level operation is invisible to the user (programmer) who only needs to worry abut the logic involved.

As a fictitious (e.g.made up HLL) example:  "IF  Motor1  <15  THEN  Sound<15" - the user/programmer has a library of functions and links them logically to give the effect required. He doesn't need to know how (or what) 'Motor1' does - just that it 'knows' the motor speed. Likewise, he doesn't need to know what 'Sound<15' does - just that it plays a specific sound file.   

So going back to my comment about there being plenty of powerful hardware platforms around that can do this - I think the challenge is to come up with equally powerful (and application specific) software that doesn't frighten people away. Gavin see's the Arduino as this platform - and he may well be right (there is a lot of general support for it) but I'm not sure it's quite as friendly (to G3 railway modellers) as it needs to be.
   
Personally, I think Micromite Basic would be a much better HLL choice for many here (and I did cheat a little - as I could almost write my 'fictitious' example in MMB). I could also change it interactively, editing any on-board software to debug or modify behaviour as required. Aurduino was devloped to encourage young programmers and naturally uses 'C' - but BASIC was developed to be a simple beginners language - which I suspect would be easier for many 'non-professionals'. However, whatever the platform chosen, it does need someone to do all the neccessary grunt work to develop it - and basically - whoever decides to do that - will also decide what platform and tools to use...   :-)

For my part, I have several CBus units built, with three more to do. I have a very simple (IR based) 'DC' engine controller that is awaiting an 3.5A H-Bridge motor driver (currently on a slow boat from China) and I've even managed to solder-flow the tiny DRV chip to an adaptor board, so I can try to drive low-cost BLDC motors. Both of these will use Micromite based controllers - and both will use the same core "logic". I'm afraid I'm past the stage where I want to commit to community projects these days - but assuming I get them working - I'll be happy to share any outcomes from these projects with others here if they are interested.

Lot's of things to do, so little time to do them all!  :-)

Have a great Christmas everyone...Grandchildren arriving soon - so goodbye relaxing coffee breaks!!
   
Regards,

IanT

Nothing's ever Easy - At least the first time around.

Offline Gavin_B

Re: openhab-trains
« Reply #14 on: Dec 24 2018 15:00 »
I would agree that programming in C is not in the skill set of most G3 modelers.    The way the current modules have been written should avoid any re programming as once the wifi details and name of modules have been set all other tweaks can be done on the server rather than reprogramming the arduino code.

The other modules I have in mind will follow the same princible.

This might not be the way forward but it is a way forward and being open source am happy for other people to take what I have and improve.

Have just updated the github page with more detailed install guides.