E1.20 RDM (Remote Device Management) Protocol Forums

E1.20 RDM (Remote Device Management) Protocol Forums (http://www.rdmprotocol.org/forums/index.php)
-   RDM General Implementation Discussion (http://www.rdmprotocol.org/forums/forumdisplay.php?f=4)
-   -   Help needed for a responder (http://www.rdmprotocol.org/forums/showthread.php?t=1237)

Cyril December 23rd, 2015 02:34 PM

Help needed for a responder
 
Hi !

I'm currently developping a RDM Responder. It's a project in my engineering school.

I'm currently in the discovery zone :)

So, I answer well in the DISC_UNIQUE_BRANCH command. But I've a problem with the DISC_MUTE.

Here is what my DISC_MUTE like : http://hpics.li/da64321
(First line is what the MCU received, the second line is what my MCU sent and the last line is what is on the rs485 line)

So you can see that I begin my answer correctly but here : http://tinyurl.com/nhbsr8j

On the second line you can see the end of my response but the rs 485 line is at level high before the end of my response... And on the first line, the controller receive a strange high level....

Please someone could help me ?

Thank you a lot

ericthegeek December 23rd, 2015 09:42 PM

I looks like you may be turning off the 485 transmit enable before the UART has finished sending the last byte. Many UARTs give the TX interrupt when the have started sending the byte. You either need to wait for the "shift register empty" state or use a timer to give the byte time to finish.

Cyril December 26th, 2015 04:07 AM

I've already checked.. The receive enable is put on just after the uart response...

So my problem is not resolved

Cyril December 26th, 2015 04:14 AM

Maybe my answer is not correct...

Here is what I answer to the first mute command I receive :

CC 01 1A 53 77 00 05 09 01 F0 7F 53 52 51 50 9A 00 00 00 00 11 00 02 02 00 00 00 24

Cyril December 26th, 2015 04:25 AM

Oh sorry ... My checksum calculation had a problem.. Shame on me :(

It work now :) :) :) :)

Thank you :)

ericthegeek December 26th, 2015 11:14 AM

You can use these tools to help analyze packet data, checksums, etc.

To break down hex dumps:
http://rdm.openlighting.org/tools/packet-extractor

To build example packets:
http://rdm.openlighting.org/tools/packet-builder

An EUID analyzer:
http://rdm.openlighting.org/tools/uid-converter

They're very handy tools when you're troubleshooting.

Cyril December 26th, 2015 11:23 AM

Thank you very much for these tools.
I've another question.
It happens only during the UNMUTE : the response is fine but the controller don't let the time to the responder to answer... Is it normal ?

Thank you for your help
Cyril

ericthegeek December 26th, 2015 12:44 PM

Are you saying that when the controller sends an unmute it does not wait for a response and starts sending the next packet right away? is the unmute being sent as a broadcast or vendorcast request?

Unmute is usually sent as a broadcast request, and you can't respond to a broadcast. So this is acceptable behavior when the controller sends a broadcast.

Cyril December 27th, 2015 05:17 AM

Thank you very much for your help :)


All times are GMT -6. The time now is 06:03 PM.

Powered by vBulletin® Version 3.8.7
Copyright ©2000 - 2019, vBulletin Solutions, Inc.