I’m trying to use the RS485 port on a RUT955 to send DMX data - this is a protocol for control of stage lighting. I have installed ola (Open Lighting Architecture) which can send DMX over UART, and after initial configuration it does output something which looks basically correct on an oscilloscope, but at the wrong speed. DMX requires a baud rate of exactly 250k, and this is where I’m running into trouble.
I can set a baud rate using stty, but I can only choose between the “standard” rates, and 250000 is not valid.
Using setserial -ag /dev/rs485 I can see that the base baud rate is 2500000, which means that a custom divisor of 10 should do the trick. However, I’m not getting anywhere with
(normally, selecting 38,4k should activate the custom divisor). It seems this setting is simply ignored. It also complains to syslog that this method is deprecated - but deprecated for what? How do I work around this?
I’ve consulted with our R&D and we had a question regarding the setserial command you’ve used - does it come from the ola package you’ve mentioned? What does it exactly check when trying to set the baudrate?
One more question would be whether your setup functions when using, for example, 9600 or 115200 baudrates.
I’ve also got a comment that this will potentially be a hardware-limitation where you can’t really go above the maximum predefined baudrate, but if you could answer my previous questions we could look more into this.
I installed the setserial package with opkg, it’s unrelated to ola - I just figured I’d try because it’s a trick that has worked before on Linux systems (in general, I haven’t used it for UART DMX specifically). setserial is probably a dead end here.
Apart from the baud rate issue. the setup does work, in a sense; it doesn’t properly work with actual DMX receivers because they depend on the exact timing, but I’ve hooked it up to an oscilloscope and the waveform does look correct; I can see the start codes, data bytes changing as expected et cetera. Between each data packet there is a «break» which should be of fixed duration (100µs) but it does not seem completely stable, but this is probably because ola depends on the correct baud rate for this to work.
But yes, in short, ola is able to open and use the port.
It’s not throwing any errors as far as I can see (but clearly doesn’t work)
Fully understand there might be hardware limitations here. Speaking of which - the official spec says max RS485 baud is 115200, but in the WebUI it’s possible to choose up to 3000000 when adding a serial console. If that’s actually possible, I assume setserial is wrong when reporting 2500000 as base?
Thanks for getting back. I’ve consulted further and got some suggestions for you to try:
Try to setup Serial OverIP which would use the /dev/rs485. The configuration itself doesn’t matter that much, you can just keep the default settings.
Wait for the OverIP service to start running.
Turn it off.
Check the settings via the command stty -a -F /dev/rs485
Try to use ola again.
The R&D reviewed the “ExtendedSerial.cpp” file, and they have a theory about what might be happening. It’s possible that there are many older stty settings still active, and the program does not reset them. For example, serial echo is often enabled by default even though it is usually not needed.
The simplest way to reset all serial settings back to a clean default state is to start the Over IP service using its default configuration. When this service starts, it disables many unnecessary options on the serial device, which often resolves these issues.
Hi, I gave it a shot – rebooted the router, turned on Serial over IP (RS485 at 9600 baud) at gave it time to initialise, turned it off again, then started ola. Before starting ola, stty reported 9600 baud as expected. After starting ola, it says “speed 0 baud”. The actual waveform it outputs looks the same as on previous attempts.
I then tried using stty to change the baud rate while looking at the waveform on the scope, trying different baud rates starting from 230400. The waveform did not change until I got to 14440. Any settings above that (19200) looked identical. I’m not sure what to make of that.
I think I’ll have to take a closer look on the scope and measure the exact timing of the data bits to figure out what the real data rate is, after ola attempts to change it. Or maybe read register 0x18500008 of the AR9344 – bits 23:16 and 15:0 are UART1_CLOCK_ SCALE and UART1_CLOCK_STEP, they should probably reveal what’s going on …