Raspbery Pi, native DMX/RDM with RS-485 isolated break-out board

[Arjan van Vught]

Hi,

As suggested in another topic, herewith the details and the progress for my RPi project.

The RPi project consists of several subprojects :

*. RPi DMX512 Receiver (Slave / Analyzer) : Finished
            - See https://sites.google.com/site/rpidmx512/home

*. RPi acting as a "DMX USB Pro" device, phase 1 : "DMX" : Finished
            - OLA recognizes RPi as a "DMX USB Pro" device.
            - DMX Input / Output is working using the DMX512 Isolated break-out board. For details see : https://sites.google.com/site/rpidmx512/home/dmx512-isolated-break-out-board.

*. RPi RDM Isolated break-out board.
            - Just received a prototype PCB. Status : Work in progress.
            - Add photo's to website. Status : Not started

*. RPi acting as a "DMX USB Pro" device, phase 2 : "RDM"
            - Update the code using GPIO for data direction switch. Status : Not started
            - Add RDM capabilities. Status : Not started

*. Upgrade the "RPi DMX512 Receiver (Slave / Analyzer)" to a RDM responder. Status : Not started
         
All source code will be available here : https://github.com/vanvught/OpenDMX

Finally, I will try to get a fully assembled and low cost RPi RDM Isolated break-out board manufactured by a small company.


Cheers, Arjan

[Peter Newman]

Cool Arjan. A minor thing, it may be worth choosing a new project name, given the Open DMX exists, that may get rather confusing.

Have you considered implementing the Enttec USB Pro RDM sniffer commands, as used by our rdmpro_sniffer too? Then it provides another option and reduces how much of the interpretation code you need to write.

[Peter Stuge]

Arjan van Vught wrote:
> *. RPi DMX512 Receiver (Slave / Analyzer) : Finished
> - See https://sites.google.com/site/rpidmx512/home

> https://sites.google.com/site/rpidmx512/home/pl011-interrupt-routine
> https://github.com/vanvught/OpenDMX/blob/master/pl011_dmx512_fiq/firmware/main.c

The state machine looks a bit too rigid. I would suggest that you
also add timeouts in both BREAK and DATA to kick it back into IDLE.


//Peter

[Arjan van Vught]

Thanks Peter.

I will rename the project.

Yes, I am also considering implementing firmware version 3, the RDM sniffer firmware.

I have just finished the RPi RDM isolated break-out board. There might be a minor design flaw in the current design.
As GPIO01(data direction pin) is high at startup, the device is in send mode per default.
Wouldn't it better to have the device in receive mode at startup?

Op donderdag 12 februari 2015 01:19:36 UTC+1 schreef Peter Newman:

[Arjan van Vught]

Peter,

Thanks for your suggestion. However I am not eager to add timeouts in the receiving interrupt routine.

There is an interrupt for each received BREAK frame, and interrupts for each received DATA byte.
At the end of the DATA stream, the receive state goes into IDLE.

I am not sure where I need to add timeouts.

Thanks, Arjan

Op donderdag 12 februari 2015 06:29:13 UTC+1 schreef Peter Stuge:

[Arjan van Vught]

I have renamed the projects as follows:

• The GitHub project is now called "rpidmx512" : https://github.com/vanvught/rpidmx512
• The RPi DMX512 Analyzer/Slave project is now called "rpi_dmx_analyzer-slave" : https://github.com/vanvught/rpidmx512/tree/master/rpi_dmx_analyzer-slave
• The project for RPi acting as a "DMX USB Pro" device is called "rpi_dmx_usb_pro" : https://github.com/vanvught/rpidmx512/tree/master/rpi_dmx_usb_pro

Please note that the code for "rpi_dmx_usb_pro" is stable for DMX, but a lot of work needs to be done for RDM. When you connect a monitor to the Raspberry Pi, then it will give you some debug information. For details see https://github.com/vanvught/rpidmx512/blob/master/rpi_dmx_usb_pro/lib/monitor.c

The first pictures for the RPi RDM breakout board can be found here : https://sites.google.com/site/rpidmx512/raspberry-pi-rdm-controller/rdm-isolated-break-out-board

[Arjan van Vught]

Hi,

I am working on the RDM implementation for the Rpi USB Pro widget. It seems that my device is not properly recognized. There is no RDM request for ESTA Id: 0x7ff0.

Any idea what is missing for my code?

Many thanks in advance.

Arjan


plugins/usbpro/WidgetDetectorThread.cpp:210: Found potential USB Serial device at /dev/ttyUSB0
plugins/usbpro/WidgetDetectorThread.cpp:215: new descriptor @ 0x1b28250 for /dev/ttyUSB0
plugins/usbpro/WidgetDetectorThread.cpp:376: trying stage 0 for 0x1b28250
olad/PluginManager.cpp:108: Started Serial USB
plugins/usbpro/UsbProWidgetDetector.cpp:517: Detected USB Device: ESTA Id: 0x7ff0 (AvV), device Id: 1 (Raspberry Pi DMX USB Pro), serial: 0x0, f/w version: 2.4
plugins/usbpro/WidgetDetectorThread.cpp:307: Defaulting to a Usb Pro device
olad/DeviceManager.cpp:105: Installed device: AvV - Raspberry Pi DMX USB Pro:5-00000000
plugins/usbpro/EnttecUsbProWidget.cpp:292: Incremental discovery triggered
plugins/usbpro/EnttecUsbProWidget.cpp:325: Un-muting all devices
olad/PortManager.cpp:119: Patched 5-00000000-O-0 to universe 1
olad/RDMHTTPModule.cpp:678: Adding UID 7a70:ffffff00 to resolution queue
olad/RDMHTTPModule.cpp:678: Adding UID 7a70:ffffff01 to resolution queue
olad/RDMHTTPModule.cpp:678: Adding UID 7a70:ffffff02 to resolution queue
olad/RDMHTTPModule.cpp:678: Adding UID 7a70:ffffff03 to resolution queue
olad/RDMHTTPModule.cpp:678: Adding UID 7a70:ffffff04 to resolution queue
olad/RDMHTTPModule.cpp:678: Adding UID 7a70:ffffff05 to resolution queue
olad/RDMHTTPModule.cpp:736: sending manufacturer request for 7a70:ffffff00
olad/Universe.cpp:437: Universe 1, RDM request to 7a70:ffffff00, SD: 0, CC 20, TN 0, PID 0x81, PDL: 0
olad/RDMHTTPModule.cpp:748: sending device request for 7a70:ffffff00
olad/Universe.cpp:437: Universe 1, RDM request to 7a70:ffffff00, SD: 0, CC 20, TN 0, PID 0x82, PDL: 0
olad/RDMHTTPModule.cpp:736: sending manufacturer request for 7a70:ffffff01
olad/Universe.cpp:437: Universe 1, RDM request to 7a70:ffffff01, SD: 0, CC 20, TN 0, PID 0x81, PDL: 0
olad/RDMHTTPModule.cpp:748: sending device request for 7a70:ffffff01
olad/Universe.cpp:437: Universe 1, RDM request to 7a70:ffffff01, SD: 0, CC 20, TN 0, PID 0x82, PDL: 0
olad/RDMHTTPModule.cpp:736: sending manufacturer request for 7a70:ffffff02
olad/Universe.cpp:437: Universe 1, RDM request to 7a70:ffffff02, SD: 0, CC 20, TN 0, PID 0x81, PDL: 0
olad/RDMHTTPModule.cpp:748: sending device request for 7a70:ffffff02
olad/Universe.cpp:437: Universe 1, RDM request to 7a70:ffffff02, SD: 0, CC 20, TN 0, PID 0x82, PDL: 0
olad/RDMHTTPModule.cpp:736: sending manufacturer request for 7a70:ffffff03
olad/Universe.cpp:437: Universe 1, RDM request to 7a70:ffffff03, SD: 0, CC 20, TN 0, PID 0x81, PDL: 0
olad/RDMHTTPModule.cpp:748: sending device request for 7a70:ffffff03
olad/Universe.cpp:437: Universe 1, RDM request to 7a70:ffffff03, SD: 0, CC 20, TN 0, PID 0x82, PDL: 0
olad/RDMHTTPModule.cpp:736: sending manufacturer request for 7a70:ffffff04
olad/Universe.cpp:437: Universe 1, RDM request to 7a70:ffffff04, SD: 0, CC 20, TN 0, PID 0x81, PDL: 0
olad/RDMHTTPModule.cpp:748: sending device request for 7a70:ffffff04
olad/Universe.cpp:437: Universe 1, RDM request to 7a70:ffffff04, SD: 0, CC 20, TN 0, PID 0x82, PDL: 0
olad/RDMHTTPModule.cpp:736: sending manufacturer request for 7a70:ffffff05
olad/Universe.cpp:437: Universe 1, RDM request to 7a70:ffffff05, SD: 0, CC 20, TN 0, PID 0x81, PDL: 0
olad/RDMHTTPModule.cpp:748: sending device request for 7a70:ffffff05
olad/Universe.cpp:437: Universe 1, RDM request to 7a70:ffffff05, SD: 0, CC 20, TN 0, PID 0x82, PDL: 0

[Peter Newman]

You may want to implement your own ESTA ID here:
https://github.com/OpenLightingProject/ola/blob/master/plugins/usbpro/WidgetDetectorThread.cpp#L248

Altthough I think it could all work if you just respond in the same way as the Enttec Pro.

The RDM requests are it doing discovery on the RDM devices plugged into the interface, not the interface itself. In this case, you have the dummy universe patched too. If you remove that, the RDM messages will go away until you have a real RDM device attached to your physical interface.

[Arjan van Vught]

Peter, thanks for your reply.

I have removed the dummy from the universe. And the RDM messages are gone.

But still I have an issue with the RDM discovery protocol.

When I do a reload of the plug-ins (Incremental discovery triggered), then olad nicely sends an E120_DISC_UN_MUTE with source_uuid 0x7ff012345678 and destination_uuid 6*0xff.
My RPi RDM Responder sends back an E120_RESPONSE_TYPE_ACK, swaps source/destination_uuid, command_class++ and creates a new checksum.
The RPi Widget get this RDM pacakge and send it to olad with label=5.

The EnttecPortImpl::DiscoveryComplete is never called.

When I run the full RDM discovery for this universe, then it keeps running. There is no data exchange at all between olad and the RPi widget.

I hope you can give me some pointer to work with. I am eager to get this to work.

Thanks, Arjan

plugins/usbpro/UsbProWidgetDetector.cpp:517: Detected USB Device: ESTA Id: 0x7ff0 (AvV), device Id: 1 (Raspberry Pi DMX USB Pro), serial: 0x12345678, f/w version: 2.4

plugins/usbpro/WidgetDetectorThread.cpp:307: Defaulting to a Usb Pro device

olad/DeviceManager.cpp:105: Installed device: AvV - Raspberry Pi DMX USB Pro:5-12345678

plugins/usbpro/EnttecUsbProWidget.cpp:292: Incremental discovery triggered
plugins/usbpro/EnttecUsbProWidget.cpp:325: Un-muting all devices

olad/PortManager.cpp:119: Patched 5-12345678-O-0 to universe 1


Op zaterdag 21 februari 2015 01:53:10 UTC+1 schreef Peter Newman:

[Arjan van Vught]

Ok. The Rpi RDM Responder should not send the E120_RESPONSE_TYPE_ACK on a E120_DISC_UN_MUTE. I have fixed that.

However, the olad server still shows no further activity after the E120_DISC_UN_MUTE  broadcast sent.

Op zaterdag 21 februari 2015 16:14:19 UTC+1 schreef Arjan van Vught:

[Peter Newman]

Arjan, do you have an alternative RDM interface or RDM responder? At the moment you've got two many variables really. Alternatively do you have an Arduino and the other bits to build one of these: https://github.com/mathertel/DmxSerial2

Can you post a dump of the current discovery logs please.

[Arjan van Vught]

Peter,

even without a RDM Responder, the olad server should show some activity. I have spent a lot of time debugging this issue, after "plugins/usbpro/EnttecUsbProWidget.cpp:325: Un-muting all devices" there is no activity at all.

The "EnttecUsbProWidget.cpp" even generates a "Received Segmentation fault". See here.

S we have one variable, the olad server.

Thanks. Arjan


Log : Incremental discovery triggered

plugins/usbpro/UsbProWidgetDetector.cpp:517: Detected USB Device: ESTA Id: 0x7ff0 (AvV), device Id: 1 (Raspberry Pi DMX USB Pro), serial: 0x12345678, f/w version: 2.4

plugins/usbpro/WidgetDetectorThread.cpp:307: Defaulting to a Usb Pro device
olad/DeviceManager.cpp:105: Installed device: AvV - Raspberry Pi DMX USB Pro:5-12345678
plugins/usbpro/EnttecUsbProWidget.cpp:292: Incremental discovery triggered
plugins/usbpro/EnttecUsbProWidget.cpp:325: Un-muting all devices
olad/PortManager.cpp:119: Patched 5-12345678-O-0 to universe 1

Log : Full RDM discovery triggered for universe 1

olad/PluginManager.cpp:108: Started Serial USB

plugins/usbpro/UsbProWidgetDetector.cpp:517: Detected USB Device: ESTA Id: 0x7ff0 (AvV), device Id: 1 (Raspberry Pi DMX USB Pro), serial: 0x12345678, f/w version: 2.4
plugins/usbpro/WidgetDetectorThread.cpp:307: Defaulting to a Usb Pro device
olad/DeviceManager.cpp:105: Installed device: AvV - Raspberry Pi DMX USB Pro:5-12345678
plugins/usbpro/EnttecUsbProWidget.cpp:292: Incremental discovery triggered
plugins/usbpro/EnttecUsbProWidget.cpp:325: Un-muting all devices
olad/PortManager.cpp:119: Patched 5-12345678-O-0 to universe 1

olad/AvahiDiscoveryAgent.cpp:236: State for OLA Server._http._tcp,_ola, group 0x559430 changed to AVAHI_ENTRY_GROUP_ESTABLISHED
olad/Universe.cpp:508: Full RDM discovery triggered for universe 1

Op zaterdag 21 februari 2015 21:29:20 UTC+1 schreef Peter Newman:

[Peter Newman]

WIth a pukka Enttec Pro (v2.4 firmware), and -l 4 and no RDM devices connected, I get.

Incremental:
olad/Universe.cpp:510: Incremental RDM discovery triggered for universe 2

plugins/usbpro/EnttecUsbProWidget.cpp:292: Incremental discovery triggered
plugins/usbpro/EnttecUsbProWidget.cpp:325: Un-muting all devices

common/io/SelectPoller.cpp:233: ss process time was 0.000003
common/rdm/DiscoveryAgent.cpp:231: DUB 0000:00000000 - ffff:ffffffff, attempt 1, uids found: 0, failures 0, corrupted 0
plugins/usbpro/EnttecUsbProWidget.cpp:344: Sending DUB packet: 0000:00000000 - ffff:ffffffff
common/io/SelectPoller.cpp:233: ss process time was 0.000004
plugins/usbpro/EnttecUsbProWidget.cpp:606: Enttec Pro discovery complete:

Full:
olad/Universe.cpp:508: Full RDM discovery triggered for universe 2
plugins/usbpro/EnttecUsbProWidget.cpp:281: Full discovery triggered

plugins/usbpro/EnttecUsbProWidget.cpp:325: Un-muting all devices

common/io/SelectPoller.cpp:233: ss process time was 0.000003
common/rdm/DiscoveryAgent.cpp:231: DUB 0000:00000000 - ffff:ffffffff, attempt 1, uids found: 0, failures 0, corrupted 0
plugins/usbpro/EnttecUsbProWidget.cpp:344: Sending DUB packet: 0000:00000000 - ffff:ffffffff
common/io/SelectPoller.cpp:233: ss process time was 0.000004
plugins/usbpro/EnttecUsbProWidget.cpp:606: Enttec Pro discovery complete:

To see the DUBs you'll need -l 4.

[Arjan van Vught]

It is really odd, nothing is happening.

pi@rpi-openlighting ~ $ ola_rdm_discover -i -u 1

common/io/SelectPoller.cpp:233: ss process time was 0.000013
olad/Universe.cpp:510: Incremental RDM discovery triggered for universe 1
common/io/SelectPoller.cpp:233: ss process time was 0.000013
common/io/SelectPoller.cpp:233: ss process time was 0.000014
common/io/SelectPoller.cpp:233: ss process time was 0.000012

pi@rpi-openlighting ~ $ ola_rdm_discover -f -u 1

common/io/SelectPoller.cpp:233: ss process time was 0.000014
common/io/SelectPoller.cpp:233: ss process time was 0.000015

olad/Universe.cpp:508: Full RDM discovery triggered for universe 1

common/io/SelectPoller.cpp:233: ss process time was 0.000013
common/io/SelectPoller.cpp:233: ss process time was 0.000012
common/io/SelectPoller.cpp:233: ss process time was 0.000012
olad/OlaServer.cpp:379: Garbage collecting


Op zaterdag 21 februari 2015 23:37:26 UTC+1 schreef Peter Newman:

[Simon Newton]

I suspect you're not returning a response message to the label 7 command.

> --
> The Open Lighting Project: 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

[Arjan van Vught]

Simon,

There is no "plugins/usbpro/EnttecUsbProWidget.cpp:325: Un-muting all devices" entry in the log. So there is even no message with label 7 sent from the olad server.

And according to Peter's post, there is no need for a response. The olad server should always send the DUB packet.

Thanks, Arjan

Op zondag 22 februari 2015 00:04:25 UTC+1 schreef Simon Newton:

[Simon Newton]

On Sat, Feb 21, 2015 at 3:15 PM, Arjan van Vught
<arjan.v...@gmail.com> wrote:
> Simon,
>
> There is no "plugins/usbpro/EnttecUsbProWidget.cpp:325: Un-muting all
> devices" entry in the log. So there is even no message with label 7 sent
> from the olad server.

There is on the segfault thread :).

>
> And according to Peter's post, there is no need for a response. The olad
> server should always send the DUB packet.

You absolutely need to respond. Otherwise the state machine will get
stuck, which is exactly what you're seeing.

Simon

[Peter Newman]

I didn't say that Arjan, anyway, what I meant was no responder (i.e. no RDM device), not no response.

> open-lighting+unsubscribe@googlegroups.com

[Simon Newton]

There is a difference between no response from the RDM device and no
response from the USB widget. Peter was talking about the former.
Because the Host OS can't do accurate timing, the USB widget is
required to provide a response, even if there was nothing on the RDM
line.

Simon

[Arjan van Vught]

Simon, Peter,
thank you both for your time. Much appreciated.

I am somehow lost in the RDM protocol. When the olad server loads the plugin, then a un-mute command is send to the widget with label = 7 (Send RDM Packet Request).
This RDM command has a destination_uuid 6*0xFF and  the the source_uuid of the widget. What is the olad server expecting as response message? Which label ?

Meanwhile I am enhancing the main code. The serial number of the widget will be the MAC address of the Pi (this should also work on a Model A). I am going to add SD Card support for storing the widget parameters. And maybe I will implement data log functionality (separate files for DMX and RDM data).

Furthermore I did some successful testing with the following applications on Windows : Freestyler, QLC Plus and Open Light.

Thanks, Arjan


Op zondag 22 februari 2015 02:19:40 UTC+1 schreef Simon Newton:

[Peter Newman]

I suspect it should reply with a timeout saying it didn't get a response from any responders, but I'm only guessing.

Why not use the Pi's actual serial number (the last three octets of the MAC is a subset of the serial):
cat /proc/cpuinfo | grep Serial

It would also cover the Model A (I'm curious how it can have a MAC).

[Arjan van Vught]

Op zondag 22 februari 2015 16:21:57 UTC+1 schreef Peter Newman:

I suspect it should reply with a timeout saying it didn't get a response from any responders, but I'm only guessing.

Ok. I will look into the olad code and see which label to use. When you have more detailed information, then please let me know.

Why not use the Pi's actual serial number (the last three octets of the MAC is a subset of the serial):
cat /proc/cpuinfo | grep Serial

The MAC address is easier to implement as the Mailbox (ARM->VC) gives me : u8[6] : MAC address in network byte order. Then I copy the last 4 u8 into the widget serial number.

It would also cover the Model A (I'm curious how it can have a MAC).

See Raspberry Pi forum post.

[Arjan van Vught]

Got it!

And the widgets get the "Send RDM Discovery Request (Label=11)". This function is not implemented, yet.

First I am going to work on reading the "params.txt" file from SD Card. And the serial number from MAC address.

Thanks again!

olad/PluginManager.cpp:108: Started Serial USB
plugins/usbpro/UsbProWidgetDetector.cpp:517: Detected USB Device: ESTA Id: 0x7ff0 (AvV), device Id: 1 (Raspberry Pi DMX USB Pro), serial: 0x12345678, f/w version: 2.4
plugins/usbpro/WidgetDetectorThread.cpp:307: Defaulting to a Usb Pro device
olad/DeviceManager.cpp:105: Installed device: AvV - Raspberry Pi DMX USB Pro:5-12345678
plugins/usbpro/EnttecUsbProWidget.cpp:292: Incremental discovery triggered
plugins/usbpro/EnttecUsbProWidget.cpp:325: Un-muting all devices
olad/PortManager.cpp:119: Patched 5-12345678-O-0 to universe 1

plugins/usbpro/EnttecUsbProWidget.cpp:344: Sending DUB packet: 0000:00000000 - ffff:ffffffff

olad/AvahiDiscoveryAgent.cpp:236: State for OLA Server._http._tcp,_ola, group 0x1cb3fd0 changed to AVAHI_ENTRY_GROUP_ESTABLISHED


Op zondag 22 februari 2015 16:42:11 UTC+1 schreef Arjan van Vught:

[Peter Newman]

Is that just down to it being a byte array not a 64 bit uint? Given they seem to support both:
https://github.com/raspberrypi/firmware/wiki/Mailbox-property-interface#get-board-serial

[Arjan van Vught]

Update :

*. RPi acting as a "DMX USB Pro" device, phase 2 : "RDM"

            - Update the code using GPIO for data direction switch. Status : Finished
            - Add RDM capabilities. Status : Working. Code needs some polishing.

New sub project :
*. RPi as a RDM Responder
            - See https://github.com/vanvught/rpidmx512/tree/master/rpi_rdm_responder
            - Status : Working. Code needs some polishing.

olad -l 3:
plugins/usbpro/UsbProWidgetDetector.cpp:517: Detected USB Device: ESTA Id: 0x7ff0 (AvV), device Id: 1 (Raspberry Pi DMX USB Pro), serial: 0xeb27fb9d, f/w version: 2.4

plugins/usbpro/WidgetDetectorThread.cpp:307: Defaulting to a Usb Pro device

olad/DeviceManager.cpp:105: Installed device: AvV - Raspberry Pi DMX USB Pro:5-15127161103

plugins/usbpro/EnttecUsbProWidget.cpp:292: Incremental discovery triggered
plugins/usbpro/EnttecUsbProWidget.cpp:325: Un-muting all devices

olad/PortManager.cpp:119: Patched 5-15127161103-O-0 to universe 1

plugins/usbpro/EnttecUsbProWidget.cpp:344: Sending DUB packet: 0000:00000000 - ffff:ffffffff

common/rdm/DiscoveryAgent.cpp:341: muting 7ff0:00000001
plugins/usbpro/EnttecUsbProWidget.cpp:308: Muting 7ff0:00000001
plugins/usbpro/EnttecUsbProWidget.cpp:490: Probably muted device

plugins/usbpro/EnttecUsbProWidget.cpp:344: Sending DUB packet: 0000:00000000 - ffff:ffffffff

olad/Universe.cpp:437: Universe 1, RDM request to 7ff0:00000001, SD: 0, CC 20, TN 0, PID 0xf0, PDL: 0
olad/Universe.cpp:437: Universe 1, RDM request to 7ff0:00000001, SD: 0, CC 20, TN 0, PID 0xc0, PDL: 0
olad/Universe.cpp:437: Universe 1, RDM request to 7ff0:00000001, SD: 0, CC 20, TN 0, PID 0x1000, PDL: 0
olad/Universe.cpp:437: Universe 1, RDM request to 7ff0:00000001, SD: 0, CC 20, TN 0, PID 0x82, PDL: 0
olad/Universe.cpp:437: Universe 1, RDM request to 7ff0:00000001, SD: 0, CC 20, TN 0, PID 0x81, PDL: 0
olad/Universe.cpp:437: Universe 1, RDM request to 7ff0:00000001, SD: 0, CC 20, TN 0, PID 0x60, PDL: 0

- Arjan

Op woensdag 11 februari 2015 20:01:33 UTC+1 schreef Arjan van Vught:

[Arjan van Vught]

I ran the RDM Responder Tests and got warnings :

------------------- Warnings --------------------
Get SOFTWARE_VERSION_LABEL with data returned an ack
Get DEVICE_INFO with data returned an ack
Get SUPPORTED_PARAMETERS with data returned an ack
Get MANUFACTURER_LABEL with data returned an ack
Get DEVICE_LABEL with data returned an ack
Get IDENTIFY_DEVICE with data returned an ack
Get DMX_START_ADDRESS with data returned an ack

I've set Slot 16 with E120_RESPONSE_TYPE_ACK (0x00). So why is the test giving me a warning?

Thanks, Arjan

Op dinsdag 3 maart 2015 21:24:26 UTC+1 schreef Arjan van Vught:

[Peter Newman]

A get of those PIDs doesn't require any parameter data, so if some is passed in while fetching them, you should respond with NR_FORMAT_ERROR.

[Arjan van Vught]

Thanks Peter.

I've fixed the warnings. And I have implemented some nice features, like reading the RTC, i2c connected device (E120_REAL_TIME_CLOCK) and resetting the RPi using the wdog timer (E120_RESET_DEVICE).
Just need to work on the remaining warnings and 12 failed tests.

-Arjan

------------------- Summary --------------------
OLA Version: 0.9.5
Test Run: 2015-03-04 08:42:29 PM
UID: 7ff0:00000001
Manufacturer: AvV
Software Version: 9
------------------- Warnings --------------------
Mute / Unmute control fields don't match. 0x25 != 0x88
year in GET REAL_TIME_CLOCK is out of range, was 15, expeced (2003, 65535)
------------------ Advisories -------------------
Responder timed out to a command with PDL of 231
----------------- By Category -------------------
              Configuration:     8 /   8    100%
                    Control:    18 /  20    90%
         Core Functionality:     3 /   4    75%
               DMX512 Setup:    19 /  20    95%
            Dimmer Settings:    13 /  13    100%
           Display Settings:     2 /   2    100%
           Error Conditions:   149 / 153    97%
         Network Management:    21 /  24    88%
      Power / Lamp Settings:     7 /   7    100%
        Product Information:    16 /  17    94%
            RDM Information:     0 /   0    -%
                    Sensors:     6 /   6    100%
          Status Collection:     3 /   3    100%
                Sub Devices:    62 /  62    100%
-------------------------------------------------
339 / 407 tests run, 327 passed, 12 failed, 0 broken

Op woensdag 4 maart 2015 01:17:25 UTC+1 schreef Peter Newman:

[Arjan van Vught]

Just two failed left. And this seems to be an issue in the RPi DMX USB Pro code.

 Do I just need to acknowledge a MuteDeviceWithData and a  UnMuteDeviceWithData with a RDM_TIMEOUT? And not sending the RDM data out of the widget at all?
 
Thanks, Arjan


MuteDeviceWithData: FAILED
Mute device with param data.
 DISCOVERY: pid: DISC_MUTE (0x0002), sub device: 0, data: 'x'
 Response: RDMResponse:, Discovery NACK Format Error, PID: 0x0002, TN: 27
 Failed: expected one of:
  RDM_TIMEOUT
  RDM_PLUGIN_DISCOVERY_NOT_SUPPORTED

UnMuteDeviceWithData: FAILED
UnMute device info with param data.
 DISCOVERY: pid: DISC_UN_MUTE (0x0003), sub device: 0, data: 'x'
 Response: RDMResponse:, Discovery NACK Format Error, PID: 0x0003, TN: 121
 Failed: expected one of:
  RDM_TIMEOUT
  RDM_PLUGIN_DISCOVERY_NOT_SUPPORTED

------------------- Summary --------------------
OLA Version: 0.9.5

Test Run: 2015-03-05 06:26:03 PM

UID: 7ff0:00000001
Manufacturer: AvV
Software Version: 9
------------------- Warnings --------------------

------------------ Advisories -------------------

----------------- By Category -------------------
              Configuration:     8 /   8    100%

                    Control:    20 /  20    100%
         Core Functionality:     4 /   4    100%
               DMX512 Setup:    22 /  22    100%

            Dimmer Settings:    13 /  13    100%
           Display Settings:     2 /   2    100%

           Error Conditions:   153 / 153    100%
         Network Management:    22 /  24    92%

      Power / Lamp Settings:     7 /   7    100%

        Product Information:    17 /  17    100%

            RDM Information:     0 /   0    -%
                    Sensors:     6 /   6    100%
          Status Collection:     3 /   3    100%
                Sub Devices:    62 /  62    100%
-------------------------------------------------

341 / 407 tests run, 339 passed, 2 failed, 0 broken

Op woensdag 4 maart 2015 20:47:33 UTC+1 schreef Arjan van Vught:

[Peter Newman]

This comes down to having two variables when testing again. Did you say you don't own a normal DMX USB Pro?

From the test output, and without bothering to look at the RDM spec, I think the RDM responder shouldn't respond, the RDM interface will then issue a timeout when it doesn't get a reply and the test will pass. Simon can confirm, or have a look at the E1.20 spec, which is free now, to at least confirm what the RDM responder should be doing.

[Arjan van Vught]

Hi Peter,

You are right. I am building both RPi DMX USB Pro and the RPi RDM Responder from scratch. And this should not be an issue with the available public documentation ("dmx_usb_pro_api_spec.pdf", "ANSI_E1-20_2010.pdf").
The "RDM_TIMEOUT" (Label =  12) is documented in the OLA source code.

I can easily fix the failed tests. When I do not return the NACK, then the "RDM_TIMEOUT" is send to the host. As I am returning a E120_NR_FORMAT_ERROR for all other requests where the param_data_length should be 0, I am wondering why the a MuteDeviceWithData and a  UnMuteDeviceWithData are special in this case.

Thanks, Arjan

------------------- Summary --------------------
OLA Version: 0.9.5

Test Run: 2015-03-06 03:31:05 PM
UID: 7ff0:eb03282c
Manufacturer: AvV
Software Version: 10

------------------- Warnings --------------------
------------------ Advisories -------------------
----------------- By Category -------------------
              Configuration:     8 /   8    100%
                    Control:    20 /  20    100%
         Core Functionality:     4 /   4    100%

               DMX512 Setup:    23 /  23    100%

            Dimmer Settings:    13 /  13    100%
           Display Settings:     2 /   2    100%
           Error Conditions:   153 / 153    100%

         Network Management:    24 /  24    100%

      Power / Lamp Settings:     7 /   7    100%
        Product Information:    17 /  17    100%
            RDM Information:     0 /   0    -%
                    Sensors:     6 /   6    100%
          Status Collection:     3 /   3    100%
                Sub Devices:    62 /  62    100%
-------------------------------------------------

342 / 407 tests run, 342 passed, 0 failed, 0 broken

Op vrijdag 6 maart 2015 01:26:08 UTC+1 schreef Peter Newman:

[Peter Newman]

It shouldn't be an issue no, but it does make diagnoising things harder, you can't really trust your implementation of either bit given neither is known good.

The test includes the comment:
https://github.com/OpenLightingProject/ola/blob/master/tools/rdm/TestDefinitions.py#L83

If we look in the RDM spec there, it says "The response RESPONSE_TYPE_NACK_REASON shall only be used in conjunction with the Command Classes GET_COMMAND_RESPONSE & SET_COMMAND_RESPONSE." which answers your question.

[Arjan van Vught]

I should have read page 29 before submitting my question ;-)

Thanks for the pointer to the comments in TestDefinitions.py.

I hope that the RPi DMX/RDM break-out board is available soon. This gives others the opportunity to test the RPi RDM Responder with a RDM Controller device which is supported by OLA RDM Test Server.

- Arjan

Op vrijdag 6 maart 2015 22:37:45 UTC+1 schreef Peter Newman:

[Arjan van Vught]

RPi RDM Responder : https://github.com/vanvught/rpidmx512/tree/master/rpi_rdm_responder

The following PIDs are currently implemented :

PID	GET	SET
E120_SUPPORTED_PARAMETERS	√
E120_DEVICE_INFO	√
E120_DEVICE_MODEL_DESCRIPTION	√
E120_MANUFACTURER_LABEL	√
E120_DEVICE_LABEL	√	√
E120_FACTORY_DEFAULTS	√	√
E120_LANGUAGE_CAPABILITIES	√
E120_LANGUAGE	√	√
E120_SOFTWARE_VERSION_LABEL	√
E120_BOOT_SOFTWARE_VERSION_ID	√
E120_BOOT_SOFTWARE_VERSION_LABEL	√
E120_DMX_PERSONALITY	√	√
E120_DMX_PERSONALITY_DESCRIPTION	√
E120_DMX_START_ADDRESS	√	√
E120_DEVICE_HOURS	√	√
E120_REAL_TIME_CLOCK	√
E120_IDENTIFY_DEVICE	√	√
E120_RESET_DEVICE		√

Implementation notes:
*. When there is no i2c RTC connected, then the Clock time is equal to the uptime.
*. The number for "Boot Software" is the firmware build time in epoch time.
*. The "Device Model" is based on the table here : http://www.raspberrypi-spy.co.uk/2012/09/checking-your-raspberry-pi-board-version/
*. Factory defaults checks the DMX Start Address, Current Personality and Device Label for changes.
*. The Device Hours is based on the 64-bit System Timer

*. You can easily add your own DMX (SPI, I2C, GPIO) functions in the poll or event table.

-Arjan

[Arjan van Vught]

Hi Peter, I've got the rdmpro_sniffer working.

As I am running out of my 5 RPi's :) RPi#1 (olad server) <-> RPi#2 (RPiUsbPro) <-> RPi#3 (RPiUsbPro) <-> RPi#4 (rdmpro_sniffer), I need to install the olad server on a Ubuntu server. Then I am able to test the rdmpro_sniffer with the RPi RDM Responder.

Currently, I have commented out the DMX, RDM routines in the RPiUsbPro. I am thinking about adding "mode=" in the params.txt file. Then the widget selects its mode (DMX , firmware v1, RDM firmware > 2.4, RDM Sniffer) based on this line. And we just have one kernel.img.

-Arjan

pi@openlighting-1 ~ $ rdmpro_sniffer -l 3 /dev/ttyUSB0
7ff0:eb27fb9d -> ffff:ffffffff DISCOVERY_COMMAND, sub-device: 0, tn: 0, PID 0x0003 (DISC_UN_MUTE), pdl: 0
7ff0:eb27fb9d -> ffff:ffffffff DISCOVERY_COMMAND, sub-device: 0, tn: 1, PID 0x0001 (DISC_UNIQUE_BRANCH), (0000:00000000, ffff:ffffffff)
7ff0:eb27fb9d -> ffff:ffffffff DISCOVERY_COMMAND, sub-device: 0, tn: 2, PID 0x0003 (DISC_UN_MUTE), pdl: 0
7ff0:eb27fb9d -> ffff:ffffffff DISCOVERY_COMMAND, sub-device: 0, tn: 3, PID 0x0001 (DISC_UNIQUE_BRANCH), (0000:00000000, ffff:ffffffff)



Op donderdag 12 februari 2015 01:19:36 UTC+1 schreef Peter Newman:

Cool Arjan. A minor thing, it may be worth choosing a new project name, given the Open DMX exists, that may get rather confusing.

Have you considered implementing the Enttec USB Pro RDM sniffer commands, as used by our rdmpro_sniffer too? Then it provides another option and reduces how much of the interpretation code you need to write.

[Arjan van Vught]

I am wondering, when an USB PRO Widget is connected to an universe as Input, will the olad server then act as a RDM Responder (table page 9, File:dmx_usb_pro_api_spec.odt CDI : nil Date:16 Oct 07) ?

Thanks, Arjan

[Simon Newton]

No, there are all sorts of problems with that - the widget would have
to ack timer everything since the host may not be able to respond
within the 2.8 ms time slice.

So we don't even try :)

Simon

[Peter Newman]

Looking at the spec Simon, it does that already in the widget "ACK_TIMER response with time of 0.1 seconds. PC should respond with Queued message." and "The RDM Responder Widget has space to store a single queued RDM message only. The ACK_TIMER and queued message mechanism ensure that the timing requirements of the RDM specification can be met, even though the PC application is slow to respond due to USB latency or scheduling delays for example."

Although that seems to imply the UID would be Enttec's, so I've no idea how it can be compliant with the standard given there is no process mentioned to reserve a model ID from Enttec.

On Friday, 20 March 2015 17:56:45 UTC, Simon Newton wrote:

No, there are all sorts of problems with that - the widget would have
to ack timer everything since the host may not be able to respond
within the 2.8 ms time slice.

So we don't even try :)

Simon


On Fri, Mar 20, 2015 at 12:19 PM, Arjan van Vught
<arjan.van.vught> wrote:
> I am wondering, when an USB PRO Widget is connected to an universe as Input,
> will the olad server then act as a RDM Responder (table page 9,
> File:dmx_usb_pro_api_spec.odt CDI : nil Date:16 Oct 07) ?
>
> Thanks, Arjan
>
> --
> The Open Lighting Project: open-l...@googlegroups.com, #openlighting
> (irc.freenode.org)
> To unsubscribe from this group, send email to

> open-lighting+unsubscribe@googlegroups.com

[Arjan van Vught]

Please see the fully assembled RPi DMX/RDM isolated board.

I have tested the board with the OLA server and the "UART native DMX"
plug-in. Before starting the server, you need to set the data direction for
DMX with :
sudo pi@openlighting-2 ~ $ sudo -i
root@openlighting-2:~# echo 18 > /sys/class/gpio/export
root@openlighting-2:~# echo out > /sys/class/gpio/gpio18/direction
root@openlighting-2:~# echo 1 > /sys/class/gpio/gpio18/value

Also, I have tested the board with the RPi RDM responder :
https://github.com/vanvught/rpidmx512/tree/master/rpi_rdm_responder

Both configurations are working nicely.

On the right side of the board you find two SPI connectors
<http://www.bitwizard.nl/wiki/index.php/SPI_connector_pinout> and the I2C
connector <http://www.bitwizard.nl/wiki/index.php/I2C_connector_pinout>.

For more information about this board, please contact the manufacturer :
http://www.bitwizard.nl/shop/index.php?route=common/home

- Arjan

[Arjan van Vught]

I'd like to announce that the RPi DMX-RDM board with the native RPi RDM Responder code and the RPi DMX USB Pro, are working correctly together with the Eurolite EDX-4R DMX RDM Dimmer pack.

For reference I have attached the stdout for ola server #1 which is connected to the RPi DMX USB Pro. And the stdout for ola server #2, which used as the RDM Sniffer. Basically running the RPi DMX USB Pro in mode 3.

- Arjan

[Arjan van Vught]

I have a difference in output for an incremental and a full discovery. See below.

Any ideas why I get "common/rdm/DiscoveryAgent.cpp:193: Unable to mute 7ff0:eb70e766, device has gone"?

Thanks, Arjan

pi@openlighting-1 ~ $ ola_rdm_discover -u 1 -f
29aa:02001420
7ff0:eb70e766
pi@openlighting-1 ~ $ ola_rdm_discover -u 1 -i
29aa:02001420
pi@openlighting-1 ~ $

OLA Server output full discovery

=~=~=~=~=~=~=~=~=~=~=~= PuTTY log 2015.04.06 15:03:06 =~=~=~=~=~=~=~=~=~=~=~=

olad/Universe.cpp:508: Full RDM discovery triggered for universe 1

plugins/usbpro/EnttecUsbProWidget.cpp:281: Full discovery triggered
plugins/usbpro/EnttecUsbProWidget.cpp:325: Un-muting all devices
plugins/usbpro/EnttecUsbProWidget.cpp:344: Sending DUB packet: 0000:00000000 - ffff:ffffffff
common/rdm/DiscoveryAgent.cpp:307: recovered checksum: 31457 != calculated checksum: 2669
common/rdm/DiscoveryAgent.cpp:396:  collision, spliting into: 0000:00000000 - 7fff:ffffffff , 8000:00000000 - ffff:ffffffff
plugins/usbpro/EnttecUsbProWidget.cpp:344: Sending DUB packet: 8000:00000000 - ffff:ffffffff
plugins/usbpro/EnttecUsbProWidget.cpp:344: Sending DUB packet: 0000:00000000 - 7fff:ffffffff
common/rdm/DiscoveryAgent.cpp:307: recovered checksum: 31457 != calculated checksum: 2669
common/rdm/DiscoveryAgent.cpp:396:  collision, spliting into: 0000:00000000 - 3fff:ffffffff , 4000:00000000 - 7fff:ffffffff
plugins/usbpro/EnttecUsbProWidget.cpp:344: Sending DUB packet: 4000:00000000 - 7fff:ffffffff
common/rdm/DiscoveryAgent.cpp:341: muting 7ff0:eb70e766
plugins/usbpro/EnttecUsbProWidget.cpp:308: Muting 7ff0:eb70e766
plugins/usbpro/EnttecUsbProWidget.cpp:490: Probably muted device
plugins/usbpro/EnttecUsbProWidget.cpp:344: Sending DUB packet: 4000:00000000 - 7fff:ffffffff
plugins/usbpro/EnttecUsbProWidget.cpp:344: Sending DUB packet: 0000:00000000 - 3fff:ffffffff
common/rdm/DiscoveryAgent.cpp:341: muting 29aa:02001420
plugins/usbpro/EnttecUsbProWidget.cpp:308: Muting 29aa:02001420
plugins/usbpro/EnttecUsbProWidget.cpp:490: Probably muted device
plugins/usbpro/EnttecUsbProWidget.cpp:344: Sending DUB packet: 0000:00000000 - 3fff:ffffffff
plugins/usbpro/EnttecUsbProWidget.cpp:344: Sending DUB packet: 0000:00000000 - 7fff:ffffffff
plugins/usbpro/EnttecUsbProWidget.cpp:344: Sending DUB packet: 0000:00000000 - ffff:ffffffff

RDM Sniffer output full discovery

=~=~=~=~=~=~=~=~=~=~=~= PuTTY log 2015.04.06 15:02:55 =~=~=~=~=~=~=~=~=~=~=~=
06-04-2015 15:03:07.520906 7ff0:eb55fda5 -> ffff:ffffffff DISCOVERY_COMMAND, sub-device: 0, tn: 80, PID 0x0003 (DISC_UN_MUTE), pdl: 0
06-04-2015 15:03:07.526893 7ff0:eb70e766 -> 7ff0:eb55fda5 DISCOVERY_COMMAND_RESPONSE, sub-device: 0, tn: 80, PID 0x0003 (DISC_UN_MUTE), pdl: 2
06-04-2015 15:03:07.534291 7ff0:eb55fda5 -> ffff:ffffffff DISCOVERY_COMMAND, sub-device: 0, tn: 81, PID 0x0001 (DISC_UNIQUE_BRANCH), (0000:00000000, ffff:ffffffff)
06-04-2015 15:03:07.539997 SC 0xfe 23:fe fe fe fe fe fe aa ab 7d aa fe fe fe fe fe fe fe aa ff 7f fa f5 eb
06-04-2015 15:03:07.548653 7ff0:eb55fda5 -> ffff:ffffffff DISCOVERY_COMMAND, sub-device: 0, tn: 82, PID 0x0001 (DISC_UNIQUE_BRANCH), (8000:00000000, ffff:ffffffff)
06-04-2015 15:03:08.554257 7ff0:eb55fda5 -> ffff:ffffffff DISCOVERY_COMMAND, sub-device: 0, tn: 83, PID 0x0001 (DISC_UNIQUE_BRANCH), (0000:00000000, 7fff:ffffffff)
06-04-2015 15:03:08.559959 SC 0xfe 23:fe fe fe fe fe fe aa ab 7d aa fe fe fe fe fe fe fe aa ff 7f fa f5 eb
06-04-2015 15:03:08.569014 7ff0:eb55fda5 -> ffff:ffffffff DISCOVERY_COMMAND, sub-device: 0, tn: 84, PID 0x0001 (DISC_UNIQUE_BRANCH), (4000:00000000, 7fff:ffffffff)
06-04-2015 15:03:08.573589 SC 0xfe 23:fe fe fe fe fe fe aa ff 7f fa f5 eb ff fa 75 ef f7 ee 77 aa 5f bb 55
06-04-2015 15:03:08.580895 7ff0:eb55fda5 -> 7ff0:eb70e766 DISCOVERY_COMMAND, sub-device: 0, tn: 85, PID 0x0002 (DISC_MUTE), pdl: 0
06-04-2015 15:03:08.585585 7ff0:eb70e766 -> 7ff0:eb55fda5 DISCOVERY_COMMAND_RESPONSE, sub-device: 0, tn: 85, PID 0x0002 (DISC_MUTE), pdl: 2
06-04-2015 15:03:08.594602 7ff0:eb55fda5 -> ffff:ffffffff DISCOVERY_COMMAND, sub-device: 0, tn: 86, PID 0x0001 (DISC_UNIQUE_BRANCH), (4000:00000000, 7fff:ffffffff)
06-04-2015 15:03:08.599646 7ff0:eb55fda5 -> ffff:ffffffff DISCOVERY_COMMAND, sub-device: 0, tn: 87, PID 0x0001 (DISC_UNIQUE_BRANCH), (0000:00000000, 3fff:ffffffff)
06-04-2015 15:03:08.606985 SC 0xfe 23:fe fe fe fe fe fe aa ab 7d aa ff aa 57 aa 55 be 55 aa 75 af 57 ab 57
06-04-2015 15:03:08.614470 7ff0:eb55fda5 -> 29aa:02001420 DISCOVERY_COMMAND, sub-device: 0, tn: 88, PID 0x0002 (DISC_MUTE), pdl: 0
06-04-2015 15:03:08.618889 29aa:02001420 -> 7ff0:eb55fda5 DISCOVERY_COMMAND_RESPONSE, sub-device: 0, tn: 88, PID 0x0002 (DISC_MUTE), pdl: 2
06-04-2015 15:03:08.626401 7ff0:eb55fda5 -> ffff:ffffffff DISCOVERY_COMMAND, sub-device: 0, tn: 89, PID 0x0001 (DISC_UNIQUE_BRANCH), (0000:00000000, 3fff:ffffffff)
06-04-2015 15:03:08.633762 7ff0:eb55fda5 -> ffff:ffffffff DISCOVERY_COMMAND, sub-device: 0, tn: 90, PID 0x0001 (DISC_UNIQUE_BRANCH), (0000:00000000, 7fff:ffffffff)
06-04-2015 15:03:09.639684 7ff0:eb55fda5 -> ffff:ffffffff DISCOVERY_COMMAND, sub-device: 0, tn: 91, PID 0x0001 (DISC_UNIQUE_BRANCH), (0000:00000000, ffff:ffffffff)

OLA Server output incremental discovery

=~=~=~=~=~=~=~=~=~=~=~= PuTTY log 2015.04.06 15:03:42 =~=~=~=~=~=~=~=~=~=~=~=

olad/Universe.cpp:510: Incremental RDM discovery triggered for universe 1

plugins/usbpro/EnttecUsbProWidget.cpp:292: Incremental discovery triggered
plugins/usbpro/EnttecUsbProWidget.cpp:325: Un-

muting all devices
plugins/usbpro/EnttecUsbProWidget.cpp:308: Muting 29aa:02001420
plugins/usbpro/EnttecUsbProWidget.cpp:490: Probably muted device
plugins/usbpro/EnttecUsbProWidget.cpp:308: Muting 7ff0:eb70e766
plugins/usbpro/EnttecUsbProWidget.cpp:377: Unable to mute device
common/rdm/DiscoveryAgent.cpp:193: Unable to mute 7ff0:eb70e766, device has gone
plugins/usbpro/EnttecUsbProWidget.cpp:344: Sending DUB packet: 0000:00000000 - ffff:ffffffff
common/rdm/DiscoveryAgent.cpp:396:  collision, spliting into: 0000:00000000 - 7fff:ffffffff , 8000:00000000 - ffff:ffffffff
plugins/usbpro/EnttecUsbProWidget.cpp:344: Sending DUB packet: 8000:00000000 - ffff:ffffffff
plugins/usbpro/EnttecUsbProWidget.cpp:344: Sending DUB packet: 0000:00000000 - 7fff:ffffffff
plugins/usbpro/EnttecUsbProWidget.cpp:344: Sending DUB packet: 0000:00000000 - ffff:ffffffff
olad/RDMHTTPModule.cpp:743: Removed UID 7ff0:eb70e766

RDM Sniffer output incremental discovery

=~=~=~=~=~=~=~=~=~=~=~= PuTTY log 2015.04.06 15:03:55 =~=~=~=~=~=~=~=~=~=~=~=
06-04-2015 15:03:56.971817 7ff0:eb55fda5 -> ffff:ffffffff DISCOVERY_COMMAND, sub-device: 0, tn: 92, PID 0x0003 (DISC_UN_MUTE), pdl: 0
06-04-2015 15:03:56.975203 7ff0:eb70e766 -> 7ff0:eb55fda5 DISCOVERY_COMMAND_RESPONSE, sub-device: 0, tn: 92, PID 0x0003 (DISC_UN_MUTE), pdl: 2
06-04-2015 15:03:56.983835 7ff0:eb55fda5 -> 29aa:02001420 DISCOVERY_COMMAND, sub-device: 0, tn: 93, PID 0x0002 (DISC_MUTE), pdl: 0
06-04-2015 15:03:56.989698 29aa:02001420 -> 7ff0:eb55fda5 DISCOVERY_COMMAND_RESPONSE, sub-device: 0, tn: 93, PID 0x0002 (DISC_MUTE), pdl: 2
06-04-2015 15:03:56.996921 7ff0:eb55fda5 -> 7ff0:eb70e766 DISCOVERY_COMMAND, sub-device: 0, tn: 94, PID 0x0002 (DISC_MUTE), pdl: 0
06-04-2015 15:03:57.1543 7ff0:eb70e766 -> 7ff0:eb55fda5 DISCOVERY_COMMAND_RESPONSE, sub-device: 0, tn: 94, PID 0x0002 (DISC_MUTE), pdl: 2
06-04-2015 15:03:57.10390 7ff0:eb55fda5 -> ffff:ffffffff DISCOVERY_COMMAND, sub-device: 0, tn: 95, PID 0x0001 (DISC_UNIQUE_BRANCH), (0000:00000000, ffff:ffffffff)
06-04-2015 15:03:57.17697 7ff0:eb55fda5 -> ffff:ffffffff DISCOVERY_COMMAND, sub-device: 0, tn: 96, PID 0x0001 (DISC_UNIQUE_BRANCH), (8000:00000000, ffff:ffffffff)
06-04-2015 15:03:58.23553 7ff0:eb55fda5 -> ffff:ffffffff DISCOVERY_COMMAND, sub-device: 0, tn: 97, PID 0x0001 (DISC_UNIQUE_BRANCH), (0000:00000000, 7fff:ffffffff)
06-04-2015 15:03:59.29672 7ff0:eb55fda5 -> ffff:ffffffff DISCOVERY_COMMAND, sub-device: 0, tn: 98, PID 0x0001 (DISC_UNIQUE_BRANCH), (0000:00000000, ffff:ffffffff

)

[Peter Newman]

Firstly, you should git pull, there's been a few changes around discovery, it probably won't make a difference, but it can't hurt.

Without having read that bit of the spec in much detail, I'd guess you're being too slow. The log line preceding it has come from here:

https://github.com/OpenLightingProject/ola/blob/a27dda448335648dc8b124c96fad512e51ce6d35/plugins/usbpro/EnttecUsbProWidget.cpp#L377

If you look at the incremental of the other device, it responds in 6ms:

06-04-2015 15:03:56.983835 7ff0:eb55fda5 -> 29aa:02001420 DISCOVERY_COMMAND, sub-device: 0, tn: 93, PID 0x0002 (DISC_MUTE), pdl: 0
06-04-2015 15:03:56.989698 29aa:02001420 -> 7ff0:eb55fda5 DISCOVERY_COMMAND_RESPONSE, sub-device: 0, tn: 93, PID 0x0002 (DISC_MUTE), pdl:2

Whereas you take tenths of a second to respond:

06-04-2015 15:03:56.996921 7ff0:eb55fda5 -> 7ff0:eb70e766 DISCOVERY_COMMAND, sub-device: 0, tn: 94, PID 0x0002 (DISC_MUTE), pdl: 0
06-04-2015 15:03:57.1543 7ff0:eb70e766 -> 7ff0:eb55fda5 DISCOVERY_COMMAND_RESPONSE, sub-device: 0, tn: 94, PID 0x0002 (DISC_MUTE), pdl: 2

In comparison, during full discovery, you are much faster.

[Simon Newton]

Peter is correct, the widget is timing out because the responder isn't
fast enough.

Also when you're collecting logs please run in debug mode (-l 4).

Simon

> --
> The Open Lighting Project: open-l...@googlegroups.com, #openlighting
> (irc.freenode.org)
> To unsubscribe from this group, send email to

> open-lightin...@googlegroups.com

[Arjan van Vught]

Please find attached the server output with -l 4 and the sniffer output.

The responder is acting the same for a full discovery as well for an incremental discovery. And it is fast enough.

I did some more testing with 3 and 4 devices. I pretty lost here. The fully discovery is working fine. Why would the incremental fail?

Thanks, Arjan

3 devices

pi@openlighting-1 ~ $ ola_rdm_discover -u 1 -f
29aa:02001420
7ff0:eb70e766

7ff0:ebb24a6c
pi@openlighting-1 ~ $ ola_rdm_discover -u 1 -i
29aa:02001420
7ff0:ebb24a6c
pi@openlighting-1 ~ $ ola_rdm_discover -u 1 -i

29aa:02001420
7ff0:eb70e766
pi@openlighting-1 ~ $ ola_rdm_discover -u 1 -i
29aa:02001420

7ff0:ebb24a6c

4 devices

pi@openlighting-1 ~ $ ola_rdm_discover -u 1 -f
29aa:02001420
7ff0:eb70e766

7ff0:eb9005c5
7ff0:ebb24a6c
pi@openlighting-1 ~ $ ola_rdm_discover -u 1 -i
29aa:02001420
7ff0:ebb24a6c
pi@openlighting-1 ~ $ ola_rdm_discover -u 1 -i
29aa:02001420
7ff0:eb70e766
7ff0:eb9005c5
pi@openlighting-1 ~ $ ola_rdm_discover -u 1 -i
29aa:02001420
7ff0:eb9005c5
pi@openlighting-1 ~ $ ola_rdm_discover -u 1 -i
29aa:02001420
7ff0:eb70e766
7ff0:ebb24a6c
pi@openlighting-1 ~ $ ola_rdm_discover -u 1 -i
29aa:02001420
7ff0:ebb24a6c

2 devices

Fully

06-04-2015 16:29:49.742390 7ff0:eb55fda5 -> ffff:ffffffff DISCOVERY_COMMAND, sub-device: 0, tn: 129, PID 0x0003 (DISC_UN_MUTE), pdl: 0
06-04-2015 16:29:49.748141 7ff0:eb70e766 -> 7ff0:eb55fda5 DISCOVERY_COMMAND_RESPONSE, sub-device: 0, tn: 129, PID 0x0003 (DISC_UN_MUTE), pdl: 2
06-04-2015 16:29:49.756895 7ff0:eb55fda5 -> ffff:ffffffff DISCOVERY_COMMAND, sub-device: 0, tn: 130, PID 0x0001 (DISC_UNIQUE_BRANCH), (0000:00000000, ffff:ffffffff)
06-04-2015 16:29:49.761390 SC 0xfe 23:fe fe fe fe fe fe aa ab 7d aa fe fe fe fe fe fe fe aa ff 7f fa f5 eb
06-04-2015 16:29:49.770404 7ff0:eb55fda5 -> ffff:ffffffff DISCOVERY_COMMAND, sub-device: 0, tn: 131, PID 0x0001 (DISC_UNIQUE_BRANCH), (8000:00000000, ffff:ffffffff)
06-04-2015 16:29:50.775382 7ff0:eb55fda5 -> ffff:ffffffff DISCOVERY_COMMAND, sub-device: 0, tn: 132, PID 0x0001 (DISC_UNIQUE_BRANCH), (0000:00000000, 7fff:ffffffff)
06-04-2015 16:29:50.781298 SC 0xfe 23:fe fe fe fe fe fe aa ab 7d aa fe fe fe fe fe fe fe aa ff 7f fa f5 eb
06-04-2015 16:29:50.791385 7ff0:eb55fda5 -> ffff:ffffffff DISCOVERY_COMMAND, sub-device: 0, tn: 133, PID 0x0001 (DISC_UNIQUE_BRANCH), (4000:00000000, 7fff:ffffffff)
06-04-2015 16:29:50.795716 SC 0xfe 23:fe fe fe fe fe fe aa ff 7f fa f5 eb ff fa 75 ef f7 ee 77 aa 5f bb 55
06-04-2015 16:29:50.803332 7ff0:eb55fda5 -> 7ff0:eb70e766 DISCOVERY_COMMAND, sub-device: 0, tn: 134, PID 0x0002 (DISC_MUTE), pdl: 0
06-04-2015 16:29:50.809414 7ff0:eb70e766 -> 7ff0:eb55fda5 DISCOVERY_COMMAND_RESPONSE, sub-device: 0, tn: 134, PID 0x0002 (DISC_MUTE), pdl: 2 => 0,006082
06-04-2015 16:29:50.816631 7ff0:eb55fda5 -> ffff:ffffffff DISCOVERY_COMMAND, sub-device: 0, tn: 135, PID 0x0001 (DISC_UNIQUE_BRANCH), (4000:00000000, 7fff:ffffffff)
06-04-2015 16:29:50.823937 7ff0:eb55fda5 -> ffff:ffffffff DISCOVERY_COMMAND, sub-device: 0, tn: 136, PID 0x0001 (DISC_UNIQUE_BRANCH), (0000:00000000, 3fff:ffffffff)
06-04-2015 16:29:50.828420 SC 0xfe 23:fe fe fe fe fe fe aa ab 7d aa ff aa 57 aa 55 be 55 aa 75 af 57 ab 57
06-04-2015 16:29:50.837325 7ff0:eb55fda5 -> 29aa:02001420 DISCOVERY_COMMAND, sub-device: 0, tn: 137, PID 0x0002 (DISC_MUTE), pdl: 0
06-04-2015 16:29:50.841899 29aa:02001420 -> 7ff0:eb55fda5 DISCOVERY_COMMAND_RESPONSE, sub-device: 0, tn: 137, PID 0x0002 (DISC_MUTE), pdl: 2
06-04-2015 16:29:50.850622 7ff0:eb55fda5 -> ffff:ffffffff DISCOVERY_COMMAND, sub-device: 0, tn: 138, PID 0x0001 (DISC_UNIQUE_BRANCH), (0000:00000000, 3fff:ffffffff)
06-04-2015 16:29:50.856573 7ff0:eb55fda5 -> ffff:ffffffff DISCOVERY_COMMAND, sub-device: 0, tn: 139, PID 0x0001 (DISC_UNIQUE_BRANCH), (0000:00000000, 7fff:ffffffff)
06-04-2015 16:29:51.862185 7ff0:eb55fda5 -> ffff:ffffffff DISCOVERY_COMMAND, sub-device: 0, tn: 140, PID 0x0001 (DISC_UNIQUE_BRANCH), (0000:00000000, ffff:ffffffff)

Incremental

06-04-2015 16:29:59.480448 7ff0:eb55fda5 -> ffff:ffffffff DISCOVERY_COMMAND, sub-device: 0, tn: 141, PID 0x0003 (DISC_UN_MUTE), pdl: 0
06-04-2015 16:29:59.486368 7ff0:eb70e766 -> 7ff0:eb55fda5 DISCOVERY_COMMAND_RESPONSE, sub-device: 0, tn: 141, PID 0x0003 (DISC_UN_MUTE), pdl: 2
06-04-2015 16:29:59.493842 7ff0:eb55fda5 -> 29aa:02001420 DISCOVERY_COMMAND, sub-device: 0, tn: 142, PID 0x0002 (DISC_MUTE), pdl: 0
06-04-2015 16:29:59.498379 29aa:02001420 -> 7ff0:eb55fda5 DISCOVERY_COMMAND_RESPONSE, sub-device: 0, tn: 142, PID 0x0002 (DISC_MUTE), pdl: 2
06-04-2015 16:29:59.507258 7ff0:eb55fda5 -> 7ff0:eb70e766 DISCOVERY_COMMAND, sub-device: 0, tn: 143, PID 0x0002 (DISC_MUTE), pdl: 0
06-04-2015 16:29:59.511833 7ff0:eb70e766 -> 7ff0:eb55fda5 DISCOVERY_COMMAND_RESPONSE, sub-device: 0, tn: 143, PID 0x0002 (DISC_MUTE), pdl: 2   => 0,004575
06-04-2015 16:29:59.520520 7ff0:eb55fda5 -> ffff:ffffffff DISCOVERY_COMMAND, sub-device: 0, tn: 144, PID 0x0001 (DISC_UNIQUE_BRANCH), (0000:00000000, ffff:ffffffff)
06-04-2015 16:29:59.526328 7ff0:eb55fda5 -> ffff:ffffffff DISCOVERY_COMMAND, sub-device: 0, tn: 145, PID 0x0001 (DISC_UNIQUE_BRANCH), (8000:00000000, ffff:ffffffff)
06-04-2015 16:30:00.532485 7ff0:eb55fda5 -> ffff:ffffffff DISCOVERY_COMMAND, sub-device: 0, tn: 146, PID 0x0001 (DISC_UNIQUE_BRANCH), (0000:00000000, 7fff:ffffffff)
06-04-2015 16:30:01.538923 7ff0:eb55fda5 -> ffff:ffffffff DISCOVERY_COMMAND, sub-device: 0, tn: 147, PID 0x0001 (DISC_UNIQUE_BRANCH), (0000:00000000, ffff:ffffffff)





Op maandag 6 april 2015 16:01:13 UTC+2 schreef Simon Newton:

[Simon Newton]

What build are you running? The version in git has more logging.

Also you should double check the timings with a logic analyser. I'm
not sure on what event the sniffer logs the timestamp, but a RDM
responder has 2ms from the end of the controller packet to the break.

Simon

[Arjan van Vught]

Simon,

I am running the OLA olad version: 0.9.5

With the Saleae Logic analyzer I have validated the timing. According to "3.2.2 Responder Packet spacing" the minimum value should be 176μs and the max 2 ms. The responder is set to 200μs.

I cannot understand why the fully discovery is working (for all cases with 2, 3, and 4 responders) and the incremental gives me such a headache ;-)

Thanks, Arjan


Op maandag 6 april 2015 18:24:29 UTC+2 schreef Simon Newton:

[Sean Sill]

I find it odd that there is a discovery UN_MUTE response from a broadcast. Is this a quirk of the UsbPro Simon?

[Arjan van Vught]

I am totally lost. I will grab the latest from github. And I will buy the RPi 2 for rebuilding the code ... Thanks, Arjan

pi@openlighting-1 ~ $ ola_rdm_discover -u 1 -f

7ff0:eb70e766
7ff0:ebb24a6c
pi@openlighting-1 ~ $ ola_rdm_discover -u 1 -f
7ff0:eb70e766
7ff0:ebb24a6c
pi@openlighting-1 ~ $ ola_rdm_discover -u 1 -f
7ff0:eb70e766
7ff0:ebb24a6c
pi@openlighting-1 ~ $ ola_rdm_discover -u 1 -f
pi@openlighting-1 ~ $ ola_rdm_discover -u 1 -f
pi@openlighting-1 ~ $ ola_rdm_discover -u 1 -f

7ff0:eb70e766
7ff0:ebb24a6c
pi@openlighting-1 ~ $

Op maandag 6 april 2015 15:53:54 UTC+2 schreef Peter Newman:

...

[Peter Newman]

Apologies, I got my maths wrong. I think Sean is onto it, only your device responds to the broadcast Arjan, the other one doesn't. I guess that quirk may be confusing OLA (but only in incremental mode):
06-04-2015 16:29:59.480448 7ff0:eb55fda5 -> ffff:ffffffff DISCOVERY_COMMAND, sub-device: 0, tn: 141, PID 0x0003 (DISC_UN_MUTE), pdl: 0
06-04-2015 16:29:59.486368 7ff0:eb70e766 -> 7ff0:eb55fda5 DISCOVERY_COMMAND_RESPONSE, sub-device: 0, tn: 141, PID 0x0003 (DISC_UN_MUTE), pdl: 2

Although 5.3 of the standard does say:
When Broadcast Addressing is used for non-Discovery messages, the responders shall not send a response.

This bit of the standard does seem a little vague, it's clear in 7.5 you should respond to a DUB, but I'd say the other cases are a bit ambiguous.

...