9 thoughts on “LE50-868 LBT not working as expected”
We
have set up a star network with 27 clients, each of them sending a 10 byte
message every 20 minutes and in addition sporadically a set of three 25 bytes
message with 30 sec interval several times a day.
The
clients have firmware GC.S00.01.04-B008 and are operated with LBT S226=2, Repetition
S223=10, random waiting S227=1.
We
observed that some frames go lost for which we suspect a data
collision anomaly. In order to further investigate this, we have set up a test
network with same settings as the original, but with only three clients. When we issue messages simultaneously
to any two clients, it can be seen that one of them starts sending whilst the other one is quiet, only receiving
data as expected. After the first one stops transmitting with an OK at its
serial port, the second one, however, in most cases does not start transmitting but issues an
ERROR. Only in less than 5% of the tests the message is received from both
clients. Same behaviour is observed for all three LBT levels.
When
we switch off the LBT (S226=0) then in the message is received from both clients
in more than 95% of the test cases.
Is
there anything we have overlooked in the LBT setting?
Do
we need a special setting also for the network server?
For
how long does a module wait until the radio channel is free and it starts
transmission?
Hi
please
consider that in case of LBTactive, when channel is not free,
module transmission is stopped and message got is ERROR and any data is
not sent on radio.
Module send data again only when radio is free.
every LBT has a timeout of 4ms
Dear Cosmin,
many thanks for the swift response.
But there is a discrepancy between your reply and my perception of the "Star network protocol stack user guide".
Accordingly the module should wait and retry to transmit several times as specified in register S223. Waiting time between subsequent trials should be random between 0 and 64ms because register S227 is set to "1" when LBT is active.
How does it fit with the 4ms time out?
I would expect ERROR to be issued only if eventually after the number of retries specified in S223 there was no Ack from the receipient.
Hi,
sorry,
maybe my description was not so clear, 4mS it is the LBT duration, so
when module is in listen mode (LBT), it remains in LBT for 4ms, and
until the radio is busy you will get always ERROR.
Thank you Cosmin for this further clarification, but what happens after the 4 ms?
I would expect from the description in the protocol user manual that the module listens again after a random waiting time of up to 64ms according to S227=1 and then if the channel is still busy it repeat this as many times as is defined in S223?
Yes it is correct,
module
listens again after a random waiting time up to 64 mS ….and listening
duration is 4 mS, 4 ms is not timeout between listening but it is LBT
duration.
Thank you Cosmin,
since I now understand how it should work, I wonder what is wrong in our set up.
Again: when two messages are sent simultaneously from two clients to the server, then only one is received. The other client obviously senses through LBT logic that the channel is busy, but it does not retry transmission regardless of what is defined in S223 and so its message is lost.
Answers are from my specialist colleague Romano.
Hi
I have 3 hypothesis:
1 It is possible that radio channel is still busy when module try to transmit data.
2 Register works only in Address Security mode, no in Transparent mode.
3 try to send a <RX level of sensibility (ATS226=3)
Let me know
thanks
Dear Romano,
Thanks for your reply. I have meanwhile checked your hypotheses with following conclusion:
1) I have repeated my tests and monitored the transmit and receive indictaions (I/O1 and I/O2 respectively) When data are sent to each module simultaneously, one module starts transmitting and the other one indicates receiving. After very few cycles, when the first module has received an acknowledge from the server, the second one unexpectedly does not start transmitting but issues ERROR and so the second message is lost. There is no other source which could occupy the RF channel.
2) Yes, the modules are operated in addressed secired mode (S220=9)
3) When I select LBT level 3 corresponding to -70 dBm and reduce the transmit power (simply removing the antennas) so that the RSSI on received data shows less than -70dBm, then every thing works fine. But then, effectively the LBT logic is not triggered as all levels are below the threshold.
I have then set the number of repetitions on the client modules to 25, set the random delay S227=1 and turned LBT off (S226=0) In that configuration everything is fine with almost 100% successful data transfer from the two simultaneous transmitting modules. It is a work around solution which we will adopt for our WSN installation.
We use cookies to enhance your browsing experience and help us improve our websites. To improve our website, we carefully select third parties that use cookies to allow us to serve specific content and achieve the purposes set out in our cookie policy. For more information on how to make adjustments through your browser to the cookies being used on your device, please click Find Out More link. By closing this banner or continuing to browse our website, you agree to our use of such cookies. FIND OUT MORE
We
have set up a star network with 27 clients, each of them sending a 10 byte
message every 20 minutes and in addition sporadically a set of three 25 bytes
message with 30 sec interval several times a day.
The
clients have firmware GC.S00.01.04-B008 and are operated with LBT S226=2, Repetition
S223=10, random waiting S227=1.
We
observed that some frames go lost for which we suspect a data
collision anomaly. In order to further investigate this, we have set up a test
network with same settings as the original, but with only three clients. When we issue messages simultaneously
to any two clients, it can be seen that one of them starts sending whilst the other one is quiet, only receiving
data as expected. After the first one stops transmitting with an OK at its
serial port, the second one, however, in most cases does not start transmitting but issues an
ERROR. Only in less than 5% of the tests the message is received from both
clients. Same behaviour is observed for all three LBT levels.
When
we switch off the LBT (S226=0) then in the message is received from both clients
in more than 95% of the test cases.
Is
there anything we have overlooked in the LBT setting?
Do
we need a special setting also for the network server?
For
how long does a module wait until the radio channel is free and it starts
transmission?
Dear Cosmin,
many thanks for the swift response.
But there is a discrepancy between your reply and my perception of the "Star network protocol stack user guide".
Accordingly the module should wait and retry to transmit several times as specified in register S223. Waiting time between subsequent trials should be random between 0 and 64ms because register S227 is set to "1" when LBT is active.
How does it fit with the 4ms time out?
I would expect ERROR to be issued only if eventually after the number of retries specified in S223 there was no Ack from the receipient.
Thank you Cosmin for this further clarification, but what happens after the 4 ms?
I would expect from the description in the protocol user manual that the module listens again after a random waiting time of up to 64ms according to S227=1 and then if the channel is still busy it repeat this as many times as is defined in S223?
Thank you Cosmin,
since I now understand how it should work, I wonder what is wrong in our set up.
Again: when two messages are sent simultaneously from two clients to the server, then only one is received. The other client obviously senses through LBT logic that the channel is busy, but it does not retry transmission regardless of what is defined in S223 and so its message is lost.
Answers are from my specialist colleague Romano.
Dear Romano,
Thanks for your reply. I have meanwhile checked your hypotheses with following conclusion:
1) I have repeated my tests and monitored the transmit and receive indictaions (I/O1 and I/O2 respectively) When data are sent to each module simultaneously, one module starts transmitting and the other one indicates receiving. After very few cycles, when the first module has received an acknowledge from the server, the second one unexpectedly does not start transmitting but issues ERROR and so the second message is lost. There is no other source which could occupy the RF channel.
2) Yes, the modules are operated in addressed secired mode (S220=9)
3) When I select LBT level 3 corresponding to -70 dBm and reduce the transmit power (simply removing the antennas) so that the RSSI on received data shows less than -70dBm, then every thing works fine. But then, effectively the LBT logic is not triggered as all levels are below the threshold.
I have then set the number of repetitions on the client modules to 25, set the random delay S227=1 and turned LBT off (S226=0) In that configuration everything is fine with almost 100% successful data transfer from the two simultaneous transmitting modules. It is a work around solution which we will adopt for our WSN installation.