I2C multi master comminication

I have a Multi master setup directed to a single slave with a Ethernet connection to send data from position x and position y to the server, but when both (by accident) sends data at the same time only one of the masters data is received, is there a way to add a check/ delay to ensure that both communications go through?

Any help would be greatly appreciated.

Have the receiving end send back a "got it!" type of message.
If answer is not received, retry the transmission.

I strongly guess you’ve chosen the wrong connection method by using I2C. Why did you choose I2C? Why do you need two Arduinos?

I think you have this backwards - I'd use a single master with the ethernet, and have the other two be slaves and have the ethernet-bearing master grab the data from data gathering slaves, instead of the other way around.

wvmarle:
Have the receiving end send back a "got it!" type of message.
If answer is not received, retry the transmission.

A slave cannot initiate the communication though.

The basic Arduino library doesn't do multi master. As far as I know, nobody has published a version that does.

Have you checked the result of endTransmission()?

DrAzzy:
A slave cannot initiate the communication though.

I know, never implied it does.
Master sends message, slave replies to the master - commonly with a piece of requested data, in this case with an acknowledgement. That's how master knows that its transmission has been received.

The I2C sniffer already uses the ACK feedback of the protocol. If no slave responds to an address, no ACK signal is generated and the transmission terminates with an error.

As the lines are shared, in this case the master may not be listened to, but still receive an ack which was meant for the other master. So it should be something more unique.

wvmarle:
As the lines are shared, in this case the master may not be listened to, but still receive an ack which was meant for the other master.

If the requests are the same, the answer applies to all masters. Different requests are recognized and stop the lower priority masters.

Instead of us telling you some way, it would be better for all if you tell us what you want to do.
how far the wires are, the speed of response and such.

we may offer you a better way all around.

Thanks for all the replys they were realy helpfull.
So to address the questions

  • Unfortunately I do not know the speed, currently the wires are about 20cm apart but that will change in the next stage of development as this will be a multi access system connected to a single terminal the action boards will be about 2-5 m away from each other
  • The replays will be different so I need to assume that each request will need to be handled individually
  • Thanks DrDiettrich this answer seems to be spot on I’ll test this and get back to you
  • I would brette to have the Ethernet as the master but unfortunately the action-boards that connects to the terminal has a BLE extension and to constantly poll to see if any message has come through would be difficult to get it down to a decent reaction time

Karel_Kruger:
currently the wires are about 20cm apart but that will change in the next stage of development as this will be a multi access system connected to a single terminal the action boards will be about 2-5 m away from each other

  1. that's a lot of wiring for I2C. Lots of stray capacitance, lots of interference. It may simply stop working due to that. Stronger pull-ups and twisted pair wiring helps here, but no guarantee it will work.

  2. you have a single terminal - why isn't that the I2C master and all the action boards the slaves? Saves worrying about multiple masters on the bus.

wvmarle Thanks for the reply

The reason is that the action-boards with the BLE embedded needs to wait for a signal to attach once it receives a payload of data it then needs to send it to the terminal, which then relays the data to a server and after some verification it needs to send the reply back, because the communication needs to be triggered by the BLE it is difficult to make the terminal the master. Unfortunately I could not find a way for it to work with the terminal being the master.

You're now suddenly talking about BLE. What happened to the I2C?

I thought I had an understanding of your layout. That understanding is now completely gone. Please post a schematic drawing of your layout and the modes of communication between them.

apologies wvmarle if it was confusing. The setup is as following on the action-board there is a NFC and ble that waits for communication from a phone (nfc or ble) this data is then transfers using I2C to the terminal which then using an Ethernet shield sends the data to the server. There are multiple action-boards to a single terminal (at most 5) which will be between 2-5 m away from the terminal

I see. That helps getting an idea of what’s going on.

It appears not very time sensitive (you have the inherent and unpredictable delays of the BLE or NFC communication for starters). The terminal could poll the action boards for data instead, then a request could come in every 10-100 ms and you don’t have to worry about the multi-master collision. You still have the problem of the large length of wires attached to the master.

Or if you have WiFi available you could use a NodeMCU or WeMOS in the action boards, and send the data directly to the server, without having to pass through the terminal.

I should have posted the setup quicker. Sadly WIFI might be excluded due to it being on an internal network that does not supply WIFI. I still have some problems with the unpredictable delays of the BLE or NFC but as you said its quite unpredictable. Since there are multiple terminals there might be cases of communication happening at the same time which in my case caused an error and data loss since it did not resend, I added a method to cater for a retry connection currently as suggested by DrDiettrich, and I will begin to test this new setup shortly

There are other wireless options available, too. May work better than wires for your application, also more flexible.

BLE can be read at quite a distance in contrast to NFC, which is a few cm usually (but has options for longer distance). So you may have to find a way to ensure the phone is on the action board, not a few meters away from it. The way you describe it the action boards are close enough together to allow multiple boards to contact the same phone.

The ble will be limited using the very unreliable rssi signal strength to fix the distance but ill defiantly look into wireless options