Syncronization of Gateway and multiple Nodes & collision avoidance

[Leonid49]

Hi everyone.

Let's imagine that one of several nodes of the network is trying to send its information to the gateway, and at that time the gateway processes the received data from another node. The duration of this processing by the gateway may take more time than the repetition cycle of the function
radio.sendWithRetry  (RECEIVER, (const void *) (& data), sizeof (data), Retries, retryWaitTime). Obviously, the transfer of information from the node to the gateway will not take place.
Such conflicts are very likely. Tell me how to avoid such situations?

Thanks.
Leonid.

[Kilo95]

I have a gateway that's connected to 4 nodes and I've never had a problem. There are 3 WeatherShields and a Sonarmote for my remote nodes

[Felix]

The radio can receive while the MCU is doing something else. It just raises an interrupt when a packet is fully received and verified by the library code.
Also the library has built in collision detection (via RSSI threshold). There is no guarantee that a collision cannot occur but this is a best effort approach by listen-first then-transmit, similar to CSMA.
Please look at the library code if you want to understand how all this is done.

[TomWS]

@Leonid49, as you point out, if the gateway is too busy with one node's message to respond to another node's series of transmissions with ACK, then, yes, none of the second node's transmissions will be properly acknowledged.   The first transmission from that node may be in the gateway's receiver and the gateway may send the requested ACK, but it's too late for the second node to receive the ACK.

The key is the design of the gateway.  A simple gateway will have this weakness - you can not take more time to process a message than the times you allocate to send with retries - this is fundamental.

A fairly simple fix, but one that generally suggests using a gateway with more RAM, is to queue all incoming messages, ACK immediately on each one, and then process them as the gateway becomes less busy.  This is what I do with my gateways, using a AtMega1284 processor if using an Atmel chip for the gateway.

Tom

[Felix]

Just wanted to mention:
the "time to process" a received packet, meaning copying it from the library buffers, takes much less time than the transmission of a packet which takes some dozens of milliseconds.
While the packet is "transmitted", the radio and RF spectrum is busy and other nodes can wait using the collision detection. Once a packet is received, another reception can start while the MCU is processing/copying previously received packet from the radio buffers. Each node waits until the RF medium is "quiet" before starting a transmission.

[Leonid49]

I guess I did not quite clear the question.
You are absolutely right, Felix, that the transfer process is longer the reception process.
I have a transmission time (3 repetitions, 50ms between repetitions) of a packet of 12 bytes with the default settings of the radio module RFM69HW, it takes 308ms, but receiving, saving a packet and sending a ACK takes 4-6ms. But in my network, only the gateway can initiate the transfer, the nodes transmit their information to the gateway only after the end of receiving the packet from the gateway. Therefore, there is no violation of the requirement of CSMA that there should not be more than one transmission device at a time in the network.

I meant that when a gateway sends a packet to a node, the node can be occupied by its internal tasks: interrogating and processing the sensor readings, turning on / off the elements of the managed object, etc. And yes, you are right that the node will accept the packet from the interrupt, but it will not be able to send a ACK to the gateway about the successful reception of the packet, because ACKRequested () and sendACK () do not work in the interrupt handler.

[Leonid49]

Hi.

Tom, Feliks, what do You can advice  me (see my last letter in this theme)?

Thanks.
Leonid.

[Felix]

The interrupt will stop whatever the MCU is doing and let the library read a received RF packet.
Then by polling receiveDone() you can do something with that packet.
So maybe it's the language barrier but I don't fully understand what you are doing so I'm not sure what to suggest.
An ACK should usually only be used to tell the sender the packet was received OK. It's an empty fast transmission/packet.

[perky]

I think the OP is saying that even though the receiving of the packet and flagging one up is interrupt driven, the sending of the ACK is part of the main code and could be blocked by other activity. However, good design practice is to have the main loop run as fast as possible in a non-blocking fashion using state machines where necessary. If you send an ACK that says 'yes, got the packet, understood its contents and it's all good' that requires knowledge of the packet structure. So I'd say to the OP make your main loop non-blocking and your response in sending the ACK will be as fast as it can be short of putting all the decoding and validation in the ISR.

Mark.

[Felix]

Thanks Mark, makes a lot of sense.

[Leonid49]

Hi.
Thanks All.
I will try do all as You advised and will message to You my rezult in this topic.
Leonid.