RDM discovery fails when device responds to DISC_UN_MUTE

[Frederik Nord]

Hi,

I am experimenting with the Arduino RDM library [1] together with a DMXUSB Pro with RDM Firmware. I have noticed that when the device responds to the DISC_UN_MUTE message, the whole discovery process hangs. Is this a known issue or am I interpreting the specs wrong? When I remove the response to UN_MUTE commands, the discovery works as expected.

Regards

Felicitus

[1] http://www.mathertel.de/Arduino/DMXSerial2.aspx

[Frederik Nord]

I forgot to mention that discovery works fine when the device responds to UN_MUTE command and using the windows RDM tool from ENTTEC.

Regards

Felicitus

[Simon Newton]

What version of the Enttec firmware are you running on the USB Pro ?

Simon

> --
> The Open Lighting Group: open-l...@googlegroups.com, #openlighting
> (irc.freenode.org)
> To unsubscribe from this group, send email to
> open-lightin...@googlegroups.com
> For more options, visit https://groups.google.com/groups/opt_out?hl=en

[Frederik Nord]

Am Sonntag, 24. November 2013 18:24:23 UTC+1 schrieb Simon Newton:

What version of the Enttec firmware are you running on the USB Pro ?

Version 2.4. I haven't tried 2.3 so far, would you suggest I should give that a go?

As I mentioned, it works fine with Version 2.4 on Windows using the ENTTEC RDM tool.

Regards

Felicitus

[Matthias Hertel]

Frederik sent me this bug description some days ago too.

First I like to clarify if there has to be a response on not.

In the specs (page 35+36) there is a defined response to MUTE and UN_MUTE.

My setup did work without responses as well a with responses.

Maybe it depends on the algorithm you use to discover devices.

Do you have a dump of the conversation so I can have a look at it ?

  

[Frederik Nord]

First I like to clarify if there has to be a response on not.

In the specs (page 35+36) there is a defined response to MUTE and UN_MUTE.

I have to double-check if omitting a response to UN_MUTE works with the ENTTEC RDM Test tool.

My setup did work without responses as well a with responses.

Does your setup involve OLA?

 

Maybe it depends on the algorithm you use to discover devices.

I'm not sure if the algorithm of OLA can be changed without changing the code; however, OLA just hangs (and I have to restart it) when it receives a response to DISC_UN_MUTE. It doesn't even attempt to start discovery if a packet is received.

 

Do you have a dump of the conversation so I can have a look at it ?

Will do so later.

Regards

Felicitus 

[Simon Newton]

On Tue, Nov 26, 2013 at 9:30 AM, Matthias Hertel <math...@gmail.com> wrote:
> Frederik sent me this bug description some days ago too.
>
> First I like to clarify if there has to be a response on not.
> In the specs (page 35+36) there is a defined response to MUTE and UN_MUTE.

If the controller sends a well formed non-broadcast MUTE / UNMUTE the
device must respond with an ACK (and change it's mute state).

Some controllers may ignore the response and everything may continue
to work. Some controllers will report the failed-to-mute condition to
the user.

> My setup did work without responses as well a with responses.
> Maybe it depends on the algorithm you use to discover devices.
>
> Do you have a dump of the conversation so I can have a look at it ?

I'm interested in both the RDM traffic and and olad logs. Do you have
a sniffer you can attach to the line?

Simon

[Frederik Nord]

> Do you have a dump of the conversation so I can have a look at it ?

I'm interested in both the RDM traffic and and olad logs. Do you have
a sniffer you can attach to the line?

I have attached a log of the OLA rdm sniffer, the daemon (truncated one for the working version, full for the non-working version) and  the data from the Saleae Logic Analyzer (Version 1.1.18 beta, 1.1.15 would crash when saving files). Non-working means that I have commented in the response to DISC_UN_MUTE on the target device, working means that the response to DISC_UN_MUTE is commented out on the target device.

Unfortunately, I don't have any other RDM devices to cross-test with.

Btw, if you are interested in which device I'm developing: http://log.raumzeitlabor.de/image/51238310840

Regards

Felicitus

[Simon Newton]

Take a look at Nonworking.logicdata . After the DUB your device isn't
responding.

The same thing is visible in the rdm sniifer logs. Olad sends a DUB
and nothing responds.

Simon



>
> Regards
> Felicitus

[Frederik Nord]

Take a look at Nonworking.logicdata . After the DUB your device isn't
responding.

The same thing is visible in the rdm sniifer logs. Olad sends a DUB
and nothing responds.

Thank you for pointing this out. To me, it looked as if OLA hangs (which it actually does until I re-start it). Is there a timeout if a device doesn't respond? It sits there just forever. RDM protocol debugging is a bit PITA for me, especially beause no RDM analyzer plugin for logic exists :(

I will take a closer look at the DMXSerial2 library, I'm pretty confident that I can fix the bug soon.

Regards

Felicitus

[Simon Newton]

What do you mean by "OLA Hangs". From the logs it completes discovery,
but doesn't find anything:

EnttecUsbProWidget.cpp:322: Un-muting all devices
DiscoveryAgent.cpp:231: DUB 0000:00000000 - ffff:ffffffff, attempt 1,
uids found: 0, failures 0, corrupted 0
EnttecUsbProWidget.cpp:341: Sending DUB packet: 0000:00000000 - ffff:ffffffff
EnttecUsbProWidget.cpp:603: Enttec Pro discovery complete:

Simon

[Frederik Nord]

What do you mean by "OLA Hangs". From the logs it completes discovery,
but doesn't find anything: 

The command ola_rdm_discover hangs until I hit ctrl+c. Additionally, when I hit "Full Discovery" in the web UI, it also hangs. I have to kill olad and restart it, even tough it claims that the discovery may be complete.

Regards

Felicitus

[Simon Newton]

Hmm, that's a bug then. I'll try to reproduce it. Are you using the git version?


Simon

[Frederik Nord]

Hmm, that's a bug then. I'll try to reproduce it. Are you using the git version?

I can't tell right now, but it's either 0.8.32-1-wheezy1 or git from a few days ago. When I'm back in the lab I can do further tests if you wish.

The hang only happens in my non-working scenario; when no device is attached to the bus OR the device doesn't answer the DISC_UN_MUTE command, ola_rdm_discover returns near instant with the expected behavior. Maybe OLA gets confused by the 2 long breaks in my non-working logic dump; it could interpret those as BREAK, waiting for a MAB, which never happens.

Is there some kind of timeout already implemented?

Regards

Felicitus

[Simon Newton]

There is a timeout in the USB device itself, only with v2.4 of the
firmware though.

[Simon Newton]

On Wed, Nov 27, 2013 at 6:35 PM, Simon Newton <nom...@gmail.com> wrote:
> On Wed, Nov 27, 2013 at 6:34 PM, Frederik Nord <timoa...@gmail.com> wrote:
>>> Hmm, that's a bug then. I'll try to reproduce it. Are you using the git
>>> version?
>>
>>
>> I can't tell right now, but it's either 0.8.32-1-wheezy1 or git from a few
>> days ago. When I'm back in the lab I can do further tests if you wish.
>>
>> The hang only happens in my non-working scenario; when no device is attached
>> to the bus OR the device doesn't answer the DISC_UN_MUTE command,
>> ola_rdm_discover returns near instant with the expected behavior. Maybe OLA
>> gets confused by the 2 long breaks in my non-working logic dump; it could
>> interpret those as BREAK, waiting for a MAB, which never happens.
>>
>> Is there some kind of timeout already implemented?
>
> There is a timeout in the USB device itself, only with v2.4 of the
> firmware though.

Are you absolutely sure you're not using 2.3? I haven't been able to
reproduce the issue.

[Frederik Nord]

Are you absolutely sure you're not using 2.3?  I haven't been able to
reproduce the issue.

Yes, I'm using 2.4. I have now created a dump in combination with the ENTTEC RDM Software where the device actually sends a response to DISC_UN_MUTE. I am a bit puzzled, especially because I cannot interpret the logic dump (I simply cannot find the RDM start code in the dump). That dump is attached, so there must be any difference between OLA and the ENTTEC RDM software. The dump is attached.

On the device side, I never receive the E120_DISC_UNIQUE_BRANCH command from OLA when it answers with DISC_UN_MUTE. Could this be a timing issue, where ola tries to send E120_DISC_UNIQUE_BRANCH before it receives the response to E120_DISC_UN_MUTE?

Regards

Felicitus

[Simon Newton]

On Thu, Nov 28, 2013 at 12:23 PM, Frederik Nord <timoa...@gmail.com> wrote:
>> Are you absolutely sure you're not using 2.3? I haven't been able to
>> reproduce the issue.
>>
>
> Yes, I'm using 2.4. I have now created a dump in combination with the ENTTEC
> RDM Software where the device actually sends a response to DISC_UN_MUTE. I
> am a bit puzzled, especially because I cannot interpret the logic dump (I
> simply cannot find the RDM start code in the dump). That dump is attached,
> so there must be any difference between OLA and the ENTTEC RDM software. The
> dump is attached.

Why are you responding to a broadcast UN_MUTE? A responder should
never respond to messages sent to the broadcast UID.

>
> On the device side, I never receive the E120_DISC_UNIQUE_BRANCH command from
> OLA when it answers with DISC_UN_MUTE. Could this be a timing issue, where
> ola tries to send E120_DISC_UNIQUE_BRANCH before it receives the response to
> E120_DISC_UN_MUTE?

I suspect what's happening is that the DUB from OLA is colliding with
the response from your device.

[Peter Newman]

For the benefit of future Googlers, currently (13/01/2014) the code on the libraries website still isn't to spec and doesn't work with OLA:
http://www.mathertel.de/Arduino/DMXSerial2.aspx

However there is a more up to date version on Github by the same author that does work with OLA and is more compliant with the RDM specs:
https://github.com/mathertel/DmxSerial2/

I'd obviously recommend using the latter for now. Hopefully Matthias will get a chance to update his website with the working library at some point. But I can confirm the latest code "just works" with an Enttec USB Pro with the RDM firmware v2.4 loaded.