| Author |
Message |
|
|
 Posted: Feb 09, 2010 - 12:15 PM |
|
Joined: Nov 20, 2009
Posts: 28
|
|
Hello!
It´s me again. I want to confirm that when an End device is sleeping in the WSNDemo application (in Zigbit Development Kit), he wakes up and does the next sequence:
Transmit - Wait for acknowledge - Read acknowledge - Sleep
I send you the consumption curve to see what I mean. Is it true my theory?
In that case, if I put the node in no acknowledge mode, how can it knows that the network has or hasn´t fallen?
Thank you |
|
|
| |
|
|
|
|
|
|
Posted: Feb 09, 2010 - 01:43 PM |
|
Joined: Apr 15, 2009
Posts: 4870
Location: San Jose, CA
|
|
What exactly this image shows?
Quote:
In that case, if I put the node in no acknowledge mode, how can it knows that the network has or hasn´t fallen?
You can't. |
|
|
| |
|
|
|
|
|
|
Posted: Feb 09, 2010 - 03:53 PM |
|
Joined: Nov 20, 2009
Posts: 28
|
|
The image is the power consumption of a Zigbit Development Kit board during a transmission of a message by a end device. It´s like a castle, where the first peak should be the busy_tx state, the valley the "waiting for ack" state, and the second peak the busy_rx state. Am I right?
alexru, you are helping me a lot, I have to invite you to something (I´m kidding) |
|
|
| |
|
|
|
|
|
|
Posted: Feb 09, 2010 - 04:31 PM |
|
Joined: Apr 15, 2009
Posts: 4870
Location: San Jose, CA
|
|
|
alejandrofdelhierro wrote:
Am I right?
I don't think levels would be so distinctive. Power consumption differs not so much in RX and TX states (and radio is in RX mode when waiting for ack). Also there are IEEE ack frames transmitted (and received) for every frame automatically.
Why do you need to know the exact power consumption figure? |
|
|
| |
|
|
|
|
|
|
Posted: Feb 09, 2010 - 06:46 PM |
|
Joined: Nov 20, 2009
Posts: 28
|
|
Because I want to know what parameters in the program code affect the power consumption curve and how they affect.
What I´ve done is to put a 1 ohm resistance between CM- and CM+ terminals to see how the voltage changes in the resistance and so with the current (they are equivalent because of the 1 ohm value). So, what I see is in the next image (bigger than previous), are these three levels. If you say that after the first peak the node is in RX mode, what does the second peak mean?
Remember that the curve is for all BOARD, not only the module. |
|
|
| |
|
|
|
|
|
|
Posted: Feb 09, 2010 - 08:36 PM |
|
Joined: Apr 15, 2009
Posts: 4870
Location: San Jose, CA
|
|
Ok. If I recall correctly then wakeup sequence is:
1. MCU wakes up.
2. Radio wakes up.
3. Data request frame is sent (to get data from parent).
4. Rx mode to get possible data.
5. Application is notified about wakeup.
6. Application enables sensors (possible source of power consumption).
7. Application reads sensors data.
8. Application sends data frame.
9. Rx mode to get APS ack.
10. Application closes sensors.
11. Application puts MCU & radio to sleep.
Steps 3 and 4 are executed only if CS_AUTO_POLL is true (default value).
Before every transmission there is reception stage for clear channel assessment algorithm.
After any unicast transmission there is reception stage to receive MAC ack.
Possible sources of extra power consumption are sensors.
I will try to reproduce your experiment when I'll get to work after business trip (next week probably) and I'll try to time power consumption with actual transmissions. |
|
|
| |
|
|
|
|
|
|
Posted: Feb 10, 2010 - 12:41 PM |
|
Joined: Nov 20, 2009
Posts: 28
|
|
Mmmmmmmm, that changes a lot my point of view... Now I don´t know what´s influencing power consumption values!
But it has more sense.
How can I time and measure the power consumption of the communication process (not considering other processes like sensing)? Is it possible with the experiment I´m doing? At least the times would be fine cause I could model the power values with the theorical ones in the datasheets (MCU and transceiver ones).
It would be grate you to do the experiment also (although it´s not necessary if you want). Another possibility it´s to make more experiments to see if we discover something. I can have some tests with the sniffer to see some timings. If you have some other idea tell me. |
|
|
| |
|
|
|
|
|
|
Posted: Feb 10, 2010 - 03:32 PM |
|
Joined: Apr 15, 2009
Posts: 4870
Location: San Jose, CA
|
|
| I'll look into it when I'll be back at work. |
|
|
| |
|
|
|
|
|
|
Posted: Feb 11, 2010 - 10:25 AM |
|
Joined: Nov 20, 2009
Posts: 28
|
|
| OK, perfect, thank you very much. |
|
|
| |
|
|
|
|
|
|
Posted: Feb 15, 2010 - 11:53 AM |
|
Joined: Nov 20, 2009
Posts: 28
|
|
I´ve made a model with your information of the wakeup sequence and the timings of the steps with my sniffer, and everything is OK except when I change the CS_AUTO_POLL value to false.The end device doesn´t do steps 3 and 4(that´s expected) neither 9 or 10 and it resends the data all the time. As it is seen in the timings the end device usually sends a data request for the APS ack, and when CS_AUTO_POLL is false it doesn´t: it sends the data, waits for a while, and resends the data. I´ve tried to change the value just before sending the data (only to avoid steps 3 and 4) by CS_WriteParameter(CS_AUTO_POLL_ID, &autopoll), but it happens to me like with tx power (I couldn´t change the value with CS_Write function only with ZDO_SetTxPowerReq. In this case there is no ZDO_Set... function, so it doesn´t work).
How can I avoid only steps 3 and 4?
Do you know how can I change AUTO_POLL value in runtime? |
|
|
| |
|
|
|
|
|
|
Posted: Feb 15, 2010 - 03:30 PM |
|
Joined: Apr 15, 2009
Posts: 4870
Location: San Jose, CA
|
|
|
alejandrofdelhierro wrote:
How can I avoid only steps 3 and 4?
Do you know how can I change AUTO_POLL value in runtime?
1. With autoPoll == false you should call NWK_SyncReq() by yourself.
2. CS_AUTO_POLL should be writable at runtime.
3. Task for investigating this is planned and should be done in couple weeks (lots of tasks with higher priorities). |
|
|
| |
|
|
|
|
|
|
Posted: Feb 16, 2010 - 03:53 PM |
|
Joined: Nov 20, 2009
Posts: 28
|
|
I have tried to change CS_AUTO_POLL at runtime and it works when changing from true to false but not the other way around. Neither using NWK_SyncReq() cause I know how to include this function in the code(reading stack´s network h files) but not how it works: I have the auto poll with true, send the first message, and before sleeping I change autopoll to false. Then in the next message I try to call NWK_SyncReq() or CS_WriteParameter(CS_AUTO_POLL_ID, &autopoll) but they don´t do anything and the message is resent all the time and the node doesn´t go to sleep.
Can you explain me how to use correctly the NWK_SyncReq()??
It would be fantastic to avoid steps 3 and 4 for our wake up sequence. |
|
|
| |
|
|
|
|
|
|
Posted: Feb 16, 2010 - 06:15 PM |
|
Joined: Apr 15, 2009
Posts: 4870
Location: San Jose, CA
|
|
|
alejandrofdelhierro wrote:
I have tried to change CS_AUTO_POLL at runtime and it works when changing from true to false but not the other way around.
What do you mean by "works"? Functions CS_{Read|Write}Value() do not check parameters or perform any actions on them, so value must be written successfully at all times.
alejandrofdelhierro wrote:
It would be fantastic to avoid steps 3 and 4 for our wake up sequence.
Ok. I'll explain all this in a more detailed way.
1. When device wakes up it looks on a value of csAutoPoll variable. If it is true then stack calls NWK_SyncReq()
2. Correct way of working with NWK_SyncReq():
Code:
NWK_SyncReq_t syncReqParams;
syncReqParams.track = false;
syncReqParams.NWK_SyncConf = NWK_SyncConf;
NWK_SyncReq(&syncReqParams);
You should have function with prototype "void NWK_SyncConf(NWK_SyncConf_t *conf)"
Most interesting values of conf->status (in general it is any NWK and MAC status code):
MAC_SUCCESS_STATUS - request was sent and data was available (on this message you should immediately poll if new data available).
MAC_NO_DATA_STATUS - request was sent and no data available. Here you may want to go to sleep or poll again after some time.
Any other codes should be treated as errors.
3. To avoid implementation of this complex logic by user there are two functions available ZDO_StartSyncReq() and
ZDO_StopSyncReq().
If you call ZDO_StartSyncReq() stack will start to do what I described in item 2. You should call ZDO_StopSyncReq() before sleep in this case.
In your case you should set CS_AUTO_POLL to false (always). On wakeup call ZDO_StartSyncReq(), before sleep call ZDO_StopSyncReq().
The problem with this solution is that you don't know when all data was received to call ZDO_StopSyncReq(). To workaround this you may try to call NWK_SyncReq() manually.
CS_AUTO_POLL parameter was added later and API is not as clear as it could be. I'll try to do something about this. |
|
|
| |
|
|
|
|
|
|
Posted: Feb 17, 2010 - 10:59 AM |
|
Joined: Nov 20, 2009
Posts: 28
|
|
|
Quote:
MAC_SUCCESS_STATUS - request was sent and data was available (on this message you should immediately poll if new data available).
Thanks for that info. Now, a short question, how do I poll the new data? |
|
|
| |
|
|
|
|
|
|
Posted: Feb 17, 2010 - 11:02 AM |
|
Joined: Apr 15, 2009
Posts: 4870
Location: San Jose, CA
|
|
|
alejandrofdelhierro wrote:
Thanks for that info. Now, a short question, how do I poll the new data?
Call NWK_SyncReq() again. |
|
|
| |
|
|
|
|
|
|
Posted: Feb 17, 2010 - 02:48 PM |
|
Joined: Nov 20, 2009
Posts: 28
|
|
OK, with CS_AUTO_POLL = false, I´ve tried to put NWK_SyncReq() after waking up and before sleeping and the program blocks retrying to send the data message. It seems that it doesn´t recuperate the synchronism.
If I use only ZDO_StartSyncReq() when I wake up, the application recovers the control and send the messages correctly.
But if I put ZDO_StartSyncReq() when I wake up and ZDO_StopSyncReq() just before sleep, it goes to sleep and when it wakes up(see from the red light on) it stops sending messages even when in APP_WOKEUP is the ZDO_StartSyncReq().
Can you explain this? |
|
|
| |
|
|
|
|
|
|
Posted: Feb 17, 2010 - 03:01 PM |
|
Joined: Apr 15, 2009
Posts: 4870
Location: San Jose, CA
|
|
|
alejandrofdelhierro wrote:
Can you explain this?
I'll need to see your source code. But what exactly you are trying to achieve? You are basically doing what stack will do by itself with CS_AUTO_POLL = true. |
|
|
| |
|
|
|
|
|
|
Posted: Feb 17, 2010 - 03:26 PM |
|
Joined: Nov 20, 2009
Posts: 28
|
|
These are the parts of the code I´ve changed:
Code:
case SENDING_DEVICE_STATE:
switch (event)
{
case APP_PROCESS:
visualizeAirTxStarted();
APL_WRITE_LOG(0x70)
[b]ZDO_StartSyncReq();[/b]
APS_DataReq(&messageParams);
appDeviceState = WAITING_DEVICE_STATE;
break;
default:
break;
}
break;
case SLEEPPING_DEVICE_STATE:
switch (event)
{
case APP_PROCESS:
[b]ZDO_StopSyncReq();[/b]
APL_WRITE_LOG(0x7C)
visualizeSleep();
if (!isVisualizerReadyToSleep())// Wait for Visualizer ready
{
appDeviceState = WAITING_VISUALIZER_STATE;
appPostSubTaskTask();
}
else
{
appDeviceState = WAITING_DEVICE_STATE;
ZDO_SleepReq(&sleepReq);
}
break;
case APP_WOKEUP:
[b]ZDO_StartSyncReq();[/b]
visualizeWakeUp();
APL_WRITE_LOG(0x7F)
appDeviceState = READING_SENSORS_STATE;
appPostSubTaskTask();
break;
default:
break;
}
break;
case WAITING_VISUALIZER_STATE:
switch (event)
{
case APP_PROCESS:
if (!isVisualizerReadyToSleep())// Wait for Visualizer ready
{
appPostSubTaskTask();
}
else
{
appDeviceState = WAITING_DEVICE_STATE;
ZDO_SleepReq(&sleepReq);
}
break;
default:
break;
}
break;
What I want to achieve for my application is:
1. MCU wakes up.
2. Radio wakes up.
(I don´t want to get possible data from parent)
3. Application is notified about wakeup.
4. Application enables sensors.
5. Application reads sensors data.
6. Application sends data frame.
7. Rx mode to get APS ack.
(Here I think I have to activate syncrhonism to get APS ack)
8. Application closes sensors.
9. Application puts MCU & radio to sleep.
(I don´t want to poll again any data from parent as it´s programmed, just go to sleep)
It´s possible handling it with ZDO_Start and Stop Sync functions? |
|
|
| |
|
|
|
|
|
|
Posted: Feb 17, 2010 - 03:40 PM |
|
Joined: Apr 15, 2009
Posts: 4870
Location: San Jose, CA
|
|
|
alejandrofdelhierro wrote:
It´s possible handling it with ZDO_Start and Stop Sync functions?
Code looks ok,it is possible that there are some bugs in ZDO_Start/StopSyncReq(), but it does not matter right now.
The first thing that ZDO_StartSyncReq() does is send poll frame to parent, so your code still behaves like original stack.
Not polling for data is dangerous (not to mention standard incompatible) - ZDO commands are also passed to device via polling, so you MUST poll to get ALL data (and commands) available, otherwise you won't be ZigBee compatible any more.
For extremely low power application consider simple proprietary protocol. |
|
|
| |
|
|
|
|
|
|
Posted: Feb 17, 2010 - 03:52 PM |
|
Joined: Nov 20, 2009
Posts: 28
|
|
OK, but you told me that steps 3 and 4 in the original wake up sequence were avoidable maintaing standard compability didn´t you?
At least, is it possible to do only one poll at the beginning or the end of the active stage and not both?
I just want to know how to do that, to force the possibilities of the Zigbee without escaping from it. |
Last edited by alejandrofdelhierro on Feb 18, 2010 - 10:30 AM; edited 1 time in total
|
| |
|
|
|
|
|
|
Posted: Feb 17, 2010 - 06:05 PM |
|
Joined: Apr 15, 2009
Posts: 4870
Location: San Jose, CA
|
|
|
alejandrofdelhierro wrote:
OK, but you told me that steps 3 and 4 in the original wake up sequence were avoidable maintaing standard compability didn´t you?
I don't remember saying that. You may disable BitCloud doing this but in this case you must poll by yourself.
alejandrofdelhierro wrote:
At least, is it possible to do only one poll at the beginning or the end of the active stage and not both?
In response to one poll request only one packet will be sent and if it was sent then there may be other packets waiting. You should poll for them too. In general you should poll until no data packet will be sent in response.
It is possible that not only data or ack will be sent back but also some commands which are transparent to user but still should be handled by stack.
I don't know if you'll gain any significant amount of time by handling polling by yourself. |
|
|
| |
|
|
|
|
|
|
Posted: Feb 18, 2010 - 01:33 PM |
|
Joined: Apr 15, 2009
Posts: 4870
Location: San Jose, CA
|
|
We repeated your experiment and here is the image with actual packet exchange in the air.
As you can see here the longest interval is between 12:34:56.149 and 12:34:57.147 (1 second is a default CS_INDIRECT_POLL_RATE interval).
Bumps are data transmissions and receptions.
We have tried to set CS_INDIRECT_POLL_RATE to 10 ms and total wake up time was about 100 ms. It looks like it is the shortest possible time.
PS: Time is not fake, it actually was 12:34:56  |
|
|
| |
|
|
|
|
|
|
Posted: Feb 18, 2010 - 03:22 PM |
|
Joined: Nov 20, 2009
Posts: 28
|
|
Great job! Three questions: Shouldn´t be the longest interval (between 12:34:56.149 and 12:34:57.147) the CS_ACK_TIMEOUT¿?
And... CS_INDIRECT_POLL_RATE is defined as (CS_ACK_TIMEOUT >> 1). Is not its value function of ACK_TIMEOUT one?
Last one: Confirm me, is it 10 ms the shortest possible time of CS_INDIRECT_POLL_RATE? |
|
|
| |
|
|
|
|
|
|
Posted: Feb 18, 2010 - 03:35 PM |
|
Joined: Apr 15, 2009
Posts: 4870
Location: San Jose, CA
|
|
|
alejandrofdelhierro wrote:
Great job! Three questions: Shouldn´t be the longest interval (between 12:34:56.149 and 12:34:57.147) the CS_ACK_TIMEOUT¿?
No, all ACKs are received in time and no timeout reached.
alejandrofdelhierro wrote:
And... CS_INDIRECT_POLL_RATE is defined as (CS_ACK_TIMEOUT >> 1). Is not its value function of ACK_TIMEOUT one?
CS_INDIRECT_POLL_RATE is defined as 1000 by default.
alejandrofdelhierro wrote:
Last one: Confirm me, is it 10 ms the shortest possible time of CS_INDIRECT_POLL_RATE?
It is shortest possible interval for application timer. And you also should give time to other side to generate and queue ACK. |
|
|
| |
|
|
|
|
|
|
Posted: Feb 18, 2010 - 03:54 PM |
|
Joined: Nov 20, 2009
Posts: 28
|
|
MMmmmmmmm, I´ve discovered that I´m using BitCloud 1.6 and the definition of the CS_INDIRECT_POLL_RATE is diferent. In one it is 1000 and in the other (CS_ACK_TIMEOUT >> 1). I´ve seen that CS_ACK_TIMEOUT has dissapeared...
What I used to do before is to change CS_ENCRYPTION_TIME and CS_MAX_NETWORK_DEPTH and as CS_ACK_TIMEOUT=(4 * ((CS_ENCRYPTION_TIME * 2) + (CS_MAX_NETWORK_DEPTH * 100))),
CS_ACK_TIMEOUT changed.
Now, for example, if I´ve a very large network, with 5 hops between coordinator and end device, and I run the application, the waiting time would be 1 sec also? Or I should change CS_INDIRECT_POLL_RATE to wait more? |
|
|
| |
|
|
|
|
|
|
Posted: Feb 18, 2010 - 05:33 PM |
|
Joined: Apr 15, 2009
Posts: 4870
Location: San Jose, CA
|
|
|
alejandrofdelhierro wrote:
I´ve seen that CS_ACK_TIMEOUT has dissapeared...
Yes, ack timeout now calculated automatically.
alejandrofdelhierro wrote:
Or I should change CS_INDIRECT_POLL_RATE to wait more?
No, if ack won't arrive at the time of poll then new poll will be performed in CS_INDIRECT_POLL_RATE time. |
|
|
| |
|
|
|
|
|
FAQ
Search
Register
Log in to check your private messages
Log in
Maximize
RSS
