Digikeijs DR5088RC - and direction sensing

[jamespetts]

I have spent some time with a small test layout that I constructed for the purposes of testing automation systems trying to work out the unfortunately undocumented features of the Dijikeijs DR5088RC, especially relating to RailCom and direction sensing. I have now managed to work out how this works and how to use this information in both Traincontroller and (to some extent) JMRI. Since there is no other information available that I can find on how to do this, I thought that it would be helpful to post it here.

 

For reference, I am using the DR5088RC with the DR5000 command station and using the latest firmware of both at the time of this post, which is 1.4.0 for the DR5088RC and 1.5.0 of the DR5000. I recommend upgrading to the latest firmware if using an older version.

 

How direction sensing works in the DR5088RC

 

The idea behind direction sensing is that the hardware can tell the command station or computer software (such as JMRI or Traincontroller) connected to the command station which way that a locomotive is facing in a block. This is useful, especially with diesel locomotives, whose direction can be difficult to work out without turning on the lights or trying to move it.

 

The way in which this is actually implemented in the hardware is rather a hack. Both the DR5088RC's configuration application and the DR5000's configuration have an option for "RailCom sense direction" in the "LocoNet" dialogue. These must be set to the same setting on both DR5088RC and DR5000 for this feature to work.

There are three possible settings of this. The first is "off". The second is "in Loco Address"; and the third is "in Block Address". These settings determine whether and the means by which the detected direction of the locomotive is communicated through the LocoNet protocol.

The "in Block Address" setting means that, if the locomotive is facing in one direction, the block address in which it is detected will be increased by 2048 when reporting. So, for example, if the locomotive is in block 7 and facing <, it will be reported as present at address 7. If the locomotive is in block 7 and facing >, it will be reported as present in address 7+2048=2055. This method does not work with Traincontroller. I am not sure whether it might be more useful for JMRI.

The "In Loco Address" setting means that, if the locomotive is facing in one direction, the reported locomotive address will be reduced by 4096, and, if the locomotive is facing in the other direction, it will report the correct number. (I have not tested this, but I suspect that the opposite behaviour occurs with locomotives whose base address is <4096). So, if locomotive 4715 is present in block 7 facing <, it will report the address 4715; however, if it is present in block 7 facing >, it will report address 4715-4096=619. This method does work with Traincontroller.

 

Configuring direction sensing with Traincontroller

 

I assume for these purposes that the block occupancy detection has already been configured, as this is a separate configuration setting (this is quite simple in any event).

 

In the "Train Identification" tab of the block properties, use the "LocoNet - Bleucher GMB16X" as the "Digital System", use the number assigned to the whole DR5088RC unit as the "address" (if you only have 1 unit, it will be numbered 1) and use the block number as the "input". So, for block 7, the address would be 1 and the input 7; for block 15, 1, 15, etc. If you have more than one DR5088RC, you would have to use multiple addresses (and the units must be preconfigured using the USB cable first - do not forget to unplug the command station from power before connecting the USB cable to the DR5088RC to avoid equipment damage).

 

Edit: The address is slightly more complex than it needs to be, and my original advice above is incorrect. The correct position is as follows: the address set in the DR5088 for each individual feedback is just a single number. However, this needs to be broken down into two numbers for TrainController to emulate the Bleucher GMB16X. Do this by dividing the numbers into groups of 16. So, for feedback nos. 1 - 16, enter these in TrainController as address 1, inputs 1 - 16. For feedback nos. 17 - 32, enter these in TrainController as address 2, inputs 1 - 16, and so forth. There seems to be an upper limit to this, as I could not get this working for high numbers (519 set in the DR5088RC) even though this is permissible in the DR5088RC, although I might have got the mathematics for this wrong. Note that, if one uses the global RailCom sensor as just another feedback section, as is possible (and probably sensible, since I am not aware of any reliable use of global RailCom, although if someone has found one, I should be very interested), the addresses in TrainController will not correspond to physical units.

 

Two things to note: first of all, the feedback address does not need to be the same as the occupancy (in TrainController language, "contact indicator") address. Thus, one can have (as I do) a contact indicator address of 519 and a feedback address of 1. Secondly, unlike the occupancy indicator addresses, the feedback addresses are totally independent from the LocoNet addressing scheme. You do not need a valid or unique LocoNet address as a feedback address, just as long as it is unique among the other feedback addresses.

 

Finally, there is an anomaly in the current version of the DR5088 configuration utility, where the labels for the columns "feedback" and "block" are inverted in the UI used for setting addresses.

 

Configuring direction sensing with JMRI

 

I am not aware of any automatic way of doing this, and I suspect that this would have to be scripted. There is very little built-in RailCom functionality in JMRI, although the scripts can make extensive use of RailCom data (I have not tested whether any functions other than locomotive ID and direction sensing work with the DR5088RC, however).

 

One final note about the DR5088RC and RailCom

 

In the DR5088's configuration utility, there is a setting called "RailCom Report". By default, this is set to OPC_MULTI_SENSE Standard. Leave it there: I have found that this does not work at all when this is changed to any other setting.

Edited October 10, 2019 by jamespetts
Correction relating to module addressing and addition regarding OPC_MULTI_SENSE standard

[WIMorrison]

Thanks for the information - I have been tryiong to follow it through but I am afraid that I can't and wonder if you could clarify? 

 

For direction in Block Address are you saying that if it in reverse then all you get is the block address (in your example 7) and when the loco is travelling forward the feedback will be 7+2048=2055? I think this is what you have said. My question is how does the programme know which loco this is referring to?

 

In the latter Loco Address case clearly the control programme will know which loco it is as it has the DCC address (in your case 4715) however the logic doesn't appear to work when the loco DCC address is less than 4096 as you end up with a negative number, which AFAIK isn't allowed.

 

if travelling forward then for Loco ID=15, I think you suggest it is simply 15 that is reported? In other words no direction information therefore the programme should interpret this is forward.

 

but in reverse 15 - 4096 = minus 4081 which suggests that the logic failed

 

Interestingly as I use iTrain rather than the programmes you mention I don't need to set up anything regarding the DR5088RC (iTrain doesn't care what feedbacks I use) and all I do is check a box to say that Railcom Polarity is available and it just works, however I always like to know how and why things work hence asking for the clarification

[jamespetts]

To answer your questions:

 

(1) the software will know the locomotive being referred to because the locomotive's ID will be returned as being present in one of the two addresses, in this example, either 7 or 2055, depending on the direction - so, for example, it will report (in JMRI) "4715 enters" and "4715 exits" in reporting address 7 or reporting address 2055, depending on the direction in which the locomotive is facing (using the standard JMRI reporter texts, you would need two of these for each block - one for each direction, each assigned to a different address); and

 

(2) I have not tested with a locomotive address of <4096 - what I infer probably happens is that the base address is used for one direction and an address with 4096 added to it is used for the other direction (so a locomotive with an ID of 15 would be 15 in one direction and 4111 in the other) - I assume that you are not actually getting negative numbers, as I do not imagine that these values are stored in signed integers (an integer underflow is another possibility, although this would give 61,324, which is also not a valid CV).

 

It is interesting to note that iTrain works automatically with this.

[fcwilt]

Hi,

 

What is going to happen when the modified address returned matches the normal address of another loco?

 

Frederick

[jamespetts]

Hi,

 

What is going to happen when the modified address returned matches the normal address of another loco?

 

Frederick

 

That is an interesting question. I have not tested this case - I assume that Traincontroller will not be able to tell them apart, so it is probably best to take care to prevent this sort of clash in setting one's decoder addresses.

[jamespetts]

I have just discovered that my original post contained an error regarding module addressing. After many hours of trial and error, I have worked out the correct method for module addressing, and have updated my instructions above. I have also added information regarding the correct setting for RailCom Rerpot.

[Marklin Norm]

On ‎25‎/‎08‎/‎2018 at 22:53, jamespetts said:

the address set in the DR5088 for each individual feedback is just a single number. However, this needs to be broken down into two numbers for TrainController to emulate the Bleucher GMB16X. Do this by dividing the numbers into groups of 16. So, for feedback nos. 1 - 16, enter these in TrainController as address 1, inputs 1 - 16. For feedback nos. 17 - 32, enter these in TrainController as address 2, inputs 1 - 16, and so forth.

 

I hope you are still monitoring this, as your posting was some time back. Could you please clarify;  the copy of TC that I have, for the Bleucher system it does not ask for "address" plus "input number". It asks for an address number and a block number.

And what does it mean by "block" number ?

It was easy with the S88 system, that has an address number (in other words the module number) plus an input number, corresponding to one of the 16 (or 8 in some cases) inputs or ports.

 

regards

Norm.

[jamespetts]

6 hours ago, Marklin Norm said:

 

I hope you are still monitoring this, as your posting was some time back. Could you please clarify;  the copy of TC that I have, for the Bleucher system it does not ask for "address" plus "input number". It asks for an address number and a block number.

And what does it mean by "block" number ?

It was easy with the S88 system, that has an address number (in other words the module number) plus an input number, corresponding to one of the 16 (or 8 in some cases) inputs or ports.

 

regards

Norm.

 

Can I ask what version that you have? Also, are you referring to the "train identification" or the "contact indicator" dialogue boxes?