Synchronizing half duplex communication

[Jester]

I'm working with a pair of half duplex transceivers, that need to share a small amount of data (20 bytes or so). Same type of hardware and uController at both ends
 - The problem is making sure the two ends don't try to transmit at the same time, or if they try, that they get back in sync so they take their turn transmitting.
 - Transmission can't be constant, and should only occur when the data changes and this can be infrequently (seconds to hours).
 - Power can go down and up at either end independently or simultaneously.
 - Prefer to avoid a master/slave configuration, so identical code can be used at either end.

  I'm thinking part of the message could include a revolving time stamp (say 0-499ms) to allow the receiving end to synchronize its clock to the other end and then only transmit in the 500-999ms window
 - Obvious problematic scenarios:
   + Power up both ends simultaneously, both want to send their data at the same time, and continue to do so not allowing the system to synchronize.
   + Assuming the two ends were synchronized and shared their data, and have now gone dormant and then the clocks slowly drift apart (@100ppm => 84 minutes => 500ms)

I'm sure this problem has been solved countless times, any bright ideas?
   

[coppice]

The two commonest methods to make half duplex work are:

• Make one end poll the other, so you have a master and a slave (no master baiting please), and you don't get collisions when things are working properly.
• Use random backoff times before retrying a collision, and eventually the messages will get through.

Most MCU applications have some activity that allows a reasonably random time to be derived. Just using a PRBS, with different seeds embedded in the code of the two MCU may be sufficient.

[Jester]

The two commonest methods to make half duplex work are:

• Make one end poll the other, so you have a master and a slave (no master baiting please), and you don't get collisions when things are working properly.
• Use random backoff times before retrying a collision, and eventually the messages will get through.

Most MCU applications have some activity that allows a reasonably random time to be derived. Just using a PRBS, with different seeds embedded in the code of the two MCU may be sufficient.

That makes sense:
 - I don't particularly like the idea of the master/slave because for one thing the master would have to ping the slave too frequently
 - I was thinking about the random delay before posting, I think that's a better fit for this problem.

I'm mostly retired now, one thing I miss from a regular work environment is the opportunity to bounce ideas and questions off other engineers/colleagues.

Thanks

[coppice]

I'm mostly retired now, one thing I miss from a regular work environment is the opportunity to bounce ideas and questions off other engineers/colleagues.

This is a key reason why permanent mass working for home will never actually work. Its fine when you are experienced, but how are people going to reach that state without a lot of day to day interaction with more experienced versions of themselves?

[Marco]

- I don't particularly like the idea of the master/slave because for one thing the master would have to ping the slave too frequently

Unless it's super duper low power, what does it matter? You might even be able to get tricky with PWM with external triggers to do the polling only causing an interrupt on actual comms.

[Siwastaja]

Best solution depends on the actual problem.

What are the two devices and what is the content of their communication?

[Jester]

Best solution depends on the actual problem.

What are the two devices and what is the content of their communication?

The two devices are simple I/O,  23 bits in and out on each side, very slowly changing

[Jester]

- I don't particularly like the idea of the master/slave because for one thing the master would have to ping the slave too frequently

Unless it's super duper low power, what does it matter? You might even be able to get tricky with PWM with external triggers to do the polling only causing an interrupt on actual comms.

Power is not the issue, constantly transmitting in unlicensed band is not allowed. I'm not sure where they draw the line between intermittent transmission is okay (think garage door opener) and constant transmission (think telemetry) is not.

[Jester]

I'm mostly retired now, one thing I miss from a regular work environment is the opportunity to bounce ideas and questions off other engineers/colleagues.

This is a key reason why permanent mass working for home will never actually work. Its fine when you are experienced, but how are people going to reach that state without a lot of day to day interaction with more experienced versions of themselves?

Agreed and how do you even quantify the value of that constant interaction?

For a while I worked in a research facility with lots of PhD types, I really enjoyed chatting with the Physics group and the way they viewed problems from that perspective.

[Marco]

Power is not the issue, constantly transmitting in unlicensed band is not allowed. I'm not sure where they draw the line between intermittent transmission is okay (think garage door opener) and constant transmission (think telemetry) is not.

You don't really have to poll, you just need to keep the slave synchronized enough its transmission slot doesn't start overlapping with the master transmission slot. With crystal clocks that doesn't need to happen all that often.

[Jester]

Power is not the issue, constantly transmitting in unlicensed band is not allowed. I'm not sure where they draw the line between intermittent transmission is okay (think garage door opener) and constant transmission (think telemetry) is not.

You don't really have to poll, you just need to keep the slave synchronized enough its transmission slot doesn't start overlapping with the master transmission slot. With crystal clocks that doesn't need to happen all that often.

Good point, perhaps every 10 minutes would do it

[ve7xen]

Detecting collisions is non-trivial, especially with an air interface, so is probably off the table.

If there are only two nodes you could do something as simple as duplicated transmissions with a different delay time for each node. This should be able to guarantee that at least one copy is received. For example, say your frame takes 1ms to transmit. You set a minimum 'update' interval of say 10ms. Node 1 transmits at 0ms and repeats at 3ms. Node 2 transmits at 0ms and repeats at 6ms. Even if one copy of the transmissions overlaps, the other is guaranteed to not overlap.

[Doctorandus_P]

Collision avoidance is quite common and effective.

I'm using this on Uart & RS485 over CAT5 wiring @ 115k2baud.

First you packetize your data, and just for good measures you also add a CRC, just to be sure.
Then, when you want to send, you start by listening for silence on the bus, and you do this for the time of a byte.
If you've detected a silence, then you switch as fast as you can to sending the data.

This means there is only an opportunity of 100ns for an collision to start happening, that means that if you send one packet per second on average, the collision rate will be one in ten million.
Collisions are still possible, and that is where the checksum adds further reliability.
On top of that, you may add a requirement for an acknowledge response. If a node sends a packet and it does not get an Ack within some reasonable time (few ms) then it assumes the packet was not received properly and it resends the packet.
If reception of the same packet twice can be a problem, you have to add a packet numbering or timestamp feature.

Another possibility is to use CAN.
because this has an active and a passive state, collisions can be detected (and remedied) CAN peripherals in uC's should detect collisions in hardware and back off to prevent data corruption.

Reading back the data with RS485 to detect data corruption does not work.
Even if the data is severely corrupted down the line, a uC node tends to read back it's own data perfectly all right because of the cable resistance between itself and the noise source (for example another node sending).