LE50-868 LBT not working as expected

9 thoughts on “LE50-868 LBT not working as expected

  1. 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.

    clients have firmware GC.S00.01.04-B008 and are operated with LBT S226=2, Repetition
    S223=10, random waiting S227=1.

    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.

    we switch off the LBT (S226=0) then in the message is received from both clients
    in more than 95% of the test cases.

    there anything we have overlooked in the LBT setting?

    we need a special setting also for the network server?

    how long does a module wait until the radio channel is free and it starts


    1. Hi

      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

      1. 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. 

        1. Hi,

          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.

          1. 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?




          2. Yes it is correct,

            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

          3. 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.

          4. Answers are from my specialist colleague Romano.



            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



          5. 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.