CC1352R: Calculating air occupancy

Markus Proeller

Part Number: CC1352R

Hi,

we have a large production building and want to place a lot of Sub-1 Ghz devices (~7000) into the building. We are in Europe, that's why we use PHY ID3 (34 channels, 50kbps).

At the moment we plan to exchange a few bytes, let's say 10 bytes about every 60 seconds from the devices to the pan coordinators. The pan coordinators might also want to send a few bytes, but less often to the devices.

I was using the collector and sensor sample application in a non-beacon, non-frequency hopping configuration. As far as I understand, I have to disable security settings, because otherwise a PAN coordinator can only handle 50 devices.

1. question: If I disable MAC security is my PAN coordinator able to handle 7000 devices (i.e. will it work to set CONFIG_MAX_DEVICES to 7000)?

2. question: I'm not limited to 1 PAN coordinator. If I understand coorectly I could also use 34 coordinators to use all channels in parallel, right?

My 3rd problem is to estimate whether the air interface is capable for this amount of traffic.

How can I do this estimation? In the sample application I saw, that there are three messages which are exchanged:

1. Tracking request from coordinator to devices

2. Poll request from devices to coordinator

3. Actual Sensor data

If I understand correctly, message 1 and 2 are necessary and the "actual sensor data" can be replaced by our application specific data.

My last question is now, what is the overhead in bytes from these messages. Do all SubGhz messages have the same message header and how much byte does this header contain?

Thanks,

Markus

over 7 years ago

0 Jesu over 7 years ago

TI__Mastermind 22935 points

Hi Markus,

Regarding the network capacity of the coordinator it all depends on memory available. You are correct by thinking disabling security will allow you to handle more devices. I believe on the 1352 it will bump it up to 200 devices.

For the other two questions, let me get back to you on Monday.

Regards,
Jesus

0 Markus Proeller over 7 years ago in reply to Jesu

Prodigy 105 points

Hi Jesus,

thanks for the clarification.

I was playing around with the CONFIG_MAX_DEVICES macro in config.h of the collector example.

For the CC1352 I was able to set this define to 2000 even when security is enabled (CONFIG_SECURE true).

If I then increase the number, I start getting linker errors, because the device is out of RAM.

Okay, this answers my first question. I would need 4 coordinators to talk to 7000 devices and as far as I understand these coordinators can use different channels.

Now I'm looking forward to receive answers for my other two questions.

Best regards,

Markus

0 Jesu over 7 years ago in reply to Markus Proeller

TI__Mastermind 22935 points

Hi Markus,

Glad I could help a little bit. I have re-assigned your post to Hector. He works with the 15.4 stack a lot more than I do and would be able to help you better than I can.

Best of luck!

Jesus

0 Markus Proeller over 7 years ago in reply to Jesu

Prodigy 105 points

Hi,

regarding my 3rd question from the very beginning, I proceeded into more detail. I was looking into the sendSensorMessage function of the sensor project, where cyclic temperature messages are exchanged.

The payload of this message is 15 bytes (SMSGS_BASIC_SENSOR_LEN + SMSGS_SENSOR_TEMP_LEN), I would expect to have a PHY and MAC Layer overhead of ~15 bytes as well, so something around 30bytes should be transmitted over the air, right?

On our PHY-ID3 we have 50kbps. 30 bytes*8=240 bits, 240bits/50kps = 0.0048[s]. It should take around 5 ms to transmit this data.

I measured the current consumption of the device and the current peak there is ~60 ms. Why is this the case?

Best regards,

Markus

0 Hector_r over 7 years ago

TI__Genius 12415 points

Hi,

For question 2: yes you can use different coordinators in parallel in different channels

To estimate how many devices you will be able to support based on air occupancy you can do something like this:

each packet sent from each sensor will be 10 bytes + ~12 bytes(overhead) = 22 bytes every 60 secs per device

22bytes @ 50kbps will take ~3.52ms + 2ms(approximated time to get MAC Acknowledgement) ~5.5ms

to increase the margin of error we can double the 5.5ms to 11ms of air time per device. Given that every device reports data every 60 seconds then we then 60/0.011 this will give us a total of 5454 devices that can be supported based on air occupancy. If we don't increase the margin of error and leave the air time per device at 5.5ms then you will be able to support ~10900 devices.

Please note that these calculations are assuming that the sensors are the only ones transmitting data and they are not receiving any data from the coordinator. Also they assume the tracking request is not being used since it is not a required packet.

Regards,
Hector

0 Markus Proeller over 7 years ago in reply to Hector_r

Prodigy 105 points

Hi Hector,

my last question about the current consumption is not answered yet. Do you have any explanations, why the current consumption peak has a width of 60ms? Is this the time, the air-interface is occupied, or do we see anything else here?

Best regards,

Markus

0 Hector_r over 7 years ago in reply to Markus Proeller

TI__Genius 12415 points

Hi,

In the screen shot of the current consumption that you shared there seems to be a little bit more going on than just 1 over the air transmission. From what I can see there seems to be 3 different TX operations, also the active time of the device will always be grater than the amount of time that it will take the device to send a packet over the air since there are many other things that need to happen. For example the device has to wake up, then do a channel assessment, then if the channel is clear the device will transmit data, following that the device will open the receiver to receive an acknowledgement after this the main core will continue to do any other processing that needs to happen depending on the application and finally it will go back into sleep mode.

Regards,
Hector

Sub-1 GHz

Sub-1 GHz forum

CC1352R: Calculating air occupancy