General question on typical node quantities and throughput

[raysgroi]

Hello All!
I am interested in a single master multiple slave serial I/O topology.
Each node (master included) will have one RF Engine UART tied into an 8 bit MicroP for Tx of data to the wireless network.
The MicroP performs external environmental data processing and to sends this data to the master. The master in turn will occasionally have to send instructions to the nodes MicroP's to perform some actions.

Since there is a relatively small UART buffer capability, about 100 usable bytes max, I would be interested in a 64 byte packet, that might transmit 10-20 seconds, and that is a W.A.G. It could be every 5 to 30 seconds.

I see various options with ID 16-18 parameters, would this even be an issue with 20-30 remote nodes and one master node? Is there an upper bound that I should be concerned with in terms of collision avoidance?

There is no reason for any of my slave nodes to talk to each other, each slave node only communicates with the master node.

I'm at the early design stage, my first design issue is reliable throughput.

Thank You

Ray

[kbanks]

Since there is a relatively small UART buffer capability, about 100 usable bytes max, I would be interested in a 64 byte packet, that might transmit 10-20 seconds, and that is a W.A.G. It could be every 5 to 30 seconds.

Will the nodes be LOOKING AT the serial data? Or just passing it through transparently?

If your wireless nodes don't have to look at the data (in other words, if you are using Data Mode), then 64 bytes of payload per packet is not a problem.

If you DO need to examine the data, then you are doing what I call "scripted IO". In that case you will need to be aware of the maximum size of a string on your particular SNAP platform (it varies, refer to the SNAP Reference Manual).

For example, on a RF100 the maximum dynamic string size is only 62 (not 64) characters. You might have to send data as two strings instead of 1.

rpc(otherNode, 'sendData', part1, part2)

I see various options with ID 16-18 parameters, would this even be an issue with 20-30 remote nodes and one master node? Is there an upper bound that I should be concerned with in terms of collision avoidance?

I don't know where the exact boundary is, but I know that as an example, 64 nodes in direct radio range of each other need to be adjusted off of the default settings. With that many nodes within range of each other, some of them need to be set to NOT rebroadcast multicasts.

Similarly, some of them may need to be set to "Mesh Override ON", so that they don't ALL try and help mesh route at the same time.

With these types of configuration changes, we often run 100+ nodes in a single test network.

There is no reason for any of my slave nodes to talk to each other, each slave node only communicates with the master node.


If this is the case, then you can gain a little speed by turning off the DEFAULT "collision avoidance setting". It defaults to ON, the assumption being that "any node might talk at any time". In a master/slave system you don't need this.

[raysgroi]

Will the nodes be LOOKING AT the serial data? Or just passing it through transparently?

If your wireless nodes don't have to look at the data (in other words, if you are using Data Mode), then 64 bytes of payload per packet is not a problem.


No I don't believe the nodes will have a need to examine payload



If you DO need to examine the data, then you are doing what I call "scripted IO". In that case you will need to be aware of the maximum size of a string on your particular SNAP platform (it varies, refer to the SNAP Reference Manual).

For example, on a RF100 the maximum dynamic string size is only 62 (not 64) characters. You might have to send data as two strings instead of 1.

rpc(otherNode, 'sendData', part1, part2)






I don't know where the exact boundary is, but I know that as an example, 64 nodes in direct radio range of each other need to be adjusted off of the default settings. With that many nodes within range of each other, some of them need to be set to NOT rebroadcast multicasts.

Similarly, some of them may need to be set to "Mesh Override ON", so that they don't ALL try and help mesh route at the same time.

With these types of configuration changes, we often run 100+ nodes in a single test network.



If this is the case, then you can gain a little speed by turning off the DEFAULT "collision avoidance setting". It defaults to ON, the assumption being that "any node might talk at any time". In a master/slave system you don't need this.

I don't believe our networks will even reach an upper bound of 64 nodes. The wireless message payload should easily be kept under 64 bytes. I am hoping that the network will have those collision avoidance settings dynamically settable, so I will be able to monitor the traffic within my python scripts and adjust accordingly.

For now, I just want to get about 10 nodes talking first :)
Small steps.

Thank You
Ray

[umaksudi]

Hi,
in my application the number of nodes will need to be 250-1000
One node will act as a "master" i.e sending a multicast rpc to all nodes ("broadcast"?)and then wait for each node to respond with the result.
payload/result would be lets say 5 bytes only from each node.
Is this realistic/practical ? I'd imagine some network parameters such as collision, retry , time to live etc need to be fine-tuned to ensure proper operation?
Or may be there is a software that i can use to simulate this first? (before my end customer buying 1000 units and in the end find out its not practical)

I do understand that the "master" need coordinate the response using a Snappy script, or may be just get the portal to simply log all the response for further processing? (i will look at logging option on portal)

Thanks

[mgenti]

You could have 1000 nodes respond to a multi-cast but not right away. Even with collision detection and avoidance they would not all get their responses to the main node.

Does your application depend on getting the response within a certain time? You could try polling your nodes for the information. Or have them report their information if it has hit a particular threshold.

[umaksudi]

Hi Mark
thanks for your response. 1000 nodes need to respond within 1 hr time frame, i.e not at the same time. The nodes are sleeping most of the time, and will only wake up 2x a day, on a set time (considering to use an external RTC chip if not just internal time keeping-that may consume more power). It will go back to sleep again after transmitting 5 bytes or so, to conserve power.

I did consider polling, though it could means some nodes will stay awake longer waiting for its turn, some could go back to sleep quicker. This is where i'm not sure if by using multicast they will stay awake longer anyway in the end, to get the data through the master. I need to make decision which scenario would conserve more power, but unable to evaluate without having real 1000 nodes? (hence was hoping for a simulator)..
Transmitting upon threshold is not an option as the nodes will only be on radio range to the master when they wake up(that 2x a day above).

Any thought and suggestion would greatly be appreciated
Thank you

[Jheath]

Ucu,

If these are fixed (location) nodes, then you can sub-divide the network into segments. Each waking up to participate in the network, then sleeping again while the next section is active. This will require that the master be up at all times and that a site survey is done once the nodes are installed to make sure that all nodes have a path back to the master once their segment is awake (might have to switch segments for some). This can be done to some degree in software by having the nodes remain awake and catch the next "wave" they hear from if they happened to awake and not hear from their original segment.

[kbanks]

(hence was hoping for a simulator)..

No, we do not currently have a SNAP simulator. Such a product is on our roadmap (and has been for some time), but we do not currently have the resources to pursue it.