Putting an Xbee to bed...(sleep, that is!)

G

Grogster

Senior Member
Hi everyone.
:)

Xbee's and Picaxe's are a perfect match for RF data-related projects, and I have used lots of Xbee's(series 1, pro @ 100mW). Their range and performance cannot be beat when compared to other more expensive RF-data modules.

However, I have run into a little problem with respect to sleeping the modules.

In all cases, PICAXE chips used are either the 14M or the 18X - primarily the 18X, as it allows me to program more message text into the code, with the higher memory of the 18X.

Anyhoo, if I use simple 3x 10k metal-film(1%) potential-dividers between the Picaxe output pins and the Xbee to correct the voltage levels, the modules transmit and receive data beautifully, but with the divider on pin-9 of the Xbee module(sleep mode pin), and the Xbee programmed for Pin Hibernate, so that the Xbee sleeps with a 3.3v high on it's pin 9, the module will not sleep for about 10 seconds, at which time it does sleep and everything is fine. During the 10-second waiting period, there is a 5v high on the Picaxe output pin, and 3.3v measured directly across the Xbee sleep pin and deck, so the Xbee SHOULD be sleeping...

After the 10 second initial waiting period, the module will wake whenever the Picaxe output pin goes low, and sleeps immediately once the message has been transmitted, and the Picaxe has pulled pin-9 of the Xbee high again.

This only ever happens on initial start-up, and confuses me.
I've written to Digi, but have yet to receive a response to this specific issue(perhaps they are trying it for themselves before they reply - Digi seem pretty good on replies to questions)

So, I am wondering if anyone else has had this issue when interfacing the Picaxe to the Xbee modules AND are using the Xbee's sleep mode.

See attached GIF of the schematic, which shows how I have things connected up.

As I say: This works beautifully to drop the 5v TTL from the Picaxe to CMOS 3.3v level for the Picaxe, and data transmissions and reception is just fine, it's just that the same divider won't work on the sleep pin of the Xbee, and I want to find out why.

I generally don't use any divider at all on Xbee pin 2(DOUT, Data-Out), as this tends to be connected directly to the Picaxe as it is less then 5v, or directly to a MAX202 arrangement for connection of the Xbee to a PC port.

IF I BREAK THE 3x 10k RESISTORS TO DECK ON PIN3 AND PIN9 OF THE XBEE, SO THAT PIN3 _AND_ PIN9 OF THE XBEE ARE ESSENTIALLY FLOATING, THE MODULE SLEEPS IMMEDIATELY ON POWER UP.

If I reconnect the 3x 10k resistors to deck on EITHER PIN3 OR PIN9 OF THE XBEE, THE MODULE REFUSES TO SLEEP.(during this test, I reconnected the potential-divider to deck on pin9 of the Xbee FIRST - the module stays awake, so then I disconnect it - the
module sleeps right away, so I then reconnect the potential-divider to deck on pin3 of the Xbee - the module stays awake.)

If I rig up a test as in the attached GIF, and put 5v on the top of the divider, so that there is 3.3v on the Xbee pin, the module sleeps immediately. If I measure the voltage on the Xbee pin upon power up when connected to the Picaxe, it is also 3.3v, but in this case, the Xbee won't sleep for 10 seconds.

Is this not a weird one?(rhetorical)

Any comments/suggestions/hints/large hammers?
 

Attachments

Last edited:
hippy

hippy

Technical Support
Staff member
I recall having some similar issues but it was so long ago I forget the details. One thing you could try is running the PICAXE at 3V3 with the voltage divider removed and see if that improves things.
 
G

Grogster

Senior Member
hippy said:
I recall having some similar issues but it was so long ago I forget the details. One thing you could try is running the PICAXE at 3V3 with the voltage divider removed and see if that improves things.
Click to expand...
Is the Picaxe 14M or 18X happy at 3.3v?

I thought that they were(are) 5v TTL devices...
 
C

ciseco

Senior Member
Hi,

I suspect you have Sleep Mode (SM register) set to "pin hibernate", we don't use them this way as you have to supply a voltage to the pin to make it sleep which consumes power, not really the object. If you set to "no sleep" they work the other way round, strange terminology of theirs, "no sleep" not actually what it means.

So, take the pin low and it sleeps, this way the device needs waking at power up as by default the PICAXE output will be low. Heres what I do in code, on our dev boards, just call the procs when needed. I also as dippy suggests run everything at 3V3, makes life so much simpler.

If you go to the x1 parts you can background recieve too, which makes "proper" two way comms possible.

You can set the SM register with either AT commands or XCTU

Here's a link to our circuit, compare it with yours, tried to embed link to the picture but it wont work PHPBB, here's the actual page instead

http://www.ciseco.co.uk/forum/viewtopic.php?f=34&t=41


XBEEwake:
high 6'take XBee SLEEP pin high
high 4'take XBee DATA pin high
high 7'take XBee RESET pin high
return
XBEEsleep:
low 6'take XBee SLEEP pin low
low 4'take XBee DATA pin low
low 7'take XBee RESET pin low
return

Miles
________
medical marijuana card
 
Last edited:
C

ciseco

Senior Member
Ah, just re-read your post, you are working this way round, if as you say taking the pin straight to ground sleeps it immediately but not going low through an output, get a meter on it, got to be some good reason for it. Try another output as well. Failing that post your entire circuit and I?ll see if there?s anything I spot. Are you anywhere near Nottingham? I could plop your Pro into a board and see if still does the same.

Miles
________
vaporgenie vaporizer
 
Last edited:
G

Grogster

Senior Member
Thanks. Yes SM-1 - Pin Hibernate. I will re-program that to NO SLEEP - yeah, NO SLEEP sounds like the sleep pin is disabled - weird...
:(

Anyhow, will do this, then test.

Yes, already put meter on it - 3.3v upon power up on pin9 of Xbee - it should sleep, but it won't for 10 seconds, during which time, it is sucking almost 100mA from the 9v battery - batteries do not last long...

Nowhere even CLOSE to Nottingham - I'm in New Zealand - other side of the planet!!!
:p

Also, to clarify - are the Picaxe's happy at 3.3v?
Manual says it should be 4.5v - 5.0v.
There is no mention of 3.3v...

Thanks.
 
C

ciseco

Senior Member
They are fine at 3V3.

So I don't need to put the kettle on then :)

I've been doing some trials, with 4AA's powering a prototype with a NATIONAL SEMICONDUCTOR LP38693MP-3.3 voltage reg, in sleep mode (XBEE and PICAXE) it's down to about 0.5ma (if my meter is acurate which I doubt), the dropout is low enough to use LiPo cells too. A 3rd PP3 size 900ma should be good for over a month, seen a 11000ma which might do a year + snoozing.

It's got an enable pin so you can shut the entire circuit down to 0.00x something, spec sheet time, from an output. You could have an RTC with alarm fuction to power it back up periodically if needed.

Hope you get to the bottom of it

Miles
________
vaporizer instructions
 
Last edited:
M

muckypups

Member
Hi,
I'm not using a Pro, just a basic series 1 Xbee but I see a similar thing.
I am using one device to take readings (Grandad), then send a signal through the xbee when out of spec.
The second device (Mother) mostly sleeps, but wakes to check for a signal periodically.
I have found that after the initial power up of the (Mother) device, even though my code specifies a time period of 2 seconds + a nap 5 , it takes a good 10 seconds or so for the xbee to go back to sleep. After that initial delay, the device sleeps for 6 seconds, then the xbee is live for 2 seconds then back to sleep (as intended).

I have determined this by measuring the current readings, and when correctly asleep, the device pulls 0.1 mA, while when awake it pulls 50mA.
The receiving device also seems to have inconsistent results after it receives a valid signal. Sometimes the xbee will return to sleep as intended after an alarm is triggered, but occasionally, it will not behave until it has received another alarm signal. Obviously this is not good.
It took me ages to figure out how to check for a signal from the xbee without reading via serin, so my code is probably still incorrect.

Here is the code for the sensor device (Grandad):
Code: 
' This is the arrangement for 3.3v feed (1.4 mA quiescent current/ 56 mA alarm current)

symbol RED = 7
symbol xbee = 4
symbol Xaxis = b0
symbol Yaxis = b1
symbol Zaxis = b2

init: 
	high xbee

main:
	readadc 0,Xaxis	'X axis
	readadc 1,Yaxis	'Y axis
	readadc 2,Zaxis	'Z axis
	if Xaxis >149 then alarm
	if Xaxis <104 then alarm
	if Yaxis <131 then alarm
	gosub normal
	goto main

alarm:
	low xbee  'power up xbee
	nap 4 'pause 200
	high RED
	nap 3 'pause 100
	serout RED,T4800,(1)
	nap 5 'pause 500
	goto main

normal:
	high xbee
	low RED
	nap 7
	return
And this is for the receiver (Mother):
Code: 
' This is the arrangement for 3.3v feed (0.1 mA quiescent current/ 56 mA alarm current)
symbol xbee = 4

init: 
high xbee 'assert pin sleep
sound 0, (124,10,123,10) ' power-up beep
setint %01000000, %01000000 'check for a high on the xbee RSSI pin

main:
	low xbee 'wake xbee
	nap 5 'wait for xbee
	pause 2000 'leave time for the interrupt to work
	high xbee ' send xbee to sleep
	nap 7 'power save picaxe
	nap 7
	nap 7
	goto main

interrupt:
	serin 7,T4800,b0
	if b0 = 1 then
		for b1 = 1 to 20
			sound 0, (124,10)
			sound 0, (123,10)
			sound 0, (122,10)
			pause 10
		next b1
	else if b0= 2 then
		for b1 = 1 to 2
			sound 0, (123,20)
			pause 20
			sound 0, (123,20)
			pause 20
			sound 0, (123,20)
			pause 20
		next b1
	endif	
	low 6 ' clear residual xbee RSSI reading before main loop
	setint %01000000, %01000000
	return
The sensor (transmitter) is set to SM1 (hibernate) and the receiver is set to SM2 (doze).
I am setting the xbee sleep pin high to make it sleep, and low to wake it up. This appears to pull only 0.1 mA when asleep.

I realise this probably doesn't help your situation, but I share some of your issues.
I may try the "no sleep" and set low to sleep method described by ciseco.
I also agree that picaxes are fine at 3.3v, as that is what mine are running at. I program them through an AXE90 board.

If anyone has a better way to save power please share ;-) I can't use the cyclic sleep modes of the xbees because they require a coordinator, and a coordinator cannot sleep.
One interesting thing is that if the receiver sees valid alarm activity as soon as it's powered up, there is no unexplained delay in sleeping. It's only when it's first powered during a quiet stage. Definitely odd, but the xbee spec sheets are pretty cryptic, so it could be explained in there somewhere.

Alan

ps. I'm using a 1/2 AA 3.7v Lithium Thionyl Chloride 1AH battery with a diode to drop the voltage below 3.4v (max xbee voltage) Not the best solution, but it works ok. This has a max continuous draw of 40mA, but according the to spec sheet can handle a higher draw for short periods.
 
Last edited:
C

ciseco

Senior Member
mmmm, strange, here's what I've just done, to see if I get the same behaviour, here's a dump from my log file

18/09/2008 17:12:51 SENT:aCC2ZZ00001S
18/09/2008 17:12:51 RECD:aAC2SNOOZING
18/09/2008 17:12:51 RECD:aAC2AWAKE---
18/09/2008 17:12:52 SENT:aCC2ZZ00001S
18/09/2008 17:12:52 RECD:aAC2SNOOZING
18/09/2008 17:12:52 RECD:aAC2AWAKE---
18/09/2008 17:12:53 SENT:aCC2ZZ00001S
18/09/2008 17:12:53 RECD:aAC2SNOOZING
18/09/2008 17:12:53 RECD:aAC2AWAKE---
18/09/2008 17:12:54 SENT:aCC2ZZ00001S
18/09/2008 17:12:54 RECD:aAC2SNOOZING
18/09/2008 17:12:54 RECD:aAC2AWAKE---

You'll see that I say to sensor C2(3&4thbyte)ZZ(sleep)00001(period)S(seconds)

It then replies I'm snoozing, then awake a second later and so on

I use either 10CD (latest) or 10A5, versions of firmware, what are you running?

Miles
________
501
 
Last edited:
G

Grogster

Senior Member
Thanks to both of you for you posts. Today, I will do a little hardware-hacking on the prototype to see what happens. My plan of attack is:

1) Re-program Xbee so that SM=0(no sleep)
2) Remove 7805 feeding Picaxe, and run both Xbee and Pic from the same 3.3v
3) Remove the potential dividers and directly connect Xbee to Pic.
4) Alter code of Pic to put a low on Xbee pin9 to see if it sleeps.

I will post back here with result later.

Thanks again for your help and suggestions.
:)
 
G

Grogster

Senior Member
Programming pin9 on the Xbee for SM=0(no sleep), then pulling pin9 directly to deck, the module stays awake. Pulling pin9 high or low with SM=0 has no effect on sleeping the module at all.

One thing that does seem to be working, is pulling the pin5(RESET) low, which holds the module off until pin5 is released. I will now rig up a test with pin5 pulled low(ignoring pin9 for the moment, and leaving SM=0) then pull it high to 3.3v and see if it wakes up on command.
 
M

muckypups

Member
Grogster said:
One thing that does seem to be working, is pulling the pin5(RESET) low, which holds the module off until pin5 is released. I will now rig up a test with pin5 pulled low(ignoring pin9 for the moment, and leaving SM=0) then pull it high to 3.3v and see if it wakes up on command.
Click to expand...
Hey Grogster, how did that work out ?
I haven't tried it, but I would have thought that holding the reset down will just delay the inevitable. The xbee will still need to initialise when you release the reset and I would think if you use that method to "sleep" the xbee, you may end up with a 10s wait every time you need to send/receive. My problem is only a one time penalty on first power up, and then it wakes up, waits for a signal and then shuts down (doze) all within 1 second, repeating every 7th second. (I've modified the receiver code since I posted it here).

Also, if you are running at 3.3v and using the sleep pin method, you are better off using doze over hibernate, as the current draw is higher for hibernate at 3.3v than it is for doze.

My project is fine on the transmitting side, with a 1AH battery lasting roughly 72 * 10 hour days (estimated), but I can only get the receiver up to 12.5 * 10 hour days so far.
I can't see where else to get the savings from. I'm attempting to increase the power down delay on the receiver, and decrease the transmission time on the xmitter to try and reach a middle point. As long as the receiver can set the alarm off within about 30 seconds of the first transmission it will be good. As long as I don't kill the xmitter battery waiting for the receiver to pick up.

Sorry, I'm not trying to hijack your thread. Just rambling. Let us know how you're getting on when you get chance.
BTW, I actually get a 15 second start up delay so you're better off than me before you start ;-)

Alan
 
M

muckypups

Member
ciseco said:
Hi,

Do you know what your sleep/doze overall current is? are you sleeping the picaxe at the same time?

Cheers

Miles
Click to expand...
Not sure who you're asking, but my device uses 0.18 mA when the picaxe is on a nap AND the xbee is dozing (SM2). This corresponds nicely with the 0.17 mA the xbee should draw when on SM2 and the voltage is 3.4v, according to the data sheet.
Other than a speaker and related cap and resistor, there are no other components.
Alan
 
C

ciseco

Senior Member
Cool, glad I saw your post, I'll try tommorow at 2.8v and see what I get down to and if all still works

Cheers

Miles
________
Jaguar XKSS
 
Last edited:
G

Grogster

Senior Member
ciseco said:
That's why I gave you a schematic and code to look at :D

hehehehehe

miles
Click to expand...
Oh yes, I looked at the schematic, and thanks for that - not meaning to sound ungrateful - anything but.
:)
:)
:)

I think I will just leave SM=0 and pull the RESET pin low to sleep the module, and leave it at that. Still have not actually tested it on the prototype, but on my programmer board(self designed) there are two buttons - one for WAKE(connected between Xbee pin9 and deck), and RESET(connected between Xbee pin5 and deck), and pressing and holding the RESET button holds the module off(low on pin5). Releasing the reset button wakes the module(3.3v measured across pin5 and deck).

There is around 5mA drawn by the module while held in RESET like this, but this should provide much better battery life - that 100mA for 10 seconds is killing 9v batteries very fast. The device was only lasting 6 hours on a new 9v battery.
 
Last edited:
G

Grogster

Senior Member
@ muckypups: Re. RESET control - no, this does not seem to be the case. Testing shows that on initial power-up, with a 14M pulling Xbee RESET pin5 low, the module "Sleeps" right away. It then "Wakes" when Xbee pin5 is high, transmits, and sleeps again when commanded.
 
Last edited:
M

muckypups

Member
Hi, glad to see it works. That method seems to use 25 times the amount of power I use though, and while I'm not happy to have 15 seconds at 50mA, it is only once in 10 hours.
The longer time is spent with it sleeping properly so I gain there. Whether the battery will be happy is another issue. If you can get it down any further it would be cool. My project is waking up at first power up unlike yours, so I don't want the xbee to sleep immediately.
I'll let you know if I cure it while using pin sleep.
cheers

Alan
edit:
Actually, I may try your method for initial power up and see if I can get rid of the 15 second delay, then switch to my method for normal use in main. Have to solder another couple of wires first ...
Thanks to ciseco too.
 
Last edited:
C

ciseco

Senior Member
Cool bananas,

As to squeezing more out, using the enable pin on this vol reg would take you down to 1ua (bet theres even better), just need to find a way of waking it back up once a day, for that all I can think of is an RTC with alarm, but someone better than me might be able to come up with something capacitor based. There's always the bistable relay option to take it to nothing same problem exists about waking it though.

http://www.farnell.com/datasheets/67170.pdf

Miles
________
Mercury Topaz history
 
Last edited:
M

muckypups

Member
Ok, I've tested the system using the reset pin, with interesting results.
Holding the reset pin low while powering up does not remove the delay or lower the current drawn. It does reduce the delay down to 10 seconds. Odd.
So to sum up, At first power up, the current drawn for the whole circuit is 50mA which lasts for 10 seconds with the reset pin held low. After those first 10 seconds, the circuit wakes as required normally. After the first power up and the reset has been released, the code uses the sleep pin as before and sleeping current is 0.18 mA.
Now I'm confused. If the code is working as required then the reset pin is released immediately, the normal code waits for the interrupt then sleeps using the sleep pin. Next time it wakes, it checks to see if this is the first run then wakes the module using pin sleep instead of releasing the reset. Whatever happens, the reset should not be allowing current to flow immediately. It is hard to observe due to the required immediate wake up of the module, but as the main code only wakes the xbee for 1 second, where are the extra 9 seconds coming from on first run ?
Could someone check my code and see if it's correct for holding the reset low ?

Cheers
Alan

Code: 
symbol xbee = 4 'xbee pin sleep
symbol reset = 5 'xbee pin reset
symbol firstrun = bit0

init: 
low reset
firstrun = 0
sound 0, (124,10,123,10) ' power-up beep
setint %01000000, %01000000 'check for a high on the xbee RSSI pin

main:
	if firstrun = 0 then
		high reset
		firstrun = firstrun+1
	else
		low xbee 'wake xbee
	endif 
	nap 4 'wait for xbee 288ms
	pause 500 'leave time for the interrupt to work
	high xbee ' send xbee to sleep
	sleep 3 ' power save picaxe
	goto main
interrupt:
	serin 7,T4800,b0
	high xbee
	if b0 = 1 then
		for b1 = 1 to 18
			sound 0, (124,10,123,10,122,10)
			pause 10
		next b1
	else if b0= 2 then
		for b1 = 1 to 6
			sound 0, (123,20)
			pause 20
		next b1
	endif	
	setint %01000000, %01000000
	return
edit:
Ok, I've changed init: to read
let pins =%00000000 instead of low reset
Now on first power up, I get approx 2 seconds at 5mA then 9 or 10 seconds at 50mA then sleep.
I believe the module is being held in reset, but there is an initialisation delay of 10 seconds when the xbee is first woken up.

???
 
Last edited:
M

muckypups

Member
Right, in order to test the reset held low theory, I have inserted a wait 5 before the high reset inside the firstrun test.
Bizarrely, now I get less than a second at 5 mA and still get 10 seconds of 50 mA before it sleeps again. What happened to the wait 5 ?
:(:confused::mad:
I have checked the xbee settings and it is not set to try and associate at power up, so it really shouldn't be active (AFAIK).
This is bugging me now.
 
M

muckypups

Member
I've changed the code back to my previous post. I can't get rid of the delay using code, and it seems the best I can manage is 10 seconds at 50mA as a powerup penalty.
I read somewhere that the xbee xmits various values at start up, but there seems to be no way of preventing this or making it quicker.
Time to go down the pub I think :eek:
Another issue is my xmitter device is running low on charge so the alarm doesn't work anyway now.
Time to dig out the 433mHz chips I think ...

Cheers

Alan
 
C

ciseco

Senior Member
I still dont know how you've got a 10 second wake up, mine pop up almost instantly (would have to try to give you an exact figure, the code below gives you an idea though)

If I plug one in, I get a message saying it's started before having chance to look up, however do seem to remember the old 1083FW versions I first got from tech supplies took a few seconds to come alive.

I put a little pause in as if you dont it doesnt work, 100 is a nominal figure, I can try reducing it to see how low I can go if you like? I could also try doing an immediate sleep if that would help too. I'm as puzzled as you :confused:

Doing it this way I'm not getting as low current as you sleep wise, that's next on the list to see how to make it go sub 0.5ma


init:
setfreq m8
symbol BAUD=T4800_4
symbol XBEEdataoutPIN=4
symbol XBEEdatainPIN=7
symbol s1="C"
symbol s2="3"
gosub XBEEwake
pause 100
serout XBEEdataoutPIN,BAUD,("aA",s1,s2,"STARTED-")
main:
blah blah
XBEEwake:
high 6'take XBee SLEEP pin high
high 4'take XBee DATA pin high
high 7'take XBee RESET pin high
return
XBEEsleep:
low 6'take XBee SLEEP pin low
low 4'take XBee DATA pin low
low 7'take XBee RESET pin low
return
________
Brabus
 
Last edited:
M

muckypups

Member
Hmmm, I think my issue is due to trying to make it sleep immediately, then wake, rather than just wake. I did find that the reset does hold it down but doesn't deal with the delay in waking. I may try waking it immediately (like you), sending a quick signal, then see how long it takes to sleep after that. Also, you have SM=0 whereas I need SM=2 to get the low sleep current. You are also doing the opposite with pin sleep to what the spec sheet says. That may be fine when SM=0 but with SM=2 it will try to sleep if held high.
I'm gonna go back to the breadboard and just concentrate on this issue I think, with minimal components. You are giving all the pins high which might be "energizing" the xbee faster. I'm only giving the reset pin high, and keeping the rest low. My device is a receiver which might be making the difference too.
I have a feeling that it is part of the design that it takes a while on first wake, but it shouldn't be 10 seconds. I have posted a question at Digis forum, we'll see what turns up.
Thanks

Alan
 
G

Grogster

Senior Member
Well, as far as what I am doing, I put Xbee SM=0, then left Xbee pin9 floating, and connected the Picaxe output pin to Xbee pin5(reset), and pulling this low upon power-up IMMEDIATELY puts the module to "Sleep" with a 5mA current - OK not as good as you have stated you can get it, but so long as it works to reduce battery consumption, I don't really care that much.
:p

I _DO_ send the Xbee some "Pre-amble" bytes during initial startup - perhaps this is relevant?

The bytes are simply "ABCD"

I've also dropped the 9v rechargeable batteries in favor of 3x 3.7v LiIon batteries in series instead, and these seem to last much longer then 9v batteries...
 
hippy

hippy

Technical Support
Staff member
Just throwing ideas in the wind ... but could the different behaviours on Reset be down to it not being a pure 'hardware reset' but a software reset initiated by hardware, coupled with the fact that an XBee can have its firmware re-programmed being an issue on top ?

I always got the impression there was some hardware means of restoring factory defaults but it was never clear to me how that could be achieved.

Different bahaviour could also arise with different hardware and different firmware.
 
M

muckypups

Member
Hi hippy.
Yes you can send AT commands to reset the xbee(FR) and also to restore the defaults (RE).
I agree about the different firmware causing differing results too. I have been through the entire range of settings using XCTU, and I cannot get rid of the initial 10 sec delay at power up. I'm not too worried overall, as since 6/7 of the time I will be running at 0.2mA instead of the 5mA drawn by using the reset pin. Just bugs me that there seems to be no way to find out what is actually causing the delay. I have turned off association, and turned all the active scanning down as low as the software will permit, but those 10 seconds still pop up on power up. There was a brief glimmer of hope when I realised I could set the sleep mode (SM) by AT commands so I could start with it set to 0 (no sleep) and use the reset pin instead, but unless the sleep pin is floating (disconnected) it won't make any difference.
My question on Digis forum has gone unanswered thus far, but I don't expect there will be too many people who have the same energy worries as me. If an answer comes up I will of course have a crack, but for now I'm happy I've done all I know how to do.
The power problem still remains of course, and so it is now time to move on to 433mHz modules, which should be far more controllable power wise (from what I've read so far). My main issue with using 433mHz will be the antenna, as I want this to fit in a pretty small enclosure, but I have some good howtos to refer to, so I'm gonna have at it forthwith :)
 
C

ciseco

Senior Member
Mucky rather than me try to replicate your problem (which I can't seem to), what do you need to acheive and I'll have a bash at mocking something up, if I get it working without the 10 sec's issue maybe you can see where the difference lies. I'm about to start work on a colour LCD remote that's powered by a 900ma LiPo so it'll be useful and good practise to squeeze every drop of efficiency out.

Miles
________
Ford VN platform picture
 
Last edited:
hippy

hippy

Technical Support
Staff member
Yes you can send AT commands to reset the xbee(FR) and also to restore the defaults (RE).

I'm sure I read there was an ( undescribed ) means to purely hardware restore factory defaults, such as after the baud rate had been changed and AT commands could not be sent but it's been a while since I've read the datasheet.

I got myself into a major mess when playing with sleep modes, telling it to go to sleep so quickly that I couldn't re-program it from the AXE110 Wizard nor X-CTU which - on topic - may suggest I wasn't seeing such start-up delays as you're experiencing. I cannot recall exactly how I saved that from being jammed up, I may have re-flashed the firmware.
 
M

muckypups

Member
Hippy, you're probably right. I'll reflash the firmware to default. I've changed things back and forth so many times it may help. I may try another module too. And a bigger battery.
I've got this all mounted on stripboard, that wouldn't cause impedance issues would it ? (if impedance is the word I think it is). Also, I have a speaker and associated capacitor ( 10uF) and resistor attached to an output on the picaxe. Would that allow current to feed the cap at power up ? (newbie !)

Miles, there is very little to it really. One device uses a picaxe to read an accelerometer and when the values go out of a defined spec, it transmits a signal to the other device. Obviously I want the receiver to use as little power as possible and still catch any signal, which hopefully will be an edge case anyway. The unit with the gmeter idles at 1.4mA which I'm happy with. But the receiver needs xbee current levels to do its job.

There really isn't a lot to change hardware wise. I originally got the xbee, gmeter, and picaxe because I thought they had all the needed functions and the xbee was a "drop in networking" module. The gmeter has an onboard regulator, and the picaxe is easy to program. I've been involved in electronics since I started building this project, so I know nothing. I'm learning, but this xbee issue doesn't seem to be an EE problem more an issue with the xbee design in the way I'm using it. 0.18mA isn't bad, but it averages out at around 7.3mA (ignoring the initial 10 second surge) which is too much. I'll never get it to be equal to the other device, but around 2 mA average would be nice.
Have a crack at it by all means.

Cheers

Alan
ps. should we start another thread or take it private ? I seem to have thoroughly hijacked this thread :eek:
Although the title is still relevant ...
 
P

parisien

Member
urgent help guyzzz

hey guys plz help me

tell me hw do we use the ADC1 / ADC2 in a picaxe 08M? wat are we using for ??im building an MPPT but got some problems, coz i have to regulate the output in such a way i always get 12V/2A or 20W output. so i think i have to use those ADC1 / ADC2 but dt know how.

plz help me guys if u have aby idea coz im really stuck

tanx for ur help

cheers.

Parisien
 
P

parisien

Member
guys,

stil got another problem. iset my pwmout at a freq of 20Kh, 80% duty. i need to use this signal to switch my transistor in the boost converter. the problem is now, b4 i connected my picaxe to the circuit, i got the squarre wave that i want , with the magnitude and duty cycle, everything perfect. then now when i connect the pin5 to the base of my transistor, i got a funny wave signal, and the magnitude of the waveform drops so much like close to 0.8V.

Dt know wat the problem is !!! can u plzzz guys help me out with this, is someone understand the problem


plzzz help me out, its so urgent.
tanx.
 
C

ciseco

Senior Member
parisien, I'm sorry I can't help you much with this, might be good to create a new thread as you've tagged onto the end of somehting to do with zigbee comms.

Alan,

Here's what I'll do to mockup something, not got a g meter, so let's go for something really basic, I'll get an LDR across a potential divider, read the values and when I swipe my hand over send a message, that way I'll be checking something and then alerting on a condition. And measure the resultant current and time to respond. Not quite what you have. My measurements will be higher unless I bypass the voltage reg, but at least we'll see a jump back and forth. If that looks ok I'll try and get something a little closer. Whats the G meter, does it just give out a proportional voltage to force? or is it serial, I2C??

No, no no, it's recieve you have issues with, I'm slightly confused with "gmeter idles at 1.4mA which I'm happy with. But the receiver needs xbee current levels to do its job"

Can you take a photo or descibe what both ends should do.

I might be being thick here, had a wine or two, but I can't understand exactly. When I do (I'm a bit dim at times) I'll be on it in the morning, like a good challenge :)

Miles
________
Inspire
 
Last edited:
M

muckypups

Member
Miles,
Code: 
--------   -------------    -----------                    ------------   ---------   -------------
 gmeter } |   picaxe   }    |   xbee   }  ->   ->   ->  -> {   xbee  |  {  picaxe  |  {   speaker |
--------   -------------    -----------                    ------------   ---------   -------------
                                          |<-30 meters->|
The only reason I mention the gmeter is because it's part of the project, it's not a cause for concern so far. 1.4ma is the total current draw for that side of the equation if you like, and I'm trying to get the speaker/receiver side to match the gmeter side. Not going to happen I don't think, but it's worth a try. The gmeter side will keep running for over 70 * 10 hour days at that current, but the receiver/speaker side will only last 12.5 * 10 hour days or so because the average current is about 8mA. The energy budget is lopsided and there is no point transmitting to a receiver that died 10 days ago. So in the interests of efficiency, I'm trying to reclaim the 10 seconds that are wasted energy when the receiver circuit powers up. Over all it will only make about 1.5 hours difference to the battery life if I only power up once per day, but it's a loose end :D
So the only hardware to worry about is the picaxe and the xbee, which is why I was trying to code my way out of it.
The gmeter is the Dimension Engineering DE-ACCM3D. I've attached the specs sheet.

Cheers

Alan
 

Attachments

M

muckypups

Member
To be fair I ought to describe the connections between the picaxe and the xbee.
I currently have pins 1,2,3,5,6,9,10 connected on the xbee which is Vcc, Dout, Din, Reset, RSSI/PWM, Sleep and Ground.

I've attached the schematic showing the picaxe pins.
 

Attachments

G

Grogster

Senior Member
hippy said:
I got myself into a major mess when playing with sleep modes, telling it to go to sleep so quickly that I couldn't re-program it from the AXE110 Wizard nor X-CTU which - on topic - may suggest I wasn't seeing such start-up delays as you're experiencing. I cannot recall exactly how I saved that from being jammed up, I may have re-flashed the firmware.
Click to expand...
Oh yes, I did the same!!!
:p

I programmed an Xbee for SM=1, then when I wanted to change something, I couldn't, as the module was "Asleep" and would not acknowledge the programmer anymore!!!

In my case, I had designed a programmer/repeater/receiver PCB, and had put a reset tact on the board, but no "Wake" tact - a quick re-design and re-etch of the programmer PCB, and now I have a reset AND a "Wake" button. The wake button just pulls pin9 of the Xbee low, to wake it up, and you basically just hold this button down while you program changes in the Xbee Connect wizard.

I probably should have used a toggle switch for the "Wake", so that I can have my finger back while programming, but it does not seem to be that much of a hassle to just hold the wake button down...
 
G

Grogster

Senior Member
muckypups said:
Alan
ps. should we start another thread or take it private ? I seem to have thoroughly hijacked this thread :eek:
Although the title is still relevant ...
Click to expand...
As the thread starter, I am perfectly happy with the way the thread is going, if that is worth anything to anyone here.

The problems muckypups is posting about is still relevant to the 10-second delay and current consumption problems of sleep modes etc with respect to the Xbee module. The posts are actually quite interesting to read, and will be useful for future reference.

I don't consider this thread to be hijacked...
:)
 
Last edited:
You must log in or register to reply here.
Top