DCC Monitor

[St1ngr4y]

Does anyone know if you can buy a DCC monitor? I would imagine it would consist of a small piece of hardware, one end of which connects to your DCC bus or track, and the other end would have a USB cable to plug into a computer. There would also be a software program which would read from this USB port, and display on the screen, in a user-friendly format, the messages being sent on the DCC.

I wasn't sure whether to put this in the DCC forum, but I decided that since a computer would be involved, this forum would be better.

Ray

[Yelrow]

RAY, hi, do you mean you have not got one yet. Link ARDUINO, MYNA BAY. DCC MONITOR. Unlike you to be behind, john

[RB51]

I didn't know about those. Not that it matters, as I dont understand the output anyway. As far as I am concerend a packet is something that is wrapped up and usually arrives via The Royal Mail. R-

[Yelrow]

ROG, it could also be a Steam Packet, if you live in the isle of man. Dont say you have not got one of these yet either. john

[96RAF]

Are you looking for the DCC signal profile like a wiggly line or just what the command status is Ray.

 

If the former you need a DCC sniffer - a specialist meter.

 

If the latter and you don't want to spend money (Costa-Packet) try Rocrail. Its a free download.

 

The user screen shows the trackplan, a loco list and 2 frames - one of these echos what command(s) you are sending and the other echoes what is happening as a result of that command.

 

e.g.

 

Command Frame - Point 3 (address 0,3) set to straight....

 

Other Frame - Elite not responding, resent twice.

 

You don't even need any hardware to try it as there is a simulation mode with a test track plan.

[RB51]

ROG, it could also be a Steam Packet, if you live in the isle of man. Dont say you have not got one of these yet either. john

 

I can assure you I have plenty of usless/unsused/bewildering/expensive/"why did I get that"/ "where are the instructions" type kit (to me anyway) already. :-) R-

[St1ngr4y]

Are you looking for the DCC signal profile like a wiggly line or just what the command status is Ray.

 

If the former you need a DCC sniffer - a specialist meter.

 

If the latter and you don't want to spend money (Costa-Packet) try Rocrail. Its a free download.

 

The user screen shows the trackplan, a loco list and 2 frames - one of these echos what command(s) you are sending and the other echoes what is happening as a result of that command.

 

e.g.

 

Command Frame - Point 3 (address 0,3) set to straight....

 

Other Frame - Elite not responding, resent twice.

 

You don't even need any hardware to try it as there is a simulation mode with a test track plan.

 

It would be the latter. I thought it might help sort out possible bugs in RM. Or does Rocrail replace RM?

Thanks for that - I'll have a look.

Ray

[RB51]

It would be the latter. I thought it might help sort out possible bugs in RM. Or does Rocrail replace RM?

I looked at Rocrail some time ago - currently (I've just checked again) the Elite (lucky for you) is the only supported Hornby command station via Expressnet. I think you might have to ditch RM if you went this route. R-

[Fishmanoz]

I didn't know about those. Not that it matters, as I dont understand the output anyway. As far as I am concerend a packet is something that is wrapped up and usually arrives via The Royal Mail. R-

 

Roger, are you having trouble with delays in your commands being executed? And are there little pieces of wrapping paper accumulating next to the rails around your layout? I think we can figure it out now.

[RB51]

Funny you should say that. I thought that as no-one generally takes any notice of what I say anyway the same applied to the trains. Not noticed anything alongside the rails - but then, I can't find my glasses at the moment. R-

[96RAF]

Are you looking for the DCC signal profile like a wiggly line or just what the command status is Ray.

 

If the former you need a DCC sniffer - a specialist meter.

 

If the latter and you don't want to spend money (Costa-Packet) try Rocrail. Its a free download.

 

The user screen shows the trackplan, a loco list and 2 frames - one of these echos what command(s) you are sending and the other echoes what is happening as a result of that command.

 

e.g.

 

Command Frame - Point 3 (address 0,3) set to straight....

 

Other Frame - Elite not responding, resent twice.

 

You don't even need any hardware to try it as there is a simulation mode with a test track plan.

 

 

It would be the latter. I thought it might help sort out possible bugs in RM. Or does Rocrail replace RM?

Thanks for that - I'll have a look.

Ray

 

Ray

 

Rocrail is just another type of RM. Unfortunately you can't run them both together so you can't use Rocrail to fault find RM. I run both as there are times I want to check stuff speed step by speed step, which is not easy to do in RM and almost impossible using the Elite on its own. Rocrail allows me to see which speed step has been sent and also shows loco speed in MPH/KPH. I use it as a tool and to run trains, but it won't replace RM, merely compliments it.

 

Rob

[idlemarvel]

Ray, if you are really into this there is a thread on the rmweb forum where someone is analysing elink messages at the bits and bytes level, if you search for "elink and hornby railmaster" you should find it. Amongst other things the guy is using Microsoft Message Analyser but you could use Wireshark or similar.

[St1ngr4y]

Ray, if you are really into this there is a thread on the rmweb forum where someone is analysing elink messages at the bits and bytes level, if you search for "elink and hornby railmaster" you should find it. Amongst other things the guy is using Microsoft Message Analyser but you could use Wireshark or similar.

 

Thanks Dave, I'll take a look.

Ray

[96RAF]

Ray, if you are really into this there is a thread on the rmweb forum where someone is analysing elink messages at the bits and bytes level, if you search for "elink and hornby railmaster" you should find it. Amongst other things the guy is using Microsoft Message Analyser but you could use Wireshark or similar.

 

 

Thanks Dave, I'll take a look.

Ray

 

He's trying to produce a commercial bit of kit at day's end, but is also looking for beta testers for it. You may get lucky.

[RB51]

He's trying to produce a commercial bit of kit at day's end, but is also looking for beta testers for it. You may get lucky.

 

Just had a look at that. It's very grown up isn't it? As usual I didnt understand most of it - but it sounds good. Perhaps I'm just easily impressed? R-

[96RAF]

 

He's trying to produce a commercial bit of kit at day's end, but is also looking for beta testers for it. You may get lucky.

 

Just had a look at that. It's very grown up isn't it? As usual I didnt understand most of it - but it sounds good. Perhaps I'm just easily impressed? R-

 

Certainly is Rog

 

He seems to know his way inside the eLink. Maybe HRMS/HCC should be following that thread to pick up tips on how the eLink could be improved, without stealing his ideas of course.

[RB51]

What is also impressive is that none of what he's suggesting seems to add to the cost (as far as I can tell) but improves performance no end. Definately one to watch. R-

[RDS]

What an interesting thread. Thanks Ray.

[St1ngr4y]

I know this thread is almost 4 years old, but I thought I would resurrect it. Well over a year ago, Chrissaf made available some notes for making a monitor based on an Arduino. Not being at all good with electronics and delicate soldering, I asked a friend of mine if he would like to have a go at building one for me. Unfortunately, due to family bereavements, he was unable to give it any time until recently. He finally delivered it on Wednesday, and it worked immediately.

The first noticeable thing is that Railmaster is constantly sending out packets of information for every loco which is defined in your database. Even when nothing is running, there are packets setting the speed of each loco to zero, and packets containing the status of every loco function. Unfortunately, using the monitor provided with the Arduino software, and the program loaded into the Arduino itself, there is very little scope for filtering the vast amount of information which appears on the screen. It would have been nice, for example, to be able to select only one loco address to see all the messages for just that loco. The best that can be done is to filter out all of the loco packets, leaving only accessory decoder packets. So until someone can suggest a way of providing extra filtering, I have been looking at accessory packets only, in particular, those sent to TrainTech signals.

The first signal I looked at was a 4-aspect signal, which has a base address of 222. This means it uses 222 for the red and green aspects and 223 for the Y and YY aspects. A while back, before I had this monitor, I discovered that the INI file entry "Double pulse=1" caused RM to send two messages to the same port for a signal when executed in a RM program. So I expected to see a pair of messages on the monitor for each command sent to a signal by a program. What I saw was unexpected and inexplicable. After the two identical messages sent to either 222 or 223, there were another one or two messages sent to address 220. After experimentation with several other signals, I discovered that the address used for this extra message seems to be the next lower unused even address !!!!!! Now what is that all about ??? It only happens when a signal is controlled by a program. When the signal icon on the layout display is clicked, only one message is sent to the appropriate address. Why on earth is different program code in RM being used to change a signal in a program as that used to change it from a layout icon?

 

If anyone can suggest any (preferably free) software which can provide filtering of the messages coming in from the monitor, I would be very grateful.

 

Ray

[96RAF]

Can’t help there Ray, even with my Pico-scope monitoring the DCC signal.  Despite all efforts to gee them up Pico has stalled at a software level that only translates basic decoder data streams not extended decoders, hence the on screen deciphering of the data is mostly nonsense, although the sent code is graphically shown as a ribbon on screen.

 

To add to this Chris looked at decoding the accessory decoder packets and that uses a mysterious system of ones-equivalent in the binary whereby what is a zero is actually a 1 making translation into laymans terms outwith my skill set, although Chris has a couple of his superb diagrams illustrating the conversion.

 

The best I have seen so far is  probably what you are using - Rudy’s method - and although he provides all the files to run it I cannot find in there where it deliniates (say) to speed step or binary increment level what each data byte means in English.

 

Again the NMRA standard telling of how functions are grouped seems illogical as though it were iterated piecemeal as progress was made in the DCC world.

 

Rob

[Chrissaf]

Yes Ray, you can possibly restrict what is being displayed on the Arduino monitor with more options than your post indicated.

.

As well as being able to filter on Accessory packets only or on Loco packets only. You can also turn off showing 'idle' packets. The idle packets are still sent, but just not shown in the display. This cuts down what is displayed quite drastically. Idle packets are sent by an Elite when RM isn't being used as the actual controller interface. So 'Idle' packet suppression may not be an option you can use, if you are looking at the RM track output when running RM programs.

.

However what if you created a RM Group with only the loco(s) you want to monitor in it (rather than the full loco roster). With this dummy group selected in RM, then maybe only these restricted Group listed loco packets will be sent to track. If this idea works, then this will be the same as a filter that selects specific loco DCC addresses.

.

PS - Don't know about RM ProPack, but in RM Standard Edition, if you want to delete a 'Group' that you have only been using temporarily, you have to manually delete the 'Groups.dat' file in the RM program folder. This will of course also remove all and any other groups that you might have previously set up.

.

See page 16 of my V2 construction 'How To' make this monitor PDF. Fresh download link below.

https://btcloud.bt.com/web/app/share/invite/vUyZxCc5oD

File above now updated to V2.1 as of 16:26

.

Note for other readers. This monitor was designed and built and software written by Dutch man Rudd Boer. All I did was take his instructions, build it, then produce a set of documentation to my own enhanced standard so that anybody could follow the process. As per my normal standard, full 'Step by Step' instructions are included in my document with 'screen shots' as appropriate.

.

A small amount of soldering is required for less than half a dozen components. The SW is downloadable from the links included in the PDF. Thus this project can be built by anyone with a modicum of soldering & computer (installing / using software) skill.

.

EDIT: All the clickable links in my current PDF document have been tested and are still valid and working.

[St1ngr4y]

I know this thread is supposed to be about a DCC Monitor, but my recently acquired monitor has proved that a fault which I reported 3 or 4 years ago still exists.

 

In my earlier post on this thread, when I was talking about TT signals, I said this....

 

"After the two identical messages sent to either 222 or 223, there were another one or two messages sent to address 220. After experimentation with several other signals, I discovered that the address used for this extra message seems to be the next lower unused even address !!!!!!"

 

I now realise that this has exposed a fault whereby signals with an address exactly divisible by four were incorrectly receiving messages meant for other signals. The "temporary" solution at the time was to re-address all of my signals which had addresses excatly divisible by 4, which I did. The reason I used the phrase "next lower unused even address" was because that is how it appeared i.e it was searching for an unused address. But this isn't the case - it is actually going to the next address lower than the current signal which is a multiple of 4.

 

So, come on HRMS - please explain why when a signal is switched from a program, an extra message is sent to the next lower address which is an exact multiple of 4.

 

Ray

[St1ngr4y]

@Chrissaf

 

However what if you created a RM Group with only the loco(s) you want to monitor in it (rather than the full loco roster). With this dummy group selected in RM, then maybe only these restricted Group listed loco packets will be sent to track. If this idea works, then this will be the same as a filter that selects specific loco DCC addresses.

 

That sounds like a great suggestion, Chris - I'll give that a go tomorrow and will report back.

 

Many thanks

 

Ray

[St1ngr4y]

@Chrissaf

 

Hi Chris,

 

I gave your idea a go with some success, but I encountered something I hadn't expected in the process....

 

I loaded up RM and the DCC Monitor, which started displaying messages for all locos. In RM, I opened up the locos definitions window, and I chose a loco whose address was 0005. It is a Class A1 60130 Kestrel with a TTS decoder onboard. I added a new group called "Testing" while having this loco open, then I saved the details and exited the loco definition window. I checked the monitor - it was still pouring out messages for all locos. Then from the dropdown list of loco groups, I selected "Testing" and the loco list changed to show only loco 0005. However, the monitor was still pouring out loads of messages for all locos. So, I unloaded RM. To my surprise, the monitor was still displaying messages for all locos.

 

I waited a minute or so in case it was some sort of buffering delay, but no they were still displaying. So I reloaded RM. The "Testing" group and the single loco 0005 were still in force, but all of the messages were still pouring out on the monitor display. I unloaded RM again - the messages were still there. 

 

Then I took the sledgehammer approach and reset the Elite. The messages stopped immediately. Next, I reloaded RM, and now, the loco messages were limited to only loco 0005. 

 

At the end of that session of RM, those messages for loco 0005 were still being displayed in the group shown below every couple of seconds......

 

/media/tinymce_upload/1a08efc532219794b416b8dbfe213182.png

 

This looks to me as if the Elite is sending these messages by itself, even when RM isn't running. Is this possible?

 

Ray

[96RAF]

Ray I believe NMRA says for a controller to send the last live stream until something else is commanded whereupon that new data is sent.

Rob