LWM how to send packets fast

Go To Last Post
5 posts / 0 new
Author
Message
#1
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

In my application i want to send 4-5 LWM packets as fast as possible. (using ATmega128RFA1)

Aggregating the payload to 1 packet is not practical.

If i send next packet (NWK_DataReq()) right after the Confirmation callback (requesting only appNwkDataReq.options = NWK_OPT_ENABLE_SECURITY;, no ACK),

then sometimes (about 30%) i get NWK_PHY_NO_ACK_STATUS (0x21) status back.

If i wait 1 ms after the callback before sending the next packet then all is well.

 

Firstly i do not know the reason for this behaviour.

How can i remove that ugly 1 ms wait?

 

Secondly is there any way to speed this up? For example does it make sense to send 2 or more NWK_DataReq() at the same time?

Will be the transmission any faster that way?

 

 

Last Edited: Fri. Oct 16, 2015 - 12:48 AM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

The fastest would probably be to request an ACK. 1 ms wait is required for receiving node to process the frame. The time is actually shorter, but it would be impossible to predict how short exactly.

 

With 2 requests in a row you will end up in a similar situation. You are oversaturating the receiver.

NOTE: I no longer actively read this forum. Please ask your question on www.eevblog.com/forum if you want my answer.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Thank you for your fast answer.

It makes sense.

 

However when i tested it, it was slower with acks.

(i assume that sending the ack takes more time than 1 ms)

 

It may be my application what is slow, or my radio, i am not sure yet.

I measure around 20 ms ping using the radio (security enabled, no route discovery)

Do you think it is normal, or am i doing something fundamentally wrong here?

 

 

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Here is some statistical information:

 

Througput, kbps

No security - 74339.3

HW Security - 48752.2

SW Security  - 15064.6

 

Latency, ms

10 bytes payload - 3.8 

109 bytes payload - 7.5

 

20 ms for ping seems way too long.

 

Actually waiting for a certain amount of time between the frames to ensure good throughput is not a bad idea. The problem is that you never know how log you should wait for optimal performance. Some streaming protocol even include algorithms to dynamically adjust that delay.

 

Disabling security may also help a bit, if it is acceptable for your application.

NOTE: I no longer actively read this forum. Please ask your question on www.eevblog.com/forum if you want my answer.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

You are the best!

 

It seems that there is some delay in my other part of my application then.

 

I think i will stick to this 1 ms wait then (it can be finetuned of course). It is still lower than 3.8ms for the ack.

Fortunately your stack notifies me when there was an error in the transmission, so i can retransmit.

 

As you probably guessed, the main goal is preserving battery life.

It does matter if i have to stay awake for 50ms or 25ms.

Theoretically it can double the battery life.