Software brute forces PID enumeration during probing

[unclewalter]

Hello! First of all thank you for putting together this software. I've been mostly using it for aiding in the RDM implementation on some fixtures I'm designing. It has been very helpful for testing my custom PIDs, which OLA doesn't support.

The issue

During the probing process, I've noticed that rather than querying what's listed in SUPPORTED_PARAMETERS, it queries a whole bunch of other parameters that are not listed as required by the spec. This create quite a lot of extra traffic while enumerating fixtures.

I'm not sure if it's related to the issue, but I have noticed that sometimes it takes a while to populate device labels if it succeeds at all. Sometimes the software locks up and my computer fans start really spinning up if I've clicked around too much and still hasn't populated device labels, despite all of traffic being generated. At this point I restart the software or switch to OLA. I was worried I'd not implemented discovery correctly. But then in Chamsys and in OLA, device labels and parameters populate nearly instantly every time.

Platform and software version

Mac OS 14.8.3 (23J220)
Macbook Pro 2019 - Intel Core i9

ENTTEC Storm10 DMX node firmware v1.5.5

DMXRouter 1.11.2

Possible fixes

The standard isn't super explicit about whether or not to probe parameters not listed under a SUPPORTED_PARAMETERS response that aren't the minimum required parameters.

ANSI E1.20 2010 section 10.4.1, page 55

PIDs that are included in the minimum support list, indicated by the ―Required‖ column of Table
A-3, shall not be reported.

And the required parameters listed in table A-3:

DISC_UNIQUE_BRANCH
DISC_MUTE
DISC_UN_MUTE
SUPPORTED_PARAMETERS (Support required only if supporting Parameters beyond the minimum required set)
PARAMETER_DESCRIPTION (Support required for Manufacturer-Specific PIDs exposed in SUPPORTED_PARAMETERS message.)
DEVICE_INFO
SOFTWARE_VERSION_LABEL
DMX_START_ADDRESS (Support required if device uses a DMX512 Slot.)
IDENTIFY_DEVICE

My reading of it is you just need to query the above with PARAMETER_DESCRIPTION and DMX_START_ADDRESS only being queried conditionally based on the SUPPORTED_PARAMETERS and DEVICE_INFO responses, respectively. The only instance I see the use of querying unsupported parameters would be a non-compliant fixture. Maybe that can be something to opt into for debugging purposes, but I don't feel like it should be the default behaviour. It's certainly not a behaviour I've observed in other software that queries RDM.

Let me know your thoughts.

[fiverecords]

Thanks for the detailed report — you're right, and the reading matched yours exactly.

Two things were going on. The probe chain asked three optional labels (MANUFACTURER_LABEL, DEVICE_MODEL_DESCRIPTION, DEVICE_LABEL) before the device had answered SUPPORTED_PARAMETERS. And selecting a device in the RDM tab swept roughly sixty optional PIDs at it regardless of what it listed — that's the traffic you saw. On a compliant responder each one is a NACK; on a quiet one it's a timeout, and those timeouts sat in the same queue as the next device's probe on a half-duplex line, which is why labels came late and clicking around a rack bogged down.

Fixed for the next release:

• A device is asked for the Table A-3 required set, then SUPPORTED_PARAMETERS, and after that only what the list contains. A NACK on SUPPORTED_PARAMETERS is taken as "minimum set only" per §10.4.1; no answer at all means nothing optional is asked.
• Selecting a device that is still being probed waits for its list instead of firing the sweep blind.
• The old behaviour is available as an opt-in for exactly your case (fixtures under development whose list isn't complete yet): View → RDM → "Probe unlisted PIDs (debug)".

I'll post here when a build is up.