• 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.

                  7 months later

                  • HhaK

                    • Post #13

                    Sorry for the late followup. I had to take a long break from this project due to other work.

                    However I came back to it recently and finally managed to get the enttec usb pro working.
                    I reworked the parsing in my pd patch.
                    Bela can now receive DMX on all 512 DMX addresses via the enttec from several DMX devices I have tested. For example a Showtec TR-512 dmx trigger recorder as well as several fader boxes.

                    So far so good but I have encountered another issue now. Everything works fine when the bela is plugged into (or powered by) my computer (Mac book pro M3). Booting the patch from the IDE as well as in "run project on boot" mode works.
                    But as soon as I have the bela mini unplugged from my Mac and powered by usb adapter on an outlet it won't receive the DMX serial data anymore. I presume the enttec box is no recognized. Could it be that the serial device address changes when the computer is missing? At the moment I have this " /dev/ttyUSB0 "

                    and here the patch:

                    Can you measure the voltage on the 5V lineof Bela when powered from the external adapter?

                    • HhaK

                      • Post #15

                      Thanks for the quick reply. Right now I don't have a multimeter with me. Will check once I am home in an hour.

                      If the voltage is above 4.8V, then probably the device will be up. It could be then that it takes a while to come online on boot, so you may want to add a [delay 10000] to all loadbangs and see if that helps.

                      • HhaK

                        • Post #17

                        Just measured. 5.09V when connected to the computer. Device comes up.
                        4.98V on the external adapter. Device doesn't come up.
                        For a moment it worked on another external adapter but somehow not anymore or at least not all the time.
                        There I measured 5.01V.
                        Maybe my multimeter isn't correct?

                        I tried delaying the bang that initializes the [my serial ] by 1000 and 2000 and 10000 ms but that didn't help either.

                        It may be an inrush current thing. Try the following:

                        • set the loadbang delay to 20 seconds
                        • remove the dmx device from the usb port
                        • power on the board
                        • after 3 seconds when the lights start flickering, plug in the dmx device
                        • when the patch finally starts, does the dmx work?