# Is anyone using an arduino-controlled S88 network?



## Shdwdrgn (Dec 23, 2014)

I'm going to get started expending my test layout to include track sensors soon and S88 seems like a decent choice for my needs. However looking around I can seem to only find a single example of arduino code from Rudy's model railroad page. This makes me wonder if there is really that little interest in S88 now, or if Rudy's code is just that good that nobody else ever bothered writing their own code?

Yes I know Loconet is another option for track sensors. The big thing that pushes me away from this is that each module needs to be specifically addressed, while in S88 each module is given an address based on its location in the chain. Since I will be working on a fixed layout, the S88 option means I can program spare arduinos which can be dropped right into place without having to flash them with an address before use. I'm open to any suggestions as to why loconet would be better in the arduino world, though, as both networks are fully supported by my DCC++ controller. The only requirement is that I can run it from an arduino nano board.


----------



## gregc (Apr 25, 2015)

S88 seems dated. separate data and clock requiring a synchronous controller and Ground. What would PS and Reset be used for. These additional lines consume I/O on an Arduino.

RS-485 requires just 2 wires and is well suited for the asynchronous communication controller on an Arduino. RS-485 is used by the NCE cabbus (NCE compatible Arduino and code)

not sure how addressing becomes position sensitive unless each device needs to propagate a message not matching it's own address to the next node. Won't this require two UARTs? And won't your code need to be modified or adaptive as nodes are add/removed? I think it would be easy to simply program an address into EEPROM. Then you can add/remove nodes during development w/o requiring any changes to controller code.

yes, half duplex RS-485 code requires polling and a node will need to wait for the next poll to send. but layout accessory control doesn't require much bandwidth. (KISS)

more sophisticated layouts separate locomotive control (DCC) from accessories (C/MRI, LCC). Not sure combining control of turnouts, signals and occupancy detection with DCC++ on an arduino is the best approach. Assume you'll want a PC interface for layout control and there are inexpensive RS-485 USB adapters.

The same PC application can control accessories and locomotive thru a separate HW interfaces.


----------



## gregc (Apr 25, 2015)

Shdwdrgn said:


> The only requirement is that I can run it from an arduino nano board.


why an nano with it's limited I/O? are you using them as nodes? or intelligent controllers?

the C/MRI approach uses unintelligent I/O nodes to do I/O and message it between the node and control application running on a PC. The PC sequentially polls each node, sending update output bits (e.g. turnout, signal states) and expects the node to respond with an input update (e.g. turnout position, block occupancy detection. 

nodes would be geographically spaced around the layout to provide I/O. turnout/signals on one side of a long siding may be served by one node and the other end of the siding by a different node. Spare I/O on a node can support expandsion.

if the number of input and output bits are equal, the same code could run on each node, a different address programmed into EEPROM (via configuration msg). If unequal, a configuration message could be sent during initialization.

an MCP23017 could be added to an existing node to expand the amount of I/O it supports. Generic code could be configured to support as many MPC23017 as needed.


----------



## Shdwdrgn (Dec 23, 2014)

The board I'm using is a "DM nano strong". It has a unique layout that allows easily plugging in things from IR sensors to servos, so I can use the same board as a DCC decoder/controller as well as being a sensor in an S88 or loconet bus. Yeah it's an older chip but as you mentioned these functions don't require much bandwidth and there's a lot of available code specifically for using the nano.

I am drawn to the simpler bus and tree-style connections of loconet, and what little I've read on it suggests that has a much greater range of features than S88. When I mentioned my objects to having to program in addresses for loconet boards I was thinking along the lines of plug&play replacements when a board fails, however it occurs to me that the DCC decoders which I also use this board for ALSO require setting an address on each unit... so that objection went right out the window. Now I'm trying to learn more about loconet or find some code I can load on an arduino to test it out, but don't seem to be having much luck on either.

And one other thought came to mind today... S88 only provides information on simple on/off switches -- an item is either triggered or it isn't. That will work for *most* of my plans, but I also have RFID tags I want to be able to read. I'm just not sure if any current bus types are up to that task, or if it would be easier for me to just send the information over wifi to the computer? However along that same thought I also wonder if loconet could handle a variable range, for instance to read the strength of a signal or the brightness of a light? If loconet is also a 0/1 state machine then I'll probably handle the variable stuff over wifi as well, maybe set up an MQTT service to track the info. What it comes down to is I just don't know much of anything about the current state of model train sensors and networks, within the realm of stuff that is open and available to create on arduinos.


----------



## gregc (Apr 25, 2015)

Shdwdrgn said:


> It has a unique layout that allows easily plugging in things from IR sensors to servos, so I can use the same board as a DCC decoder/controller as well as being a sensor in an S88 or loconet bus.


a generic C/MRI node (poll/response) simply does bit I/O. It interfaces to separate HW to control switch machines and signals (to conserve bits) and occupancy detectors for input.




Shdwdrgn said:


> Yeah it's an older chip but as you mentioned these functions don't require much bandwidth and there's a lot of available code specifically for using the nano.


an arduino type processor has more than enough MIPS



Shdwdrgn said:


> I am drawn to the simpler bus and tree-style connections of loconet, and what little I've read on it suggests that has a much greater range of features than S88.


Digitrax champions loconet. But like the CAN bus used by LCC, it supports CSMA/CD which requires not inexpensive communication controllers that can autonomously detect a collision and immediately suspend transmission.

what features interest you?




Shdwdrgn said:


> Now I'm trying to learn more about loconet or find some code I can load on an arduino to test it out, but don't seem to be having much luck on either.


sounds like you're expect to find a library supporting communication rather than writing your own code.




Shdwdrgn said:


> And one other thought came to mind today... S88 only provides information on simple on/off switches -- an item is either triggered or it isn't. That will work for *most* of my plans, but I also have RFID tags I want to be able to read.
> 
> I'm just not sure if any current bus types are up to that task, or if it would be easier for me to just send the information over wifi to the computer? However along that same thought I also wonder if loconet could handle a variable range, for instance to read the strength of a signal or the brightness of a light?


i'm sure any bus can transmit as many bits as you'd like. Protocol and message type dictate what can be sent. Besides an address, a message type/size byte can be used to send different types of information of varying length.

you may need a less than generic node to measure an photo transistor level using an ADC and transmit it in a message other than a bit I/O response. (a bit can be added to a response message indicating that it is the final msg in a response). Such a msg may need to indicate which sensor the value is for.




Shdwdrgn said:


> If loconet is also a 0/1 state machine ...


not sure what you mean by 0/1 state machine. Loconet is used by Digitrax for communication between its controllers and command station.



Shdwdrgn said:


> What it comes down to is I just don't know much of anything about the current state of model train sensors and networks, within the realm of stuff that is open and available to create on arduinos.


i believe the current state is moving toward LCC (which is CSMA/CD). But C/MRI has been around since 1985 supporting layout control independent of locomotive control (i.e. before DCC).

we've often had to develop our own mechanisms for getting debug information from the embedded systems I worked on. (On one system I used a spare DAC to output echo canceller coefficients). Not only do you need something to do what the system is intended to do, but also debug it when it doesn't do what's intended.

being able to build your own tools avoids the learning curve of libraries and their limitations. Sometimes those tools are bigger than the application.


----------



## Shdwdrgn (Dec 23, 2014)

It appears there are at least a couple arduino libraries already available already (including for the ATmega328 that the nano uses), plus some simple circuits to interface the bus with an arduino pin, so that isn't much of a problem. I'm not sure why you seem to indicate the interface is expensive?

I *think* maybe I'm starting to understand the basics of loconet. Maybe someone can check me on this?

Slow communications over the rails. Seems like it might be compatible with DCC, but I can't tell for sure?
Fast communications over a 6-wire bus. This seems to be used for everything other than throttle control.
Simple sensor network with 1-bit flags to indicate when a sensor has been tripped
I believe commands can also be sent TO devices on this bus, so for instance you could control turnouts?
I'm still not certain if the loconet rail sync pins are meant to connect directly to the rails, or if there's supposed to be some kind of interface between them?

There also seems to be some kind of interface for a computer, but I'm not sure yet how the state of sensors would be read. Are we talking about a closed-source protocol, or is it something simple like a telnet connection?

Still a lot of questions here, and I'm trying to figure it all out in between a lot of other work. I think my biggest concern right now is I haven't seen a compete circuit for fully integrating an arduino with loconet which is paired with any specific code library. I know there would need to be a specific interrupt connected with whatever pin is used to read the bus signal. I get this feeling this is going to be like DCC++ all over again, in that I need to get a whole system up and running before I can see if any one piece is not working, and trying to diagnose a problem on the system while barely understanding what it even does. Yeah it's probably going to be a bumpy ride, but I think loconet is probably going to be the route I take.


----------



## gregc (Apr 25, 2015)

Shdwdrgn said:


> It appears there are at least a couple arduino libraries already available already (including for the ATmega328 that the nano uses), plus some simple circuits to interface the bus with an arduino pin, so that isn't much of a problem.
> 
> I'm not sure why you seem to indicate the interface is expensive?


because loconet is CSMA/CD, transmission must be suspended when a collision is detected as soon as the bit recognized as an error is detected. This mean in the middle of a byte. CAN chips are designed to do this.

Not sure I understand this loconet interface. (Loconet spec). looks like SW must monitor the RX pin to detect a collision an suspend TX and reschedule transmission later when the line is idle.

RS-485 simply requires a bipolar line driver converter to interface to the arduino UART and doesn't need to deal with CSMA/CD. The Arduino does have a function to indicate when TX is complete and the TX can be disable (half-duplex bus).




Shdwdrgn said:


> I think maybe I'm starting to understand the basics of loconet. Maybe someone can check me on this?
> 
> 
> Slow communications over the rails. Seems like it might be compatible with DCC, but I can't tell for sure?
> ...


seem pretty basic ... DCC supports communication over the rail by representing bits with timed polarity inversions. how can rails support a 6-wire bus ... as well as DCC?


As I said, Digitrax uses it for communication between it's controllers (button presses) and command station. The Digitrax command station also communicates with locomotives over the rails using DCC.

Loconet uses a common bus that nodes bridge onto or daisy chain from one to another.



Shdwdrgn said:


> There also seems to be some kind of interface for a computer, but I'm not sure yet how the state of sensors would be read. Are we talking about a closed-source protocol, or is it something simple like a telnet connection?


by "closed source protocol" you mean proprietary? Loconet is used by more than just Digitrax

presumably the node can monitor several inputs and could (haven't looked at spec) send a message with the state of each input represented by bit position in the data, as well as receive a message to control output bits



Shdwdrgn said:


> I think my biggest concern right now is I haven't seen a compete circuit for fully integrating an arduino with loconet which is paired with any specific code library.


the the link to the circuit above 



Shdwdrgn said:


> I know there would need to be a specific interrupt connected with whatever pin is used to read the bus signal.


so the data would be bit banged instead of using the Arduino UART?



Shdwdrgn said:


> I get this feeling this is going to be like DCC++ all over again, in that I need to get a whole system up and running before I can see if any one piece is not working, and trying to diagnose a problem on the system while barely understanding what it even does.


if loconet nodes are configured to generate messages to specific addresses when specific event occur, then you should be able to have two nodes echoing data to one another.

configuring the LCC nodes seemed involved. each node requires configuration to detect some event from multiple inputs and to autonomously send a message(s) to a different node unique to the event. And the receiving node needs to be configured to accept and do something with the event message. For example, a node detects that the block has become occupied. It sends a message to a different node to set a stop signal and possibly to a 2nd node to set an approach signal, in addition to a controlling PC.



Shdwdrgn said:


> Still a lot of questions here, and I'm trying to figure it all out in between a lot of other work.
> 
> Yeah it's probably going to be a bumpy ride, but I think loconet is probably going to be the route I take.


the C/MRI approach uses slave nodes that simply process input/output. A PC (Raspberry Pi) is the bus master and contains all the intelligence.


----------



## Shdwdrgn (Dec 23, 2014)

gregc said:


> DCC supports communication over the rail by representing bits with timed polarity inversions. how can rails support a 6-wire bus ... as well as DCC?


That's not what I said, nor is that how it works. From what I've read the communication over the rails is considered 'slow' because not a lot of traffic can be passed. If it is simply using the DCC protocol to talk over the rails then that would make sense. Also the 6-wire connection appears to be carrying a copy of what's on the rails, plus two ground lines, plus two wires used for the loconet traffic. However judging from the interface schematics, both of the loconet wires are tied together, so in reality loconet is just a single-wire interface.



gregc said:


> so the data would be bit banged instead of using the Arduino UART?


Essentially, yes. It doesn't look like it is a regular serial interface, so it is handled exactly like DCC on the arduino -- the Rx is driven by interrupt and the library puts together the data until a full packet is received. Tx appears to be handled by timing and collision detection. Unlike DCC, any one of the nodes can transmit data so the master controller sends out a signal when a collision is seen and all transmitting nodes reschedule their broadcast. Assuming the bit rate is pretty high, this would probably be an imperceptible delay.



gregc said:


> the C/MRI approach uses slave nodes that simply process input/output. A PC (Raspberry Pi) is the bus master and contains all the intelligence.


I know loconet doesn't require that much processing power. The DCC++ESP32 controller I'm using supports it, which is the only reason I considered using loconet. And now that I think about it, the controller probably collects all of the loconet information and presents it through its own telnet port along with the DCC data. At least that would make the most sense, and would explain how folks are easily interfacing with a computer. Maybe I should be checking with the author of DCC++ESP32 to get a clearer idea of how this all works.


----------



## gregc (Apr 25, 2015)

did you look at the link to the Loconet Spec I posted?


----------



## Shdwdrgn (Dec 23, 2014)

Ah I did miss that. Just kind of browsing through it now, there seems to be some inconsistencies. The doc indicates pins 3-4 are +/- for the data signal, yet the interface schematic I've seen physically tie those two pins together. And it's very curious that this indicates loconet DOES use a standard serial interface. Yeah now I'm even more confused as to how it is supposed to work.

And now I'm even more confused... The only reason I considered loconet was because I thought it had been discussed on trainboard in relation to DCC++, and yet checking back now it seems like it is questionable as to whether that support was ever added. However it does look like LCC is now supported. Yeah I'm all kinds of confused...


----------



## Severn (May 13, 2016)

How about ant?

https://en.m.wikipedia.org/wiki/ANT_(network)


----------



## wvgca (Jan 21, 2013)

i'm in favour of anything arduino controlled, mainly because of cost and availability of the arduino's themselves


----------



## gregc (Apr 25, 2015)

wvgca said:


> i'm in favour of anything arduino controlled, mainly because of cost and availability of the arduino's themselves


maybe not because of the processor, but because of the libraries for the Atmel processors used on Arduinos.

while I think the avr compiler can support other processors, the avr toolchain uses board names. see https://www.avrfreaks.net/sites/default/files/forum_attachments/avr_cpunames.h


----------



## Shdwdrgn (Dec 23, 2014)

@Severn -- you dropped the closing parenthesis on your wikipedia link so it doesn't quite work, but I did find the article. Looks like that is just a wireless network, but the arduinos don't have wireless built into them so it would require an additional component. If I were going that route I would just stick with an ESP32 which already has wifi and bluetooth built in.

My network thus far is using a raspberry pi as a wifi access point (and provides the link to my main network so I can connect through my desktop). The base station is an ESP32 with a small OLED display for status info. The ESP32 is connected to the Pi via USB which gives me the option of flashing new code to the base station over wifi, very handy at this point until I have all of my options decided.

For controlling devices via DCC I am using these nano-strong boards. Other than a 5V power source (which I get from my 16V track power), I have a tiny board that connects between the nano and the track to filter the DCC signal. Otherwise the only connection to the board is up to 16 servos plugged in directly. It's so dead-simple that I found it ideal for use with turnout servos. It costs around $4 for the board plus less than $2 for my DCC filter board, and the servos are around a buck each. Basically for the cost of a single turtle motor I can put together the controller and 16 turnout motors.

Because I'm already using the nano-strong boards, I thought they would be really nice to use for the sensors as well. This board has 3-wire output for every I/O pin, so I could build a whole cable including IR transmitter and receiver to plug in, and even with the four wires needed for S88 I could still handle 16 inputs at each board.

Beyond that, as I mentioned I plan to use RFID detectors to verify a train is pulling all of the expected cars (at least when leaving the yards). Worst case, I can handle that over wifi with an ESP32. I think that would probably cover everything though?

So I just need to settle on which wired network to use for at least the block detection and other simple sensors, and if that network can do output as well as input then I won't have to clutter up DCC on the rails for things like turning on lights (buildings and track signals).


----------



## Shdwdrgn (Dec 23, 2014)

I've been doing some reading on LCC (aka: OpenLCB) and I think I'm starting to figure out how it interconnects. I also found some brief discussion on how to transmit RFID, but nothing solid and no working examples yet. Ah well, that part is still off in the future for me anyway.

For now, it looks like there are several working node examples that can be used with standard IR pairs and getting a pair of nodes to talk to each other. However the part I'm having trouble finding any kind of info on is the bridge from LCC to wifi... Has anyone seen any working arduino examples? If I can find something showing how the information is transmitted then I'd know what I need to work with in order to receive the data in a computer program. From just the way the nodes transmit and receive information I am strongly reminded of a standard MQTT arrangement, and I could certainly set up an ESP32 to talk to an MQTT server (if the data arrangement is really as similar as I think).

Anyway, if anyone has run across examples of receiving the LCC data with an arduino and transmitting it to a computer/network could you please point me in that direction? Thanks. In the meantime, I'll keep digging...


----------



## gregc (Apr 25, 2015)

here's an intro to OpenLCB and here's an OpenLCB Forum where I had read of people using Arduino.

again, LCC is CSMA/CD using CAN.


----------



## Shdwdrgn (Dec 23, 2014)

You found a forum??? *Bows to your google-fu*



gregc said:


> again, LCC is CSMA/CD using CAN.


I'm not sure what you're getting at here?


----------



## Severn (May 13, 2016)

for some RFID work, take a look here: 
http://www.silogic.com/trains/RFID.html

As for ANT, well it was just a thought. Mainly I like that it's wireless and pretty well used outside model trains in the sport market. And seems to have some nice features. I have no actual hands on experience with it and only know of it as its mentioned in products I don't buy as a selling pt. 

There seems to be some support for it -- https://github.com/cujomalainey/ant-arduino

anyway it was just informational.


----------



## gregc (Apr 25, 2015)

i was told about the LCC group by a proponent of LCC while trying to understand LCC better. It seemed a challenge to develop the SW for a CAN node. RR-CirKits sells LCC hardware (prices). By using CSMA/CD, LCC uses bandwidth more efficiently, minimizing response time on very large layouts with a very large number of nodes (100+).



Shdwdrgn said:


> _again, LCC is CSMA/CD using CAN.​_I'm not sure what you're getting at here?


are you familiar with CSMA/CD or CAN used by LCC? As I've said, this requires special HW or bitbanging SW with HW to detect the collision and SW that suspends transmission before the next bit and reschedule transmission.

A polling approach such a C/MRI requires no special HW and can use a UART. That SW is relatively simple, allowing you to focus on the purpose of the node. KISS. (please look at the links)


----------

