Other Parts Discussed in Thread: CC1350
Hi All,
We are developing a sensor network using TI-15.4 stack on CC1310 chip. We've used the example codes for the sensor and collector and modified the following:
- CONFIG_PHY_ID to APIMAC_GENERIC_ETSI_LRM_863_PHY_131
- CONFIG_SECURE to false (for packet sniffing)
- CONFIG_REPORTING_INTERVAL to 160000ms
- CONFIG_POLLING_INTERVAL to 480000ms
- TRACKING_DELAY_TIME to 1600000ms
- TRACKING_TIMEOUT_TIME to 320000ms
- CONFIG_TRANSMIT_POWER to 7 dBm (testing was done indoors)
We are using a CC1310 Launchpad as the collector, 9 as sensors, and a CC1350 Launchpad as our packet sniffer via Wireshark. We also used a HackRF One to check radio signals sent by the sensors.
First, we initialized the sniffer, followed by the initialization of all 9 sensors, then the initialization of the collector.
During the test, Sensor 9, as identified by its short address, flooded the collector with data requests as shown by the packet sniffer. Below is a screenshot of how the data requests looked like in HackRF:
This went on for a few minutes so we decided to remove the battery of Sensor 9. We checked the device with SmartRF Flash Programmer and it was still fine. We put back the battery and still saw the same results. We thought this was a hardware problem until Sensor 6 suddenly showed the same behavior. This went on for a minute until the collector acknowledged the requests. According to the logs in the packet sniffer, the collector and Sensor 6 had a configuration realignment. Sensor 6 was then able to report, then polled, underwent reconfiguration with the collector. After a few seconds, the collector was flooded again by data requests of Sensor 6. This went on for a few minutes until we decided to remove its battery. The other sensors polled and reported as it normally would.
So here are our questions:
- What should be the normal behavior of the sensors sending data requests?
- Is there a specific ratios for the intervals required for the 15.4 stack to function
We are hoping you could help us with our problem regarding the flooding of data requests. Attached is a log from Wireshark and the serial output from PuTTy for your reference.
TI Collector Started Channel: 2 PermitJoin-ON Joined: 0x1 Joined: 0x2 Joined: 0x3 ConfigRsp: 0x1 Joined: 0x4 Joined: 0x5 ConfigRsp: 0x2 Joined: 0x6 ConfigRsp: 0x3 Joined: 0x7 ConfigRsp: 0x4 ConfigRsp: 0x5 ConfigRsp: 0x6 ConfigRsp: 0x7 Sensor 0x1 Sensor 0x2 Sensor 0x3 Sensor 0x4 Sensor 0x5 Sensor 0x6 Sensor 0x7 Sensor 0x1 Sensor 0x2 Sensor 0x3 Sensor 0x4 Sensor 0x5 Sensor 0x6 Sensor 0x7 Sensor 0x1 Sensor 0x2 Sensor 0x3 Sensor 0x4 Sensor 0x5 Sensor 0x6 Sensor 0x7 Sensor 0x1 Sensor 0x2 Sensor 0x3 Sensor 0x5 Sensor 0x6 Sensor 0x7 Sensor 0x1 Sensor 0x2 Sensor 0x3 Sensor 0x5 Sensor 0x6 Sensor 0x7 Sensor 0x1 Sensor 0x2 Sensor 0x3 Sensor 0x5 Sensor 0x6 Sensor 0x7 Sensor 0x1 Sensor 0x2 Sensor 0x3 Sensor 0x5 Sensor 0x6 Sensor 0x7 Joined: 0x8 ConfigRsp: 0x8 Sensor 0x1 Sensor 0x2 Sensor 0x3 Sensor 0x5 Sensor 0x6 Sensor 0x7 Sensor 0x8 Sensor 0x1 Sensor 0x2 Sensor 0x3 Sensor 0x5 Sensor 0x6 Sensor 0x7 Sensor 0x8 Sensor 0x1 Sensor 0x2 Sensor 0x3 Sensor 0x5 Sensor 0x6 Sensor 0x7 Sensor 0x1 Sensor 0x2 Sensor 0x3 Sensor 0x5 Sensor 0x6 Sensor 0x7 Sensor 0x1 Sensor 0x2 Sensor 0x3 Sensor 0x5 Sensor 0x6 Sensor 0x7 Sensor 0x6 Sensor 0x1 Sensor 0x2 Sensor 0x3 Joined: 0x9 Sensor 0x5 Sensor 0x7 ConfigRsp: 0x6 Sensor 0x1 Sensor 0x2 Sensor 0x3 Sensor 0x5 !Responding: 0x4 Sensor 0x7 Sensor 0x6 ConfigRsp: 0x9 Sensor 0x1 Sensor 0x5 Sensor 0x7 Sensor 0x1 Sensor 0x2 Sensor 0x3 Sensor 0x5 Sensor 0x7 Sensor 0x1 Sensor 0x2 Sensor 0x3 Sensor 0x5 Sensor 0x7 Sensor 0x1 Sensor 0x2 Sensor 0x3 Sensor 0x6 ConfigRsp: 0x6 Sensor 0x1 Sensor 0x2 Sensor 0x3 Sensor 0x5 Sensor 0x7 Sensor 0x6 Sensor 0x3 Sensor 0x5 Sensor 0x7 Sensor 0x1 Sensor 0x5 Sensor 0x7 Sensor 0x5 Sensor 0x5 Sensor 0x5 Sensor 0x5 !Responding: 0x2 Sensor 0x5 !Responding: 0x3 Sensor 0x5 Sensor 0x5 Sensor 0x5 Sensor 0x5 !Responding: 0x6 Sensor 0x5 !Responding: 0x7
Regards,
Ralph Abastillas
