| Author |
Message |
|
|
 Posted: Feb 24, 2011 - 03:39 PM |
|
Joined: Feb 24, 2011
Posts: 7
|
|
Hello there,
i’ve been working with ZigBit modules the last few months and after implementing my software on the nodes i was eager to do a calculation, how long the batteries may last. To get reliable results i decided to measure the current of two different Meshnetic-boards i'm programming:
A MeshBean2 board (MN-MB-09B0) with a ZigBit 900 module and a Meshbean Amp board (WDB-A1281-PN) with a ZigBit Amp module.
I coded different scenarios to be able to measure different states of the radio transceiver with an analyzer. I was able to measure the sleep and idle state without further problems. When i proceeded to measure the current during a transmission or a reception i used following simple program:
A ZC establishes a network, a router joins and then they just ping-pong messages.
I connected the ZR to an analyzer (taking measurements each 0.02 ms), providing 3V to the board, like two 1.5V batteries would do. I got the periodically repeating results i attached to this post. They seem a little odd to me...
As you can see i get a steady line interrupted by two peaks. I assume the first peak represents the transmission of an MAC-ACK after getting the ping message from the ZC and the second peak represents the transmission of the pong packet (no App-ACKs used). If i increase the size of the pong packet, the width of the peak increases correspondingly. I am sending at 3dBm and with an activated power amplifier (+17dBm).
So i’ve got two questions about this scenario:
1.) Does the action of receiving a packet (BUSY_RX) consume more energy then just listening (RX_ON)? On the screenshot there seems to be no increase in the current just before sending the ACK. Maybe this is, because the ACK is sent immediately after receiving the ping and the resolution of measurements is too low?
2.) Why are the peaks so high? I know that I am monitoring the current for the whole board (ZigBit Amp on top of a Meshbean Amp) so the measured current will be higher than when just measuring the ZigBit module. The Datasheet is talking about 23mA in RX mode and 50mA in TX mode with the same configuration for the ZigBit module only. I get values of around 39mA in RX mode and 172mA in TX mode for the whole board. Isn't this way to high? My measurements in sleep state revealed a current of 4mA for the whole board, so i guess the high TX current is composed of these 4mA + the current @ZigBit module. I've read somewhere that transmitting at 100mW (20dBm) may cause a current flow of ~150mA... anyone observed a similiar behaviour?
Another question is related to the modulation used by the ZigBit 900 module:
I’m working at 868MHz (channel page 0, channel 0) which should correspond to a BPSK modulation with a 20kbit/s maximum data rate. I tried to change the modulation in the Configuration.h file to a OQPSK with 100kbit/s by changing the channel page to ‘2’.
I tried to verify the change by transmitting a certain amount of bytes and monitoring how long the node needs to transmit the packet with each of the modulation schemes, but I always get the same result (the “slow” transmission of a BPSK). Am I missing something in my configuration?
I hope I posted this at the right place and i would be very thankful, if someone could answer my questions.
Thanks,
Bizzl |
|
|
| |
|
|
|
|
|
|
Posted: Feb 25, 2011 - 01:55 PM |
|
Joined: Apr 15, 2009
Posts: 4870
Location: San Jose, CA
|
|
|
Bizzl wrote:
1.) Does the action of receiving a packet (BUSY_RX) consume more energy then just listening (RX_ON)?
I theory listening should consume a little bit more, but nothing noticeable really.
Bizzl wrote:
Isn't this way to high?
Hard to tell, better find a way to measure power consumption by ZigBit only. 150+ mA looks too big, but I don't know for sure.
Bizzl wrote:
Am I missing something in my configuration?
Duration of the frame does not change (well, it changes a bit), O-QPSK just allows to pack more bits in a time period.
Alse have a look at this topic. Not exactly relevant, but may be of interest. |
|
|
| |
|
|
|
|
|
|
Posted: Feb 25, 2011 - 05:29 PM |
|
Joined: Jan 14, 2011
Posts: 156
|
|
This is a minor point and it makes the situation worse, but you're not measuring the second current transient correctly. The cursors should be placed at the beginning of each transition. (Or the end, but it's easier to see the starts.)
M1 needs to move to the left. Looks like about 1000 uS rather than 737 uS. During the rise-time, the current is being supplied by caps on the board. |
|
|
| |
|
|
|
|
|
|
Posted: Feb 25, 2011 - 06:23 PM |
|
Joined: Feb 24, 2011
Posts: 7
|
|
Hello alexru,
thank you very much for your answers. I think you are doing a great job in this forum.
Let me comment your answers:
Quote:
I theory listening should consume a little bit more, but nothing noticeable really.
Since the difference between RX_ON and RX_BUSY seems to be neglectable, i'll use just one value for both of them.
Quote:
Hard to tell, better find a way to measure power consumption by ZigBit only.
One can enable a current measurement mode by disconnecting a certain jumper to measure the power consumption of the ZigBit Module using the CM+/- pins on the board.
I already tried to measure values this way using an oscilloscope but i got very variable results. I built a bridge connecting the two pins with an 1 Ohm (and later a 10 Ohm) resistor and then measured changes in the voltage. Afterwards i calculated the current with the approximation of Current = Voltage/Resistor.
Peaks with the same transmission power did not always have the same amplitude, so i discarded this method to measure the current; maybe noise is affecting the measurements, i'll have to check this again.
By measuring the power consumption of the whole Meshneticw board i also hope to get a more realistic model of the possible battery lifetime. In fact not only the ZigBit module consumes energy; using external pins, the usart interface, LEDs, etc. also consumes energy depending on the application.
Quote:
Duration of the frame does not change (well, it changes a bit), O-QPSK just allows to pack more bits in a time period.
If you take a look into the AT86RF212 data-sheet on page 68, there is a table with different durations for packet transmissions depending on the modulation (http://www.atmel.com/dyn/resources/prod_documents/doc8168.pdf). Maybe i'm getting something wrong, but my interpretation of the table is that the transmission of packets with maximum size lasts 5-times longer with a BPSK (20kbit/s) than with a O-QPSK (100kbit/s).
The link you posted may help me to understand better, what exactly is going on when i analyze the screenshots, thanks.
If i get any reliable results about the power consumption i'll post it here. |
|
|
| |
|
|
|
|
|
|
Posted: Feb 25, 2011 - 06:37 PM |
|
Joined: Feb 24, 2011
Posts: 7
|
|
|
MurMan wrote:
This is a minor point and it makes the situation worse, but you're not measuring the second current transient correctly. The cursors should be placed at the beginning of each transition. (Or the end, but it's easier to see the starts.)
M1 needs to move to the left. Looks like about 1000 uS rather than 737 uS. During the rise-time, the current is being supplied by caps on the board.
Thank you MurMan,
i get your point.
Applying your correction, the average value would drop a bit and therefore get closer to the specs provided by the data sheets.
On the screenshot provided i just wanted to show, that the current "on top" of the peak is very high. I transmitted a packet with - i believe it were - 3 Bytes + headers + footers. Transmitting a much longer packet will change the ratio of the rising edge to the actual duration of the peak even more, so i will get only a very slight difference in the average.
Anyway, I'll do the measurements again to get the correct values for the transmission average. |
|
|
| |
|
|
|
|
|
|
Posted: Feb 25, 2011 - 06:55 PM |
|
Joined: Apr 15, 2009
Posts: 4870
Location: San Jose, CA
|
|
|
Bizzl wrote:
One can enable a current measurement mode by disconnecting a certain jumper to measure the power consumption of the ZigBit Module using the CM+/- pins on the board.
It is better to power the board from batteries for those measurements, I had some troubles measuring power consumption while powering from USB.
Bizzl wrote:
Peaks with the same transmission power did not always have the same amplitude,
That's strange, I've used this method without any troubles. In fact, I have a jumper with resistor soldered to it that fits pins on the MeshBean board.
Bizzl wrote:
In fact not only the ZigBit module consumes energy; using external pins, the usart interface, LEDs,
Well, yes, but normally all that would be disabled during sleep.
Bizzl wrote:
If you take a look into the AT86RF212 data-sheet on page 68, there is a table with different durations for packet transmissions depending on the modulation
Yes, I'm wrong here. So I don't know what happens, further investigation is required. |
|
|
| |
|
|
|
|
|
|
Posted: Feb 25, 2011 - 07:25 PM |
|
Joined: Jan 14, 2011
Posts: 156
|
|
|
Bizzl wrote:
Applying your correction, the average value would drop a bit and therefore get closer to the specs provided by the data sheets.
My comments were about how to measure the duration of the current transient. Sometimes it's important to know the actual length of the transient.
The average current should be measured using the current at the top of the transient, i.e. between the cursors in your screen shot. It's probably safe to assume that this current is flowing on board during the rise time portion of the transient, but is not being measured because of the current being supplied by the on-board power supply caps and the rise-time of your current instrumentation. |
|
|
| |
|
|
|
|
|
|
Posted: Feb 28, 2011 - 03:53 PM |
|
Joined: Feb 24, 2011
Posts: 7
|
|
I repeated my measurements with the following setup:
1.) Meshbean Amp/900 powered by 2 AA Batteries
2.) CM Jumper disabled
3.) 1 Ohm resistor connecting CM+ and CM- pins
4.) Oscillator measuring the voltage over the resistor
By measuring the voltage i calculated the current. Using the batteries as power source i got a more constant behaviour of my transmission peaks than with USB as power source, even though sometimes peaks for the same transmission differed a little (+-4mA).
I was hoping to get values closer to the specs in the data sheet, but i still got high values, in particular for transmissions with the ZigBit Amp:
20dBm (3dBm + Amp) = ~146mA
10dBm (-7dBm + Amp) = ~96mA
0dBm (-17dBm + Amp) = ~66mA
RX_ON (with Amp) = ~31mA
I'll use this values for my calculations; this imples, that the power consumption for the ZC and ZRs may be higher than we expected, given the great difference between the values from the data sheet and the measured ones. If i didn't get the measurements completely wrong, i think it is an interesting fact, that there are such differences between specs and reality. Looking at other ZigBee products transmitting at 100mW (20dBm), there are several data sheets talking about currents around 150-170mA, but i don't know if they are comparable.
I still don't know what happens to the ZigBit 900 modules when using OQPSK; after checking if the channel page and the channel were set right i could not observe an improvement. If anybody experienced a similar problem, let me know. |
|
|
| |
|
|
|
|
|
|
Posted: Feb 28, 2011 - 04:13 PM |
|
Joined: Apr 15, 2009
Posts: 4870
Location: San Jose, CA
|
|
|
Bizzl wrote:
I was hoping to get values closer to the specs in the data sheet, but i still got high values, in particular for transmissions with the ZigBit Amp:
I'll try to find time tomorrow to repeat that experiment.
Bizzl wrote:
I still don't know what happens to the ZigBit 900 modules when using OQPSK; after checking if the channel page and the channel were set right i could not observe an improvement.
I'll check this also and I'll try to find out if anybody knows what's going on. |
|
|
| |
|
|
|
|
|
|
Posted: Mar 01, 2011 - 09:55 AM |
|
Joined: Apr 15, 2009
Posts: 4870
Location: San Jose, CA
|
|
|
Bizzl wrote:
1.) Meshbean Amp/900 powered by 2 AA Batteries
I'm confused. There are MeshBean Amp and Meshbean 900. I don't know about MeshBean Amp/900.
Here are current measurements for LowPower application on Amp board. |
|
|
| |
|
|
|
|
|
|
Posted: Mar 01, 2011 - 12:04 PM |
|
Joined: Feb 24, 2011
Posts: 7
|
|
Hello alexru,
many thanks for uploading the measurements! 
alexru wrote:
Bizzl wrote:
1.) Meshbean Amp/900 powered by 2 AA Batteries
I'm confused. There are MeshBean Amp and Meshbean 900. I don't know about MeshBean Amp/900.
Here are current measurements for LowPower application on Amp board.
I meant ZigBit Amp / ZigBit 900, i measured currents with both modules, sorry for the confusion.
About the measurements you posted:
First a question: Are the modules using the amplifier?
I try to analyze the results for the end device. I can see the sleep state (10 seconds long) and i can see the "awake" state.
In the sleep state, as expected, the current is very low and steady, i'm totally OK with that. Looking at the awake state, i've got some doubts.
This period of 1.3 seconds includes sending a message, which should provoke a current around 50mA (data sheet). The maximum is around 30.5mA, and just 6mA away from the average, which includes listening, that has the highest share of time in the awake state. Shouldn't the difference between RX and TX be higher, like ~20mA?
The average of ~24mA is very close to the current mentioned in the data sheet for listening, so i guess these values are somehow related. I also got similar values for listening. Still, i'm not sure if we can see the current for the transmission in those measurements, it should be around 50mA, as mentioned before.
What is the actual sampling rate of the FLUKE 189? I got the feeling, that it's actually to low to capture the transmissions. I assume the minimum length of an event is 50ms (way above the time for a transmission). I'm referring to Table 1 in this document
http://www.flukecommunity.com/forums/at ... hmentid=17
Since you made your measurements with a FLUKE 189, i'll ask around in the labs, if someone could provide me such a device or at least a similar one. I'd like to get the same style of representation for the measurements, so i can post it here.
ZigBit 900: I tried to activate the OQPSK (channel page 2) with channels 1-10 (not 0 as before). I just could confirm the improved transmission time for a BPSK @ 40kbit/s, instead of a BPSK with 20kbit/s on channel 0. Again the OQPSK was not enabled, it just behaved as if the channel page would be 0. |
|
|
| |
|
|
|
|
|
|
Posted: Mar 01, 2011 - 12:35 PM |
|
Joined: Apr 15, 2009
Posts: 4870
Location: San Jose, CA
|
|
|
Bizzl wrote:
First a question: Are the modules using the amplifier?
Actual measurements were performed by test and verification team, so I don't know exact conditions.
Bizzl wrote:
Shouldn't the difference between RX and TX be higher, like ~20mA?
Quite possible that Fluke is not capable of sampling at that rate.
It is just data, I have at hand, I'll do measurements with oscilloscope.
Bizzl wrote:
ZigBit 900: I tried to activate the OQPSK (channel page 2) with channels 1-10 (not 0 as before). I just could confirm the improved transmission time for a BPSK @ 40kbit/s, instead of a BPSK with 20kbit/s on channel 0. Again the OQPSK was not enabled, it just behaved as if the channel page would be 0.
I'll need to check this, but I don't have any idea how (except for pulse width of course). |
|
|
| |
|
|
|
|
|
|
Posted: Mar 01, 2011 - 01:58 PM |
|
Joined: Apr 15, 2009
Posts: 4870
Location: San Jose, CA
|
|
Here are the measurements I just made with MeshBean Amp boards on LowPower application.
I used 10 Ohm resistor between CM+ and CM- test points.
Below are pictures of voltage drop across this register for Coordinator and End Device while normal operation.
For C:
average current: 40 mA (400 mV drop)
peak current: 65 mA (650 mV drop)
For ED:
average current when active: 40 mA (400 mV drop)
peak current: 90 mA (900 mV drop)
I did this test for the best of my abilities and those the numbers I've got. |
|
|
| |
|
|
|
|
|
|
Posted: Mar 02, 2011 - 02:12 PM |
|
Joined: Feb 24, 2011
Posts: 7
|
|
Hello again!
I also did the measurements with a 10 Ohm resistor and i got similar values to the ones you posted, at least for transmissions:
Peaks @ coordinator(transmissions) = ~82mA
I did exactly the same measurements with 1 Ohm and i got:
Peaks @ coordinator (transmissions) = ~133mA
The average values you mentioned (~40mA) are a little above the ones i measured :
averages @ coordinator (1 Ohm / 10 Ohm) = 36mA / 30mA
It seems measuring with different resistors leads to different results. I will do calculations for both cases, since I'm not sure, which ones are closer to the real currents. The 10 Ohm values are closer to the data sheet, even though there is still a big difference. The 1 Ohm values are closer to the currents i measured for the whole Meshbean-board.
Since i've made measurements with all possible combinations (USB/batteries - 1Ohm/10 Ohm), I'll just have to decide which ones to trust. 
Thanks for the help!
-----------------------------
Another thing off-topic:
I already moved on a little with my project, i've got two questions about LQI values returned by
Code:
ZDO_GetLqiRssi();
on ZigBit Amp nodes. I'm using the Bitcloud stack, version 1.10.0. Maybe someone can help me out.
I always get values between 0 and 252 for the LQI.
1.) An LQI value of 0 represents a PER of ~99%, but still i managed to get a (long) chain of succesfully delivered packets that arrived with LQIs between 0 and 4. To achieve this, i did measurements outside our building, with a distance of approximately 200m between the nodes. I only could measure those low values by turning the amplifier off at one node and transmitting with TX_POWER = 3 at both nodes.
I could see how the node without amplifier received packets with LQI values as mentioned before. Are these values reliable? I assume the LNA is also turned off when deactivating the amplifier, leading to a reception with a weak signal quality.
2.) I never get LQIs over 252. Even if the nodes are 20cm away from each other...
Any ideas?
Bizzl |
|
|
| |
|
|
|
|
|
|
Posted: Mar 02, 2011 - 04:27 PM |
|
Joined: Apr 15, 2009
Posts: 4870
Location: San Jose, CA
|
|
|
Bizzl wrote:
Since i've made measurements with all possible combinations (USB/batteries - 1Ohm/10 Ohm), I'll just have to decide which ones to trust.
Bizzl wrote:
Any ideas?
Have a look at this topic |
|
|
| |
|
|
|
|
|
|
Posted: Feb 14, 2012 - 01:32 PM |
|
Joined: May 25, 2011
Posts: 85
|
|
|
alexru wrote:
Here are the measurements I just made with MeshBean Amp boards on LowPower application.
I used 10 Ohm resistor between CM+ and CM- test points.
Below are pictures of voltage drop across this register for Coordinator and End Device while normal operation.
For C:
average current: 40 mA (400 mV drop)
peak current: 65 mA (650 mV drop)
For ED:
average current when active: 40 mA (400 mV drop)
peak current: 90 mA (900 mV drop)
I did this test for the best of my abilities and those the numbers I've got.
Hi !
I have similar results for my board with ZigBit Amp module:
COORDINATOR : 37 mA
ROUTER : 39 mA
So if I plan to use and power them with 19 Ah battery standard D size that would mean:
19 Ah = 19 000 mAh / 36 mA = 527 h / 24 = 22 days ??
I also suppose that I have to take these 19 Ah with reserve, like 17 or 18 Ah maybe.
If so, then COORDINATOR and ROUTERS shouldn't be battery powered regarding operational time length, just END DEVICES could be powered with batteries ?
Thanks ! |
|
|
| |
|
|
|
|
|
|
Posted: Feb 14, 2012 - 04:07 PM |
|
Joined: Apr 15, 2009
Posts: 4870
Location: San Jose, CA
|
|
|
xtal_88 wrote:
If so, then COORDINATOR and ROUTERS shouldn't be battery powered regarding operational time length, just END DEVICES could be powered with batteries ?
That's the idea. Why would people invent EDs if routers could be battery powered? |
|
|
| |
|
|
|
|
|
|
Posted: Feb 15, 2012 - 02:26 PM |
|
Joined: May 25, 2011
Posts: 85
|
|
|
alexru wrote:
Why would people invent EDs if routers could be battery powered?
OK Alexru,
but what if application needs that COORDINATOR and ROUTERS should/must be also battery powered?
I'm not talking about some solar panels or anything like that just not rechargeable batteries.
BitCloud UG wrote:
The user application is fully responsible for synchronizing sleeping end devices with sleeping routers and coordinator.
In many posts you mentioned that routers shouldn't sleep because of routing, network stability...
So I have to implement some kind of time synchronization and then I can only communicate with nodes during this "specific time gap".
So where and how to start? What's general idea?
Thanks again ! |
|
|
| |
|
|
|
|
|
|
Posted: Feb 15, 2012 - 04:16 PM |
|
Joined: Apr 15, 2009
Posts: 4870
Location: San Jose, CA
|
|
|
xtal_88 wrote:
but what if application needs that COORDINATOR and ROUTERS should/must be also battery powered?
Then ZigBee is a wrong choice of a protocol.
xtal_88 wrote:
So where and how to start? What's general idea?
ZigBee sleeping routers is a hack, that I neither support nor will comment on.
You need to create your own protocol, designed to accommodate this scenario from the beginning. |
|
|
| |
|
|
|
|
|
FAQ
Search
Register
Log in to check your private messages
Log in
Maximize
RSS
