We have a small number of Linux nodes in a network. Each node has an RF200 connected via a serial port.
The RF200 modules all talk to each other with no problems.
Linux is running a SNAP Connect python application that only talks to the local RF200 across the serial port -- the Linux apps do not talk to each other, nor to RF200 modules across the radio. The units are using the default 10-node license that gives each SNAP Connect application a SNAP address of 0x000020.
When one unit is turned on, Linux and its local RF200 talk just fine. When two or more units are turned on, we don't always get unicast rpc calls from the RF200 to the SNAP Connect application. Could the RF200s be picking up routes for 0x000020 across the radio? If so, is there a way we can constrain traffic between SNAP Connect and the RF200 to the serial connection?
For what it is worth, we have this set to zero everywhere:
Thanks!
P.S. We are using this for the python app to get the SNAP address of the RF200:
Alternative suggestions are welcome.
The RF200 modules all talk to each other with no problems.
Linux is running a SNAP Connect python application that only talks to the local RF200 across the serial port -- the Linux apps do not talk to each other, nor to RF200 modules across the radio. The units are using the default 10-node license that gives each SNAP Connect application a SNAP address of 0x000020.
When one unit is turned on, Linux and its local RF200 talk just fine. When two or more units are turned on, we don't always get unicast rpc calls from the RF200 to the SNAP Connect application. Could the RF200s be picking up routes for 0x000020 across the radio? If so, is there a way we can constrain traffic between SNAP Connect and the RF200 to the serial connection?
For what it is worth, we have this set to zero everywhere:
Code:
NV_MESH_ROUTE_AGE_MAX_TIMEOUT_ID
P.S. We are using this for the python app to get the SNAP address of the RF200:
Code:
self.snap.mcast_rpc(1, 1, 'callback', 'rf200_snap_addr', 'localAddr')
Comment