• State
  • Replies 8 replies
  • Subscribers 54 subscribers
  • Views 102 views
  • Users 0 members are here
Support feedback
Options
Options
Related

LP-EM-CC1314R10: Multi sensor network - disconnect problem - sniffer log

Muniyappan R M
Prodigy 185 points
Part Number: LP-EM-CC1314R10
Other Parts Discussed in Thread: SYSCONFIG

Tool/software:

Hi,

I am using TI stack 15.4 wireless stack for my wireless communication. I am using , PHY type: 5 kbps (SimpleLink Long Range), with ETSI regulation (863–869 MHz) - Non beacon mode.


In my setup I have 4 sensors and one collector and a additional sniffer to analyze the network. I have set the reporting interval as 10 seconds (sending the incremental data on each sensor) and the polling interval is set to 20seconds (not sending any data from the collector).

Sensor MAC ids:
00:12:4b:00:35:97:fa:46
00:12:4b:00:14:fe:75:df
00:12:4b:00:14:fe:7b:cf
00:12:4b:00:14:fe:79:73

Collector MAC id:
00:12:4b:00:35:97:ab:a8 


When running this setup I observer two scenarios.
1. collector and sensors are all working fine i.e no packet losss and no disconnection.
 


2. Sensors are continuously disconnected (orphaned) and rejoining. Also many data lost 
sniffer log:

...

In both scenarios HW setup is same and the code is also the same; nothing modified.
In the disconnection log I could see that the ACK is missing and due to the missing ACK, the sensors are orphaned.

Upon analysing the TI15.4 guide, in NBCN- direct data transfer sequence,

they didn't mention more about this ACK and how it is generated.

So My questions are,
a) What actually this ack? is collector is giving this ack?
b) The collector moves to Tx and sends ACK if any sensor packet is received.
Because when analyzing my attached images, in working condition the time difference between the next sensor packets is 500 to 600 ms. which means in between that collector sends the ACK and the network is fine.
In my disconnection images the sensor packets are triggered within 150 ms. Is it really a problem. Since It is a multi sensor network -  each sensor can trigger packet at any time.
c) So in a multi-sensor network, is there any limitation or condition mentioned that sensor reporting packets should be triggered with more than 150ms?


Kindly anyone help me to understand this. As we are planning to develop mass production on gateway - sensor boards, we need to sort this multi sensor communication at high priority.

Thanks and regards,
Muniyappan R.M

  • 0
    TI__Intellectual 1170 points

    Hi Muniyappan,

    a) Yes, these are ACK. Every message is ack'ed by the collector. Since there are no beacons, this is the only way the sensor knows it is still in the network. After a certain number of missed ACKs, the sensor will start sending the orphan notifications.

    b) and c) I'm not aware of the limitation, I'm going to do some more research and come back to you. What SDK version are you using? Are you running the fully embedded collector project or the coprocessor with a linux host?

    Best regards,

    Daniel

  • 0 in reply to Daniel Guarecuco Aguiar
    Prodigy 185 points

    Hi Daniel,

    Thanks for your valuable response.


    Daniel Guarecuco Aguiar said:
    , I'm going to do some more research and come back to you. What SDK version are you using? Are you running the fully embedded collector project or the coprocessor with a linux host

    >> I am using the sdk version 7.41.00.17 and fully embedded collector project.


    Note:
    This issue cannot be reproduced directly, as it depends on the sensor2 reporting packet being transmitted within 150ms of the previous sensor's (i.e Sensor1) reporting packet. But the Sensor1 and Sensor2 won't have any common signals. 

    From your answer to the question a)

    Daniel Guarecuco Aguiar said:
    ) Yes, these are ACK. Every message is ack'ed by the collector. Since there are no beacons, this is the only way the sensor knows it is still in the network. After a certain number of missed ACKs, the sensor will start sending the orphan notifications.

    >> So which means the collector will go to the Transmit mode (i.e the collector antenna will be on a Tx mode?)  immediately after receiving any packets from the sensor inorder to send the ACK. Is my understanding is correct?.


    Regards,
    Muniyappan R.M

  • 0 in reply to Muniyappan R M
    TI__Intellectual 1170 points

    Hi Muniyappan,

    From your capture it seems the packet is 105 Bytes (or is this the payload, without the MAC and PHY header? ). In any case, if the packet is 105 bytes, the packet transmission is about 105*8/5kbps = 168ms. Meaning that in a 150ms window, the tail of the first packet is overlapping with the head of the second packet. Clearly this is not enough, you would need at least 168ms gap, probably even a bit more so that the ACK can be transmitted.

    If 105 Bytes is just the payload, the packet is about 120 bytes, giving you a transmission time of 192ms.

    Best regards,

    Daniel

  • 0 in reply to Daniel Guarecuco Aguiar
    Prodigy 185 points

    Hi Daniel,

    Thanks for your response.

    From your response 

    Daniel Guarecuco Aguiar said:
    Meaning that in a 150ms window, the tail of the first packet is overlapping with the head of the second packet. Clearly this is not enough, you would need at least 168ms gap, probably even a bit more so that the ACK can be transmitted.

    actually I am using the multi sensor in the network, so It is impossible to maintain 160ms delay across the sensor transmissions in the network (since one sensor don't know when the other sensor transmitted the packet).

    So is there any way to overcome this issue?

    Is there any option to set predefined slots to each of the connected sensors from the collector?

    Our customer requirement is to connect 14 sensors to one gateway and they will transmit the data to the gateway. Kindly help us to achieve my requirement.

    Regards,

    Muniyappan R.M

  • 0 in reply to Muniyappan R M
    TI__Intellectual 1170 points

    HI Muniyappan,

    The non-beacon mode uses unslotted CSMA algorithm, when a device wants to transmit it waits a random period, if the channel is idle the device transmits, otherwise it backoffs again for a random period of time. For Long Range Mode, we should increase the backoff times, the following values are recommended:

    CONFIG_MIN_BE = 5 (default 3)
    CONFIG_MAX_BE = 8 (default 5)

    You can change this at Sensor's Sysconfig > TI 15.4-Stack > Network > MAC.

    Could you try this and check if it improves collision avoidance? 
    You could also increase the reporting interval if it fits within your requirements.
    Normally, is most of the communication going from sensors to collector?
    Best regards,
    Daniel
  • 0 in reply to Daniel Guarecuco Aguiar
    Prodigy 185 points

    Hi Daniel,

    Thanks for your response. We are changing this backoff intervals and testing the network with one collector and 5 sensors + a sniffer.
    We will update you about our results.




    Daniel Guarecuco Aguiar said:
    Normally, is most of the communication going from sensors to collector?

    >> Yes. Actually I dont want sensor to send polling packet to the collector since the collector wont send the data more often to the collector except (sensor config and OAD).
    In my current setup I set the polling interval as 20 (each sensor also sending this poll packets unneccessarily every 20 sec).


    0x0001/0x0002/0x0003/0x004 -> 0xaabb (polling req)

    I have also posted a question regardinig my polling interval here : 
    RE: LP-EM-CC1314R10: To configure different polling and reporting intervals for each sensors.

    Still I am struggling to setup the reporting and polling interval for my customer requirement.

    One quick question: you mentioned the NBCN mode uses the unslotted CSMA algorithm. which causes the packets to transfer asynchronuosly , Is it better to go with Frequency Hopping?. Kindly give us your opinion.

    Regards,
    Muniyappan R.M

  • 0 in reply to Muniyappan R M
    TI__Intellectual 1170 points

    Hi Muniyappan,

    Please let me know how it goes with the testing

    Muniyappan R M said:
    Still I am struggling to setup the reporting and polling interval for my customer requirement.

    What are you struggling with here?

    Muniyappan R M said:
    it better to go with Frequency Hopping?

    I will double check, but I believe it wouldn't help, as the sensors still need to transmit at the frequency the collector is listening on.

    You could also try the following approach: If all the sensor boot up at the same time, you could try adding a random sleep function at startup, so that they are no longer in the same slot.

    Best regards,

    Daniel

  • 0 in reply to Daniel Guarecuco Aguiar
    Prodigy 185 points

    Hi Daniel,

    We are testing the network with the updated backoff interval and will update you about the network stability. Maybewe will run the over night test and update you.
     

    Daniel Guarecuco Aguiar said:
    What are you struggling with here?

    >> I am strggling to se the suitable reporting and polling interval for my final network i.e 14 sensor connected to one Gateway with the minimum data loss. Also there should be no sensor disconnection issues in the network (since the disconnection can tigger service request from the customer sites) except some unpredictable scenarios.

    Daniel Guarecuco Aguiar said:

    You could also try the following approach: If all the sensor boot up at the same time, you could try adding a random sleep function at startup, so that they are no longer in the same slot.

    >> Yes that is also a good approach. But in my case the sensors may not be configured at the sam time. As we are buildiing the product like Gateway-sensor model, user can connect/config a new sensor to the network at any time.

    Thank you once again for your continuous support.


    Regards,
    Muniyappan R.M