CC1310 Sensor/collector/gateway Beaglebone example

Disregard the first question, I see that a hard-coded check is done in run_collector.sh.

I still need help with changing the PanID as we can't have multiple gateways running with the same PanID.

I changed /bin/collector.cfg (changing ttyACM0 to ttyS1) and it works. The problem is that on starting the demo, it says that nothing is connected to ttyACM0. So right now I have to have a 'fake' cc1350 launchpad connected to usb. This 'fake' launchpad is actually programmed as a sensor, while another launchpad is programmed as the coprocessor and connected to ttyS1. Everything works, but I'd like to not have to have anything connected to the usb.

[] looks like you are using the run_demo.sh (which calls run_collector.sh) or directly run_collector.sh to start the collector application. To remove this message please edit the run_collector.sh file which hardcodes the dev to be ttyACM0 to remove the unwanted message in your case

if [ ! -c /dev/ttyACM0 ]
then
echo ""
echo "The Launchpad (/dev/ttyACM0) does not seem to be present"
echo ""
exit 1
fi

.

..

Second, I have multiple gateways running during testing and would like each to have a unique PanID. I changed it from 0xADCD to something else in /bin/collector.cfg, but it seems to not have any effect. The web interface still shows 0xACDC. Likewise, I changed it for the sensors in config.h and they still connect to 0xACDC.

[] It is possible that the panid is getting picked up from the nv-simulation.bin file which is created to create persistence storage over power cycle for  previous network information. You would have to delete this file and try again. You can see this file at /prebuilt/bin, if running the application from the prebuilt directory. Or /examples/collector/ if running the application from /examples/collector directory. 

Hope this helps.

Ok, I deleted the nv-simulation.bin file and now the updated PanID shows up in the web interface. I changed it in /bin/collector.cfg. I don't need to make any other changes on the gateway/collector side, correct?

Because my sensor, which I did not reprogram still connects to the gateway that now has the new PanID.

My understanding is that by using different PanIDs, I can have multiple gateways and sensor groups at the same time.

Thanks.

Hey Ferdster,

Make sure to erase NV on both the linux "collector" side as well as the sensor side. To erase nv on the sensor, simply hold BTN2 and press the reset button.

~Brocklobsta

I just tried it again using the new SimpleLink CC13x0 SDK.

I have two gateways running. The only things I changed on the gateway side in the collector.cfg file are:
config-fh-enable = true
config-pan-id = 0xABCD (other gateway set to 0xDCBA)
config-coord-short-addr = 0x5678 (other gateway set to 0x8765)

I see in the web interface that the 'Coord Addr' stays 0xFFFF for both of them.

I then programmed four sensors (two each)where the only changes were in config.h:
#define CONFIG_FH_ENABLE true
#define CONFIG_PAN_ID 0xABCD (and 0xDCBA)

Reprogamming the sensors should erase any nv data and I erased the nv data on the gateways as well.

On powering up the sensors they are not associating with their respective gateways based on the PanID.

I put some printfs in the ApiMac_assocStatus_t cllcDeviceJoiningCB() function in collector.c and devicePanID always matches pDevInfo->panID. It never goes into the 'else' for denying access.

Also, is it possible to add some code in the sensor to have it clear it's nv data on power-up?

Thanks.

You can clear NV on power-up by calling Csf_clearAllNVItems (collector) or Ssf_clearAllNVItems (Sensor). Or you can disable NV by removing the NV_RESTORE compile flag.

PAN filtering is done in the stack, so there isn't any application logic to filter pan.

~Brocklobsta

Ok, so all I should need to do is the change the '#define CONFIG_PAN_ID' in config.h of the sensor and 'config-pan-id = ' in prebuilt/bin/collector.cfg on the gateway, correct?

I assume that having frequency-hopping enabled should not make a difference with regards to the PanID.

Thanks.

Ok, I did more testing and it does seem like enabling frequency-hopping causes the PanID to get ignored.

With frequency-hopping disabled, my five sensors with different PanID's connected to their respective gateways.

But after enabling frequency-hopping, deleting all the nv data, and reprogramming the sensors, they get all confused.

I am still waiting on an official answer on whether I am just doing something wrong or if frequency-hopping and PanIDs just don't work together.

Hey Ferdster,

You are correct in your observation. PAN filtering is not done in FH mode. As a workaround you can start the first network and have all the nodes join, then turn permit join off. Then start the next network, and turn permit join off when finished. This way 2 collectors will not have permit join enabled at the same time.

~Brocklobsta

Does TI have any plans on enabling PAN filtering in FH mode?

Thanks.

So, if I am using frequency-hopping, can I leave the PAN ID the same for all my networks and give each network just a unique CONFIG_FH_NETNAME? Or, do both have to be unique per network?

It seems like changing just the CONFIG_FH_NETNAME is not enough and my sensors are still getting mixed up and connecting to different gateways.

Yeah changing the netname should be enough.

~Brocklobsta

I tried that earlier today and my sensors were getting mixed up and connecting to the wrong gateways. I am pretty sure I deleted the nv-simulation.bin file on the gateway and cleared the NV on the sensors, but I'll try again tomorrow.

Thanks.