Jump to content
 

Reverse engineering the NCE cab bus using the PowerCAB


Recommended Posts

The purpose of this thread is to document the operation of the NCE Cab bus, sometime known as the NCE Command bus, using my NCE PowerCAB to experiment and reverse-engineer where the documentation is absent or unclear.

 

The purpose of the exercise is to garner sufficient information to support the development of home-grown Auxiliary Input Units (AIUs) and USB interfaces using Arduinos rather than buying proprietary devices from NCE.  Some will shake their heads at the point of this exercise, but as a retired electrical engineer and computer programmer, I should be OK.  Given sufficient information.

 

There is information out there, but much of it is difficult to locate and sometimes down-right contradictory.  I’m attempting to straighten it all out for my own use, and perhaps it might be useful to others.  Or perhaps others have already been down this track, in which case I would love to hear.

 

Sources:

 

Electrically, the NCE Cab bus is an RS-485 serial bus run at 9600 baud with 8 data bits, no parity and 2 stop bits.  Interfacing to an Arduino merely needs an RS-485 interface.  Search for MAX485, an industry-standard RS-485 transceiver chip, built into a number of modules and shields.

 

The bus is controlled by the system command station.  In the PowerCAB, it’s implemented in the hand-held.  The command station sends commands out the bus, and then relinquishes the bus to allow the addressed cab to respond.  The system is designed to support up to 63 cabs, although address 1 is reserved for future use.  The PowerCAB only supports 7 cabs, including itself (more later).

 

The protocol begins with the command station sending a single-byte 0x80 broadcast ping command.  No cab should respond to this ping.  The protocol looks to be designed such that this is the only way that a 0x80 byte can appear on the bus, and hence it can be used to sync up any cab to the bus protocol.  Whenever a 0x80 byte is read, it must be a broadcast ping, and the following byte must be the start of the next command.

 

Further, it appears that all bytes sent from the command station have bit 7 set, while all bytes sent by units (cabs/AIUs/USBs/mini-panels) on the bus have bit 7 cleared.

 

The command station will also ping specifically addressed cabs (0b10aaaaaa, 0x81-0xBF, where aaaaaa is the address of the cab being addressed).  The NCE documentation states that the cabs may not be addressed in numeric order, as the system will give priority to cabs that respond.

 

Experimentation with my PowerCAB shows that it only pings addresses 3, 4, 5, 8, 9 and 10.  The PowerCAB specification in the PowerCAB manual states that the PowerCAB supports up to 4 controllers plus up to 3 AIUs, USB interfaces and/or mini panels.    It is possible that the PowerCAB command station pings the internal PowerCAB cab at its default address of 2, but this data does not appear on the external cab bus.

 

This limitation of the PowerCAB is documented here: the cab addresses are 2, 3, 4 and 5, while the AIU/USB/mini-panel addresses are 8, 9 and 10, although even this is confusing as the NCE USB manual states that the USB forces its cab address to 3 when used with a PowerCAB.

 

Further, the NCE AIU manual recommends that AIUs be placed at addresses over 50, which is clearly inappropriate for use with a PowerCAB where these addresses are never pinged.

 

 

Edited by aardvark
Corrected link to Ralf's train pages
Link to post
Share on other sites

Hi,

 

I hope you do manage to fully document this.

 

I like the NCE handhelds but cannot use the NCE command station on my layout due to an annoying shortcoming. My current command station is a Roco Z21.

 

I have often thought it would be grand to have a device that would allow connecting the NCE handhelds to other command stations such as mine.

 

Good luck.

 

Frederick

  • Like 1
Link to post
Share on other sites

LOL: ask for help?

 

Seriously, that is a very good suggestion, although I dispute whether it is obvious.

 

In the meantime ...

 

 

If there is a unit (cab/AIU/USB/mini-panel) on the bus corresponding to a pinged address, the unit should respond.  The response can be either 2 or 5 bytes.

 

Type ‘a’ units (cabs with LCD display) and type ‘b’ units (cabs without LCD display) respond with 2 bytes:

  • Byte 1 - key press information
    • 0b010xxxxx, 0x40-0x7C, where xxxxx is the code for the key pressed
    • 0b01111101, 0x7D: no key pressed
    • 0b01111110, 0x7E: repeat current screen
  • Byte 2 – speed
    • 0b0xxxxxxx, 0x00-7E, where xxxxxx is the speed control from the knob (0-126)
    • 0b01111111, 0x7F: knob not used, keys used

Type ‘c’ units (reserved, sometimes also called ’smart’ and may include USB interfaces) respond with 5 bytes:

  • Byte 1 & 2: device address
    • I read something somewhere that this might be loco short or long address, accessory address or signal address.  No idea how these are distinguished.
  • Byte 3 & 4: operation
    • No idea.
  • Byte 5:  XOR checksum of bytes 1-4

Type ‘d’ units (AIUs) respond with 2 bytes:

  • Byte 1: 0b0xxxxxxx, 0x00-7F, where xxxxxxx is the bit map for inputs 1-7 (bit 0 is input 1)
  • Byte 2: 0b0xxxxxxx, 0x00-7F, where xxxxxxx is the bit map for inputs 8-14 (bit 0 is input 8)

The responses of type ‘e’ units (reserved), type ‘f’ units (Cab-Bus/X-bus bridges) and type ‘g’ units (Cab-Bus/Loconet bridges) are unknown.

 

When the command control receives a 2-byte response, it may then issue a one-byte 0xD2 cab-type command.  This command (and most others) has no explicit cab address: it would seem that the unit addressed by the preceding ping command continues to be address until a subsequent ping command with a different cab address.

 

In response of the 0xD2 cab-type command, the addressed unit must respond with its cab-type (‘a’-‘g’, 0x61-0x67).

 

The command station does not always issue a 0xD2 cab-type command.  The 0xD2 command is never issued for 5-byte response, which can only come from type ‘c’ units.  Moreover, the command station only sometimes issues a 0xD2 for 2-byte responses – this appears to depend on the values of the 2-byte response bytes, and possibly even the cab address.  This is problematic.

 

In the case of type ‘d’ units (AIUs), the command station can only know that it is a type ‘d’ after it responds to the 0xD2 command.  Experimentation with my PowerCAB shows that the 0xD2 command is never issued if the ping command 2-byte response bytes are both zero, which would be a valid response for an AIU.

Edited by aardvark
Link to post
Share on other sites

  • 2 weeks later...

Hi,

 

I hope you do manage to fully document this.

 

I like the NCE handhelds but cannot use the NCE command station on my layout due to an annoying shortcoming. My current command station is a Roco Z21.

 

I have often thought it would be grand to have a device that would allow connecting the NCE handhelds to other command stations such as mine.

 

Good luck.

 

Frederick

Does the NCE not work on the sniffer port of the Z21?  

 

Brendan

Link to post
Share on other sites

Does the NCE not work on the sniffer port of the Z21?  

 

Brendan

Hi,

 

I have no idea what you are asking me.

 

I cannot use the NCE command station but would like to be able to use the handheld throttles on other systems.

 

For example I can use a Digitrax handheld with the Z21.

 

Frederick

Link to post
Share on other sites

Sniffer ports are generally for DCC, not cab busses.

Correct, but I understood the issue to be using the NCE handheld on Z21.  If you have the NCE system, you can connect it to the Z21 through the sniffer ports to be able to use the NCE handheld.

 

Brendan

Link to post
Share on other sites

...

 

For example I can use a Digitrax handheld with the Z21.

 

Frederick

 

Yes, you can plug the Digitrax handset into the Z21 but not the z21.

 

Correct, but I understood the issue to be using the NCE handheld on Z21.  If you have the NCE system, you can connect it to the Z21 through the sniffer ports to be able to use the NCE handheld.

 

Brendan

 

What is the NCE output voltage? It needs to be 16v or higher to work with the Z21 sniffer and I think that NCE is 14v?

Link to post
Share on other sites

Correct, but I understood the issue to be using the NCE handheld on Z21.  If you have the NCE system, you can connect it to the Z21 through the sniffer ports to be able to use the NCE handheld.

 

Brendan

 

The issue is with the NCE command station. It doesn't send certain DCC packets that my system needs to see.

 

Frederick

Link to post
Share on other sites

Yes, you can plug the Digitrax handset into the Z21 but not the z21.

 

 

What is the NCE output voltage? It needs to be 16v or higher to work with the Z21 sniffer and I think that NCE is 14v?

 

For the standard supply.  If a higher voltage power supply is used, it will raise the output voltage.  I use and old laptop supply (19V) for mine.

The issue is with the NCE command station. It doesn't send certain DCC packets that my system needs to see.

 

Frederick

 

Ahh

  • Like 1
Link to post
Share on other sites

Hi BrendanS


 


I've contacted NCE a couple of times about this issue but nothing has changed - possibly because few are affected by it.


 


My layout is fully automated and the software I use needs this additional information from the command station to avoid some annoying behavior that occurs as a result of not having the information.


 


Digitrax, Roco, Digikeijs and other command stations don't have this issue so it would it not seem to be a huge technical hurdle to leap.


 


But I do like the NCE handhelds!


 


Frederick


Edited by fcwilt
Link to post
Share on other sites

They are also slow to move ahead with the times.

 

Brendan

 

I am not sure that they are unique in this respect, most suppliers in this space seem to create one system and then all you get is variations on that offering without any real innovation or change. Most of the platforms seems to have been around for many years without any change which either means they were incredibly overspec'd when first delivered or innovation isn't something that they do - some I don't think that the former applies ;)

Link to post
Share on other sites

I am not sure that they are unique in this respect, most suppliers in this space seem to create one system and then all you get is variations on that offering without any real innovation or change. Most of the platforms seems to have been around for many years without any change which either means they were incredibly overspec'd when first delivered or innovation isn't something that they do - some I don't think that the former applies ;)

 

I don't know if you have checked out the Digikeijs DR5000 but there is a company that seems to working hard and has some good ideas.

 

Frederick

Link to post
Share on other sites

Frederick

 

I know them very well and am actually a beta tester for some of their products ;)

 

They are very much and exception, possibly with a ROCO not far behind but the established player are very slow to market and when something does appear it is underwhelming in the extreme - look at Lenz’ latest offering, hardly earth shattering and several year late.

Link to post
Share on other sites

Frederick

 

I know them very well and am actually a beta tester for some of their products ;)

 

They are very much and exception, possibly with a ROCO not far behind but the established player are very slow to market and when something does appear it is underwhelming in the extreme - look at Lenz’ latest offering, hardly earth shattering and several year late.

Hi,

 

Interesting!

 

I've been impressed with their products - I purchased one or two of most of their "DCC" products just to check them out.

 

Do you know how Digikeijs got started?

 

Frederick

Link to post
Share on other sites

  • 9 months later...

I am working on an automated floor level six track storage system with two entry/exit points  to a 2 metre lift to floor level and return.  I want to connect to the Cab Bus (RS485)  to copy instructions from Cab06 throttles to operate the storage system.  For example when a Cab F8 is pressed my Pic "Pseudo Cab" would copy the Loco Number to use it to drive the Loco into an empty storage track.   Read as much as I may, there is one simple thing that eludes me.  The protocol says that a dumb cab, such as the Cab06, responds to a ping to its Cab Address always with two bytes - Byte 1 is a key press, byte 2 loco speed.  So, how does my PowerPro controller know what Loco Number a polled Cab 06 is controlling?   (asked NCE but the silence has been deafening)

 

If the response was a five byte address as described for smart cabs, this would be (relatively) easy.  Or is a Cab06 deemed a Smart Cab"

 

Can anyone help please?

 

Anybody have any ideas? 

  • Like 1
Link to post
Share on other sites

Hey @DonSn35Quixote, welcome to RMWeb and to this thread.  It sounds like you've created quite the project for yourself.

 

I haven't made much progress on  the subject: the early research described above all took place while I was procrastinating over the construction of my layout.  Since actually starting, there is much to do, although I do expect to return to this subject later.

 

You might like to have a read through Ralf's train pages., which has plenty of relevant information.  I did come to the understanding (which I haven't investigated further) that the NCE cabs are really really dumb, and that the controller does everything.  The cab sends every keypress and knob twiddle to the controller, which is responsible both for converting these to DCC messages to control your locos and accessories, and for creating screen images which are sent back to the cab for display.  I suspect that the cabs are so dumb that even they don't know what loco they're controlling.

 

To figure out which loco is actively being controlled by a cab, you have to eavesdrop the NCE bus and track the keypresses, something like: select-loco, 1, 2, 3, enter.  I missed this entirely, and I think it was Ralf that set me straight.

 

Therefore, the controller must maintain the full operating state of each cab.

 

Further, I suspect the PowerCab (which I have) doesn't expose the goings-on between the internal PowerCab controller and the internal PowerCab cab, which would be quite limiting for me.  I hope further investigation will prove this suspicion wrong.

 

I have had thoughts of an automated transverser driven by a stepper-motor, and your post has re-awakened them.

 

One day ...

 

 

 

 

Edited by aardvark
Link to post
Share on other sites

Thanks AArdvark.

 

I had read Ralf's Train pages.  Helped a lot but not completely.   (Cant see how he gets his Xor checksums though) It is exactly the "Sniffing" of the Cab Bus that Ralf talks about that I am trying to do.  When (say) F5 is pressed, record the number of the loco associated with that Cab, and go from there to set up the storage entry/exit and drive the loco in/out, control the lift an so on.  Not that hard when one charts it out, but I am snagged on how to recognise the "Control this loco" command(s) from Cab to CMD.

 

I have ground my way to the understanding that the Cabs really are dumb and that all data is stored in the Command Controller - a PowerPro in my case - as you say.  But the issue I have is that the NCE doc's specify all dumb terminals respond to a Ping with two byte response - Key Press and Speed, and cannot change their response type.  Though that does not quite correspond with Ralf - he has fice and two byt resonses in his discussion. No mention of what the Cab06 sends in response to a Ping after Enter is pressed.  But that response must be at least three bytes - Enter (0x60? and two address bytes.

 

I got an answer from NCE on this today and it was about the five byte response the CMD box sends to Cabs:  

 

"Q How does the PowerPro learn what loco number the Cab 06 is controlling?

 

A The cab receives an 0xdb multibyte from the command station after entering a loco or

when just ENTER is pressed during normal operations."

 

I have rephrased the question, and will let you know what answer I get.

 

Their reply does not explain how the data gets to the CMD station in the first place.  I suspect  the response is 0x60 followed by three, or maybe the standard five bytes, CMD being alerted to a non-two byte response by the 0x60.  I guess I am just going to have to put my logic analyser to work and do a few tests to find out.

 

I will let you know how it goes.  A relatively simple thing I would have thought made difficult by confusing and incomplete documentation from NCE.  But in true Quixote fashion I am determined to smash this windmill.

 

Quixote.

 

PS on your traverser,

 

Suggestion.  Use decent size steppers to make a bird of the job, and drive them with Gecko drivers.  Your controller than needs to supply a direction signal and the pulses.  The Gecko's microstep, turning (say) a standard 200 steps/rev motor into a 1000 step per rev one.  Good resolution is need as the top of the rails are only 1mm wide, giving not much margin for misalignment and derailments. 

 

As to the Grand Plan, there are five of us working two afternoons and one evening for the last five years. Two ex Army WOI's, One truckie, and Mr Weller (Used to run the soldering equipment part of Weller Australia - he gets all the difficult soldering jobs.   Me?  Army, Concrete Industry, Appliances and Automotive in various positions.  Our in joke over out coffee sessions is the trains will never run (They have) and the opening ribbon will be cut at my wake.  

 

  • Like 1
Link to post
Share on other sites

On 23/07/2018 at 00:20, BrendanS said:

They are also slow to move ahead with the times.

 

On 23/07/2018 at 08:07, WIMorrison said:

.....most suppliers in this space seem to create one system and then all you get is variations on that offering without any real innovation or change.....

........innovation isn't something that they do......

 

The NCE system was first introduced (as the Wangrow System One) in 1994.

27 years ago.

 

 

John Major was the UK PM and mobile phones looked like this....

 

ivdmdspvljfo4byeuogx

.

  • Like 1
  • Funny 2
Link to post
Share on other sites

19 hours ago, DonSn35Quixote said:

I have ground my way to the understanding that the Cabs really are dumb and that all data is stored in the Command Controller - a PowerPro in my case - as you say.  But the issue I have is that the NCE doc's specify all dumb terminals respond to a Ping with two byte response - Key Press and Speed, and cannot change their response type.  Though that does not quite correspond with Ralf - he has fice and two byt resonses in his discussion. No mention of what the Cab06 sends in response to a Ping after Enter is pressed.  But that response must be at least three bytes - Enter (0x60? and two address bytes.

 

I don't know the Cab06 - I only have a PowerCab.  I'd suggest that you hook up your logic analyser and see.  There's nothing like seeing how a system works as opposed to how it's supposed to work.

 

Assuming for the moment that it gives a 2-byte* response when pinged, the cab will send the code for the most recently pressed button and/or the most recent value for the speed knob, or a null value if there has been no change. I recall that it may send the same code up to 4 times to ensure that the controller gets it, although having written that, I'm not sure how it copes if the same button is pressed twice.  Perhaps just a null value between reporting the two presses, but I'm guessing.

 

In the case of selecting a loco, you should see the code for the select-loco key, followed by individual keycodes for zero or more digits keys, followed by the code for the enter key.  I don't think that there is any single transmission from the cab that provides the loco address, and further, I suspect that the cab has no use retain that state for itself.

 

* cab always give the same 2- or 5-byte response: their cab-type determines which.

Edited by aardvark
Link to post
Share on other sites

I finally got a meaningful reply from NCE Support.

 

"The cab send nothing after the ENTER.

 

The digits for selecting the loco address are sent one at a time as the user presses them

after the Select Loco button,  Enter ends the digit sequence."

 

Makes sense. This  suggests the Cab06 replies to a ping from CMD with Select (49H) the a series of digits from button presses with the sequence ended with Enter (40H).  That is not a two byte response, and is not mentioned in any documentation I have uncovered. Hopefully this will be helpful to anyone working on a project involving the NCE Cab Bus.  I intent to take the Irish approach (To be sure, to be sure to be sure) and confirm this advice by testing.

 

 

Another response from NCE support was not quite so helpful. In response to a question of how to calculate the CheckSum, this:

 

"The first 4 bytes are Xor'd together and will result in the 5th byte."

 

Documentation says add the first 4 bytes and Xor them.  But Xor require two bytes.  I get the sum byte, but Xor'd with what other number?  I suspect FF, but not sure. Ralf's Train Pages gives examples, but I cannot get his checksum values from his data no matter how I do the Xor.  Fortunately this looks to be moot as the above transaction does not involve a checksum, and the rest of the 2 byte  transactions  i intend using do not use a checksum.

 

Non the less I am uncertain I have the full story.  So I intend a few hours sending and receiving on the Cab Bus and recording the data.  As Ralf did for a ProCab, but with a Cab06. I will publish the results when my poor old addled brain completes the task.

  • Like 1
Link to post
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now
 Share

×
×
  • Create New...