Discovery response not recognized - E1.20 RDM (Remote Device Management) Protocol Forums

ericthegeek · January 13th, 2022

Look at the 485 data on the wire with a scope and decode it. Then you can see what's actually being sent, not what you think you're sending. As Scott said, turning off Transmit Enable prematurely is a common problem. You need to wait for the shift register to finish sending the byte, not for the "TX FIFO empty" interrupt.

I ran the reference code you found through a C compiler and it does produce the correct output. It has some clever boolean optimizations to reduce the work at runtime. For example: If you add 0xAA and 0x55, you get 0xFF.

If you add (0xAA.or.VALUE) to (0x55.or.VALUE) you get 0xFF+VALUE. Do this six times (for each byte of the UID), and you see why it init's the checksum to 6 * 0xFF.

January 13th, 2022	#8
ericthegeek Task Group Member Join Date: Aug 2008 Posts: 390	Look at the 485 data on the wire with a scope and decode it. Then you can see what's actually being sent, not what you think you're sending. As Scott said, turning off Transmit Enable prematurely is a common problem. You need to wait for the shift register to finish sending the byte, not for the "TX FIFO empty" interrupt. I ran the reference code you found through a C compiler and it does produce the correct output. It has some clever boolean optimizations to reduce the work at runtime. For example: If you add 0xAA and 0x55, you get 0xFF. If you add (0xAA.or.VALUE) to (0x55.or.VALUE) you get 0xFF+VALUE. Do this six times (for each byte of the UID), and you see why it init's the checksum to 6 * 0xFF. Last edited by ericthegeek; January 13th, 2022 at 10:30 AM. Reason: spelling correction

Similar Threads
Thread	Thread Starter	Forum	Replies	Last Post
Discovery response format	FishFood6	RDM General Implementation Discussion	5	November 19th, 2020 06:15 AM
Discovery Response Preamble	prwatE120	RDM General Implementation Discussion	0	January 20th, 2007 12:22 AM