Hmm, new direction for signals?

[rrinker]

 The more I play around with Arduinos, the more I keep thinking I can roll my own signal control points for far less than any of the commercial products. The small Arduinos on eBay are like $2, you need one more 50 cent part and a couple of resistors and caps - the Arduino can directly drive RC servos which I am going to use anyway, or Tortoises. And they can directly drive LEDs. So one little board cna handle a turnout and the signals around it (and still have inputs for the block detectors).

 The question is, qhat interface to hook them all together? There are libraries for Loconet, but it can get fairly complicated. There are also a couple of libraries for C/MRI - which is about as bog simple a protocol as you can get. It would seem a natural for LCC (OpenLCB), but amazingly there is very little Arduino support. Then I could always just roll my own, but that would require either immediately going to a physical CTC panel, or basically writing all of what can be already done in JMRI to get a virtual CTC panel - which I really want to do first, that way if I need to tweak the layout after it's operational, I don't have to rebuild physical hardware. Eventually I plan to have a physical CTC machine.

I WAS just going to use various off the shelf parts with Loconet. But playing around with Arduino has made the decision more difficult. I'm not in a position to build the layout right now, but I could work on this stuff. It's cheap. It's pretty easy. It partly all started when I got a deal on an RGB LED reel - I plan to use LED lighting for the layout, and while the main lights I would use would be a flavor of white ones, I wanted to have RGB strnads to do sunrise, sunset, and night effects. The controller that comes with them is somewhat limited in the color mixing options, but that's a limitation of the remote control and that portion of the circuit, the driver itself can do much more. Plus there are what they call 'amplifiers' that you cascade off the unit that has the actual control circuitry so you can drive more strands of LEDs. Kind of like a command station and boosters in DCC. You can have a large number of the booster drive by one controller, and each booster cna drive three to five 15 meter strands of LEDs, depending on the power supply you use. So I think this is plenty even for a two level layout - and all the LEDs then work together. So I started looking at Arduino again as a way to control all this. And at various model railroad uses for Arduino. ANd here I am.

                           --Randy

 

[gregc]

pico processors can provide a lot of intelligence.    But once you add a 2nd in a layout, information often needs to be be shared and coordinating decision making (distributed intelligence) can become complex.

One approach is centralized intelligence (e.g. PC) and pico processor nodes that are slaves to the PC (via rs-488), simply providing I/O to control turnouts and signals, and detect turnout position and block occupancy.

The PC can provide both centralized control and a GUI interface of a virtual CTC machine and live track display.   Socket interaces can allow mutiple sub-stations (laptops) supporting the CTC GUI, communicating back to the central PC having the intelligence and controlling the layout thru the C/MRI bus, possibly even an electro-mechanical I/F to a physical CTC machine.

see Pacific Southern documents.

[rrinker]

 That's some neat stuff there. Probably more than I want to do. I'm fairly confident I could design my own protocol, and I would much rather program the logic on a computer using a language I know better than Java (wuite frankly, I despise Java). However, the pieces are there to 'borrow' C/MRI, and JMRI already supports that, plus all the nifty icons for US&S panels are there, so the programming isn't really in java, but rather defining the logic using JMRI itself. I've done some virtual panel creation before.

 There are a couple of different CMRI libraries for Arduino that I found, most are strictly polled like the original, but there is one that implements a NoWait mechanism so you can have the Arduino code do things like flash lights locally without resorting to complex interrupt handling. That way, instead of the JMRI computer constantly sending on/off commands for the specific bit, it just has to send a single on, and the Arduino does what it needs to. Given that in my era there weren't flashing signal aspects on the Reading, I don't really have to worry about that for most nodes - just something like a grade crossing flasher. On the club layout, they had to run a dedicated signal Loconet because it uses older boards that do not have the Aspect method of control, and since the layout implements contemporary NORAC rules, there are plenty of flashing aspects - it cuased loco control problems with all those on/off/on/off packets, until the signal and detection system was given a private Loconet. My concept is to implement the control point design, like a prototype CTC system - the dispatcher sends the desired turnout alignment and direction of travel, the local node reads the occupancy sensors and lines the turnouts and sets the signals as appropriate. The DS and the railroad computer don't have to tell a given signal to set a medium clear, the fact that the dispatcher has cleared movement eastbound and set the crossover to cross from #1 main to #2 main allows the node to make that determination. This is effectively what Model Railroad Control Systems does with their cpNode. Well more cost effective than the Chubb SMINI, they are still pretty costly, at least if you are willing to build part of the system yourself - those super cheap Arduinos are what make it possible.

                        --Randy

 

[DigitalGriffin]

I'm currently playing with a $30 Raspberry Pi 2 (which runs JMRI) and arduino

 This looks interesting though...

http://www.slashgear.com/zeropi-dev-kit-is-compatible-with-arduino-and-raspberry-pi-13409411/

 

[mlehman]

rrinker

It would seem a natural for LCC (OpenLCB), but amazingly there is very little Arduino support.

Randy,

It's probably a little early in LCC for all the bases to be covered. Give it a little time, doesn't sound like you're in a great hurry here, and I bet you'll find more to work with soon as new applications are developed as people start to implement it.

[NP01]

My Francisquito Valley Railway will be fully detected and signaled and computer controlled. I started getting into Arduino and writing logic on my own. But! I realized two things:

(1) I absolutely hate wiring. Sure, soldering can be very calming. But attaching a signal to an se8c is a daunting task. Why add more.

(2) Money is in short supply, but time is the real tough commodity here. Think about this: the Digitrax SE8C, a PR3, BDL168 add to $250 and feels expensive. But how many hours does it actually take to wire them up? 16 blocks, 32 signals ... I bet it's 40 hours MIN. Even if you valued your time at $10 an hour (not saying that's what you would make, but typical entertainment like movies, sports tickets + beer, dinners) would be at least that much ... Unless you were just watching TV. That's $400 right there ... So why would I do this to save money if it added 40 mpre hours of programming. 

I think as a hobby within a hobby it will be awesome. But cost should not be the driver. 

[rrinker]

 I do firmly believe that once I get a system (I intend to use some sort of plug and socket for signals, so they can be removed - they are far too expensive, for nice ones anyway, to be damaged when fixing track or scenery in the area), it will take far less than an hour per signal to hook each one up. Using servos saves a huge amount of time on the switch machines - it all plugs in, there is no soldering, no installing screw terminals at the bench before installing the switch motor, etc. Development of the Arduino nodes is a one time thing - the code will be effectively identical for each one other than an address, so once I have it working, I just need to load it on all of them. Consistency is again the name of the game, so the red diverging LED is always on the same Arduino pin to avoid having to modify the code for every plant. And minor code tweaks liek that - honestly takes me alomost no time, I'm always scripting things in various languages for work.

 The time sink is all up front. I can't build a layout right now, well, I suppose I could build a small standalone thing, but there's too much work to be done on the basement. So i can play with Arduinos or I can play video games - I rarely watch TV, there's nothing worth watching on. At least with the Arduinos I will be working on something that will be used on the future layout. By the time I get whole hog into layout building, I should have the signalling boards ready to go, so installing it all will be little more than installing a commercial product.

               --Randy

[carl425]

rrinker

but there's too much work to be done on the basement. So i can play with Arduinos or I can play video games

Maybe this is a stupid question, but why not spend the time working on the basement?

You may also find Joe Fugate's article in the latest MRH interesting.  He's advocating a modular approach to building that would allow layout sections to be built and later installed in the basement when it's finished.

BTW, when do we get to see the new track plan?

[rrinker]

 Renovating the basement requires either more time than I have until winter sets in or more money than I have to get it done so the heat is back in and working before it gets too cold. In the meantime, Arduino experimentation has cost me all of $50 so far, and I have a huge pile of electronic parts to play with. I also have to sell a car to make room in the garage to fit all the junk that's in the basement while the basement is redone.

 I'm not so sure about the modular approach for a double deck layout. It MIGHT be possible for the lower level, since clearnace underneath isn't as critical. There's been some discussion on the subject on a couple of Yahoo groups.

 I have what I think will be the basic for for the lower level now, plus lower level staging and the main yard. In a design that allows complete access with no duckunders, and the only removeable sections can be semi-permanent as they will only have to come out to change out the furnace or water heater, both of which are practically brand new. If I can live with a shorter branch line, I can even leave the weird stair situation - it comes down from the kitchen to a landing, and then goes off perpendicular in both directions for the last 2 steps. I was planning to close off the one side and extend the branch line along that new wall and wrap around the corner. If I leave it, the branch will have to stop short of the stairs, although I could still add a drop leaf tail track that blocks the stairs. I'll post it soon.

              --Randy

[gregc]

rrinker

That's some neat stuff there. Probably more than I want to do.

Building even moderate intelligence into multiple Arduino nodes under the layout will involve many evolutionary steps.   Multiple nodes will require constant updates and updating target images once the target is under the layout may not be that convenient.

I think you'll agree that developing code to run on a PC is much easier than for another target.  (I prototype algorithms at work on my desktop rather than our target even though our target runs Linux).

Keeping the node firmware simple and putting all the intelligence in a PC, even without a graphics interface, will make is much easier to develop that intelligence.  A usb/rs-485 module can be had for just a couple $$.   Once you establish communication between the PC and arduino I/O slave node(s) progress can be swift.

 

rrinker

... I would much rather program the logic on a computer using a language I know better than Java.

The Pacific Southern Control System (PSCR) code is written in an old version of Borland C/C++ that supports windows graphics running under an older version ('98) of windows.

I developed a simulator to study the PSCR code using GNU C++ to compile the control portion of PSCR and a socket I/F to a Java program for graphics.    I use Cygwin to provide a Linux like environment under windows.   Cygwin is free and provides almost all Linux available development tools (GNU C, make, vim, emacs, xterm, ...) and applications.

The Java graphics application is relatively simple.  It becomes a slave to the control SW.  And because of the socket I/F, can run on a PC other than the one with the control SW.

[rrinker]

 Hmm, now there is an idea, seperate the logic and the panel. However, I don't see much benefit in reinventing the wheel and creating logic in other software if I'm going to end up providing the user interface through JMRI - doing the logic in JMRI doesn't really involve Java programming, the Logix stuff is pretty well thought out and covers nearly any condition you can imagine. And I've already done work with that. To give you an idea of how far ahead of the game I work sometimes, it was back arounf JMRI 1.7 that I came up a method using LocoIO boards at the control panels and JMRI as a virtual CTC panel to offer dispatcher control, dispatcher ability to set a turnout to local control, and full local control when the computer wasn't on. This was to meet the requirement that the layout be operated without a computer for when I wasn't around, yet I wanted to have a proper dispatcher with no 'cheating' allowed - one of the things I did was set the switch decoder addresses all above what can be accessed from a DT400 throttle. In the process I actually discovered and submitted a bug report for JMRI and Bob Jacobsen sent me a special build to check to see if it was fixed. I'd continue on the same path, but LocoIO has changed and the newer version uses a different PIC and Hans no longer releases the code to burn your own (and I have a low cost PIC programmer I got on eBay, too). For now the boards are still compatible with the old chip, of which I have over a dozen, and I don't need any of the features of the newer versions, so I COULD potentially build a bunch more LocoIOs and just use those. I don't know if I have enough to handle the entire layout. Even if the board changes, I am perfectly capable of hand wiring my own from the schematic, or even generating my own Gerbers to have boards made - friend of mine even has a board router to make prototypes before sending them off for mass production. It wouldn't be such a crazy idea - one LocoIO is just about right for a single control point. The question comes in obtaining enough of the right PIC to build as many as I need. The supply I have on hand I obtained as samples, and there are a few variations of the actual part used, including ones that are pin and code compatible but have double the memory. I'm making a strong assumption that these would be exact replacements in counting my supply. Cost to build a LocoIO (at least about a dozen) would be very low. The other option is what I've been talking about, abandon this path and switch to Arduino-based devices, which seems to be the way the whole DIY world has gone. Any more I wouldn't know where to go for PIC resources, but there are multiple Arduino railroad sources - some that used to be PIC but switched. There is some other benefit, in that the IO and rest of the support circuitry is already put together with Arduino varients, rather than working from bare chips in the PIC world and having to construct the clock, power supply, and IO. And the open hardware design of the Arduino means I can get the smaller ones like the Nano for about $2. For C/MRI, all it needs is a 485 IF chip with some discrete support components and it's ready to go. For Loconet or LCC is much the same, but the more complex protocols mean more digging to create a functional node device. That's the attraction of C/MRI - there's no complex signalling protocol, it expects all logic to be in the master computer. That's the limit of intelligence in my nodes - they won't be so very unique in code other than the C/MRI node address. They may figure out the signal aspect to display based on supplied information, but they won;t be supplied information from the next node up the track, they will be supplied information from the master computer. So no crazy complications adding some sort of peer to peer capability to C/MRI.  This is along the lines of what Seth Neumann and Chuck Catania have done.

 ANother advantage of working on this development now, before the layout is that whole not needing to plug in a USB cable under the layout to reprogram the nodes, if I can get it right now. Though it's not that big of a deal, really - nothing a laptop on a cart and a long USB cable can't solve.  I'd probably mount them right at the fascia in the area they are controlling anyway - not way back buried under the layout.

                  --Randy

[Graffen]

A friend of mine has developed a totally new Loconet based switch, servo, panel, signal and occupying system that is VERY affordable!

Everything is programmable thru an android tablet via bluetooth.

I got the news today, so I will relay the info as it gets more known.

the signal aspects are currently swedish, but the block signals are the same as the US.

https://translate.google.se/translate?hl=sv?sl=sv&tl=en&u=http%3A//www.mollehem.se/index.php/electronics

[rrinker]

 Also interesting. Initially hard to tell, then I plugged the price into a currency converter to see how much those board would be in US Dollars. And you're right, they are quite inexpensive. Something to keep an eye on, for sure.

                       --Randy