E1.20 RDM (Remote Device Management) Protocol Forums

E1.20 RDM (Remote Device Management) Protocol Forums (http://www.rdmprotocol.org/forums/index.php)
-   DMX512 Discussion (http://www.rdmprotocol.org/forums/forumdisplay.php?f=10)
-   -   DMX512 Alternate Start Code=91h (http://www.rdmprotocol.org/forums/showthread.php?t=1276)

majid January 23rd, 2018 05:49 AM

DMX512 Alternate Start Code=91h
I am developing DMX array LED fixture, (not RDM)
It will be 1 meter length 10 RGB pixels,

I plan to make it flexible pixel length : 1, 2, 5 and 10 pixel/meter
so the footprint will be 3, 6, 15 and 30 respectively

I know it can be done in RDM using PERSONALITY,
but the fixture is not RDM , it is DMX
I plan to use DMX signal to configure the pixel/meter of fixture.

my question is according to ANSI E1.11, Table D1
can I use Alternate START code 91h + MID + PixelLength to configure the fixture?

we have registered MID
we do not have registered START code

ericthegeek January 23rd, 2018 08:41 AM

Yes, you can.

Whenever possible, I'd encourage you to use RDM, but if that's no possible then this is an appropriate use of the 91h Start Code.

prwatE120 January 23rd, 2018 12:04 PM

Can you please explain WHY you have chosen not to use RDM for configuration ? It is exactly what RDM was designed for.

And please don't tell me there are no RDM Controllers available. ETC, Robe,Chauvet,Lumen Radio, City Theatrical, Goddard Design, JESE Ltd, Swisson, ELC, to name but a few have RDM tools available for very reasonable prices.

majid January 23rd, 2018 12:10 PM

Aim is to ajdust pixel length during production
Single hardware, different models
Very rare for customer,


majid January 23rd, 2018 12:39 PM

We will also have RDM model
Proposed to customer as adjustable LED/pixel and start address

This is for DMX model, proposed to customer as fixed pixel models, pixel will be adjusted only during production, not customer,

shawn November 15th, 2018 12:11 PM

@majid: I'm curious, what sort of hardware are you using inside your box? A custom microcontroller or something, or off-the-shelf DMX hardware?

majid November 15th, 2018 12:37 PM

MCU mostly based on Microchip AVR. We write our own code.

shawn November 15th, 2018 03:22 PM

I've written my own stuff (the current one is for the Teensy, full RDM & DMX) too, but I don't really build the hardware. I've been wondering what sort of needs people have when they need to adapt software and API's into their own packages.

For example, what DMX and RDM features do you write into your products?

majid November 15th, 2018 09:41 PM

I should say I am also learning RDM
I have just finished 2 designs, still optimizing them.
For sure the forum elders and real field experienced seniors have the right answer for your question.
I think RDM is almost like an endless sea, you can always find new features to add and optimize them.
More features means more complexity and hard to maintenance and debug.
As in Table A-3 supporting min 9 parameters is mandatory. The rest depends on your requirements.
DMX PERSONALITY is the parameter that can be used creatively to suit your requirements.
As example I used PERSONALITY to select LED/Pixel options of my RGB Pixel Line fixture.
I would like to recommend to develop your equipment gradually, start from min required 9 parameters.
Before adding a single bit, absolutely verify your device with RDM Tester Package.
Execute RDM tests regularly at every step of progression of your project.

shawn November 16th, 2018 02:25 AM

I like your phrase describing RDM, "endless sea". :)

I'm already passing most of OLA's RDM tests (342/426). The 6 that fail and several that don't execute are due to DMXKing's ultraDMX2 PRO not allowing vendorcast nor broadcast nor some discovery packets through. The rest don't execute because I don't implement every RDM feature.

What sort of RDM test hardware and test suites are you using?

My issue is figuring out how I can make the API and framework design the most useful. I figured since you're building your own in a real product, you have a glimpse into what features you're actually finding useful and which you're not using. For example, "We use feature XXX the most, but not YYY because it turns out to be useless for us."

I wrote my own just because I enjoy such things and so don't have any real-world experience with it.

majid November 16th, 2018 09:02 PM

I have got ENTTEC USB Pro
And OLA Responder Tester on Raspberry Pi, I am content with them.
I have succeeded passing 367 of 426, not run 59.
As I said, I have no real field experience of RDM, we will release first product in 2019.
You may review old threads of this forum and benefit info shared by experienced old members.
My device is fixed LED fixture just supports min required plus DEVICE_HOURS and POWER_CYCLES
in our requirements the RDM as user interface of device is in second priority and min RDM features satisfies the requirements. Our first priority is DMX light fixture durable, robust device against harsh outdoor environment. It must survive ESD, spikes, rain, sun,...
I think in complicated moving devices such as scene light effect robots it is critical to support more RDM features and various sensors.

All times are GMT -6. The time now is 09:56 PM.

Powered by vBulletin® Version 3.8.7
Copyright ©2000 - 2021, vBulletin Solutions, Inc.