Timeline for SN65176 RS485 contention
Current License: CC BY-SA 3.0
21 events
| when toggle format | what | by | license | comment | |
|---|---|---|---|---|---|
| Jul 15, 2016 at 2:22 | comment | added | Reinderien | My new RS485 woes are here: electronics.stackexchange.com/questions/246097/… | |
| Jul 14, 2016 at 21:49 | vote | accept | Reinderien | ||
| Jul 13, 2016 at 21:11 | comment | added | SamGibson♦ | @Reinderien - Thanks for the test results in your recent updates. That confirms the unintentional contention on the bus. I have written up an answer to summarise my views and linked to another EE.SE topic which is very relevant. Kudos to Mark for his earlier comments :-) | |
| Jul 13, 2016 at 21:05 | answer | added | SamGibson♦ | timeline score: 3 | |
| Jul 13, 2016 at 18:59 | history | edited | Reinderien | CC BY-SA 3.0 |
added 154 characters in body
|
| Jul 13, 2016 at 15:27 | history | edited | Reinderien | CC BY-SA 3.0 |
Re-tag - not likely a noise issue
|
| Jul 13, 2016 at 13:28 | comment | added | Reinderien | @Mark, that "10 points" article is really great. In turn, it refers to AN-847 specifically about differential biasing, which I'm reading now. | |
| Jul 13, 2016 at 3:45 | comment | added | SamGibson♦ | Looking at your link to the RS232-RS485 converter, two points stand out (though no schematic is given for further analysis). They say it has "Fail-safe bias resistors" so that may affect what decisions about bias voltage and making it obvious on the scope. More importantly they confirm my suspicion - it has "Automatic Send Data Control" - bingo! The datasheet shows that the RTS signal is not used for direction control, just for parasitic power from the RS232 port. Please add a 1 s delay after Tx from the PC before the PIC attempts to Tx, repeat your original test and report back. | |
| Jul 13, 2016 at 3:35 | comment | added | SamGibson♦ | @Reinderien - Mark has already given lots of good advice. I'll just add my $0.02 re: " the biasing network is [...] difficult in practice. It's a differential pair that requires a specific termination impedance [...]" imho for temporary testing purposes, you don't care about the termination so much. You just need to bias the +/- lines so that you can see on the 'scope when they are being actively driven by the PC, or just the bias voltage from the resistors. Then run the PC-only test I suggested to see how quickly the PC stops actively driving the bus, to confirm the focus on the PC hardware. | |
| Jul 13, 2016 at 1:44 | comment | added | Mark | For an example of how I terminate, take a look at figure 10 on the last page of this document: usconverters.com/downloads/support/10waysrs485.pdf | |
| Jul 12, 2016 at 23:23 | comment | added | Reinderien | Perhaps the thevenin bias shown in goo.gl/images/yY5BjW | |
| Jul 12, 2016 at 23:16 | comment | added | Reinderien | @Mark the biasing network is a good idea, but difficult in practice. It's a differential pair that requires a specific termination impedance and so the biasing topology wouldn't just be a single termination resistor. | |
| Jul 12, 2016 at 23:14 | comment | added | Reinderien | The converter I am using is this. usconverters.com/rs232-rs485-converter-xs201a | |
| Jul 12, 2016 at 22:08 | comment | added | Mark | Sam makes a good point: some RS-232->RS-485 wait for the transmitter to be idle before disabling the driver. It takes some time to detect idle. What is the RS-485 adapter that you are using? (@SamGibson) | |
| Jul 12, 2016 at 20:52 | comment | added | SamGibson♦ | @Reinderien - I agree with Mark (+1), from those waveforms your issue is contention. There are various RS-485 adapters which fit the description you wrote, but they don't all operate in the same way e.g. some claim to have "auto-enable" of the RS-485 side. Those require time after they finish transmitting, to stop driving the RS-485 bus. I suggest focussing on just the PC transmitting (tx 1 byte then 5s pause, repeating) and monitor the bus during those pauses. I suspect you will find the RS-485 bus is actively driven for up to an extra character time longer than the transmitted byte itself. | |
| Jul 12, 2016 at 20:47 | comment | added | Mark | One thing that might help: I usually put biasing resistors on the bus, so that a tri-stated bus has a voltage about 300 millivolts below center-line (about 2.2v with a 5v bus). That way, it is obvious on a scope when the bus is not driven. It appears that your bus is always driven, which is why I suspect that the two transmitters are overlapped. | |
| Jul 12, 2016 at 20:44 | comment | added | Mark | It looks like a baud-rate of around 125k, but I don't see the stop-bit from the PC's transmission. It looks like the PIC is transmitting before the PC is done. It appears from your code that the PC's Transmit-enable is controlled by RTS, but my understanding is that there can be latency before RTS drops, especially through USB. | |
| Jul 12, 2016 at 20:23 | history | edited | Reinderien | CC BY-SA 3.0 |
Show PC code
|
| Jul 12, 2016 at 20:19 | comment | added | Reinderien | I'm fairly confident that the Z-states of the PIC side are implemented correctly, but not so confident about the PC side. It's a USB-to-UART adapter and then a UART-to-RS485 adapter. I will post my code. | |
| Jul 12, 2016 at 20:10 | comment | added | Mark | It looks to me like contention. Are you sure that the transmitter on the PC side is disabled before the PIC starts transmitting? How is the PC's transmitter-enable signal controlled? Have you looked at both the + and the - sides of the bus and do they both show the problem? | |
| Jul 12, 2016 at 19:00 | history | asked | Reinderien | CC BY-SA 3.0 |