| Author |
Message |
|
|
Posted: Mar 15, 2012 - 01:34 PM |
|

Joined: Feb 20, 2012
Posts: 14
|
|
Hi,
I'm using ACKs in my application and I need to control the duration of the timeout before the callback APS_DataConf is called with status APS_NO_ACK_STATUS.
In configuration.h I have :
Code:
#define CS_ACK_TIMEOUT 500
In my application :
Code:
dataReq.txOptions.acknowledgedTransmission = 1;
My problem is that modifying CS_ACK_TIMEOUT has no effect on the timeout I observe : I'm always having a timeout of about 7s.
Any idea of what I am doing wrong ?
Thanks. |
|
|
| |
|
|
|
|
|
Posted: Mar 15, 2012 - 02:55 PM |
|


Joined: Apr 15, 2009
Posts: 4861
Location: San Jose, CA
|
|
| Such parameter does not exists. Where did you get if from? |
_________________ The opinions and views expressed by me on this forum are my own and do not represent my employer or anyone else that I’m affiliated with.
|
| |
|
|
|
|
|
Posted: Mar 15, 2012 - 03:25 PM |
|

Joined: Feb 20, 2012
Posts: 14
|
|
I found it in Bitcloud developer guide, page 6-7.
Quote:
Since the ZigBee protocol allows bidirectional communication, applications can request
acknowledgement of the data frame reception on the application level (so-called APS ACK) by setting
acknowledgedTransmission to 1 in the txOptions field of the data request. In this case, the application is
notified about successful frame delivery (APS_SUCCESS_STATUS) via the registered confirmation
callback function only after an acknowledgement frame for the corresponding data frame is received. If
during the CS_ACK_TIMEOUT interval no acknowledgement is received, the callback function with
APS_NO_ACK_STATUS is issued.
This code line was written by the person who worked on the project before me, he seems to have read this paragraph.
So is there a way to control this timeout ? Where do the 7 seconds I got come from ? |
|
|
| |
|
|
|
|
|
Posted: Mar 15, 2012 - 03:29 PM |
|


Joined: Apr 15, 2009
Posts: 4861
Location: San Jose, CA
|
|
| Even if it was there it is long gone, it violates ZigBee in so many ways; there is no way to control this timeout. What you can do is implement application acknowledgments - just sens data without ACK requested and wait for response from the other side. If there is no response within your timeout then consider transaction failed. This is a correct way of handling this. |
_________________ The opinions and views expressed by me on this forum are my own and do not represent my employer or anyone else that I’m affiliated with.
|
| |
|
|
|
|
|
Posted: Mar 16, 2012 - 04:17 PM |
|

Joined: Feb 20, 2012
Posts: 14
|
|
Thanks for your advice alexru. I switched off application ACK, and I noticed that I was still able to detect if there is a transmission error : APS_DataConf gives me a APS_MAC_NO_ACK_STATUS in this case. So I'm thinking about using this mechanism, which is really fast.
I found this in the Bitcloud developer's guide :
Quote:
When a unicast message is sent, the application can request an acknowledgement. If an
acknowledgement is not requested, the stack calls the confirmation callback as soon as it receives a
response from the device one hop away.
The depth of my network being only 1, those MAC ACKs seem to be enough for me. |
|
|
| |
|
|
|
|
|
Posted: Mar 16, 2012 - 04:20 PM |
|


Joined: Apr 15, 2009
Posts: 4861
Location: San Jose, CA
|
|
| Yes, this will work for you. Just keep in mind that if you have routers they might decide to use routing even if there is direct path, but routing cost will be less than sending directly. |
_________________ The opinions and views expressed by me on this forum are my own and do not represent my employer or anyone else that I’m affiliated with.
|
| |
|
|
|
|
|
Posted: Mar 16, 2012 - 04:21 PM |
|


Joined: Apr 15, 2009
Posts: 4861
Location: San Jose, CA
|
|
| Also, for the first time you send data there will be no APS_MAC_NO_ACK_STATUS, but route discovery process will be initiated and this might take considerable amount of time. |
_________________ The opinions and views expressed by me on this forum are my own and do not represent my employer or anyone else that I’m affiliated with.
|
| |
|
|
|
|
|
Posted: Mar 16, 2012 - 08:47 PM |
|

Joined: Dec 08, 2010
Posts: 152
|
|
| The APS_MAC_NO_ACK_STATUS will only be reported for the first hop! If the packet gets lost on a multi hop path to the destination you will not get notified, thats what APS Acks are made for. |
|
|
| |
|
|
|
|
|
Posted: Mar 19, 2012 - 08:50 AM |
|

Joined: Feb 20, 2012
Posts: 14
|
|
|
manuelp wrote:
The APS_MAC_NO_ACK_STATUS will only be reported for the first hop!
Yes I know, but my network depth is only 1 :
#define CS_MAX_NETWORK_DEPTH 1
So I will only have first hop. |
|
|
| |
|
|
|
|
|
Posted: Mar 19, 2012 - 02:54 PM |
|


Joined: Apr 15, 2009
Posts: 4861
Location: San Jose, CA
|
|
| You will get only one level of joining devices, but after joining routers can rearrange them in a way that routing still happens. |
_________________ The opinions and views expressed by me on this forum are my own and do not represent my employer or anyone else that I’m affiliated with.
|
| |
|
|
|
|
|
Posted: Mar 20, 2012 - 10:03 AM |
|

Joined: Feb 20, 2012
Posts: 14
|
|
Ok I think I just experienced what you are talking about...
In my network I have Coordinator, Router 1 and Router 2. C sends a message to R1, C gets the MAC ACK and R1 receives the message. Then R2 sends a message to R1, R2 gets the MAC ACK, but R1 doesn't receive anything.
It seems like R2 went through C to reach R1, so the MAC ACK just means C receives the message. Am I correct ? Is this an effect of routing ?
The strange fact is that if R1 joins the network before R2, I don't have this behavior, R1 is correctly receiving messages from C and from R2.
I set network depth and radius to 1 because I thought it would force direct path : this is where I am wrong no ? Doing that I'm just killing my message if there is a multi-hop, but I'm not avoiding multi hop at all right ?
Is there a way of forcing direct path or am I trying to violate Zigbee again ?
Thank you ! |
|
|
| |
|
|
|
|
|
Posted: Mar 20, 2012 - 04:15 PM |
|


Joined: Apr 15, 2009
Posts: 4861
Location: San Jose, CA
|
|
|
maxime31 wrote:
It seems like R2 went through C to reach R1, so the MAC ACK just means C receives the message. Am I correct ? Is this an effect of routing ?
You are correct, R2 decided that it is better to send frame via C.
maxime31 wrote:
The strange fact is that if R1 joins the network before R2, I don't have this behavior, R1 is correctly receiving messages from C and from R2.
Join order should not matter, over time they will figure out the best topology.
maxime31 wrote:
I set network depth and radius to 1 because I thought it would force direct path : this is where I am wrong no ? Doing that I'm just killing my message if there is a multi-hop, but I'm not avoiding multi hop at all right ?
You are correct. Depth in case of mesh means "maximum number of hops" since there is no node to count depth from. But when frame is sent it is sent with a radius = 2*maxNwkDepth, so it should be delivered. It is hard to tell what exactly happens without seeing sniffer logs.
maxime31 wrote:
Is there a way of forcing direct path
I don't think so. |
|
|
| |
|
|
|
|
|
Posted: Mar 21, 2012 - 01:27 PM |
|

Joined: Feb 20, 2012
Posts: 14
|
|
|
alexru wrote:
But when frame is sent it is sent with a radius = 2*maxNwkDepth, so it should be delivered.
I have manually set radius to 1 in the APS_DataReq_t structure of my message, so maybe that's why it is not delivered.
Anyway thanks a lot for all of your answer ! I think I am going to use the solution you suggested me, with home made application ACKs. |
|
|
| |
|
|
|
|
|
Posted: Mar 21, 2012 - 03:13 PM |
|


Joined: Apr 15, 2009
Posts: 4861
Location: San Jose, CA
|
|
|
maxime31 wrote:
I have manually set radius to 1 in the APS_DataReq_t structure of my message, so maybe that's why it is not delivered.
Yes, this is why. |
|
|
| |
|
|
|
|
|