Changing DMX packet size

[JBB]

I have a crappy uDMX anyma clone bought off of aliexpress and I'm having big problems with refresh rate in OLA (rocks wildly from about 0.5-3Hz). When I write my own little python program and send DMX packets from that I get a blazing fast refresh rate (probably 100+ Hz). I think this is because the python program is only sending 8 channel packets (my fixture has only 8 channels). When I move the sliders in the DMX console in the web interface the fixture lights up but with a refresh rate of about 0.5-3Hz.

Therefore, is it possible to limit the number of channels sent out of OLA?

[Simon Newton]

You can test this reasonably quickly, using the C++ or Python client
send a DMX frame with only 8 slots vs one with all 512 slots. The
output plugin only sends as much as the client - in the case of the
web interface it always sends full 512 slot frames.

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
> For more options, visit https://groups.google.com/groups/opt_out?hl=en

[JBB]

Ahh I see.. My goal is to set up an OLA server and get Lightkey (http://lightkeyapp.com/en/) to use it. So I guess I'll have to rely on Lightkey sending smaller frames.. or modify OLA's source code to cull the last zeroes from frames before they're sent..

Thanks!

[Peter Newman]

Hi,

You don't need to modify OLA's source, you can just write a client that receives the frames on one universe, truncates the frame and then sends it out on another universe.

[JBB]

That's a great idea Peter! Just wrote a small Python program that does just that and it's fixed my problem!

Thanks!

[Peter Newman]

Excellent; glad you've sorted it. Have you considered sharing the script so others can use it?

[JBB]

good idea..

It's a little buggy.. OLA seems to crash now and then when I have this set up and I haven't figured out why. Right now I deal with this by simply waiting 1 second and then retrying but that's not guaranteed to work. To set the number of channels your fixtures use modify the "channels" variable. The program shows the input frame rate on the command line (the plan is to add output frame rate as well so you can see if frames are being dropped..).

import sys, time

from array import array

from ola.ClientWrapper import ClientWrapper

#This is the total number of channels

#our fixtures are using

channels = 8

#Our input and output universes

receiveUniverse = 1

sendUniverse = 2

#This is only used to calculate input framerate

inputFrameCounter = 0

currentTime = time.time()

def dmxSent(state):

    pass

def NewData(data):

    #Send truncated frame to output universe

    global channels

    clientSend.SendDmx(sendUniverse, data[:channels], dmxSent)

    #Framerate calculation

    global inputFrameCounter

    global currentTime

    inputFrameCounter += 1

    if time.time() - currentTime > 1:

        sys.stdout.write("-Input framerate: " + str(inputFrameCounter) + "Hz \r")

        sys.stdout.flush()

        currentTime = time.time()

        inputFrameCounter = 0

print "-----truncator-----"

print "Piping data from the input of universe",str(receiveUniverse),"to the output of universe",str(sendUniverse)

#Wrapper and Client for sending to the output universe

wrapperSend = ClientWrapper()

clientSend = wrapperSend.Client()

while True:

    try:

        #Wrapper and Client for receiving on the input universe

        wrapperReceive = ClientWrapper()

        clientReceive = wrapperReceive.Client()

        clientReceive.RegisterUniverse(receiveUniverse, clientReceive.REGISTER, NewData)

        wrapperReceive.Run()

    except KeyboardInterrupt:

        print "Keyboard interrupt. Exiting.."

        sys.exit()

    except:

        print "wrapperReceive.Run() failed.. trying again"

        time.sleep(1)

[Stefan Krüger]

Hi JBB,

you can have a look at my try on wrapping the OLA-Client into a 'self-contained' threaded thing:
https://github.com/s-light/OLA_channel_mapper
its the olathreaded.py file.
i have tried to handle a ola disconnect and reconnect as clean as possible - (dont know if my way is really clean - but it works :-) )

but from your code i don't know why ola should crash..
have you tried and checkd if it really crashes? or if only the python-api in some way gets confused?

sunny greetings stefan

[Misha Mikhail]

>You can test this reasonably quickly, using the C++ or Python client

>send a DMX frame with only 8 slots vs one with all 512 slots.

Umm.. I'm having similar problem, but how do you send only 8 slots from C++ ?

I see only ola_client.SendDmx method...and it takes DmxBuffer as argument.

And I don't see any parameters in DmxBuffer where you can configure the length of it.

Am I missing something?

Thanks!

M

[E.S. Rosenberg]

You can't send less than 24 slots if you want your packet to conform to any DMX standard and not get into the unpredictable behavior zone (though to be fair some equipment will go there even for 24+ slots if you send it at higher refresh rates).

Limiting the slot count would depend on both the implementation of the driver and the core, for the FTDI driver (at least in the RDM branch) the FtdiInterface::Write() will padd the packet to 24 slots if the buffer handed to it from the core is less than 24 slots.

Looking at the code the usbdmx driver will put whatever is handed to it from the core on the line, but TBH I would assume the core already pads the packet to at least 24 slots.

From what I recall when I was working on the FTDI driver the core tends to always send 512 slot packets to the driver but my guess would be that it should be possible to change this somewhere.

HTH,

Eli

Op ma 8 mrt. 2021 om 22:50 schreef Misha Mikhail <proje...@gmail.com>:

---
You received this message because you are subscribed to the Google Groups "open-lighting" group.
To unsubscribe from this group and stop receiving emails from it, send an email to open-lightin...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/open-lighting/a5269aa1-c728-4736-b5b5-a4d000eb46d9n%40googlegroups.com.

[Peter Newman]

Yes you are Misha, just create a DmxBuffer that's the length you want.

Or are you trying to truncate an existing buffer like Johann was doing in Python? In which case you could use GetRaw and Set (but obviously make sure the length passed into Set is less than or equal to the one fetched from the GetRaw buffer:

http://docs.openlighting.org/ola/doc/latest/classola_1_1_dmx_buffer.html#aa60f3d2e6766b598466681a54e3f20a9

http://docs.openlighting.org/ola/doc/latest/classola_1_1_dmx_buffer.html#a84650b2272dd754e1c869a33a839ad3b

We'd certainly accept/welcome a PR if you wanted to add a truncate option to DmxBuffer, it should be a pretty trivial case of just reducing m_length along with a few safety checks.

Eli, that's true for the wire based DMX formats but not the Ethernet based ones. There's already a PR open to add padding to the UART plugin: https://github.com/OpenLightingProject/ola/pull/1656

The web UI normally generates a "full" frame, but e.g. ola_streaming_client can easily send a smaller frame and probably a lot of the other tool.

The core shouldn't do any processing and will pass incoming data straight back out unmodified.