|
Locked
Re: Update to JMRI 4.8 - CMRI Connection
Sorry to reply to my own, but I just had another thought. This may be a misunderstanding of the C/MRI protocol.
The NS (number of bytes of board configuration, e.g. ceiling(n_boards/4)) is sent as a raw integer, not an ASCII character. As such, it can have values that looks like protocol characters. In that case, a DLE (a.k.a. DL or 0x10) character is sent before that. When NS is 3, that¡¯s the case. It¡¯ll be sent as x10 0x03, i.e. DL 03. That¡¯s completely normal and correct AFAIK. Unfortunately, the C/MRI monitor doesn¡¯t understand that when decoding the message. So get lines like this: [41 49 58 00 00 10 03 A5 5A 09] Init ua=0 type=X DL=0 NS=16 CT: 3 a5 5a 9 That¡¯s the right raw data, but the wrong interpretation of it. I¡¯ll fix this. But, unfortunately, that means this isn¡¯t the cause of your problem. I¡¯m not sure what¡¯s going wrong there. Bob On Jul 26, 2017, at 12:26 AM, scott.rose@... [jmriusers] <jmriusers@...> wrote:-- Bob Jacobsen rgj1927@... |
|
Locked
Re: Decoder Pro output for Team Digital BLOC8D
The following is rearranged a bit to make it more readable.
On Jul 26, 2017, at 9:45 PM, Gerald Michels gjmichels53@... [jmriusers] <jmriusers@...> wrote:e.g. 11:24:32.359: [B2 42 50 5F] Sensor LS133 () is Hi. (BDL16 #9, DS5; So it seems to me that Decoder Pro is seeing the BLOC8D just fine.Agreed. I am curious about the text at the end of each line in parenthesesThe only thing that the LocoNet provides it the part in []. e.g. [B2 42 50 5F] called the raw data. The rest is JMRI trying to make it readable for you. Digitrax has used lots of ways to write addresses, depending on which Digitrax board was in use, so the part in () is trying to show those. That message could have been issued by channel 5 on a BDL16* set to #9; etc. I set the BLOC8D in this example with a beginning address of 200, so I wasLocoNet Sensor. Finally, the main reason for this whole exercise is to deliver blockIf you open the JMRI Sensor Table, you¡¯ll see entries for each of those under the LS numbers. They¡¯ll change as messages come in from the layout. You can use that in the various JMRI tools. Bob -- Bob Jacobsen rgj1927@... |
|
Locked
Re: Trouble with Virtual Signals
On Jul 26, 2017, at 6:50 PM, robert.zeolla@... [jmriusers] <jmriusers@...> wrote:You can do this, but it involves extra non-displaying SignalHeads. Roughly: 1) Define an internal / virtual head that is on the entrance to the furthest turnout. It¡¯ll show red if that¡¯s set against. (This isn¡¯t on the layout, though you might want to add it to a panel so you can see what¡¯s going on) 2) Now set up the real signal to (a) protect against the near turnout and (b) follow your signal from (1) as ¡°Distant¡±. That last part is important: ¡°Distant¡± means to be red when the far signal is red, not yellow when the far signal is red. It can become complicated, but this should always be able to handle what needs to be handled. Bob -- Bob Jacobsen rgj1927@... |
|
Locked
Re: Help with German Signals
We have a (partial) implementation of one set of German signals, see:
There¡¯s a comment on it that says "Missing aspect mapping, not finished.¡± so it probably needs a bit more work. I¡¯d be happy to help somebody with the needed knowledge set that up. What¡¯s there is enough to display the signals, but not quite enough for JMRI¡¯s automated signal logic to e.g. figure out which aspect has to appear before which other aspect. FOr more on that see and Bob On Jul 26, 2017, at 4:36 PM, Michael Piazza mpiazza2007@... [jmriusers] <jmriusers@...> wrote:-- Bob Jacobsen rgj1927@... |
Bob Jacobsen