• InteractivitySolved

  • Is there a way to get the serial data of an enttec DMX usb pro into a Pd patch?

  • HhaK

    • Post #1

    I need to control a Pd patch on a bela mini for an installation using DMX. I was wondering if I could use an enttec DMX USB Pro (which I have available) for that task and somehow get the serial data from the enttec via the USB port into the Pd patch on the bela mini.
    I've tried a couple of approaches but I am not sure if I am doing the right thing or if it is even possible at all.
    So far...based on the information I found in this thread:
    https://forum.bela.io/d/2453-how-do-i-make-bela-receive-serial-communication-from-arduino-within-pure-data/13
    I 've created a pd patch and a render.cpp file but getting an error message when compiling:

    Do I need to install the Pd serial library? And/Or do I need to install a driver for the Enttec?


      • HhaK

        • Post #3

        That helped. It is working now. Thanks so much for the quick reply.

        • HhaK

          • Post #5

          Now that I can receive the serial dataI I encountered another problem. I am breaking my head over how to separate the incoming continuous stream of data into useful chunks in order to control parameters in my Pd patch corresponding to individual DMX channels. I tried different EOM and type settings and so far "none" and "bytes" seem to be the most promising with the expected value range of 255. On the printout I get a repeating stream of 13 values, 6 of which are corresponding to the values of the 6 faders of my 6 channel DMX fader box I am using as an input. I'd like to map these onto parameters in my patch. I tried "unpack" and "route" objects but quickly realized that this is not working. I presume I have to somehow sample the data stream in order to access the individual values? Has someone got an idea how to approach this problem?

            Can you show an example of a message you'd receive and what each byte means? In general, you'd use [unpack] when I have to pick items from a list, or route when one item tells you where the following items need to go.

            haK . I tried different EOM and type settings and so far "none" and "bytes" seem to be the most promising with the expected value range of 255

            The question is how does your sender send the data: do they separate them via a control "EOM" byte, does it send a continuous stream where you are supposed to know what each byte means based on the earlier bytes, does it send it in bursts every X ms, so that you know the meaning of each byte in the burst, does it do something else?

              • HhaK

                • Post #7

                Thanks so much Giuliomoro!
                I managed to solve the problem. This might be a more quick and dirty approach but it works now. See attached images of the pd patch. I think the Enttec sends a continuous streams of bytes. See other image of the printout. In my case 13 bytes in a cycle whereas the first 6 and the last one were irrelevant to me. I filtered them out with a route object and by sampling the stream with triggered bangs from the baud rate counting and selecting the individual digits. In this way I could isolate the 4 parameters I needed for my patch.

                At first sight that [route] looks dangerous: if one of the values you are extracting matches any of those values, it'll break the state machine.

                Is there a pause - however small - beetween successive bursts so that you can split "messages" with a timer? Do you have specs for the protocol?

                • HhaK

                  • Post #9

                  Thanks for the advice. I could actually omit the route object altogether. It would work without it as well.
                  Unfortunately I could not find any spec-sheet on the Enttec but there are some preferences I can change in the config software. I am not that technically adept but I presume break time lets you configure the pauses between the successive bursts. No? Or is it the Mark after Break? Besides, I also wouldn't know how to split the individual message bursts with a timer object.

                  Those look like DMX parameters, not for the UART. Maybe you could try to create a new list and append incoming items to it and then print it after 10 or 15 ms of not receiving anything . That may give us an insight on the protocol?

                  Something like this:

                  Upon reading a bit more, it looks like there may be a BREAK condition set on the UART line, but that's hard to detect in a real-time safe way from Linux ... you'd need a dedicated process for the UART Rx and that's complicated... let's see if the above trick works for you.