Restart of the Intellibox

rjversluis
Site Admin
Posts: 39054
Joined: 10.04.2006, 08:48
Location: Speyer, Germany
Contact:

Post by rjversluis » 03.11.2010, 11:38

If anyone is interested in an Uhlenbrock LocoNet interface:

http://forum.rocrail.net/viewtopic.php?t=1972

The price can be discussed.

Besra
Moderator
Posts: 3644
Joined: 10.08.2009, 17:54
Location: North Rhine-Westphalia, Germany

Post by Besra » 05.11.2010, 14:02

Hi Rob,

:oops: , actually I was. Already ordered and received one.

Well, if it proofs to stop unwanted resets of the Intellibox I'm willing to document this on the wiki, so you should find a customer soon :wink:

Best regards
Besra

Besra
Moderator
Posts: 3644
Joined: 10.08.2009, 17:54
Location: North Rhine-Westphalia, Germany

Post by Besra » 05.11.2010, 22:55

Hi friends,

in brief, the first tests with the UB USB LocoNet Interface look very promising. At least everything seemingly works as it did before without any spontanous resets so far. I will keep you posted...

Best regards
Besra

Besra
Moderator
Posts: 3644
Joined: 10.08.2009, 17:54
Location: North Rhine-Westphalia, Germany

Post by Besra » 07.11.2010, 23:08

Hi,

still lookin' good but initialising locos after first power on takes so long... Lots of 'Master busy' messages. Most loco functions are restored, but some locos / functions are always missing. Perhaps there's not enough slots? Two times sensor activation was not recognised for reasons unknown -> Ghost trains... Needs thorough investigation... Still no spontaneous resets.

Best regards
Besra

rjversluis
Site Admin
Posts: 39054
Joined: 10.04.2006, 08:48
Location: Speyer, Germany
Contact:

Post by rjversluis » 08.11.2010, 07:43

Hi Besra,

did you setup the interface as described here:
http://wiki.rocrail.net/doku.php?id=int ... c-en#setup

Other settings are NOT supported.

rjversluis
Site Admin
Posts: 39054
Joined: 10.04.2006, 08:48
Location: Speyer, Germany
Contact:

Post by rjversluis » 08.11.2010, 07:47

Hi Besra,

the Uhlenbrock LocoBuffer does not provide hardware handshake like other LocoBuffers do...
A better choice, if not DIY, would be the RR-CirKits LocoBuffer-USB.

Besra
Moderator
Posts: 3644
Joined: 10.08.2009, 17:54
Location: North Rhine-Westphalia, Germany

Post by Besra » 08.11.2010, 16:18

Hi Rob,

thanks for having an eye on me :wink:
You wrote:did you setup the interface as described
Yes, I did. In fact I experimented with all speeds available and also Direct Mode on/off. Seems to make no difference but I stay with 19200bps and Direct Mode on.

The attached traces were recorded during / after power on. Sometimes the trace reads something like

Code: Select all

Could not get slot for loco addr=XX. (un expected response 0x81...)
and very often

Code: Select all

lnreader lnmon    0241 Master is busy
lnreader OLocoNet 1179 Busy
Any ideas?

Best regards
Besra

rjversluis
Site Admin
Posts: 39054
Joined: 10.04.2006, 08:48
Location: Speyer, Germany
Contact:

Post by rjversluis » 08.11.2010, 17:16

Hi Besra,

I'm afraid that this is because of buffer overflows in the Uhli LB; It is just missing commands...

Not all commands in LocoNet respond with a packet and other packets may come in between.
I do not know why they did not implemented a hardware handshake to prevent buffer overflows.

Use a MGV85 or the one of RR-CirKits.

Besra
Moderator
Posts: 3644
Joined: 10.08.2009, 17:54
Location: North Rhine-Westphalia, Germany

Post by Besra » 08.11.2010, 17:33

Hi Rob,

visiting the UB website I found a new driver package from July for the interface (possibly new as I'm not aware of the current version). The Release Notes contain the following:
Corrected a problem where an IO reqest would sometimes return a busy status to user mode, instead the queue is restarted if necessary before adding an IO request to the queue
I will give it a try...

Best regards
Besra

Besra
Moderator
Posts: 3644
Joined: 10.08.2009, 17:54
Location: North Rhine-Westphalia, Germany

Post by Besra » 08.11.2010, 19:28

Hi,

with the new driver the UB USB-LocoNet Interface identifies as "Silicon Laboratories CP210x USB to UART Bridge". Driver version is 6.1. It behaves very different from the one the interface was shipped with (from 2008 :cry: ). LocoNet Direct Mode (tested with 19200 only) is a no go! Even initialising the switches went totally wrong. With the Direct Mode switched off it's OK. Still sometimes a feedback report is dropped. The 'Master is busy' during loco initialisation is still present :evil: .

Could the busy state possibly serve as a substitute for hardware flow control?

Best regards
Besra

rjversluis
Site Admin
Posts: 39054
Joined: 10.04.2006, 08:48
Location: Speyer, Germany
Contact:

Post by rjversluis » 08.11.2010, 19:41

Hi Besra,
Could the busy state possibly serve as a substitute for hardware flow control?
YesNo, could be maybe not.
The problem however is to figure out which packet(s) where not processed; It could be one or many... In case of many: Which one?

If Rocrail sends 2 packets and becomes a busy response, which packet did cause it? The first or the second?

Rorail can burst 100 packets very quick and could receive one or more busy responses...
Fuzzy logic or is it defined in the LocoNet specs?

Besra
Moderator
Posts: 3644
Joined: 10.08.2009, 17:54
Location: North Rhine-Westphalia, Germany

Post by Besra » 08.11.2010, 22:13

Hi Rob,
You wrote:YesNo, could be maybe not.
:D :D :D Yes, I know, it's no fun if everything is so vague.

I am sorry I do not have the deep insight into communication protocols and related issues. I. e. my statements may be stupid concerning this matter.

From the brief documentation of the UB thingi I conclude there is in fact a flow control:
UB wrote:If the LocoNet direct mode is active then each byte is sent directly to the LocoNet without any flow control by
the interface.
I. e. without direct mode flow control is enabled...
UB wrote:Send message over USB and then wait to receive the sent message again, before a new message is sent.
Process other messages received during the waiting period.
If the echo is missing the command was not (yet) processed... be patient...
You wrote:Rorail can burst 100 packets very quick and could receive one or more busy responses...
Reading the above statement I think this must not happen. The intended sequence is: Message -> Echo? -> Sit down, relax, do other things -> Echo! -> Next Message.

Therefore the 'Master is busy' should be an error message telling us something went wrong / something is or may be lost.

Well, some unqualified thoughts :wink:

Best regards
Besra

rjversluis
Site Admin
Posts: 39054
Joined: 10.04.2006, 08:48
Location: Speyer, Germany
Contact:

Post by rjversluis » 09.11.2010, 07:03

Hi Besra,

this is no handshake for me and doubles the traffic between PC and UB-LB.
And if so, it needs a special LocoNet sublib.

Besra
Moderator
Posts: 3644
Joined: 10.08.2009, 17:54
Location: North Rhine-Westphalia, Germany

Post by Besra » 09.11.2010, 08:28

Hi Rob,
You wrote:... doubles the traffic between PC and UB-LB.
Yes, it does:
UB wrote:Note: Sending messages without flow control, can lead to errors in communication between PC and
LocoNet. When using a Baud rate of 115200 Baud this flow control cannot decrease communication speed.
The first sentence is more clear in the German version of the documentation:
"Note: Sending messages without analysing the echo ("Rückempfang") can lead to errors in communication between PC and LocoNet."
You wrote:And if so, it needs a special LocoNet sublib.
Yes, I'm afraid that's true.
The Sublib, however, is needed for the whole UB USB family (USB-LocoNet Interface, IB-Com, IB-Basic, IB-2) as they all share the same communication protocol, don't they?

May I kindly ask you to implement it in Rocrail? I will do everything in my power to support you!

Best regards
Besra

rjversluis
Site Admin
Posts: 39054
Joined: 10.04.2006, 08:48
Location: Speyer, Germany
Contact:

Post by rjversluis » 09.11.2010, 09:00

Hi Besra,
May I kindly ask you to implement it in Rocrail? I will do everything in my power to support you!
Yes.
But you must document it as feature request at LP.

Post Reply

Return to “P50 and P50x”