CC1352P7: Beagleplay - using coprocessor binary in 1352, configured FH, 200kbps - higher incidence of spontaneous re-joins with larger channel list.

Hi Joshua,

1. You can do a simple noise floor test with SmartRF studio, just listen to the background noise where you're doing this test, just to make sure there's no noise disturbing the test.
2. Were you able to see the disconnect reason on the sensors before the re-join? It would be useful to know if there are specific channels that are prone to disconnect.
3. Is it the same sensors each time or does it vary between all of them? If it's the same ones you can check the frequency offset on these specific devices.
4. You say you're sing the DMM example. Are you also using BLE when this happens?

Cheers,

Marie H

Marie,

1.) I've not done this yet, but will and report back.

2.) I've not seen the disconnect reason. Could you provide any info on how best to capture this? I presume maybe the sync loss callback in the sensor could be instrumented?

3.)It varies across the population of sensors.

4.) I am using only advertising, and quite infrequently. A burst of 4 advertisements every 30 seconds. I did notice that the frequency of re-connects decreased a bit when I changed from exactly every 30 seconds to every 30.25 seconds. I did this because the sensors are sending data at 20 second intervals, and I didn't want the advertisements to beat with the data reports on every other third report cycle.

Marie,

Noise measurements for the 64 channels in use. It doesn't look concerning to me, what do you think?

If is is advisable to exclude the worst channels, do you have a recommended algorithm or method to do this? Is there an example?

Regards,

Josh