• State Verified Answer
  • Locked Locked
  • Replies 5 replies
  • Subscribers 91 subscribers
  • Views 1586 views
  • Users 0 members are here
Attachments (0)
Nordic Case Info
  • Case ID: 284750
Options
This discussion has been locked.
You can no longer post new replies to this discussion. If you have a question you can start a new discussion

Best practice of handling large amount of LPNs for friends

Alex Ross

Hello,

I'm pretty happy with how LPN is working, the power draw is great. 

My issue is now accomodating the large amount of LPNs that will exist in our mesh (~250). Originally we wanted to keep it to a single access/gateway point but I quickly discovered that the most a Friend can support is 29 nodes. 

The debate then becomes:

1) ~10 friends scattered around the mesh area (potentially running off of solar, they will be outside but gaurentee that they'll have a wall outlet isn't a sure thing)

2) Seek alternative mesh hardware (I know you don't want to tell us to use a competitior but Silab might be able to support that many, haven't quite figured that out). However even if it could, would we want to? It seems like managing the timeout state per LPN would be pretty slow for that many nodes.

3) Consider Fruitymesh (I know this isn't Noridics stack but has anyone in the community used it for this many devices? Can't get a quote on commerical licensing either...)

4) Stuff 10 friends into a single container running off of power and have the antennas adjustable (I'm looking for insight on if the RF noise would be too much in this scenario)

I am very open to suggestions. I more so want to see if anyone else has ran into this and what the cleanest solution is.

One of the features that we require is when a device leaves the mesh that the mesh knows. The LPN/friend system has been great for this, but again, expanding into 250 devices seems like it could be clunky.

Is there a better method? The real goal here is that if the device has a low battery we want it be known to the end user right away. Mesh is great for this case.

Thanks! 

Parents
  • 0

    Hi,

    Sorry about the late reply.

    Can I get more details about your setup?

    What device are you using? Are you using a custom board or one of our DKs?

    What SDK and version are you using? 

  • +1 in reply to Mttrinh

    Hi,

    29 is the limit. This could be improved by modifying the code as discussed in the post you mentioned, but it is not advisable. Maintaining large number of friendships on a friend node also requires more RAM. For every LPN, friend needs to maintain large context structure and friend queue (size of this can be derived from the code).

    Second issue is that, when single physical friend node serves many LPNs, chances are that LPN's transmissions will start colliding eventually if you are using the same interval. This will result in LPNs having to re-poll several times, or drop the friendship after re-polling attempts are over, which is not ideal for LPN's power consumption.

    Thirdly it is bad idea to co-locate many individual friend nodes, as it will lead to the same problem mentioned above.

    If 250 LPNs are desired, it is best to split them in groups and keep these groups and their friends spatially separated at least by few feets. Also, it is recommend to use different poll interval for each one of these. For example, instead of configuring all 250 LPNs to choose polling interval of exactly 120 seconds, you should choose polling interval as a random value between 100.0 to 140.0 seconds. If exact same interval is used, random crystal clock drifts will cause many of their polls to periodically (probably after several hours or days) align with one another and at that moment most likely several LPNs will loose friendship momentarily (due to interference of polls from other LPN) and you will have to establish friendship again. This could be tolerable depending on the nature of the application, but high level network design should account for such scenario.

Reply
  • +1 in reply to Mttrinh

    Hi,

    29 is the limit. This could be improved by modifying the code as discussed in the post you mentioned, but it is not advisable. Maintaining large number of friendships on a friend node also requires more RAM. For every LPN, friend needs to maintain large context structure and friend queue (size of this can be derived from the code).

    Second issue is that, when single physical friend node serves many LPNs, chances are that LPN's transmissions will start colliding eventually if you are using the same interval. This will result in LPNs having to re-poll several times, or drop the friendship after re-polling attempts are over, which is not ideal for LPN's power consumption.

    Thirdly it is bad idea to co-locate many individual friend nodes, as it will lead to the same problem mentioned above.

    If 250 LPNs are desired, it is best to split them in groups and keep these groups and their friends spatially separated at least by few feets. Also, it is recommend to use different poll interval for each one of these. For example, instead of configuring all 250 LPNs to choose polling interval of exactly 120 seconds, you should choose polling interval as a random value between 100.0 to 140.0 seconds. If exact same interval is used, random crystal clock drifts will cause many of their polls to periodically (probably after several hours or days) align with one another and at that moment most likely several LPNs will loose friendship momentarily (due to interference of polls from other LPN) and you will have to establish friendship again. This could be tolerable depending on the nature of the application, but high level network design should account for such scenario.

Children
No Data
Related
Terms of service