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

[Grogster]

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

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.

Welcome to the forums.
If you post your question in it's own thread, people here will be able to help you i'm sure.


Posting on a thread about Xbee problems, a totally different problem, will not really get you very far, as people would have to be reading the 4th page of posts before they see you have a problem at all!


You'll get much faster help, if you start your own threads - one new thread for each problem you are having.

I'll have a look for your new thread shortly - good luck!

 

[ciseco]

Mucky, sorry it took me a day longer, but I've tried it. What I've done is put a N/O push switch into the battery circuit, so I have to press it to turn on/recieve. The code is a complete hash of rubbish, as I was working on something else at 9600 hence running at 8Mhz, but I thought keeping it simple to SERIN would help. This when I bash the button and fire a command from a mouse click works perfectly. My reaction times are hardly measurable, but it's got to be less than half a second from push button, click mouse. Seems to work time after time.

What's RSSI wired for? just interested


init:
setfreq m8
symbol BAUD=T4800_4
symbol XBEEdataoutPIN=4
symbol XBEEdatainPIN=7
high 6'take XBee SLEEP pin high
high 4'take XBee DATA pin high
high 7'take XBee RESET pin high
pause 400
main:
serin XBEEdatainPIN,BAUD,b0,b1,b2,b3,b4,b5,b6,b7,b8,b9,b10
sertxd ("COMMAND RECIEVED ",b0,b1,b2,b3,b4,b5,b6,b7,b8,b9,b10, 13, 10) '
sertxd ("looping")
goto main




Miles
________
SH150i

 

[ciseco]

My only other thought is, you are not adjusting any parameters with AT commands? this takes time to time out and revert to normal operation.

Miles
________
Plymouth Prowler history

 

[muckypups]

Miles,
Your code seems to just read serin at startup. It doesn't sleep after the serin from the xbee.
My issue is the xbee is not sleeping when it should. This can only be observed by measuring the current drawn right from initial power up.
pseudo code :

power on
wake up xbee
wait for 1 second
sleep xbee
sleep picaxe for 6 seconds
goto wake up xbee

That code should take 7 seconds to run a loop. It does not have to read any data from serin. But on my circuit, the very first time it runs it takes 15 seconds before you see the evidence of the first "sleep xbee" . It should theoretically take only 1 second. During those 15 seconds, the xbee is pulling its normal idle current (50mA).
That is my issue. I'm not seeing a delay waking the xbee, I'm seeing a delay "sleeping" the xbee on the first run through.

The RSSI is wired because it is the only way of checking for RF activity without reading serin. That is why the xbee wakes for 1 second, to check for RF activity. If you open serin and there is nothing to read, the code hangs (waits for serin to complete) and the xbee remains awake. However, if you check for a high on the RSSI pin, then you're assured that there is RF activity, and so it is worth checking for data via serin. If the RSSI pin is low then there is no RF activity, the code should skip serin and then carry on and sleep the xbee. This has no bearing on the initial sleep issues I'm seeing, as far as I can make out. If there were an erroneous reading from the RSSI pin, it would trigger a serin and the code would hang and never reach xbee sleep. This is not happening, as after 15 seconds the xbee does sleep, ergo serin is not hanging. It is not reading a signal either, as this happens whether or not the transmitter is powered up. I also have a third xbee permanently awake and connected to a pc which reads any data "in the air" so to speak, and prints it out in hyper terminal. This is seeing nothing.

For what it's worth, I also see a similar problem on my transmitting device. The code for that should hibernate the xbee immediately on power up, yet it takes 15 seconds (or so) to see a decrease from xbee current levels.

I have reset both modules to default firmware settings, tried other modules at default settings, and even measured for time differences at lower baud rates, all to no avail.

I'm virtually convinced that these modules cannot be forced to sleep within 10 seconds of power up. Not by using pin sleep anyway. I can get the time down from 15 to 10 by powering up with the reset held down, but if I were to use reset instead of pin sleep during normal runtime, I end up using more power on average overall. Increased overall battery life is what I'm aiming at. To lose the initial 10 seconds at 50mA would be great, but not at the expense of using more power over the course of a day. That is cutting my nose off to spite my face.
Here's the way I'm calculating the average current :

my loop is 7 seconds long, and of that 7 seconds -

1 second = 50 mA
6 seconds = 0.2 mA per second = 1.2 mA
overall current for 7 seconds = 51.2 mA
normal average 1 second current = 51.2 / 7 = 7.31 mA​

My circuit shows a 10 second current (at power up) of 50 mA

10 seconds = 50 mA per second = 500 mA
initial average current for 1 second = 50 mA​

This only happens once, so if the circuit is powered for 60 seconds -

10 seconds = 500 mA (50 mA x 10 seconds)
50 seconds = 365.5 mA (7.31 mA x 50 seconds)
overall current for 60 seconds = 865.5 mA
average 1 second current = 14.43 mA​

if the circuit is powered for 1 hour -

10 seconds = 500 mA
3590 seconds = 26242.9 mA (7.31 mA x 3590 seconds)
overall current for 1 hour = 26742.9 mA
average 1 second current = 26742.9 / 3600 seconds = 7.42 mA​

I realise those numbers look screwy, it looks as if a 1Ah battery should only last just over a minute based on the current drawn overall, but I think the average is what counts. If I draw 100 mA (average) the 1000 mA battery lasts 10 hours, if I draw 10 mA the battery lasts 100 hours, if I draw 7.42 mA the battery should last 134.77 hours. Maths isn't my strongest point though, so feel free to criticise
(Furthermore, if I were using pin reset the average per second (measured over 7 seconds) would rise to 11.43 mA due to the circuit drawing 5 mA while asleep. Measured over an hour it would be a 1 second average of 11.53 mA, and over more than 1 hour, it would keep rising.)

So you can see that if I power the circuit for an hour or more then I am virtually at the minimum average current I can get to for my coded xbee wake time of 1 second per 7 seconds, sleep issues not withstanding.
It's not really worth worrying about, other than to be pedantic. I'm just being a control freak, and if I tell it to sleep, there has to be a good reason why it doesn't.
I can't find that reason.

cheers

Alan

ps. just saw your latest post - no, I'm not using any AT commands. I posted the code I'm using a couple of pages back.

 

[ciseco]

cool, I'll try again tommorow, you could always "brute force" it to sleep with a tranny.

not sure I should use tranny and brute force in a sentance I'll get a bad name

will let you know the outcome
________
justin bieber fans

 

[Grogster]

That was something I was thinking about doing too - force it to a power-off state via a suitable transistor, the transistor controlled via the Picaxe. I am still keeping this one on the table as a last resort if all else fails, and in fact, I think I might do some tests on that idea within the next few daze to a weak.(deliberate spelling mistakes)

For the moment though, holding RESET low on the Xbee seems to be working for me - can't work out why it is not for muckypups...

Xbee's don't seem to play by their own rules for some of us, based on what I have been reading thus far in this thread...

 

[muckypups]

Grogster, just to make this clear.
Holding reset low DOES make the xbee sleep, my issue is making it sleep after it has been woken the first time. It seems that the initial wake up takes the time I am trying to get rid of. Bear in mind I set out to combine both methods in order to get the "best of both worlds", and maybe that just isn't possible.


I regard this as an academic question now, as the overall receive current usage is far too high to be usable for my project. If I switch to using a 433mHz system, the receive current will be cut by over 50% immediately (judging by the spec sheets I've read, receive current is around 20 to 22 mA, as opposed to 50 mA for the xbees)

If I had more space in the project for a larger battery, then this issue wouldn't be an issue.
Unfortunately, I kind of set out to build something to a fairly strict set of constraints, enclosure size being one of them. By moving to 433mHz, I release board space which means more space for the battery. These xbees are huge really, and while that's fine for robotics or general networking, they take up roughly 30% of my pcb area. I realise the 433mHz modules aren't that much smaller, but they aren't the same shape, so they can squeeze in better (hopefully). Long and thin allows space for an AA to sit along side, whereas the xbees are wide and flat, and also are a pain at 2mm pitch.

Anyway, it would be interesting to pin down the cause of the "first 10 seconds" issue, just for future reference.

At the moment it appears that if you want a responsive sleep right from power up, then use the reset pin method. The cost is a higher "sleeping" current than pin sleep.
If you want a (much) lower sleeping current, then use pin sleep. The cost is a one time 10 second delay at xbee idle current levels.

Cheers

Alan

 

[hippy]

I regard this as an academic question now, as the overall receive current usage is far too high to be usable for my project. If I switch to using a 433mHz system, the receive current will be cut by over 50% immediately (judging by the spec sheets I've read, receive current is around 20 to 22 mA, as opposed to 50 mA for the xbees)

You will however lose out on all the things an XBee / ZigBee system offers and probably need to have more complicated software to handle 433MHz. If that's needed to meet the current consumption or other requirements then it seems that is what it will have to be.

The inability to sleep for the first ten seconds is something I'd like to have the answer to ( I have XBees on my desk but haven't found time to test yet ) but it's probably not such a problem for most users or where the unit is powered up for reasonable periods; the excess current drain is just 1.4mAh. Sleep delay or not it's not much of an impact. It obviously is more of an impact if the unit is powered on and off more frequently.

 

[muckypups]

Yes, hippy you're correct. I will lose out on the capabilities of the xbee, but other than the easy serial in / out and sleep, I'm not using them anyway. It was specced because it provided an easy start to the project. Knowing what I know now, I would never have bought them for this project. £20 each is a bit steep too, especially when I only use 7 out of the available 20 pins.
Part of my enthusiasm for the xbees was the Zigbee stack and mesh networking. However, in order to use Zigbee and mesh, you must have most of the devices powered up full time. Routers can not sleep, and neither can the coordinator. Only end devices at the edge of the network can sleep in a mesh network, and they are usually in the minority. So that is strike 2 against the xbee.
Strike 3 is the "all devices must be the same version" issue. When I initially bought the first set of xbees, there was only standard or pro. Now there are 3 distinct versions, each with standard or pro, and none of the versions intercommunicate with earlier or later versions. If I were producing a retail device, I'd be very wary of mass producing a gadget that I couldn't guarantee I could get the parts for later on.
I've tried the 2.5 versions and using the developers kit, I can get around 6 inches distance before it loses signal ! WTF ? And that's using a proper antenna on the base station. So they don't necessarily work correctly out of the box.
There is also a ZB version available. You can convert a 2.5 module to ZB by loading newer firmware, but that's not the same as talking to each other despite their differences.

The xbee is a fine product for complicated network communications, but overkill for simple tasks. And that's not a criticism, just a fact. I over specced my project, because I didn't know any better. I don't really need the snazzy accelerometer, a tilt switch would probably work, and without the accelerometer, I don't need an 18x, an 8m would probably suffice. The cost savings would be pretty good too. If I changed out all those components I would bring the build cost down by about £45.

I'm not really complaining as I've learned a great deal, and I now have an idea of the power requirements and limitations of the xbees, so I can more knowledgeably spec them for any future project. Who knows how many versions there will be by then

cheers

Alan

 

[ciseco]

Hi, mucky,

Just tried this instead. First powers on the picaxe 52.2ma then sleeps it, 4.3ma consumed (haven't bypassed the voltage regulator here, so results are different to yours current wise).

After about 9 secs (sleep *2.3) the current jumps to 52.9ma when awake, I immediately send a command, this is echoed back to me and the current drops to 4.2ma and it waits for another 9 secs. Echo's me awake and I can receive again. Repeat, it's fine, can't replicate what you see.

I lowered it to sleep 1 instead of 4 for every line and it still works fine, so there's no issue I can find with up and down and any wait time. I did however by accident replicate your issue and that was by jumping back to the wrong place in code, you haven't done similar by chance?


symbol BAUD=T4800_4
symbol XBEEdataoutPIN=1
symbol XBEEdatainPIN=2
symbol XBEEsleepPIN=3
symbol XBEEresetPIN=2
'###########
pause 100
sertxd ("xbee on")
high XBEEsleepPIN'to replecate yours being on at powerup
high XBEEresetPIN
high XBEEdataoutPIN
sleep 4
sertxd ("xbee off")
low XBEEsleepPIN
low XBEEresetPIN
low XBEEdataoutPIN
sleep 4
repeat:
high XBEEsleepPIN
high XBEEresetPIN
high XBEEdataoutPIN
sertxd ("xbee on")
pause 100
serout XBEEdataoutPIN,BAUD,("aC##########")
serin XBEEdatainPIN,BAUD,("a"),b0,b1,b2,b3,b4,b5,b6,b7,b8,b9,b10
sertxd ("COMMAND RECIEVED a",b0,b1,b2,b3,b4,b5,b6,b7,b8,b9,b10, 13, 10)
low XBEEsleepPIN
low XBEEresetPIN
low XBEEdataoutPIN
sertxd ("xbee off")
sertxd ("going to sleep")
sleep 4
sertxd ("now awake")
goto repeat

?20, that's expensive we sell em for ?15 including VAT

"Routers can not sleep, and neither can the coordinator", I wonder why? marginal hint of sarcasm perhaps read what Dr A is trying to do with 433's and it should become apparent. If you think of the traffic as other things, being routed (like a pub doorman) or cached/coordinated (like the postman), send either to sleep and you'll not get in or your letters delivered. If you find a module that automatically wakes upon transmission without having the receiver powered, I'd love to know what it is.

Not tried 2.5's yet. There are only 3 types, original, 2.5 and 900mhz long range in my mind

I can understand you are fed up that your idea doesn?t work for you, your plan has a imbalanced energy budget regardless of kit, the reciever was always going to need more, humble pie and a bigger box might be the way.


Miles
________
vaporizers

 

[hippy]

Strike 3 is the "all devices must be the same version" issue. When I initially bought the first set of xbees, there was only standard or pro. Now there are 3 distinct versions, each with standard or pro, and none of the versions intercommunicate with earlier or later versions.

The xbee is a fine product for complicated network communications, but overkill for simple tasks. And that's not a criticism, just a fact.

I'll agree with you on both points (and slightly disagree later ).

When XBee was first introduced it looked to be an almost transparent way of getting a serial signal bi-directionally between A and B with minimal configuration and effort at a pretty good price. If one wanted more range, use a Pro, use a larger 3V3 regulator. Simple as that.

Now I am completely lost as to what their capabilities are, which can do what and which cannot, what interoperability there is and what there isn't, let alone trying to understand the ever increasing number of configuration options there are and a manual which ( when I last looked ) was terse and succinct but didn't really explain things in simple terms and some of the ideas are very complicated. There was a lot of "what it does" but not so much on "what that means".

On top of that there's such a wealth of firmware versions which may or may not be compatible with each other or particular hardware, and it doesn't help that since the X-CTU upgrade a while ago it seems to download everything every time not just what's new.

Where I'll disagree, is for the original XBee which remains more true to the simplistic setup ( where many options can be ignored ) and the cost - if one wants bi-directional comms - isn't much higher than two sets of 433MHz pairs with all the benefits it does bring.

Unfortunately I cannot even name what that original XBee is now called ( and it seems to change every time I look ) nor say with any confidence which firmware it should be running.

Buy the Rev-Ed / Tech-Supplies XBee's and XBee connect kits and PICAXE users should generally be okay, but trying to get more complicated and it has indeed got much more complicated.

 

[muckypups]

Hi ciseco,

This section of code :

pause 100
sertxd ("xbee on")
high XBEEsleepPIN'to replecate yours being on at powerup
high XBEEresetPIN
high XBEEdataoutPIN
sleep 4
sertxd ("xbee off")
low XBEEsleepPIN
low XBEEresetPIN
low XBEEdataoutPIN
sleep 4

this seems to show that the xbee is powered up for 9 seconds before you put it to sleep.
What happens if you take out the first "sleep 4" ? Does it immediately sleep the xbee ?
How long after power up do you see the current drop and does it coincide with your command to make the xbee sleep ?
Also regarding doormen, the xbee seems to offer great drinks and lovely women, but when you get in the bar you find that you only get what was promised if you're wearing purple shorts while standing on one leg whistling the tune to Bonanza

hippy, I agree with your disagreement, the basic ones are fine but they were sold as something they are not. As I said, when I got mine (18 months ago +) there was only series 1 available to buy, but they were still advertising the Zigbee protocol. You can't use the zigbee protocol with series 1. It isn't even mentioned in the manual.
Having said that, if one uses their API, I would expect more control over them. They are known as 802.15.4 now.

cheers

Alan

ps. both manuals can be found on my server

 

[ciseco]

Hi Alan,

That’s why I mentioned I changed them all to sleep 1 to see the effect, nothing stopped working.

I like the bonanza bit, made me giggle.

For me, like Ronseal "does exactly what it says on the tin", maybe for once in my life my expectations are in line with what someone offers, blimey, next thing you’ll know Gordon and his cronies will evaporate, maybe too high an expectation, but a more worthy one, *%^&^*%(^ labour party

The world of zigbee hasn’t settled enough yet for us to expect a finished, solid, cohesive solution, changes happen and improvements made, next will come the pains of interoperability. Eventually I expect zigbee to be a broad common like bluetooth and wifi, I suspect it'll look very different again from what it does now.

Just to add fuel to the “versions” fire I have an as yet released version of firmware that allows bridging/ routing and some mesh features on a series 1

Miles

 

[ciseco]

Hi,

Battery saving and what could be achieved

Just been doing some maths on a project I'm doing, again with XBee's. If you have an RTC that alarms every hour to fire up the picaxe for 1/2 second and transmits a reading, just one CR2032 coin cell should last 2.46 years (this isn't allowing for powering the RTC and switching circuit). Essentially 21600 operations.The reciever could last a similar amount of time if you kept them both in sync, otherwise as you have found, you need to keep the reciever up more.

If we take this to be every 10 seconds instead (which I guess is close to the response time you need) we'd only get 1.5 days. Increase the 230ma cell to a pair of 2500ma NiMH, AA's and you'd see perhaps 16-17 (24hr) days at best. Maybe the transmission could be cut to 1/4 sec to release a month.

Drac has found some RS232 433 recievers that can wake from a light sleep (5ma I think) via the first transmitted byte, that might help you out if you do not wish to introduce extra complexity sync'ing devices, however the recieve current isn't I think that much lower and if there are other 433 devices around, it'll be forever woken by them also, so might not really gain you anything.

Simple looking solutions usually hide considerable thought, a fact that is driven home to me often by dippy and the gang

Miles
________
Chrysler Crossfire picture

 

[muckypups]

Hi Miles,
Firstly, I realise that you were just punching numbers, but you can't use a CR2032 cell for powering an xbee. The maximum continuous current for the cell is about 20 mA or less, and the xbee simply won't work. I know this from experience, and I was using a much bigger cell. See this post. For my purposes, 2x AA cells is too large to fit in the project case.

There are low power 433 receiver modules that can be woken from power down in less than a second, so I would have a similar set up to the one I have now, where the receiver wakes up, checks for a signal and sleeps again if all quiet. This would give me an acceptable lifespan for a small cell. I can filter out erroneous signals using the picaxe and a transmitted "key".

My final approach would be to have the receiver powered by a much bigger supply, as a sort of base station if you like. This in fact was my original plan, but I got sidetracked into making a portable receiver too. The transmitter side of the equation doesn't need much long term power as it only transmits on an error condition, which should be very much an edge case.

I agree there is a lot of thought needed to get things right, fortunately I am building experience now, and I have an idea of the right questions to ask of any prospective product.
My reasoning goes like this - if I can get 125 hours from the xbee drawing 50mA every 7 seconds, I should be able to get 250 hours if I make the cycle 14 seconds long. If I then move to a 433 solution, I should be near 500 hours for the same cycle. Make it a 30 second cycle, and I could achieve 1000 hours. As long as the signal is received within 30 seconds of transmission all will be well. The trick is to make the signal repeatable in a determined fashion in order to guarantee that it is received inside those 30 seconds. I don't think it's impossible, just needs thought and experimentation. Bear in mind the transmitter has plenty of power to retransmit, and that interval can be adjusted dynamically if necessary.
Yeah I know, it's easy to talk a good device, but the fun is in the details.

Cheers

Alan

 

[ciseco]

can send you a picture, I have a single CR2032 powering it as we speak, just seen the whole post not just the one you pointed me at, seems actuality didn't meet expectation there either!

"For my purposes, 2x AA cells is too large to fit in the project case." tell me i'm being out of line here, but isn't this akin to agreeing to drive to scotland on ?5 on petrol, then phoning ford up to say their car is rubbish because it ran out of fuel and that having looked at every one elses fuel consumption figures, you conclude a scooter is a way better option in every sense because it uses less petrol?

I see from the spec sheet 30ma is max pulsed drain (15secs), so you'd need a pair in paralell, was only a test and numbers as you say, I've no idea how many 52ma 1/2 second bursts would kill it in real life.

"My final approach would be to have the receiver powered by a much bigger supply" I thought that was what I was eluding to, doesn't matter what the kit is.

Why do you need to power it for 7 secs continuously, on, pause 50, recieve(baud/bytes=timeout in ms), sleep, etc, should be able to do it in less than 100ms.

If the transmitter is only intermittant get it to transmit for a 2*period+a bit so you catch it.

But I'm not using an X1 part, so I can't do a timeout and it wouldn't fit in the project box, I'm assuming that's why you have the RSSI pin wired and a lower end PICAXE.

If you are going to dig your own grave, may I suggest a spade not a spoon (big smile and a wink)

Miles
________
silversurfer reviews

 

[muckypups]

"Why do you need to power it for 7 secs continuously, on, pause 50, recieve(baud/bytes=timeout in ms), sleep, etc, should be able to do it in less than 100ms.
"

I don't. That's on for 1 second every 7 seconds. Or 6 seconds off, 1 second on.
If I cut down the time between waking the xbee and expecting to read from it, it doesn't work. I currently wake the xbee, wait for 288ms, then wait for 500ms for a signal, then sleep.
If I reduce either of those wait times, I never pick up a signal from the transmitter. I've tried it. The shorter the window of receiving, the less likely I am to pick up any transmission, as the transmission isn't constant, but pulsed about once per second.

As to the rest of your comments, I think you are operating on a different wavelength to me.
If I decide I want to produce an item that does a certain task in certain circumstances, then that's what I do. I don't believe I'm "blaming" the xbee for anything, nor am I interested in making the device larger just to enable me to fulfill certain artificial constraints. If it won't work within the size alloted, then it is not suitable - end of. I'll try another method until it does work. I know I can set something up thats the size of a car battery, but that is not what I was aiming at. I already explained why I am using an xbee, and this whole process has been about finding out its limits. I have found those limits, and they are outside the limits I have set for my project. No Big Deal.
I'll try another approach. The project is important, not "using the xbee".

Imagine if you were creating a device that would fit inside a human vein, and transmit data as it traveled through the body. Would you suggest I solve the power worries by using 2 AA batteries ? Of course not, because doing that falls outside the spec of the device, ie. must fit in a vein.

I really don't want to argue about it, I'll get there one way or another, learning as I go.


Cheers

Alan

 

[hippy]

Battery powered wireless comms always presents difficulties, which is why people tend to avoid it if they can.

The best solution is to keep everything powered up all the time, but that uses excess current and isn't always suitable for battery application. The next best options are a permanently on receiver ( as with burglar alarms, where PIR's etc wake-up, transmit status then sleep again ) or a permanently on transmitter ( as with paging status systems, where the receiver wakes up, catches the latest message being sent then sleeps ).

The biggest problems comes when a transmitter only transmits infrequently and a receiver waking from sleep has to stay awake for long enough to catch anything transmitted. It's a bit of a conundrum as, however it's done, either the transmitter or receiver will be spending more time transmitting or waiting to receive than may be desirable. Getting receivers in synch with the transmitters so they wake up just before a transmitter sends is the best approach there to keep power-up times to a minimum.

For true paging systems it can be even more difficult; the receiver needs to check frequently to see if there is anything for it. Synchronisation as above helps, but there will usually be more wake time than desired.

 

[ciseco]

Exactly, what you are trying to do won't work as you hope, think about the problem, then find a solution, I have given you over the posts enough to give you one, I'm not about to build it for you too
________
Suzuki GS500 history

 

[muckypups]

Thanks hippy. I know what you're saying, and I don't expect to better the professionals. The pros have business restraints to work to - I don't. I will be happy if it works at all, but there is no harm in trying to get it as frugal as possible. I'm paying for the batteries
I didn't get into electronics to make an LED light up, so I realise there is a lot of knowledge out there to be appreciated. Trouble is, I'm a stubborn ****. At one end I'm a qualified car mechanic, and at the other I run web servers and write code to keep them running. The truck driving , machine and plant operating, and world travel sort of overlap the other two.
I'm currently building 2 ecommerce web sites for myself, as well as the live online video system somebody else wants.
Throughout all of those disciplines, there is only so much you can infer, the rest comes from trial and error.
In my experience.

Now,

Miles, did I ask you to build it for me ?

Considering my design draws less current than one you have offered as an alternative, I think you are being a bit egotistical. Exactly who are you to tell me what I want to achieve ?
I can make up a pcb and get this running NOW. The only issue is battery life/ I'm not happy with it. And that is adjustable by reprogramming the picaxe - easy. Let's face it, power is haunting all of our projects, so as I've achieved the lowest power possible using this module and you haven't, let's have a bit less attitude please.

The only reason I commented on this thread was because Grogster was experiencing a similar issue to me. He is now happy with the solution you offered - I am not because it doesn't achieve a better result than I already have. Is that wrong ? I've tried your method, but your method alone is worse than my method. As I said a week ago, I wanted to try and combine the 2 methods to get to the minimum possible. It doesn't work.
End of story. Unless you can better my average current, in which case post away. Consider it a friendly competition.
You are using an undocumented approach, which could be completely negated with a firmware update, I know, I run linux,and it only takes a subtle change in someone else's code to break the happy accident you are relying on. Then you (and Grogster) are left at square one. I am using the xbee documented method, and have taken it as far as it will go (apparently). I'm not in any way sorry I chose to use the xbee, or unhappy about the results. It does achieve the stated sleeping current. All I regret is the time, and that can't be helped. That is my fault. I'm moving on. Logically that is the only way forward. Nothing to do with anything you have offered as a solution.

I realise that there will be similar issues if I try using 433mHz, but
(a)the current I'm dealing with is already halved, and
(b) It's my project.




Like I said before, let's not argue. Don't just read the words, listen to what I'm saying.


cheers

Alan

 

[ciseco]

Hi,

Mucky, my normal sarcastic humor I guessed past you by, sorry, but I was getting frustrated that you keep trying something that you aren?t happy with and I've tried to point out more than once, think laterally.

"Miles, did I ask you to build it for me ?"

No you didn't, silly throw away comment of mine in response to your terse reply where you hadn't aknowledged anything and you (I suspect) hiding the rest of the old post you directed me to, where you were making elemental mistakes in trying to run off tiny cells. Are you miffed I offered to prove you wrong in being able to run off a single coin cell?

"design draws less current "

As you drew me to the spec sheets (of which I'm very thankful), if I drop the voltage, my approach is actually better as you rightly pointed out (did you forget that). I'm going through a voltage regulator (as mentioned, so you clearly understood, or not), I could in half an hour better your consumption figures by a little bit by ripping out the vol reg and running at less than 3.3v. I have given you other ways of tackling it, but it falls on deaf ears or so it appears.

"undocumented approach"

Maybe, not consumed the manual enough to make that judgement, I find it a chore like many others, but look at the AXE210 board that tech supplies does, does it look a similar approach? Actually while I think of it, if it's undocumented why do the consumption tables show it? But then I don?t get the 10 second delay issue either.

"I've achieved the lowest power possible using this module and you haven't, let's have a bit less attitude please."

No you haven't, your best attempt is lower than my normal board granted, I haven't tried to do what you are doing, I've tried to give you other avenues of thought as I think you are barking up the wrong tree. If fact appears like attitude, my post wasn't clear, what I should have got across was "it aint ever gonna work better Alan, change your approach"

"could be completely negated with a firmware update"

It could happen certainly, but hasn't as yet and I've had stuff back to 1083 which is 2-3 years old.

"doesn't achieve a better result than I already have"

Debatable, I dont get no tranmission for 10 secs and I've not been trying to get the current lower. Once I suggested power the whole xbee off instead of sleeping, you could have tested that very easily and it certainly would have produced a better result, have you tried it yet?

"I've tried your method"

Indeed the very simplest part, but none of my other suggestions, I never claimed what I was doing was consuming less, I was simply helping with the 10 second delay and giving you MY figures along the way, see the difference there?

"Exactly who are you to tell me what I want to achieve "

I'm the one trying to help you. It's taken me ages to understand what you are trying to do, as you were far from clear and haven?t a few times actually given me everything to go on even though I asked.

I'm not actually arguing, I call a spade a spade and love a good debate.

And whilst we are calling a spade a spade, there's no need to thank me for trying to assist or the probable few hours I've spent trying to help you by pulling apart my own kit/code and in trying to suggest different approaches and sitting at this bloomin' keyboard.

Can i beat your solution, you bet, by using a different "solution", can I improve your existing "solution", er, no, we agree there!

"Trouble is, I'm a stubborn ****. "

So am I, it's a fun club to be in some days and get's you shot others

Miles
________
video review