News:

Server migration complete, Welcome to version 2.1.1

+-+-

+-User

Welcome, Guest.
Please login or register.
 
 
 
Forgot your password?

+-Site Stats

Members
Total Members: 15500
Latest: baggiorobertson1
New This Month: 8
New This Week: 36
New Today: 2
Stats
Total Posts: 127143
Total Topics: 15596
Most Online Today: 68
Most Online Ever: 7634
(January 21, 2020, 02:14:03 AM)
Users Online
Members: 7
Guests: 28
Total: 35

DMX in high channel counts

Started by zwiller, January 19, 2016, 09:11:04 AM

Previous topic - Next topic

0 Members and 1 Guest are viewing this topic.

AussiePhil

Quote from: tbone321 on January 21, 2016, 07:36:57 AM
If this is really how the F16v2 works, then that seems to be a very poor implementation of E1.31 and even DMX 512 for that matter.

It's got ZERO to do with the E1.31 implementation.

As for DMX, it can't be a poor implementation as the standard has been followed, nothing in the standard mandates that the sender has to allow for universes less than 512 just that it can be smaller than 512.
David has implemented DMX and documented his implementation, IE I always send 512.......
It is up to the Sender to determine the content of the data slots and in reality this is you not the controller, as you have the ability in xl4 to define a full 512 slot universe dedicated to dmx..... I'd suggest as I did before people just create a dedicated DMX universe and get on with life, this will then have zeroed data for the unused slots.

I actually like that Dave has implemented the send data as a 512 block as this consistent and provides easy support.

Two further things I do agree with.
Unused slots should contain zeroed data.
DMX devices that can't handle short universes have extremely poor coded firmware and you have to question their overall reliability.

Having said that, most older professional equipment will send a full 512 slot packet at full data rate and this has long set an expectation of what a DMX frame will look like when it is sent and a lot of firmware got coded based on Microchips example code that counted the (512) slots to know when the end of the frame had arrived as this was "normal" DMX sending.

I fell into that trap when I wrote my first DMX receive firmware and quickly changed it when testing with one of those cheap chinese 192ch DMX desks that sent a short DMX frame :)

tbone321

Quote from: pixelpuppy on January 21, 2016, 02:40:50 PM
Quote from: tbone321 on January 21, 2016, 12:22:40 PM
It is a poor implementation because there is NO requirement for a DMX 512 universe to always be 512 channels.
The SanDevices controllers do the same thing.  If you set an output to DMX it will always output a full 512 slots regardless of what  you set the pixel count to be on that port.  I remember reading some time back that Jim St.John specifically added this to the firmware because of problems with DMX devices that didn't work properly if the DMX frame was not a full 512 slots.


That is only half of the reason I think that and the less important of the two.  I actually have no real issue with it always putting out 512 channels of data.  RJ did that as well with his DMX dongle and ETD to make sure that there were no performance issued based on the number of channels being used.  The main issue that I see is that it will pull 512 bytes of data for that DMX channel and jump universes to do it.  This either forces me to reserve a full 512 channels for DMX use even though that really has become a thing of the past or have the controller add channels to my DMX stream that I didn't want.  I guess I just had an issue with it jumping universes to get 512 bytes of data when FPP makes it soooooo easy to contain my DMX channels in their own little universe. 

AussiePhil

Quote from: tbone321 on January 21, 2016, 04:24:39 PM
That is only half of the reason I think that and the less important of the two.  I actually have no real issue with it always putting out 512 channels of data.  RJ did that as well with his DMX dongle and ETD to make sure that there were no performance issued based on the number of channels being used.  The main issue that I see is that it will pull 512 bytes of data for that DMX channel and jump universes to do it.  This either forces me to reserve a full 512 channels for DMX use even though that really has become a thing of the past or have the controller add channels to my DMX stream that I didn't want.  I guess I just had an issue with it jumping universes to get 512 bytes of data when FPP makes it soooooo easy to contain my DMX channels in their own little universe.

Actually RJ did it because that is how the example is written from Microchip and it also matched the way the ENTTEC Pro worked, really had nothing to do with performance at the time, it was purely consistency with the most popular commercial dongle and code examples.

I do agree that jumping universe boundaries is not a good thing as this can lead to weird unexpected results.

@Dave Pitts:
Feature enhancement: allow the user to select the exact block of channels they wish to use (eg 10,001 -> 10,0020) but still send all 512 slots with unused slots being zeroed out.
This would solve the concerns raised whilst maintaining compatibility for poorly coded receivers and also ensures no unintended data is present in the DMX stream.


tbone321

Quote from: AussiePhil on January 21, 2016, 04:43:56 PM

Actually RJ did it because that is how the example is written from Microchip and it also matched the way the ENTTEC Pro worked, really had nothing to do with performance at the time, it was purely consistency with the most popular commercial dongle and code examples.

I can only go by what he told me.  He could have been referring more toward what he was doing with PixelNet on both the USB dongle and ETD and it really made sense to do it that way, especially for PixelNet with its high channel count per universe.

Quote from: AussiePhil on January 21, 2016, 04:43:56 PM
@Dave Pitts:
Feature enhancement: allow the user to select the exact block of channels they wish to use (eg 10,001 -> 10,0020) but still send all 512 slots with unused slots being zeroed out.
This would solve the concerns raised whilst maintaining compatibility for poorly coded receivers and also ensures no unintended data is present in the DMX stream.

If this has been implemented or is about to be, then I have no issue at all and like that level of flexibility.

AussiePhil

Quote from: tbone321 on January 21, 2016, 05:28:12 PM
Quote from: AussiePhil on January 21, 2016, 04:43:56 PM
Actually RJ did it because that is how the example is written from Microchip and it also matched the way the ENTTEC Pro worked, really had nothing to do with performance at the time, it was purely consistency with the most popular commercial dongle and code examples.
I can only go by what he told me.  He could have been referring more toward what he was doing with PixelNet on both the USB dongle and ETD and it really made sense to do it that way, especially for PixelNet with its high channel count per universe.

Most likely, I'm going all the way back to the original DMX dongle, way before pixelnet was conceived and in the days RJ and I spoke all the time.

Yep hopefully DP sees this thread and enhancement request and can implement it :)

gadgetsmith

Quote from: AussiePhil on January 21, 2016, 04:43:56 PM

I do agree that jumping universe boundaries is not a good thing as this can lead to weird unexpected results.


I'm not understanding on how it would lead to "weird unexpected results"?  I think it's irrelevant what data is contained in unused slots of the DMX packet, and it would seem much easier to code opposed to having to insert data (zero is still data) that doesn't already exist.  No?


AussiePhil

Quote from: gadgetsmith on January 21, 2016, 07:15:41 PM
Quote from: AussiePhil on January 21, 2016, 04:43:56 PM

I do agree that jumping universe boundaries is not a good thing as this can lead to weird unexpected results.


I'm not understanding on how it would lead to "weird unexpected results"?  I think it's irrelevant what data is contained in unused slots of the DMX packet, and it would seem much easier to code opposed to having to insert data (zero is still data) that doesn't already exist.  No?

Simple,

Ok scenario, you have sequenced 256 to 512 of universe 2 for your dmx controllers in XL4. You tell the f16v2 to start the dmx output at absolute channel 768 (assuming 512ch universes), this then crosses over into the 1-256 of U3.
U3 contains the first 170 pixels of your megatree.
Now your DMX frame has data from U2 - 256 -> 512 then U3 - 1 -> 256

No dramas if your DMX controllers are configured only to use the first 256 channels HOWEVER if you mis configure a controller which isn't that hard to do you may be using data from the range U3 1->256.

At this point you would be getting pretty flashing lights that could be so wrong you immediately notice or they may be close enough that it doesn't get noticed till show time and you wonder where the issue is.

If the "unused" slots where zeroed out then you would immediately start looking why your lights were not working

Make Sense?

Now add some laser controllers or moving heads into the mix and the unexpected data on those slots could be dangerous (laser) or annoying due to the 8 to 12 channels some of those units consume.
If you expect from your DMX normal days that

tbone321

You can get weird and unexpected results if for some reason one or more of your DMX devices winds up on the wrong address and still appears to be working because it is still getting data, just the wrong data.  If you are doing something that is for the most part incorrect because it is easier to do it that way, that by definition is a poor implementation of something.  I would say that it is really not all that much harder to code.  These routines should be using an array to store the data read in and supply the data being sent out.  If this is the case (and it usually is), then it is simply a matter of the array being the length of the output stream and zeroing it out prior to the first read.  From that point on, the input routine reads the input data that it is told to and writes those values to the relative positions in the array.  When it reaches either the end of the universe or where it was told to stop, it simply repositions back to the beginning of the array and waits to start writing again.  Any positions not written to will still be zero.  The output routine simply starts at the beginning of the array and writes out the values stored there, including the zero's at the end with no need to insert anything.

gadgetsmith

Yes, if the DMX controller is configured wrong, strange things will happen, but not because of data contained in the DMX packet. Arguably, it might be harder to troubleshoot this issue, but doubtful.  If your controlling a device that might cause physical injury to a person or property, DMX is the wrong protocol to be used.

All things setup properly, It'll work either way, so that's what's important, IMO.

Support FPP

+- Recent Topics

Raspberry PI 4 won't connect to WIFI by rbarry1068
Today at 11:18:38 AM

Sequence freeze by Poporacer
Today at 11:04:54 AM

Beagle Bone Black for sale by ppanelli3
Today at 10:40:18 AM

Port 11 not working by rossg10
Today at 09:57:03 AM

Remote script issue by mac1321
Today at 06:43:26 AM

BRP Voting Plugin - Allow others to vote for your songs! by plaberge
December 02, 2022, 11:15:17 PM

Bacground sequence by darylc
December 02, 2022, 07:34:21 PM

Fpp 6.2 ui password by darylc
December 02, 2022, 07:30:33 PM

Updating from FPP Version 3.5.4 to the latest FPP 6.1 by Poporacer
December 02, 2022, 07:07:09 PM

schedular wont do anything ever by spudgunman
December 02, 2022, 05:52:55 PM

Powered by EzPortal
Powered by SMFPacks Menu Editor Mod