RS485 Tranceiver IC's RX Pin

[StephenYim]

Dear All,

Here is my first post, I have some question about RDM. I bought a RDM controller from Euchips(RDM-100) to test my DMX-RDM Slave. The RDM controller can't discover my DMX-RDM Slave, and I use oscilloscope to monitor the RS485 Tranceiver IC's RX Pin(the Controller) ,I find out that, even with nothing connect to the RDM controller, the RX Pin of the controller is not steady, the voltage changing as ....High-Low-High-Low....., and with a fixed frequency. Is it normal?

[ericthegeek]

Because I don't know the details of that specific RDM controller it's hard to say for sure. What is the frequency of the high-low sequence you are seeing, and what are the voltage levels?

Most RDM controllers will drive the 485 line all of the time, except when they are expecting a response from a responder. But, it's possible that the controller is going into some kind of power saving mode where it disables the line driver when it's not actively transmitting.

For example, the following would be valid behavior (especially for a battery powered device):
1: Enable the line driver for TX
2: Send a discovery request
3: Enable the line driver for RX
(Nothing responds to the discovery request)
4: Disable the line driver
5: Sleep for some period of time
6: Repeat

To an oscilloscope, this might look like a relatively low frequency square wave.

This is just one hypothesis, there are many other possibilities.


That being said, I looked at the Euchips RDM-100 and I question how well implemented it is. It uses a 3-pin XLR connector, which is explicitly dis-allowed by E1.11 (on which RDM is based). If the developer didn't pay attention to the most basic physical requirements of the standard, what other critical elements were ignored?

[StephenYim]

Dear ericthegeek (http://www.rdmprotocol.org/forums/member.php?u=2980),

Thanks for your time. Attachement is the picture I took from the oscilloscope.

You can see the Frequency is 20Hz, with 5V amplitude(RDM-100 is power by USB). And the Dir Pin of the RS485 Tranceiver IC(SP3075EEN:RE & DE shorted together) also has the same waveform as the RX pin, only with 3.3V amplitude(the CPU is STM32F103). I am thinking of giving up this RDM-Controller and buy another one. Do you have any good suggestion, better with a cheap price,thanks.

[StephenYim]

And here are more information about the communication when I click the "Full Discovery" button of the window-base Application：

RDM-100: CC 01 18 FF FF FF FF FF FF 00 00 00 00 00 00 25 01 00 00 00 10 00 03 00 07 18

RDM-100: CC 01 24 FF FF FF FF FF FF 00 00 00 00 00 00 26 01 00 00 00 10 00 01 0C 00 00 00 00 00 00 FF FF FF FF FF FE 0D 28

My RDM Slave: FE FE FE FE FE FE FE AA AB 5D AE 5D AB 55 AB 55 AB 55 AB 55 AE 57 BB 57

RDM-100: CC 01 24 FF FF FF FF FF FF 00 00 00 00 00 00 27 01 00 00 00 10 00 01 0C 00 00 00 00 00 00 FF FF FF FF FF FE 0D 29

My RDM Slave: FE FE FE FE FE FE FE AA AB 5D AE 5D AB 55 AB 55 AB 55 AB 55 AE 57 BB 57

RDM-100:CC 01 24 FF FF FF FF FF FF 00 00 00 00 00 00 28 01 00 00 00 10 00 01 0C 00 00 00 00 00 00 FF FF FF FF FF FE 0D 2A

My RDM Slave: FE FE FE FE FE FE FE AA AB 5D AE 5D AB 55 AB 55 AB 55 AB 55 AE 57 BB 57


And after these command & reply, nothing happen. No matter how many times and what I try, the result is the same, still disappointing. Please help me out.

[ericthegeek]

You can see the Frequency is 20Hz, with 5V amplitude(RDM-100 is power by USB). And the Dir Pin of the RS485 Tranceiver IC(SP3075EEN:RE & DE shorted together) also has the same waveform as the RX pin, only with 3.3V amplitude(the CPU is STM32F103).


I see what you're talking about. When the RE#/DE pins (shorted together) are low, the 485 line driver's receiver is active. The line driver will read the idle state on the bus and thus drives the "RX" signal high. But, when RE#/DE is taken high, most 485 line drivers will tristate the RX pin, so it will be floating unless there is a pullup resistor. This doesn't mean it's working or not, you're just seeing normal 485 line driver behavior.


I am thinking of giving up this RDM-Controller and buy another one. Do you have any good suggestion, better with a cheap price,thanks.


I'm probably biased because I build DMX/RDM test equipment. But in my experience good test equipment is not cheap.

[ericthegeek]

RDM-100: CC 01 18 FF FF FF FF FF FF 00 00 00 00 00 00 25 01 00 00 00 10 00 03 00 07 18

RDM-100: CC 01 24 FF FF FF FF FF FF 00 00 00 00 00 00 26 01 00 00 00 10 00 01 0C 00 00 00 00 00 00 FF FF FF FF FF FE 0D 28


This is a broadcast Unmute followed by a discovery request. I didn't validate the checksums, but the overall structure looks correct


My RDM Slave: FE FE FE FE FE FE FE AA AB 5D AE 5D AB 55 AB 55 AB 55 AB 55 AE 57 BB 57


This is a valid Discovery EUID for the UID 090C:01010101.

I changed one of my responders to have that UID, then captured its response during discovery. It matches the hexdump above, so based on this I can say your discovery response data is correct.


And after these command & reply, nothing happen. No matter how many times and what I try, the result is the same, still disappointing. Please help me out.


The controller is unmuting, and then sending a discovery request for the entire UID range. But for some reason it is not accepting your response.

Based on my testing, your response data is correct. But there are still a lot of things that could be going wrong. Check timing: You may be responding too quickly, or waiting too long to respond. Another common problem is disabling the line driver when the UART TX interrupt occurs and not waiting until it has finished shifting out all 11 bits.

[StephenYim]

mDelay_usec(100); //minimum delay 172us
rdm_response_msg[0] = 0xFE;
rdm_response_msg[1] = 0xFE;
rdm_response_msg[2] = 0xFE;
rdm_response_msg[3] = 0xFE;
rdm_response_msg[4] = 0xFE;
rdm_response_msg[5] = 0xFE;
rdm_response_msg[6] = 0xFE;
rdm_response_msg[7] = 0xAA;
rdm_response_msg[8] = (ManufacturerIDH & 0xFF) | 0xAA;
rdm_response_msg[9] = (ManufacturerIDH & 0xFF) | 0x55;
rdm_response_msg[10] = (ManufacturerIDL & 0xFF) | 0xAA;
rdm_response_msg[11] = (ManufacturerIDL & 0xFF) | 0x55;



//mUID.llbytes.Char0=0x00;
// mUID.llbytes.Char1=0x00;
//mUID.llbytes.Char2=(ManufacturerIDH & 0xFF);
// mUID.llbytes.Char3=(ManufacturerIDL & 0xFF);
// mUID.llbytes.Char4=1;
// mUID.llbytes.Char5=1;
// mUID.llbytes.Char6=1;
// mUID.llbytes.Char7=1;

rdm_response_msg[12] = (mUID.llbytes.Char4 & 0xFF) | 0xAA;
rdm_response_msg[13] = (mUID.llbytes.Char4 & 0xFF) | 0x55;
rdm_response_msg[14] = (mUID.llbytes.Char5 & 0xFF) | 0xAA;
rdm_response_msg[15] = (mUID.llbytes.Char5 & 0xFF) | 0x55;
rdm_response_msg[16] = (mUID.llbytes.Char6 & 0xFF) | 0xAA;
rdm_response_msg[17] = (mUID.llbytes.Char6 & 0xFF) | 0x55;
rdm_response_msg[18] = (mUID.llbytes.Char7 & 0xFF) | 0xAA;
rdm_response_msg[19] = (mUID.llbytes.Char7 & 0xFF) | 0x55;
/*

rdm_response_msg[12] = (mSerialID->lbytes.Char0 & 0xFF) | 0xAA;
rdm_response_msg[13] = (mSerialID->lbytes.Char0 & 0xFF) | 0x55;
rdm_response_msg[14] = (mSerialID->lbytes.Char1 & 0xFF) | 0xAA;
rdm_response_msg[15] = (mSerialID->lbytes.Char1 & 0xFF) | 0x55;
rdm_response_msg[16] = (mSerialID->lbytes.Char2 & 0xFF) | 0xAA;
rdm_response_msg[17] = (mSerialID->lbytes.Char2 & 0xFF) | 0x55;
rdm_response_msg[18] = (mSerialID->lbytes.Char3 & 0xFF) | 0xAA;
rdm_response_msg[19] = (mSerialID->lbytes.Char3 & 0xFF) | 0x55;
*/
//Update mCRC
Cal_CRC(&rdm_response_msg[8], 12);

rdm_response_msg[20] = (mCRC.ibytes.HChar & 0xFF) | 0xAA;
rdm_response_msg[21] = (mCRC.ibytes.HChar & 0xFF) | 0x55;
rdm_response_msg[22] = (mCRC.ibytes.LChar & 0xFF) | 0xAA;
rdm_response_msg[23] = (mCRC.ibytes.LChar & 0xFF) | 0x55;

GPIOSetValue(DMX_DIR_PORT_ADD,MaskValue(DMX_DIR_Pin),DMX_DIR_SetTX);

DMX_RDM_Transmit(rdm_response_msg,24,0/*NO BREAK*/,MarkTime);

mDelay_usec(100); //dealy
GPIOSetValue(DMX_DIR_PORT_ADD,MaskValue(DMX_DIR_Pin),DMX_DIR_SetRX);

Above is the source code. I had delay 100us before sending my reply, and delay 100us before setting the RS485 Tranceiver to RX mode. There for, I can't find any problem with the timing. And dear ericthegeek, thanks for your time&help.
(http://www.rdmprotocol.org/forums/member.php?u=2980)

[sblair]

I would suggest putting a scope on the line and use the Transmitter Enable line as the scope trigger. This way you can accurately measure the timing of what is occurring on the wire to see how much delay there is from the end of the request to the beginning of your response. Also if after you respond you want to make sure you aren't holding in transmit too long that you aren't missing the next request from the controller.

[ericthegeek]

To add to what Scott said, it's a good idea to look at the actual 485 signals, and not just the digital side of the 485 driver. The analog waveforms on the bus may help you determine if you have multiple line drivers that are trying to transmit at the same time.

Also, microcontroller delay routines are notoriously inaccurate, especially if there is an RTOS involved. A 100us delay will be *at least* 100us, but can often be much longer depending on how it's implemented. Use the scope like Scott suggested to see the actual timing.

(I'm about to sign off for the night, so we'll talk again tomorrow)

[StephenYim]

Dear sblair & ericthegeek,

Thanks for your help. I changed a new RS485 Tranceiver, and the RDM-100 discovered my RDM-Slave finally. Thanks!

[ericthegeek]

Glad to hear you got it working.

As you proceed with your development, I'd encourage you to consider attending one of the RDM plugfests. The plugfests are a great way to test your RDM equipment with a broad range of other equipment, and you'll find there are a lot of other knowledgeable attendees who can discuss and answer question. There's a plugfest in London next month, and another in Dallas, Texas in July.

[StephenYim]

Dear ericthegeek,

Thanks. I still need to fix some other problems.
See the attachment, the last three items still need to be fixed.
Any way, keep fighting:).

[StephenYim]

Dear ericthegeek,

Sorry to bother you again, but I have two question waiting for your answer.
1.Get-Command:DEVICE_INFO:
The controller get all the device-info except Sensor count, no matter how many Sensor I set in my firmware, the controller always display:Sensor count:0x00.

2. Set-Command:IDENTIFY_DEVICE:
After the communication channel is setted up(Discovery process has completed),the controller send out this command periodic:

CC 01 19 09 0C 00 00 01 3C 00 00 00 00 00 00 0D 01 00 FF FF 30 10 00 01 00 03 85
CC 01 19 09 0C 00 00 01 3C 00 00 00 00 00 00 0E 01 00 FF FF 30 10 00 01 01 03 87
CC 01 19 09 0C 00 00 01 3C 00 00 00 00 00 00 0F 01 00 FF FF 30 10 00 01 00 03 87
CC 01 19 09 0C 00 00 01 3C 00 00 00 00 00 00 10 01 00 FF FF 30 10 00 01 01 03 89
CC 01 19 09 0C 00 00 01 3C 00 00 00 00 00 00 11 01 00 FF FF 30 10 00 01 00 03 89
CC 01 19 09 0C 00 00 01 3C 00 00 00 00 00 00 12 01 00 FF FF 30 10 00 01 01 03 8B
CC 01 19 09 0C 00 00 01 3C 00 00 00 00 00 00 13 01 00 FF FF 30 10 00 01 00 03 8B

I search the RDM protocol E1.20, but find nothing about these requirement,is it different between different RDM-Controller?

Waiting for your answer,and tanks.

[ericthegeek]

Sorry to bother you again, but I have two question waiting for your answer.


No need to apologize. This forum was created to help developers like you.


1.Get-Command:DEVICE_INFO:
The controller get all the device-info except Sensor count, no matter how many Sensor I set in my firmware, the controller always display:Sensor count:0x00.


Can you post a HEX Dump of your GET_RESPONSE to the DEVICE_INFO?


2. Set-Command:IDENTIFY_DEVICE:
After the communication channel is setted up(Discovery process has completed),the controller send out this command periodic:
...
CC 01 19 09 0C 00 00 01 3C 00 00 00 00 00 00 13 01 00 FF FF 30 10 00 01 00 03 8B

I search the RDM protocol E1.20, but find nothing about these requirement,is it different between different RDM-Controller?


The standard doesn't define how controllers must behave. Each manufacturer will develop their controller to behave in a way that makes the most sense for their customers. Simple controllers will only send RDM when the uses asks for it, others will do a great deal of polling and monitoring in the background.

Having said that, periodically sending a "Sub-Device All Call" SET IDENTIFY_DEVICE on/off doesn't make any sense to me. You'd have to ask the manufacturer why they do that, and how to disable it.

Also, I notice that the controller's source UID is all zeros ( 00 00 00 00 00 00 ), this is not a valid RDM UID so you may want to ask the manufacturer to correct it.

[StephenYim]

Dear ericthegeek,

Below is my respond(I have check the CRC-from 0xCC to 0x11, the CRC is correct):

CC 01 2B 00 00 00 00 00 00 09 0C 00 00 01 42 AE 00 08 00 00 21 00 60 13 01 20 06 01 00 01 00 00 00 01 00 03 01 01 00 01 00 00 11 02 DB

I set the Sensor number to 0x11, but the RDM-100 controller display the number at the window-base application is 0x00,that's why I am so confused,thanks.

[ericthegeek]

Manually decoding that response, I see a few things:

Protocol version = 0x01 0x20. Invalid. It should be 0x01 0x00
Model ID = 0x06 0x01. Fine (manufacturer assigned value)
Product Category = 0x00 0x01. Not a valid category in Table A-5
Software Version = 0x00 0x00 0x00 0x01. Fine (manufacturer assigned value)
Footprint = 0x00 0x03. Fine
Personality = 0x01 of 0x01. Fine
DMX Address = 0x00 0x01. Fine
Sub-Device Count = 0x00 0x00. Fine. No sub-devices
Sensor count = 0x11. Fine, responder has sensors

It's possible that the invalid values are confusing the controller. Or there may be a bug where the controller is not properly reading the sensor count.

Have you implemented the sensor PIDs, and have you included them in the "Supported Parameters" list? It's also possible that the controller may ignore the sensor count if it can't send the SENSOR_DEFINITION/SENSOR_VALUE requests to the responder. I don't know how that controller behaves.

[StephenYim]

Thanks ericthegeek. I will check if controller had sent SENSOR_DEFINITION/SENSOR_VALUE commands.
thanks again.

[StephenYim]

Dear ericthegeek,

Please see attachment picture. I already include the "SENSOR_DEFINITION & SENSOR_VALUE" in SUPPORTED_PARAMETERS. But still, I RX no SENSOR PIDs command from RDM-100, and the Sensor count is=0x00. Can it be the setting of the RDM controller, maybe this controller doesn't support this kind of function.Thanks.http://www.rdmprotocol.org/forums/images/icons/icon9.gif

[ericthegeek]

Seems like it must be a bug in the controller. Get in touch with them and see if they can look into it.

BTW: The Manufacturer Label should be the Name of the manufacturer and not a URL. We're planning to add the ability to get the URL in the E1.37-5 document which is being written by the RDM Task Group right now.

[StephenYim]

Dear ericthegeek,

Thanks. About the Manufacturer Label, I just believe a single URL will provide much more info for the user,thanks:).