How to use the static length field when receiving

[Dominik Hochwimmer]

Hi!

My idea of sending a packet would be:

-regulary send a packet with fixed length (stated in static length field) to a base: i.e send the temperature =>4byte -if something went wrong while transmitt (and this becomes recognized) in the next attempt the new temp value (4byte) + the last one (4byte): (=> 8byte) get sent (now plus 1byte payload length information)

So i thought i set the static length in transmitter and receiver to 4byte, in case of a neccesary retransmitt the transmitter sends now 8byte data + 1byte addtional payload length information which the receiver takes care about.

Is this the way you would use this static length field or do i misunderstand something (i still cant see the benefit using/having the static length field)?

The reason i am asking: According the Reference manual i thought its like having static length = 0 and if mor bytes need to be sent the transmitter does so by adding static length.... problem with this would be though that the receiver configuration would not fit the transmiter any more.

RGDS Dominik

[Carles]

Hi there,

I am afraid you'll need to clarify a bit for me to be able to help you.

-regulary send a packet with fixed length (stated in static length field)

What's the "static length field" ? Do you mean the characteristic value length? Are you talking about fixed vs. variable length?

-if something went wrong while transmitt

Nothing can go wrong while transmitting in BLE. The radio and the protocol guarantee that the packet will be delivered, there is no need for application level retransmission schemes.

Carles

[Dominik Hochwimmer]

Hi Carles,

it was a little late when posting the question I am afraid ;) The question is about proprietary protocolls and how to best(most power efficient) define the payload length for a scenario with "random" retransmits...

When I was talking about the "static length field" this means the "statlen" bits in the radios packet configuration register.

"If something went wrong" in order to the receiver couldnt receive data because the signal strength was too low, the distance to high, the channel was used by any other transceiver,... it is needed retransmit the "lost" data in addition to the new sensor data fetched.

hope this now helps you to help me :) RGDS Dominik

[Ole Morten]

The static length field can be used if all packets you want to transmit are the same length. If so, you can omit sending a length field on air, saving a few bits there. If you want to dynamically change the payload length, as you say, you can not use a static length, and instead you must include the length of each packet in the on-air representation (you could in theory omit the length field here as well, and just always send the max length, but that would be very inefficient).

However, in general we normally recommend users to instead build on the Gazell library for proprietary use cases, as that is normally a more flexible and worked-through solution. By doing that, you avoid having to manipulate the radio peripheral directly.

[Dominik Hochwimmer]

Thanks a lot for the answer!

According Gazell, this will serve 8 clients max? If so, is there a possible/quick workaround to get it running with i.e. 100+ clients. (Assuming the transmited data from each client is small enough to not getting troubles with the datarate.)

RGDS

[Ole Morten]

Gazell have 8 pipes, each of which corresponds to one RF address, but there isn't any problems with having multiple devices sending data on one pipe. To differentiate them, you can for example include an ID byte in the payload. If you do this, it should be possible to get working with an indefinite number of clients, as long as there is radio time enough for all of them.