Hi Michael
Thanks for that. I don’t think there will be any chance of getting a circuit for that one so I will play with what I get and try to hack one to emulate what Matthew has got.
Regarding your funny result with 120Ω connected. It is quite possible your devices have yhe 120Ω fitted on board in which case you have doubled up and possibly too much of aload on output.
Easy to check. With the device unpowered or not connected to anything measure the resistance between A and B. If there is a resistor fitted it will show up. I think it could be fitted as all application drawings showing connections do not show an external resistor at this point.
Cheers Bob
Yeah, I did that test. with nothing connected to the unit (and no usb/power), it measures about 44K ohms between A and B.
Im not really concered with it, outside of interest as it does work as needed.
I think we need to more focus on the OP issue where A and B are not the inverse of each other.
Hi Michael, Matthew
Michael. OK that establishes that. Even though that output has that suspicious glitch if you look close it would probably work OK as I think it fulfils all the requirements.
Regarding Matthews 2 devices. If I look at the truth table I can’t see how either of them would work. Negative logic would stand some sort of a chance but I don’t see how the Waveshare device would work at all. According to the circuit the TX data input pin is tied permanently to ground via a 0R (zero ohm) resistor. Matthew maybe you could check the accuracy of this circuit as you have the device in front of you. I did not notice any reference to using negative logic in any of the Core product splurges.
And in both cases a positive data input signal would put the NOT RE pin at ground which disables the transmitter and places the chip in RX mode.
Maybe I am missing something here. Will see what I can find out when my order arrives.
Cheers Bob
Hi Matthew.
Thanks. That simplifies things somewhat. I should get my order from Core on Monday. Let me have a little play and I will come up with a simple solution.
Cheers Bob
As a stupid not thought out comment, but a quick look, im not sure if setting GPIO 17 high is turning the RS485 Driver into receive or transmit mode.
We want /RE and DE to be high, which is the default state of Q1 is not allowing current to flow.
Can you re-run the test but Invert Pin 17 on the script such the low is “TX” mode ?
edit:
Look more at the hat… R7 is not connected right (as factory). So it wont make any difference.
Now I need to write this down
Hi Matthew
I note the following under “Enable driver”
According to the circuit of your hat (the one with a DE9 connector) GPIO 17 is not connected. R7 is noted as “not fitted” so you are essentially operating in some sort of “automatic” mode which looking at that waveform is not too successful.
Ch A looks to be spiking from about 0.8V to about 2.6V while Ch B seems to be going from about 1.2V to about 2.9V.
I can’t quite get my head around how ths “automatic” system is supposed to work. If a data pulse is applied while DE is high output A will go high, when the Mosfet switched DE will go low and disable the output which will go high impedance. This slight delay in Mosfet switching is what I think that spike is. If that R7is fitted turning GPIO 17 high would disable the transmission by taking DE low. Cant work.
If you are only transmitting one way the task is simplified. Removing the Mosfet completely from the board will allow transmission full time.
That terminating resistor R3 needs to be on the other end of the cable. I note this is compliant with RS422 which will be OK with RS485 signals. Disconnectthe wires from NEMA IN and measure the resistance between A and B. If terminated internally you should get 100 or 120Ω or thereabouts. If a high resistance a 120Ω resistor will have to be fitted at that point. Having it at the transmitting end will be no good. It HAS TO BE at the receiver end.
Cheers Bob
Hi Machael
As I just replied according to the circuit of that hat GPIO is not connected (by not fitting R7) and you are correct. switching the Mosfet ON will disable TX mode.
Yeah, just looking at that…
I was more thinking to leave the mosfet in play and rather allow GPIO to drive it via R7. But for that to work, you need to remove R6
As is in auto mode, when TX is low, it will be in Driver Mode, and when TX goes high it will be in receiver mode.
I think that is how it works. But when Din is low line A will be low and when it goes high and Mosfet switches and disables TX line A will go high impedance. I think the whole system depends on this high Z output to go somewhere near half rail voltage which would probably allow the RS422 receiver to work in a fashion as I think the difference between A and B only has to be 200mV. A pretty cheeky way to do this if I am correct. I have not been able to find much of an explanation of how such a system is supposed to work.
Cheers Bob
That kinda looks more correct to me (?)
that looks like one of my images where it would go High then drop down.
Can you remove the white lines and “zoom” in a little?
