The RS485 port on a router packetizes the data and then it is converted elsewhere on the network using HW-Virtual Serial Port software ( but other programs show the same issue). When nothing was working, I connected RealTerm serial terminal on both ends. What I type on either end, comes out totally different on the other end. All character sets, baud rates etc. are set identically. Here are just a few of the translations. What I transmit is on the left and what I receive is on the right. The left column is from the router side to the laptop and the right column is from the laptop to the router side.

o = H o = N

O = X O = ^

c = N c = N

C = ^ C = ^

It's interesting weirdness. Uppercase C matches on both sides, but the character is also produced by uppercase O. Lowercase c matches on both sides, but the the character is also produced by lowercase o. Hoping somebody here will recognize this pattern.

 

I suggest that you look at the RS-485 signals with an oscilloscope.

 

I think the scope will confirm what I see with my eyes: that c is being transmitted and N is being received. What is the next step after that? I've tried changing speed, parity, stop bits, etc. I changed programs and still I get this mismatch.

 

I think the scope will confirm what I see with my eyes: that c is being transmitted and N is being received. What is the next step after that? I've tried changing speed, parity, stop bits, etc. I changed programs and still I get this mismatch.

Use the scope to see if there is a signal inversion (MARK/SPACE reversed) somewhere in the communications chain.

 

The oscilloscope trace should reveal all that you need to know. It will show, baud, start bit, data bits, parity bit, stop bit, as well as the actual binary data, data inversion or no inversion. No need to trouble shoot by trial and error.

 

Use the scope to see if there is a signal inversion (MARK/SPACE reversed) somewhere in the communications chain.

Okay, but if there is, then what could I do? Would there be a way to fix that through configuration of any of the parameters I can change such as parity, stop bits, packing timeout, packing length, etc? Beyond those parameters, I can't change anything else. Thanks for your suggestion!

Well, for once MAYBE, the AI is not lying as it usually does. I asked it to analyse the data pattern and this is what it came up with. Is it telling the truth? :
After analyzing the ASCII table, I found that the characters 'o', 'H', and 'N' have the following ASCII codes:

- 'o': 01101111 (binary)
- 'H': 01001001 (binary)
- 'N': 01001110 (binary)

Now, let's look at the bit patterns:

- 'o' (01101111) and 'H' (01001001) differ by 1 bit in the most significant bit (MSB) position.
- 'o' (01101111) and 'N' (01001110) differ by 1 bit in the MSB position as well.

This suggests that the baud rate mismatch is causing a bit-slip or bit-sync error, where the receiver is interpreting the bits incorrectly due to a slight difference in the baud rate.

 

Okay, but if there is, then what could I do? Would there be a way to fix that through configuration of any of the parameters I can change such as parity, stop bits, packing timeout, packing length, etc? Beyond those parameters, I can't change anything else. Thanks for your suggestion!

Well, for once MAYBE, the AI is not lying as it usually does. I asked it to analyse the data pattern and this is what it came up with. Is it telling the truth? :
After analyzing the ASCII table, I found that the characters 'o', 'H', and 'N' have the following ASCII codes:

- 'o': 01101111 (binary)
- 'H': 01001001 (binary)
- 'N': 01001110 (binary)

Now, let's look at the bit patterns:

- 'o' (01101111) and 'H' (01001001) differ by 1 bit in the most significant bit (MSB) position.
- 'o' (01101111) and 'N' (01001110) differ by 1 bit in the MSB position as well.

This suggests that the baud rate mismatch is causing a bit-slip or bit-sync error, where the receiver is interpreting the bits incorrectly due to a slight difference in the baud rate.

Have it also analyse the data pattern with the start and stop bits. I don't know what your problem is but the UART, at the physical level, looks at the complete data stream for data latching, not just the data bits.

For RS485 you can try swapping the A/B or D+/D- wires. It's a differential signal to decide MARK or SPACE.
https://ctlsys.com/support/rs-485-polarity-labeling-conventions/

 

Have it also analyse the data pattern with the start and stop bits. I don't know what your problem is but the UART, at the physical level, looks at the complete data stream for data latching, not just the data bits.

For RS485 you can try swapping the A/B or D+/D- wires. It's a differential signal to decide MARK or SPACE.
https://ctlsys.com/support/rs-485-polarity-labeling-conventions/

Thanks. I was thinking today of swapping the pins. At the moment they are matched according to the labels, but I will reverse them. I'll ask it about the start and stop bits. Time for sleep over here. In about 8 hours I'll update.

 

Post a photo of the oscilloscope screen shot and we’ll tell you what you have.

 

Thanks. I was thinking today of swapping the pins. At the moment they are matched according to the labels, but I will reverse them. I'll ask it about the start and stop bits. Time for sleep over here. In about 8 hours I'll update.

After you've been burned a few times by mysterious signal inversions you add onboard RS485 A/B swap capability on your boards.

 

Swapping the pins made a difference. It's changed from truly bizarre to normal bizarre. Some characters are coming through normally upper and lower, but other still are not. I strongly suspect now that it is the rs485 port implementation on the router, especially after reading that another router manufacturer used the same software to connect to their port. I have another model from the same firm and I will try that. It will be faster then learning how to save waveforms in the picoscope that I bought for decoding Dali-2 only to find out that when they wrote "decodes Dali" they only meant some of Dali, not Dali-2. It has manchester protocol which is what dali uses, but that's another story.

 

Check for proper bus termination and bias.
https://blog.opto22.com/optoblog/rs-485-to-terminate-bias-or-both