Capability question - reading an RS485 bus while pushing results to PC

#1
Afternoon ladies and gentlefolks,

I'm wanting to do some testing on an RS485 bus which should (I believe) be compatible with PICAXE - specs follow:
9600 baud
8 data bits
no parity
2 stop bits

This is implemented by a proprietary piece of equipment I have, namely the NCE model railway DCC systems. I'm wanting to reverse engineer the protocol, as there's very little decent documentation available... therefore, would the following be possible in members' opinions?

Using an X2 chip, connect the bus to the hserin port, and enable background read. Just leave the scratchpad empty, letting the read operation write freely and overflowing when necessary.

The main program pushes the contents of the scratchpad to the PC over the normal USB programming cable every, say, 500mS (testing required here!), so I can view it.

Does this make a shred of sense....?
 
#2
I posted about an NCE Cab Bus project as an accessory device controller here:
https://picaxeforum.co.uk/search/17629/?q=Accessory&c[title_only]=1&c[users]=westaust55&o=date

https://picaxeforum.co.uk/threads/p...-railways-using-nce-dcc-control-system.28444/

That should give some information on reading the NCE Cab bus.

Also just FYI I have previously posted on a DCC accessory decoder (used 2 PICAXE chips)

I have also used a PICAXE to read the NCE Cab Bus and pass the raw data to a PC (did not build that into a permanent project) but do not have that code to hand and currently traveling.
 

hippy

Technical Support
Staff member
#3
That should be entirely possible. RS485 is a balanced two-line +/-12V signal but it should be possible to take one of those and feed it in to HSerial In via an in-line 22K current limiting resistor. That will protect against any voltage differences as with the program download circuit.

You might have to play about with which signal to choose and what polarity to use in the HSERSETUP command but it should work. Don't forget the 0V connection to the sending equipment.

Then it's simply a case of enabling background receive, letting the Scratchpad fill up and reporting what it shows. Something like this which reports data received in hexadecimal -
Code:
#Terminal 9600
HSerSetup B9600_8, %001 ; Try %111 if data doesn't look right
Do
  Do : Loop While ptr = hSerPtr
  b0 = @ptrInc
  b1 = b0 / $10 + "0" : If b1 > "9" Then : b1 = b1 + 7 : End If
  b2 = b0 & $0F + "0" : If b2 > "9" Then : b2 = b2 + 7 : End If
  SerTxd( b1, b2, " " )
Loop
 

hippy

Technical Support
Staff member
#4
#5
flippin heck, you go away to a meeting, and everything's happened while you were away... ;):ROFLMAO:

Westaust55, can I hire you? :LOL::LOL: pretty much anything I've looked for WRT model railways, you've been there, done that, and got the T-shirt!! brilliant!

This seemed quite comprehensive though I'm no expert in DCC and completely unfamiliar with the NCE systems -

https://ncedcc.zendesk.com/hc/en-us/article_attachments/200182749/Cab_bus_protocol.pdf
Aye, that was my starting point, but of course the one part I'm really interested in reading more about (5 byte packets, using a type "c" "smart" cab) isn't included... of course! :rolleyes:

That should be entirely possible. RS485 is a balanced two-line +/-12V signal but it should be possible to take one of those and feed it in to HSerial In via an in-line 22K current limiting resistor. That will protect against any voltage differences as with the program download circuit.

You might have to play about with which signal to choose and what polarity to use in the HSERSETUP command but it should work. Don't forget the 0V connection to the sending equipment.

Then it's simply a case of enabling background receive, letting the Scratchpad fill up and reporting what it shows. Something like this which reports data received in hexadecimal -
Yep, seems reasonably simple (he says...) - ideal for simply letting me monitor the bus while I "play trains", see what each action does...

The long term goal for this project, and I'm not sure whether a PICAXE would be suitable in this instance, is to add a controller node to the system, like Westaust's accessory controller, but slightly different.... My intention is to automate certain "functions" on the locomotives, for example headlights, sounds, door warning lights etc. etc. The problem I can see is the timing needed for the NCE system, which is timed to the uS... I'll have to give the system from Westaust a test, see what happens there :)
 

Janne

Senior Member
#6
Why do you need to put a picaxe in the middle if you just need to decode the protocol? USB-RS485 adapters are available for a few bucks on ebay.
Once you've figured it out then implement what you want to achieve with a picaxe.
 
#7
Hi Danners,
Keep in mind that the NCE Cab Bus comms is not like the 3, 4 or 5 packet DCC signals from a command station (via a booster) onto the tracks.

The Cab Bus is a polled scheme where the command station issues a “Throttle” address and the “Throttle” acknowledges yes/no if present.
The command station then allows the throttle to send 1 byte per key press.
The command station in general cannot accept multiple bytes per burst - 1 per poll and I found that I needed to send nothing for around 10 polls or the information was not actioned.
10 polls equates to about the fastest time a person can press consecutive buttons on a “Throttle”.
NCE throttles are relatively dumb even with a LCD display and it is the command station that tells the Throttle what and where to display the info.

My accessory controller endeavors to be smarter but (I tell the command station it is dumb) and I needed to add 10 “do nothing” responses between each byte of “real” data.

Hope that the above helps to clarify the NCE Cab bus protocol.
 
Last edited:
#8
Why do you need to put a picaxe in the middle if you just need to decode the protocol? USB-RS485 adapters are available for a few bucks on ebay.
Once you've figured it out then implement what you want to achieve with a picaxe.
The main reason I wanted PICAXE initially was to simply use the serial monitor... but I never thought of that... hmm!

Hi Danners,
Keep in mind that the NCE Cab Bus comms is not like the 3, 4 or 5 packet DCC signals from a command station (via a booster) onto the tracks.

The Cab Bus is a polled scheme where the command station issues a “Throttle” address and the “Throttle” acknowledges yes/no if present.
The command station then allows the throttle to send 1 byte per key press.
The command station in general cannot accept multiple bytes per burst - 1 per poll and I found that I needed to send nothing for around 10 polls or the information was not actioned.
10 polls equates to about the fastest time a person can press consecutive buttons on a “Throttle”.
NCE throttles are relatively dumb even with a LCD display and it is the command station that tells the Throttle what and where to display the info.

My accessory controller endeavors to be smarter but (I tell the command station it is dumb) and I needed to add 10 “do nothing” responses between each byte of “real” data.

Hope that the above helps to clarify the NCE Cab bus protocol.
Aye, that's the "a", "b", "d" and "e" type throttles listed in the NCE documents... the one I'm really interested in is the "c" type throttle, which is the USB connector - it doesn't behave like a dumb throttle, but instead actually sends "commands" to the command station, sending addresses followed by actions... Not sure which I'd use, but I was interested to find out!
 
#9
Basically, the idea behind even considering this project was when I stumbled across the fact that the NCE cab bus was such a "simple" protocol, easily accessible using almost any microcontroller... I've been wanting to build my layout in such a way so that I could "upgrade" it to fully automatic control at some point in the future... Initially I was going to go with DCC++, running off a Teensy... but this looks like it could end up being a LOT more simple to build, program and implement!!
 

Janne

Senior Member
#10
The main reason I wanted PICAXE initially was to simply use the serial monitor... but I never thought of that... hmm!
Well you can even use the terminal on the picaxe editor if you want. The cheap RS-485 dongles have an USB to UART bridge built in, so once you've installed the driver you can open the COM port on any terminal you like.
 
#11
Well you can even use the terminal on the picaxe editor if you want. The cheap RS-485 dongles have an USB to UART bridge built in, so once you've installed the driver you can open the COM port on any terminal you like.
Yep, they would work... I'll have a look, see if I can work it out.

On another note, I did a little more research (if this is of any interest to anyone), and discovered that what NCE describe as a type "c" device (the only one which sends 5-byte commands, and actually sends "commands" instead of letting the command station do all the work) is currently only their USB adapter... I found a great article (http://ralf.alfray.com/trains/nce_usb.html) which does a basic teardown of this module, and lo and behold all it really is is a PIC acting as an encoder/decoder for the cab bus, sending TTL logic signals to a USB converter... in other words, it would probably be possible to "hack" this too, by bypassing the USB converter and sending the commands to the PIC encoder...

A lot more experimenting required here, methinks!
 
#12
Hi Danners,

Yes you can take the data from the NCE Cab bus into the PICAXE PE.
As well as the general terminal facility there is a “logger” mode intended to take data from a PICAXE datalogger and be able to save into a CSV file for further analysis. I may have been using the PE5 when I used that logger function. It has in PE5 a limit of 2000 bytes but that is enough to get some snap shots of what is happening on the Cab Bus.
 
#13
My belief is that the NCE usb adaptor is only for use with the PowerCAB.

The Power Pro systems with separate ProCAB throttle/Cab and box withe command station can only be connected via the RS232 connector and has different commands.

EDIT: I did a bit more research and seems the NCE USB module was specifically designed for the PowerCAB and some other lower level control systems.
It will work with the high end systems such as PowerPro but a limited functionality applies.

Are you aware of the software JMRI?
It has two parts:
A. Programming decoders
B. Controlling layouts.

I only use part A.
 
#14
My belief is that the NCE usb adaptor is only for use with the PowerCAB.

The Power Pro systems with separate ProCAB throttle/Cab and box withe command station can only be connected via the RS232 connector and has different commands.

EDIT: I did a bit more research and seems the NCE USB module was specifically designed for the PowerCAB and some other lower level control systems.
It will work with the high end systems such as PowerPro but a limited functionality applies.

Are you aware of the software JMRI?
It has two parts:
A. Programming decoders
B. Controlling layouts.

I only use part A.
Sorry for the delay, for some reason never got a reply notification :)

My use of the USB module would be limited to functions, accessories and speed commands, no programming or anything... Would they work on a Power Pro system?

Also, I've done a fair bit with JMRI, but was promptly put off when I realised that any custom functions I wanted to use had to be written in Java :sick: sorry, I personally hate Java! :LOL:

Nah, I'm considering going back to it I have to admit... But I'd be restricting its use to automation, as my goal is to make the layout "self-contained", with all the NECESSARY components (signalling control & interlocking / DCC system) integrated onto the baseboards
 
#15
The PowerPro uses an RS232 interface for max control and some monitoring.
The USB to CabBus interface would have very limited control for powerPro.

Through the CabBus I suggest you could use a CAB similar to the PICAXE based unit I have built and posted about.
The NCE CAbBus is a simple bidirectional serial comms and not intended to control devices via the Bus.

My PICAXE accessory decoders are dedicated to control of lighting and some scenery items such as rotation of various small cranes (servo drives)

Away from the PICAXE aspect o_O
For route, signal and point and uncoupled control I used a commercial product that has 16 inputs, 16 outputs and 8/16 routes (search for SRC162) with from 1 to 3 boards per layout module. Not cheap but quite versatile. in that way each of my 8 layout modules is self contained and I only need send one route command at the DCC track level to set upwards of 16 points.

You could use PICAXE for point, signal and route control per module but suggest you will need to hard code the PICAXE specifically for the desired options (as I did for my lighting decoder/controllers) - no CVs (config variables) for ease of change as per Commercial products.

Back on a PICAXE theme, I have used surface mount PICAXE 08M2s on modified MERG PCBs for control of the semaphore signal that have been installed to date.
 
#16
That makes a lot of sense... Would be easy enough to use your PICAXE controller in combination with another chip which does the actual "AI", sending commands to the "controller" PICAXE... all in the future methinks though, wasn't as easy as I first thought.

As for actual layout control, I'm going full custom on my system - my desire is to have full prototypical signalling (hey - signalling geek!), right down to track circuits, overlaps and approach control. In order to achieve this level of control, I'm probably going to use vanilla PICs (why coming shortly) dedicated to specific tasks:

  • block detection (track circuits) - use current sensors and isolating breaks to detect the presence of a train in a specific block section (over 50 sections)
  • point control / detection - switches points (Cobalt DCC), and detects their correct operation (auxiliary microswitches on the Cobalts) (over 30 points)
  • signal control - controls signals and detects faulty LEDs (over 20 signals)
  • control panel - 58 inputs, 200+ discrete LEDs & eighteen 24x8 dot matrix displays
  • Possibility for "point detection" (detects when a train passes a spot on the layout, nothing to do with pointwork) in the future
Because of the plethora of tasks to be undertaken, I'm likely going to use a CANbus network throughout my layout, allowing for full multi-master operation, with collision detection and message prioritisation - hence the use of PICs instead of PICAXEs :-(
 
#19
For your Cobalt motor drivers, read here:
https://picaxeforum.co.uk/threads/uln2803a-udn2981a-drop-in-dmos-alternatives-to-consider.29775/

For such stall motors only needs 1 PICAXE or other digital (high/low) output signal to set points, uncouplers for TLC type couplers, etc.
Yep, that makes sense... The thing with the Cobalt Digital though is it has the pushbutton option of being switched, so I could set them like that.... Or, of course, use this thread - send the switching commands over the DCC bus, and only use MCUs to detect the position! Much easier 😁
 
Top