Using RC Tx / Rx sending data to an Arduino as a wireless signal box (FSi6)

[Cobalt6700]

I had request from my introduction post to explain how I have used a RC Tx / Rx - in this case a FlySky i6 - to control the points / signals / other stuff wirelessly on a garden railway.

First off, I did a rather bimbly video 'write up' here:

That goes though most of what the system I configured can do. If you don't want to watch the whole video, I have put links below to the relevant points.

To explain the details of this system may take some time - so I will do my best to break it up into chunks in future posts. If there is anything you would like further info on - please ask

I'll start with a a run down of how the system works.

FSi6 RC Tx / Rx

This was modified from a 6CH RC Tx to an 14 channel Tx using the firmware here: GitHub - qba667/FlySkyI6: 14 channels FW modifications for FlySky I6
I can't take credit for this, and I would urge you to read the Wiki if you want to have a go with updating the firmware and making hardware mods.
Getting 10 channels working is easy - you just need to flash the firmware and assign the sticks / switches and pots to the channels (there are already 10 inputs on a standard radio).
Ch11 needs a soldering iron, a resistor and an extra switch.
Ch12, 13 and 14 are a little more complicated, requiring the injection of PPM signals into the Tx's PCB. I achieved this with an Arduino Micro reading switches as inputs to generate a PPM signal.

Modified FSi6 video link

Data is read from the Tx using the iBUS protocol. This requires an iBUS capable Rx and allows 14 channels of data to be sent over a single wire and ground using a serial data stream. The library for that is here: GitHub - bmellink/IBusBM: Arduino library for RC IBUS protocol - servo (receive) and sensors/telemetry (send) using hardware UART

You can send data directly to servos via a standard Tx - however you are limited to a 10Ch Rx (that I know of) and setting up the end points on the servos is a chore. Plus you are pretty limited to servos or servo controlled mosfet switches.


Arduino MEGA Sequencer

A MEGA was chosen due to the sketch file size and the multiple serial interfaces - allowing iBUS to be active at the same time as a serial connection to a laptop for debugging (there was, err, a lot of that).
As mentioned the MEGA takes an iBUS data stream and I used the iBUS library to interface with this data.


With regards to RC servo control - If you are not aware, and quoting directly from Wikipedia:
The control signal is a digital PWM signal with a 50 Hz frame rate. Within each 20 ms timeframe, an active-high digital pulse controls the position. The pulse nominally ranges from 1.0 ms to 2.0 ms with 1.5 ms always being center of range.

From here on in, I will refer to Servo PWM duration in micro seconds (us) as that is how it is used in the various Arduino libraries.

For the most basic channels, we take 1000us as logic LOW and 2000us as logic HIGH. This enables a RC channel to be used as a basic 0 / 1 switch.
For other channels, e.g. a rotary 4 position switch, we could use 1000us as Pos.1, 1300us as Pos.2, 1700us as Pos.3 and 2000us as Pos.4. This form of 'channel stacking' has it's limitations, as you can only control groups of things - such as points in a yard where you will only set one route at a time. This would output a 2 digit binary number 00 / 01 / 11 / 10.

The sequencer also used the Arduino Timer library to allow animations to be built up - e.g. a signal set to danger, a point change, another signal set to clear. This is expandable to be able to do pretty much as many animation steps as I required.

Sequence video link

I was also able to build in logic interlocks to prevent illegal point / signal moves.

The sequencer sent these commands out over a network to the separate local controllers. More on them later.


Communications Network

Now is a good time to mention that I do not have a background in electronics or programming, other than having an interest and teaching myself the things I needed to know to get a job done.
The decision on the network protocol was born out of my learning journey. I was looking for a better servo controller for points and signals - a standard RC Tx wasn't cutting it.

I stumbled on the Megapoints controllers whilst doing some googling, and after watching a few videos was intent on owning one of there 12 Channel Servo boards. They have standard functions for point servos (speed, reverse) but with the ability to precisely set the endpoints on layout with two buttons - this is a really useful feature. They also have a really nice set of animations for semaphore servo signals.
The Megapoints network is based on the I2C network protocol, so after buying a couple of servo boards, this decision was made for me.

I took myself on a bit of a journey leaning all things I2C - the protocol was developed in the '80's by Phillips for chip-to-chip communication, on a PCB. Dave at Megapoints has dropped the operating frequency from 100kbits/s to 10kbits/s - still more than fast enough to send servo control data around a layout, and has the added bonus of reducing the noise in the transmission lines, enabling communication over longer distances. Still - I think the Megapoints system is mostly designed for indoor, not garden scale layouts.

I implemented my I2C network as differential I2C - this allows transmission over longer lengths of more robust cabling. The use of differential pairs for communication is used in Ethernet cables (PC network), and protocols such as RS485.

I'm not going to go much further into that now - as with the above topics I will save that for a later, more in-depth post.


Local Controllers

As mentioned above, the servo control was handled by the Megapoints servo boards. I had 5 LGB solenoid point motors which needed driving and a Megapoints Stall/Kato board in Kato mode was used for these.

I developed my own Arduino based controller. This was designed as a multi function controller that is easy-ish to build with all through hole components (my first ever PCB) and has the following functions:

• 12-24V to 5V 3A polarity protected input.
• 12 LED two aspect signals OR 12 LED channels, 200ma / Ch.
• 2 'Input V' / 5V PWM MOSFET channels (useful for things like lights on uncouplers).
• 2 DPDT 5A relays with PWM MOSFET control - to allow track isolation, voltage dropping, polarity switching, other stuff..
• Boards can be built in such a way that they con do most things - including controlling point servos, reading inputs and driving small DC motors.

I used these to run all of the 2 aspect LED signals, the reversing loop, the yards route indicator and the uncoupler lights. An overview of this controlling a reversing loop can be found here:

Reversing Loop video link

I have now progressed to making the code interactive - you are able to plug it into a smartphone / PC and use a serial terminal to setup and test all of the functions. There is a video demonstrating my first go at that here. I have refined it a bit since, and will post an update if people are interested.

I will get to work on the more detailed posts - the first will be around the specifics of converting an FSi6 to be able to use it with toggle switches / rotary switches to control layout functions.

Thanks for reading

 

[dunnyrail]

Setting up a double slip can be a bit of a challenge as many get confused by them. I did on my friends line that had one in his station in the shed.

When I placed a Peco one on my 00 line I needed a way that would work for me in both simplistic and real operational terms. The key is to think in terms of a real railway where there are Normal and Reverce positions for points. Looking at the drawing below you can see that the double slip has a straight run thorough set, point lever 2 (servo in your setup) is set to normal for this. The other route is controlled by lever 6, the other servo also at normal.

Now route 2 is a crossover so from the normal route to the crossing with the slip and a point reversed lever or servo 2 is reversed. But at this point Lever 6 must be left at normal as the route is spoilt, your servo logic can ensure that Lever 6 is not reversable when 2 is reverced (an interlock function in a real signal box).

To gain the route required by the reverse of lever 6, 2 must be set to normal.

Note that the LGB slip also moves tye tracks in the same way as the Peco one I describe here with just 2 point bars operating 4 rails each.

 

[Cobalt6700]

Setting up a double slip can be a bit of a challenge as many get confused by them. I did on my friends line that had one in his station in the shed.

When I placed a Peco one on my 00 line I needed a way that would work for me in both simplistic and real operational terms. The key is to think in terms of a real railway where there are Normal and Reverce positions for points. Looking at the drawing below you can see that the double slip has a straight run thorough set, point lever 2 (servo in your setup) is set to normal for this. The other route is controlled by lever 6, the other servo also at normal.

Now route 2 is a crossover so from the normal route to the crossing with the slip and a point reversed lever or servo 2 is reversed. But at this point Lever 6 must be left at normal as the route is spoilt, your servo logic can ensure that Lever 6 is not reversable when 2 is reverced (an interlock function in a real signal box).

To gain the route required by the reverse of lever 6, 2 must be set to normal.

Note that the LGB slip also moves tye tracks in the same way as the Peco one I describe here with just 2 point bars operating 4 rails each.

Double slips can indeed be a bit of a challenge. The part that makes it double confusing is the fact each servo controls the routes on the opposite side.

With your example, this would be really easy to implement in my code.
The two 'mainline' points would be set to actuate together, as the only reason you would want to switch that side of the slip is to use route 2.
The 'branch' point would be able to actuate independently.

The logic for controlling the interlocks would be as simple as:

route_2_function(state){
if( route_6 _interlock ) { } //Do Nothing 
else {
    if (state == THROWN){
        set route_2 _interlock
        set route_2
        }
    else (state == CLOSED){
        clear route_2 _interlock
        clear set route_2
        }
    }
}

route_6_function(state){
    if( route_2 _interlock ) { } //Do Nothing
    else {
        if (state == THROWN){
            set route_6 _interlock
            set route_6
            }
        else (state == CLOSED){
            clear route_6 _interlock
            clear set route_6
            }
    }
}

While we are on the subject of interlocks, more than one can be added. For example, this bit of logic would lock out if any of the interlocks were true:

if( route_1 _interlock || route_5 _interlock) { } //Do Nothing
else { move_some_stuff } //Do something

If the above doesn't make much sense - I hope to expand on the logic in a future post

 

[ge_rik]

Many thanks for that. I'm very much like you ....

Now is a good time to mention that I do not have a background in electronics or programming, other than having an interest and teaching myself the things I needed to know to get a job done.

Most of my electronics and programming knowledge has been acquired on a "need to know" basis.

Thanks for your very clear explanation. Even I could follow it......