You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Background: I have an "ENTTEC DMX USB PRO" which I've used with OLA for a couple years, and it works great.
I recently got a radio which is programmed via a cable which is essentially a USB-serial adapter. When I plugged in the cable and attempted (using the program "Chirp") to clone my radio's memory to my computer, it would start to work for a few seconds, and then abort with a cryptic error message. But occasionally, the cloning would complete successfully.
Eventually I discovered that OLA was trying to also access this device. I think it sees a USB-serial device, and tries to figure out if it's a DMX controller by pretending it is. If I stop /usr/bin/olad first, then my radio interface works perfectly every time.
(Both interfaces present themselves to Linux as the ID of their USB/serial chipset, unfortunately. Chirp asks for the device port each time it's run, which is annoying, but that means there's nothing it can or should do to avoid this.)
Request 1: Is there a way for OLA to avoid this conflict? Can OLA be given a list of USB devices which are known to be DMX controllers, rather than trying to grab every USB serial device it sees? My lighting and radio interfaces use different USB-serial chipsets, and I'd be willing to hard-code the ENTTEC's IDs into ola-usbserial.conf so it knows which one to use, and ignore the rest. (I don't see any option like this in the documentation, but I'd gladly be wrong.)
Request 2: Worse, OLA doesn't seem to ever stop trying. Even 20 minutes after plugging in my radio cable, olad logs show that it's still trying to get it to respond to UsbPro messages, and receiving the same errors each time. Even if OLA thinks it should get a crack at every USB serial device that's plugged in, why doesn't it give up after failing? It's making every USB-serial interface unusable for every other program on the computer.
Thanks!
The text was updated successfully, but these errors were encountered:
Background: I have an "ENTTEC DMX USB PRO" which I've used with OLA for a couple years, and it works great.
I recently got a radio which is programmed via a cable which is essentially a USB-serial adapter. When I plugged in the cable and attempted (using the program "Chirp") to clone my radio's memory to my computer, it would start to work for a few seconds, and then abort with a cryptic error message. But occasionally, the cloning would complete successfully.
Eventually I discovered that OLA was trying to also access this device. I think it sees a USB-serial device, and tries to figure out if it's a DMX controller by pretending it is. If I stop /usr/bin/olad first, then my radio interface works perfectly every time.
(Both interfaces present themselves to Linux as the ID of their USB/serial chipset, unfortunately. Chirp asks for the device port each time it's run, which is annoying, but that means there's nothing it can or should do to avoid this.)
Request 1: Is there a way for OLA to avoid this conflict? Can OLA be given a list of USB devices which are known to be DMX controllers, rather than trying to grab every USB serial device it sees? My lighting and radio interfaces use different USB-serial chipsets, and I'd be willing to hard-code the ENTTEC's IDs into ola-usbserial.conf so it knows which one to use, and ignore the rest. (I don't see any option like this in the documentation, but I'd gladly be wrong.)
Request 2: Worse, OLA doesn't seem to ever stop trying. Even 20 minutes after plugging in my radio cable, olad logs show that it's still trying to get it to respond to UsbPro messages, and receiving the same errors each time. Even if OLA thinks it should get a crack at every USB serial device that's plugged in, why doesn't it give up after failing? It's making every USB-serial interface unusable for every other program on the computer.
Thanks!
The text was updated successfully, but these errors were encountered: