Samstag, 17. November 2012

[RS485] Hardware Hack

Uh, that's a bit embarressing - of course the 0x00 was sent on purpose, as Strings are always zero terminated in C. If the additional byte would be a 0xFE or a 0xFF this would have been caused by the issue described below.

Nevertheless, what I intended to state was that there is a bit of hardware that causes problems - if not now, than later when having bidirectional data transfer.

The original circuit is here:

The problem causing part is the WE-SL2 current compensing inductivity. The purpose for this part in design process was to add some line filtering for harsh environments.

This works excellent for unidirectional data transfers, because when data is transmitted the inductivity load's itself, as the inductivity law states. When then suddenly the data direction changes, the inducitivty becomes a source and uses it's stored energy to try to maintain the current into the original current direction (out on RS485_B_A and RS485B_B), but ont he other side there's the PC as a sender, who sends current on RS485B_A and RS485B_B in. So there is - like on the streets - a "collision" of the currents heading into different directions. So what might happen? Truck against city car; the stronger one wins and the weaker is damaged.

In most cases the Max3078 is likely to be the weaker part in this conflict and after ~10k data direction change cycles it starts malfunctioning and a few thousend cycles later it is defect.

So what's the solution? Well, simply remove the evil inductivity and  replace it by 0R resistors ;)


Here is a before/after image:

 ... before

 ... after

Well, I think after testing the second direction I'm ready to start porting the TBL-AVR code

Keine Kommentare:

Kommentar veröffentlichen