|
RDM Physical Layer/Hardware Discussion Discussion and questions relating to the physical or hardware layer of RDM. |
|
Thread Tools | Search this Thread | Display Modes |
March 24th, 2015 | #1 |
Junior Member
Join Date: Mar 2015
Posts: 11
|
RS485 Tranceiver IC's RX Pin
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? |
March 24th, 2015 | #2 |
Task Group Member
Join Date: Aug 2008
Posts: 378
|
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? |
March 24th, 2015 | #3 |
Junior Member
Join Date: Mar 2015
Posts: 11
|
Dear ericthegeek,
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. |
March 24th, 2015 | #4 |
Junior Member
Join Date: Mar 2015
Posts: 11
|
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. |
March 24th, 2015 | #5 | |
Task Group Member
Join Date: Aug 2008
Posts: 378
|
Quote:
I'm probably biased because I build DMX/RDM test equipment. But in my experience good test equipment is not cheap. Last edited by ericthegeek; March 24th, 2015 at 10:51 PM. Reason: Spelling Correction |
|
March 24th, 2015 | #6 | |||
Task Group Member
Join Date: Aug 2008
Posts: 378
|
Quote:
Quote:
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. Quote:
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. |
|||
March 24th, 2015 | #7 |
Junior Member
Join Date: Mar 2015
Posts: 11
|
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. |
March 24th, 2015 | #8 |
Administrator
|
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.
__________________
Scott M. Blair RDM Protocol Forums Admin |
March 25th, 2015 | #9 |
Task Group Member
Join Date: Aug 2008
Posts: 378
|
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) |
March 25th, 2015 | #10 |
Junior Member
Join Date: Mar 2015
Posts: 11
|
Dear sblair & ericthegeek,
Thanks for your help. I changed a new RS485 Tranceiver, and the RDM-100 discovered my RDM-Slave finally. Thanks! |
March 25th, 2015 | #11 |
Task Group Member
Join Date: Aug 2008
Posts: 378
|
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. |
March 25th, 2015 | #12 |
Junior Member
Join Date: Mar 2015
Posts: 11
|
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. |
March 26th, 2015 | #13 |
Junior Member
Join Date: Mar 2015
Posts: 11
|
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. |
March 26th, 2015 | #14 | |||
Task Group Member
Join Date: Aug 2008
Posts: 378
|
Quote:
Quote:
Quote:
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. |
|||
March 26th, 2015 | #15 |
Junior Member
Join Date: Mar 2015
Posts: 11
|
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. |
March 26th, 2015 | #16 |
Task Group Member
Join Date: Aug 2008
Posts: 378
|
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. |
March 26th, 2015 | #17 |
Junior Member
Join Date: Mar 2015
Posts: 11
|
Thanks ericthegeek. I will check if controller had sent SENSOR_DEFINITION/SENSOR_VALUE commands.
thanks again. |
March 26th, 2015 | #18 |
Junior Member
Join Date: Mar 2015
Posts: 11
|
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. |
March 27th, 2015 | #19 |
Task Group Member
Join Date: Aug 2008
Posts: 378
|
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. |
March 27th, 2015 | #20 |
Junior Member
Join Date: Mar 2015
Posts: 11
|
Dear ericthegeek,
Thanks. About the Manufacturer Label, I just believe a single URL will provide much more info for the user,thanks. |
Bookmarks |
Thread Tools | Search this Thread |
Display Modes | |
|
|
Similar Threads | ||||
Thread | Thread Starter | Forum | Replies | Last Post |
RS485 networking | tracyu | RDM Physical Layer/Hardware Discussion | 0 | June 11th, 2008 05:54 PM |