LP-EM-CC1312PSIP: Running the sensor/collector apps for more than 15min.

Hi Kevin,

1. Which version of the SimpleLink F2 SDK are you using?

2. Are you using CC1312PSIP for both the collector and sensor in this set-up?

3. When you say the sensor rejoins rather frequently, can you give me a rough time estimate? 30 s? 5 mins?

Cheers,

Marie H

Marie H,

I have the version s 7.41.0.17, 7.40.0.77 & 7.10.2.23 versions installed.  The latest sensor/collector version that I was testing when this happened is using version 7.41.0.17 as shown in the include information when this was happening.  My project code that I have been testing and having similar issues is using the 7.10.2.23 since it was six months since I had loaded the example it was based on.  What is new with the latest version?  Would it affect my project, and should I refresh the sensor/collector portion of my project?

I am using the CC1312SPIP for collector and sensor.

About every 10 seconds it will rejoin after it has been running maybe 20-30min.

Kevin

Hi Kevin,

I will inquire what changes if any were made for the CC1312PSIP in the latest SDK.

I will try to reproduce what you're seeing and get back to you tomorrow. Can you tell me which mode you are using (FH, beacon, non-beacon) and which frequency band?

Cheers,

Marie H

Marie H,

I am using the non-beacon mode.  I did not make any changes to the projects.

Thanks,

Kevin

Marie H,

I was in a different location and running the latest projects for sensor/collector and only had one orphan occur.  I am sending you the file from Wireshark.  Can you tell me more about what happened?  It appears that it can happen more frequently at times.  It repeated over and over on Friday.

Thanks,
KevinOne Orphan Notification.zip

Marie H,

The main issues I currently have is getting the FCS checksum errors and how to fix that and how to enter the encryption key to decode the packets.  The problem with the protocol going into orphan mode is also a concern, but I don't know what occurs that makes that happen.  I would also like some guidance on the protocol.  There are several data exchanges, can you explain what these are for and why they are different sizes.  Here is a text version of the interaction when they first setup and after I have done a few disassociate/associates.

58 Beacon Request
61 Beacon, Src: 0xaabb
69 Association Request, RFD
53 Ack, Bad FCS
66 Data Request
53 Ack, Bad FCS
75 Association Response, Pan: 0x0001 Addr: 0x0003
53 Ack, Bad FCS

60 Data Request
53 Ack, Bad FCS
148 Data, Des: 0xaabb, Src: 0x0003
53 Ack, Bad FCS

60 Data Request
53 Ack, Bad FCS
78 Data Dst: 0x0003, Src: 0xaabb
53 Ack, Bad FCS
78 Data Dst: 0xaabb, Src: 0x0003
53 Ack, Bad FCS

60 Data Request
53 Ack, Bad FCS
88 Data, Dst: 0x0003, Src: 0xaabb
53 Ack, Bad FCS
90 Data, Dst: 0xaabb, Src: 0x0003
53 Ack, Bad FCS

148 Data, Dst: 0xaabb, Src: 0x003
53 Ack, Bad FCS

I will need to send some data back and I did not see in the protocol where the collector was sending data to the sensor.

Thanks,

Kevin

Marie H,

I am also seeing that when the collector is unplugged the sensor puts out an orphan notification and the sensor is not able to reconnect back.  I setup the network and opened it on the collector, but the sensor would not reconnect until it is unplugged.

Kevin

Marie H,

The sensor did reconnect after the 5min delay which I think is set in the sensor.syscfg.  It did six Coordinator Realignment packets after the Orphan Notification was sent again after the 5min delay and it now looks like it is back communicating as normal.

Kevin

Hi Kevin,

It sounds like your issue is very dependent on the environment. Could it be this is the only factor that matters? (That SDK version doesn't matter?)

When you boot the collector the first time it will do an active scan of all the channels in the channel map. Based on this scan it will choose the channel with the least activity and use it for the network.

It will never change the channel.

Do you know how long the network was running before you started getting the 10s issue? You can use SmartRF studio to quickly do a scan of your channels and the noise/activity on the channels.

Cheers,
Marie H

It seems to always favor the first channel (1).  I am not seeing the orphan issue except once today.  However, there is another issue that comes up.  I am including the Wireshark log for it.  It happens when I unplug the sensor and it does a rejoined vs a joined.  It is dependent on the network being open or closed.  When closed I get the rejoined and it connects, but will cause a delay every 10 packets where it does a Beacon request.  If the network is open it will rejoin and everything works well and I don't get the Beacon request and delay.

Stall when sensor side does a rejoined vs a joined.zip

Kevin

Hi Kevin,

I realized that the default example only enabled the first four channels.

You can increase the number of channels in the channel map but please be aware that this will increase your join time.

You could also try to switch which channels are used, maybe choose one on the different side of the band, choose one in the midle etc to get a more vaired set to choose between. 

On your second issue, I need to talk to a colleague and get back to you.

Cheers,

Marie H

Hi Kevin,

I will reproduce the issue and see if I can reproduce these beacon request packets.

Cheers,

Marie H

Hi Kevin,

We set up a test with CC1312PSIP as the collector and sensor, using the SimpleLink F2 SDK 7.41. We're not able to reproduce what you're seeing with the beacon requests.

In both cases (open or closed network) the sensor is able to rejoin and send data packets. We haven't seen any becon requests. It has been running for 5 mins and we did 4 rejoins.

Cheers,

Marie H