Menu
▾
▴
#494 Problems to reach loco-functions higher than F8 with Intellibox2
Hi all, I figured out that using an Intellibox2 on the locoNet and controlling locos via SmartphoneApp (Android or Apple) - JMRI-LocoBufferUSB (HDL) – LocoNet will last in the problem that loco functions beyond F8 are not reachable at all. If I press a key above F8 on the Intellibox itself it works fine. A short look at the LocoNet shows traffic when touching a function higher than F8 at my Smartphone using JMRI. Each function lower or equal to F8 works fine on both ways. So it seems to be a translation error or a protocol failure maybe. I already addressed that issue at Uhlenbrock as well, maybe JMRI could also take care of that problem? Thanks a lot for your effort in advance.
I think that we will need more information to proceed.
Can a JMRI throttle control functions above F8 when using Intellibox2? If so, then I would expect the problem is in the interface between the smartphone app and JMRI.
If not, then I suspect that the problem is between JMRI and the Intellibox. In this case, I would guess that the Intellibox2 may require different LocoNet messaging than is used by Digitrax command stations.
Regards,
B. Milhaupt
Hi B.
the app Engine Driver as well as the regular throttle at the panelpro showing the same effect. Any try to address functions over F8 is not working. It seems that the intelliboxII expects a slot-adressing-message instead of direct dcc-adress commands over loconet. Functions up to F8 are translated by the intelliox internally. Using a commercial software functions up to F28 can be addressed. So I guess the solution will be to change the loconet commands sent by JMRI. If a slot-addressing is used it should work.
rgds
M. Meeh
M.,
If I understand correctly, you believe that the code for mobile decoder "function" control in JMRI does not provide the correct Intellibox-specific messages for function numbers greater than 8. Apparantly, Intellibox-II does not accept the message Digitrax defines as "send this NMRA packet to the DCC track signal".
If this is a correct summary of the problem, then resolving this requires specific information on the correct messages to be used, along with a developer who has sufficient understanding of JMRI's mechanisms for controlling and monitoring mobile decoder "function"s.
Regards,
B. Milhaupt
B.
that's correct.
I already called Uhlenbrock Hotline, they claimed that they stringently keep on loconet specification. As I'm not an expert in loconet codes I just can repead it. However - the current version of digitrax DCS 100 does accept the JMRI-sent loconet codes up to function F28. Maybe Uhlenbrock is not supported with fully loconet functionality from digitrax as its role as franchisee? As many Intelliboxes are already in use, I would appreciate if you could forward this item to a JMRI developer. I guess the adoptation in JMRI is less effort and more constructive instead of asking Uhlenbrock fitting its intellibox.
If you have any questions don't hesitate to contacte me. Thanks.
rgds
M. Meeh
M.,
I've embedded some comments below.
At 03:59 PM 11/5/2014, you wrote:
Presumably this means that they have implemented the entire LocoNet
specification, including the LocoNet message for sending NMRA packets
to the DCC track signal.
I have heard that Uhlenbrock uses some LocoNet messages which
Digitrax apparantly does not use. At least some of these messages
are ones which relate specifically to the Uhlenbrock system
design. Because the Digitrax system design is different, Digitrax
apparantly does not use those specific LocoNet messages.
I agree. My own experience includes using an old DCS100 which has a
"bug" where F5 thru F8 do not work correctly, as well as a more
recent DCS100 where F0 thru F28 work correctly.
It is quite possible that Uhlenbrock hardware does not implement all
of the LocoNet messages. In other words, Uhlenbrock hardware might
not pay attention to the LocoNet message for sending NMRA packets to
the DCC track signal. But I would think that the Uhlenbrock support
people would know this.
FYI, I am a JMRI developer, and I primarily work on LocoNet-related
JMRI code. I happened to notice your post on the bugs list, and
posted some of my thoughts on the problem. I know that there are
other JMRI developers who have some knowledge of the Uhlenbrock
products, so I will bring this issue to the attention to the other
JMRI developers.
The JMRI development team is a bunch of people who happen to think
that JMRI is useful. Most developers have specific areas of
interest, usually for features that they actively use or want to
improve or add, so most JMRI developers will contribute primarily in
their areas of interest.
My own area of primary interest is primarily in LocoNet
functionality, so that is why I replied to your bug report. And it
is why I will be interested to see how this issue is resolved.
Do you have any JMRI LocoNet Monitor log files which show the LocoNet
traffic when you attempt to control any function above F8? If you
could provide a short log, it could be helpful, especially if the log
includes the "raw data". It is possible that the Uhlenbrock command
station is returning an error or status message when JMRI sends the
LocoNet F8-F28 control message, and we may be able to understand the
problem from such a reply, if there is one.
Regards,
B. Milhaupt
JMRI is sending the right messages for a Digitrax command station. The problem is that the Uhlenbrock command station is looking for something else. There's nothing JMRI can do to figure out that something else; you're going to have to figure that out somehow. Once we know what to send, exactly what to send, we can put it in the code.
Perhaps Uhlenbrock will tell you what messages is needs to receive? (Details are important)
Or perhaps you can get a trace of some other (not JMRI) device telling the Uhlenbrock command station those right sequences.
Thanks both of you guys for your detailed answers. Yes, I can support you with logfiles, but I need about 4 more weeks for that as I will be on a business trip. Do you have an mail addess or shall I post the files right here?
thanks, rgds
M.Meeh
Hi,
faster than I'd expected I was able to get some logs.
The "Intellibox II.txt" shows acquiring, setting all functions starting with F0 up to F28 and dispatching a loco on the Intellibox 2 directly. JMRI was connected to it via USB. Unfortunately some other actions on loconet were captured. The second step was to use the JMRI Throttle and repeat the entire set of operations. It is captured in file "JMRI Handregler.txt". As it was hard for me to reproduce especially the operation of F9 to F28, I repeated that once again using the internal Intellibox throttle.
It seems to be a JMRI bug as the traincontroller is able to reach functions over F8. In that case the loconet orders were exactly the same like using the intellibox throttle.
Thanks for your effort!
rgds,
M. Meeh
The traces of what JMRI does don't tell us anything we don't know.
The trace of the Intellibox provides what we're looking for:
Unable to parse command.
contents: A3 09 01 54
Unable to parse command.
contents: A3 09 00 55
...
Unable to parse command.
contents: A3 09 00 55
Unable to parse command.
contents: D4 20 09 08 01 0B
Unable to parse command.
contents: D4 20 09 08 02 08
Unable to parse command.
...
Unable to parse command.
contents: D4 20 09 05 00 07
These are non-standard LocoNet messages that the Intellibox is sending and expecting.
The A3 messages are for the low functions, as shown in the F9 - F12 file.
The D4 20 messages are shown in the F13 - F20 and F21 - F28 files to be for the high functions F21 to F28. The last message in each file seems to be out of the same pattern as the rest, probably because the high bit in LocoNet bytes is reserved.
So this is probably enough to code this up.
Bob M, do you want to do this?
I think that jmrix/loconet//uhlenbrock/UhlenbrockLnThrottleManager.java is already in use for Intellibox connections, though it would be good to confirm that. If so, that's the place to create a new kind of LocoNetThrottle subclass that reimplements the sendFunctionGroup3() method to send A3 messages, and sendFunctionGroup4() & sendFunctionGroup5() to send the D4 20 messages.
I believe that the functionality implied by M.'s log files should only be implemented across some of the Uhlenbrock command stations - not all of them. I found an English-language flyer for the Intellibox-II on the Uhlenbrock web site. A statement from that flyer, included below, leads me to believe that these unexpected LocoNet messages may be specific to the Intellibox-II, and not to other Uhlenbrock command stations.
From the flyer: "The speed indication is not only in speed steps and per
cent, but now also in km/h. Up to 32768 Special functions
for each locomotive can be controlled."
I will try to e-mail Uhlenbrock (in English) to find out the applicability of these messages to other products which use the Uhlenbrock portions of JMRI code.
(In the meantime, I will attempt to reverse-engineer the log files M. has provided and update the LocoNet Monitor code to provide a more meaningful display of the Intellibox-II function control messages.)
I have updated JMRI's LocoNet Monitor to decode the Intellibox-II mobile function decoder messages.
M., can you download the development relesase with these fixes, and check to see that LocoNet Monitor properly decodes F9 thru F28 when you get a chance? The JMRI "development" version with the fixes can be found at:
http://builds.jmri.org/jenkins/job/Development/job/Packages/1529/
Hi Bob,
attached you'll find new logs. I checked it with loco 3 (short address) and loco 500 (long address). It seems to be fine, isn't it?
Matthias Meeh
Matthias, the logs you have provided show the result I expected.
Hi Bob,
I operated the internal throttle of the IntelliboxII to get the logfiles above. But I haven't figured out yet the right settings to use the JMRI throttle with your new functionality. I tried the settings below:
1. System manufacturer => Digitrax, System connection => LocoNet LocoBuffer-USB, Settings => Command station type intellibox
2. System manufacturer => Uhlenbrock, System connection => Uhlenbrock LocoNet Implementation, Command station type => Intellibox.
Both cases are still transmitting the "old" command types fitting for DCS100 but not like depicted in the logfiles. Can you see what is wrong? Did I use bad settings?
Thank you,
Matthias
The <only> change I have made so far is to LocoNet Monitor. I have not made any changes to way that JMRI tries to control mobile decoder functions.
I will not change JMRI mobile decoder function control until I know which Uhlenbrock command stations use the old-style mobile decoder function control messaging and which ones use the "new" mobile decoder function control messaging.
Hi
if you need any help for translation to corresponde with Uhlenbrock or more logfiles please let me know.
rgds
M. Meeh
I understand, so I guess you gonna post a short message when you did it? Thanks. Matthias
Just noticed this thread as the same question was raised in the "Feature Requests" section.
The necessary changes are currently being implemented and will be available as of JMRI 3.11.1.
see https://sourceforge.net/p/jmri/feature-requests/554/