Xbee's vs other 2.4GHz services...

[Grogster]

Hello everyone.


Xbee's are still my preferred RF solution, and I have done several field tests with them, including operating Xbee links in the presence of a constantly-active 2.4GHz wireless Internet connection, and they have always worked flawlessly - even when used within the same room as the aforementioned wireless Internet router and a laptop connected to the wireless Internet connection browsing the net at the same time. I have also tested Xbee's ability to work within the range of cheap and moderately priced A/V senders, and have also experienced no problems. This probably has something to do with the "Intelligence" of the Xbee units themselves, and their ability to "Find" a channel in the 2.4GHz band with which to transmit the data on...

What I am now curious about, is that many towns and small cities have started setting up small 2.4GHz wireless Internet transmitter sites, to offer free wireless Internet to anyone within range. These 2.4GHz Internet transmitters tend to be in the area of 500mW-1W or so, from what I can find, so am curious if anyone has any information as to how this may or may not affect the performance of Xbee modules used within range of one of these high-power wireless Internet transmitters?

Do any New Zealand members here, know of any transmitter output powers used with these new wireless Internet sites? I am curious as to if the NZ regulations have changed, and that more then 100mW is now permissible in the 2.4GHz band.

I know this is not specifically a PICAXE question, but there are many members here who use Xbee's with the PICAXE(as do I), and are very familiar with the wireless technology and power ouputs as a whole, so figured I would just ask.

 

[ciseco]

Hi,

Quick reply.

"This probably has something to do with the "Intelligence" of the Xbee units themselves, and their ability to "Find" a channel in the 2.4GHz band with which to transmit the data on..."

They aren't unfortunatly, the channel is set manually.

"has any information as to how this may or may not affect the performance of Xbee modules used within range of one of these high-power wireless Internet transmitters"

IEEE 802.15.4 (the basis of the xbee and others) was designed to coexist with IEEE 802.11x, it will still work, there is however bound to be a tradeoff in certain locations and changing channel or using directional antennas maybe the only way to improve things. As the band gets busier, transmission distances will drop for sure, by how much, who knows, 315/433/868 etc are all busy places to be too, nature of the beast I'm afraid.

Miles
________
Plymouth Belvedere

 

[Dippy]

Tell him to load up a stack Miles

 

[ciseco]

Aren't you in bed yet?
________
extreme vaporizer

 

[manuka]

Powerful WiFi APs are found usually outdoors of course - on building tops etc. IMHO the weaker, but more localised indoor 2.4GHZ "RF Fog" is much more of an issue. The average western home is now festooned with Bluetooth cell phones/headsets, cordless phones, video links, baby monitors, security systems, diverse toys & of course WiFi laptops etc - all "sharing" the same 2.4GHz spectrum slice.

It's a near miracle that a weak service like ZigBee can find a spectrum niche!

 

[ciseco]

Where of cause in other unlicenced bands there's plenty of free space and better behaved kit?

Weak? limited by the same regs as wifi, bluetooth etc, you can buy boosters if watts are needed.

manuka, I'm led to believe you are a man of considerable knowledge especially in RF, I'd not expected such narrow views. Maybe it's all a bit too "new fangled", spectrum niche, that's very misleading.

Bluetooth devices and the like, while operating in the same band, in theory do not interfere with 802.11b/g because they use a frequency hopping spread spectrum signaling method (FHSS) while 802.11b/g uses a direct sequence spread spectrum signaling method (DSSS). Less can be said about deliberatly designed in coexistance of ASK or FSK on 433Mhz kit.

Miles
________
sativa strains

 

[manuka]

Ciseco: That's a tad personal! "Narrow views"? The 2.4GHz ISM band (2.4- ~2.48GHz) is only ~80MHz wide. Given the huge B/W available at µwave freqs, this is incredibly narrow! Of course it was never intended for so many sophisticated & diverse services, & some now have moved up to a quieter 5GHz, or even back to 900MHz.
I'm well aware of the diverse analog/digital/SS/FH techniques being used by BT/ZigBee/802.11b/g/n, but even here in wide open spaces NZ shared spectrum issues arise. Powerful analog. AV senders are a particular culprit, as is "all over the band" frequency hopping Bluetooth when nearby.

At the very least these emissions tend to raise the 2.4GHz spectrum noise floor, meaning weaker signals such as ~1mW ZigBee may be swamped, or WLAN system performance annoyingly degraded into near uselessness. It's akin to pedestrians trying to cross a road perhaps. Sure -cars & pedestrians can avoid each other, but too many of either will congest the roadway & frustrate. Google for numerous tales of 2.4GHz wireless woe!

Don't get me wrong- I'm an enormous ZigBee fan,but I keep it in perspective! 73s- Stan (ZL2APS-since 1966)

 

[Dippy]

Oh dear, thats ruffled some feathers!
Stan has brought out his medals

You've gone and done it now Ciseco!!

Jut for the record, I've used XBee in close proximity to a busy WiFi/WLan and Bluetooth and the wife's Anne Summers Electric Toy Christmas Fun Set with absolutely NO issues.
And that was straight XBee.
Oh, and the Micowave oven was on too!!

 

[ciseco]

I didn't expect for a moment not to get anything back. Was a much better summary of things than before, good to see there's much more understanding behind what I thought was a little biased in the first place and that stan's reputation preceeds him for good reason.

Sorry stan, if as Hippy suggests it was a little strong, now just to confuse things, I'm not actually much of a fan of Zigbee, it's too little extra functionality on top on of 15.4 for the hype, 6wlopan, that's potentially a different matter.

Raw spectrum bandwidth potential maybe but the devices I read you guys mentioning spec sheets on are sub 10kbps, the demands for actually constructing a self aware network never mind supporting more than a few nodes would in my mind require a far greater data throughput than these device can support.

Add in any kind of reasonable encryption and you've blown the budget a few times over and ever being able to use a picaxe. So I conclude if you want to spend more money to actaully achieve less with something that's completely proprietory, open to the outside world from a security perspect then you're completely on the right track.

Miles
________
hashish

 

[manuka]

Dippy:Wait till your neighbours start their WiFi turkey carvers & room to room adult 2.4GHz AV entertainment!

I too have numerous happily coexisting home 2.4GHz devices, & even with most NZ buildings being near RF transparent (timber walls), rarely experience interference. Globally however such is NOT always so,with 2.4GHz frequency hopping spread spectrum (FHSS) cordless phones amongst the most notorious culprits, as they can blanket the entire spectrum slice.

Ciseco: My comments were in response to Grogster's initial posting, & were not intended as a "mines better than yours" shootout. The nature of this forum relates to tight budget educational PICAXE applications-those of you working in $$$$$$$ fields should reflect most schools & hobbyists struggle to justify $$($). In 2007, I helped a NZ school that'd assigned US$2 per student for electronics, & even at university level final year projects typically are budgeted at ~US$100, with students having to personally fund extra items...

 

[ciseco]

hehehehe

Those damn AV senders are trouble you are right, merrily trouncing any reasonable attempt at co-existence by the later technology.

You mentioned zigbee no one else really did i thought.

I felt that "It's a near miracle that a weak service like ZigBee can find a spectrum niche!" wasn't something that could be said in isolation without some kind of balance and putting in bold "go read the spec sheet" didn't land well here.

I'm always a little blunt, hope you didn't take it too much to heart, I just enjoy a bit of debate (the misses just can't cut it)

Miles



Just saw your edit, $$$$$$ I wish, this project I have worked on every day for well over two years, the last year unpaid with all development funded from my own savings.
________
website design

 

[Grogster]

Thanks guys - interesting reading!

The A/V links I have played with are ones which only output 10dBm(10mW) of juice, and I have found that with the Xbee PRO's 100mW output, they still have the power advantage over the A/V senders, which probably explains why they work in the same area as A/V senders. I have never tried any tests with the low-power Xbee, which I think is either 1mW or 3mW - I forget which. These ones might have problems(perhaps?) in that they have a lower output power then the "Noisy" A/V links have, so...

Anyway, I have not(yet - touch wood!) had any problems with the Xbee Pro's vs other 2.4GHz devices.

I primarily started this thread, as I was interested to hear(still am) from anyone who HAS had problems.

In my case, the Xbee's are roof-mounted(outside the roof) in a water-proof box, which essentially guarantees line-of-sight operation with the exception of the plastic case at each end. I have got extremely good range results when used this way - FAR superior then using them "Indoors" where they have to transmit through walls, which has a quite drastic effect on range at 2.4GHz. During one test with 100mW modules, I was only able to get about 30 meters "through-walls", which is pretty poor. Roof-mounted, I can get 700-800 meters of reliable comms easy using the pro modules with chip-aerials, dropping to less reliable comms out at about 900-1000 meters. I still think this is very good indeed. I was designing for a range of about 200-300 meters - anything more then that is a bonus, so...

 

[moxhamj]

Hi Grogster et al. I've been lost in the world of coding today and have just caught up with this thread.

First - I agree re roof mounted. Get those antennas up in the air. Basic RF stuff I know, but it is often overlooked. WiFi routers next to big metal PC boxes etc. At milliwatts and at these frequencies the RF energy is like a little torch globe. If you have a small torch in a house you might happen to see the light through the window. But put the globe on top of the house and you can see it a lot further.

Wireless mesh is complicated. Just describing protocols is complicated. Sending data like a picture jpg via multiple hops involves local storage and co-ordination to make sure not every node is talking at once. That takes complex coding and such systems are always going to be evolving so that involves systems that can upgrade their own software via the mesh. I won't say I have all the answers, but the problem has now gone open source and has input from over 80 people including the CP/M community, the propeller community and some of the picaxe community. Picaxe certainly is going to be part of the solution at the simple "sense and forward on" level.

Grogster, if you are getting those sort of ranges that is very impressive. Have you considered writing that up as either a step by step website or an instructable or some other similar format that has lots of pictures and not too many words and shows how things plug together etc? How to waterproof things up on the roof. Cabling etc. Even just how to send a simple text string from one picaxe to another would be very handy.

 

[Dippy]

"Wireless mesh is complicated."
- you can say that again!

But it sounds darned impressive don't it

I doubt if grogster and most people doing simple A-B-A should clutter their cerebellums with it. (INcluding me, and they don't come much simpler).

Check out the ZigBee and Miwi stacks in Microchip. Interesting reading for re-inventing wheels

 

[Grogster]

At milliwatts and at these frequencies the RF energy is like a little torch globe. If you have a small torch in a house you might happen to see the light through the window. But put the globe on top of the house and you can see it a lot further.

Excellent analogy!!!

Grogster, if you are getting those sort of ranges that is very impressive. Have you considered writing that up as either a step by step website or an instructable or some other similar format that has lots of pictures and not too many words and shows how things plug together etc? How to waterproof things up on the roof. Cabling etc. Even just how to send a simple text string from one picaxe to another would be very handy.

I have not considered writing any of it up until you suggested it, as it was built that way, because it works that way - documenting it was not a priority, if you see what I mean.

Basically, the Xbee modules are mounted on a carrier-PCB which has a PCB-mounted 9-pin D plug at one end. The board also has 3.3v regulation allowing me to send 5v or so up the data-cable for regulation down to 3.3v using a LDO regulator. On first reading this, many of you are probably amazed it works, as you would imagine that voltage-drop would stop the Xbee from working with only a difference of 2v or so to play with. It does not seem to. Voltage stays at 3.3v across the module even when powered via the cable(even when transmitting), and I have never yet had one single dropped or garbled transmission using this method.

5v power, enable/disable, reset, DIN and DOUT lines are carried via a 9-core serial data cable from the module. This allows ONE PCB-module to act as both a transmitting or receiving node on the network. I designed for a 10-meter cable length, but I have run tests with BOTH the transmitting AND receiving end-nodes running though 20 meters of cable each, and there has not been a single character dropped. Generally, 10 meters is enough length, if you plan the position of the roof aerial/PCB-module. If more length is needed, you just add a 9-pin serial extension cable of suitable length, plugging one into the other in a daisy-chain.

The modules(consisting of the carrier PCB, Xbee module itself, on-board LDO regulator) are fitted to the inside of a 40mm PVC pipe which is installed right through the roof(steel roof in my case, but there are ways to cut hole through concrete tiles too if that is needed - roofers are a great help with this work!). In my case, the house has a very flat roof(only a 3-5' run-off for rain water), so with the pipe sticking up 500mm clear of the highest point in the roof, the "Module" gets a clear 360' view of the entire surrounding area.

As this is on a farm house, there are no other obstructions in the way once you get up as high as the house roof. I have not tested this approach in a built-up suburban area where there might be 2-story house roofs in the transmission path, but so long as there was not more then one, the signal would probably still get though, albeit with a reduction in range in that direction.

The PCB-module itself is fitted to the inside of the top of the PVC-pipe by wrapping it first in fabric/foam dish cloth. The end of the top of the pipe is champhered to aid the fitting. The idea is, to make the module a tight, but not excessively so, push-fit into the top of the pipe. A 40mm pipe-cap is plopped on top, and sealed around the edge with silicone sealer. Using the cloth wadding serves a couple of purposes: It acts as a way of holding the module in the top of the pipe without needing to bore any holes in the pipe for mounting screws etc, which may start to leak over time, and it also acts as an absorbent for any condensation which may form on the pipe - especially in the winter. I have tested this method, by installing a dummy PCB in the end of a short piece of pipe, and putting it in the deep-freeze for a few hours to bring the assembly down to -10'C.
I then bring the module out into a room heated to 25'C and wait for condesation to form. This is a somewhat drastic test - the change in temperature would not be that sudden in reality, but it served the purpose to see how much condensation is likely to be produced. The end result was that the PVC pipe did get wet with condensation, but the wadding soaked it all up, and when the assembly was pulled out of the pipe, it was found that the inside edge of the wadding was still bone-dry, and there was only marginal(read: extremely fine) condensation on the PCB itself. During normal exposure, the temperature change would not go from -10 to 25 inside about three seconds, so the condensation factor should be even less.

Better stop ranting...

 

[Grogster]

"Wireless mesh is complicated."
- you can say that again!

But it sounds darned impressive don't it

I doubt if grogster and most people doing simple A-B-A should clutter their cerebellums with it. (INcluding me, and they don't come much simpler).

Check out the ZigBee and Miwi stacks in Microchip. Interesting reading for re-inventing wheels

Yes, I don't used MESH.
I DID considder it, as the hopping idea would be very useful, but I too decided it was too complicated to learn it, when I knew series-1 Xbee's quite well.

My system is point-to-point anyway.

 

[manuka]

Line of Sight (LOS) any 2.4GHz wireless data can go for miles- the world WiFi record with standard gear (although big dishes) is a staggering ~300km in Venuezula

Using "WokFi" dishes we managed ~3km LOS across water with a pair of 1mW XBees in 2006 => www.picaxe.orconhosting.net.nz/zigscoop.jpg yet (bare) these only reached 20m indoors thru' wooden walls.

The same WokFi dishes gave ~300m LOS with a Bluetooth range trial => www.usbwifi.orconhosting.net.nz/btscoop.jpg

 

[Grogster]

Line of Sight (LOS) any 2.4GHz wireless data can go for miles- the world WiFi record with standard gear (although big dishes) is a staggering ~300km in Venuezula

Oh...My...GOD!!!

Using "WokFi" dishes we managed ~3km LOS across water with a pair of 1mW XBees in 2006 => www.picaxe.orconhosting.net.nz/zigscoop.jpg yet (bare) these only reached 20m indoors thru' wooden walls.

The same WokFi dishes gave ~300m LOS with a Bluetooth range trial => www.usbwifi.orconhosting.net.nz/btscoop.jpg

Wow, that's impressive for 1mW!!!


Great stuff.

 

[ciseco]

Manuka,

Not sure if it was this thread or not, you drew my attention to that datasheet on the hope jobbies and the 8 year statistic. Last night I spent 10 minutes going over it. It's hardly an earth shaking result to lower the average current consumption by turning the device off for 9.x seconds out of 10. The actual recieve and transmit figures are pretty standard. They have implemented a simple synronised cyclic sleep period. This takes me back 6 months to what I susgested could easily be achevied for little cost/a little more effort.

However for me it's of little general use, something simple like turning a light on, at worst it could be 9 odd seconds before I can see. If any type of mesh was attempted, over a couple of hops the reaction time could be half a minute, fine for a temperature sensor but little use for a gate opener in the rain or a cut off for a filling tank.

I've been thinking a lot about this now. I once wished like many for a low power, cyclic sleeping, auto forming/healing routed network of autonomous nodes. The more I give it brain cycles the more I see a many sided dicotomy with absolutly no solution.

Pro ------------------------------------------------ Con
1.Batteries, you need to save power (has to be asleep) - see 2.
2.Instant reaction time (has to be awake) - see 1 and loop
3.Long distance (needs power) - see 1
4.Long distance (needs sensitivty) - read COST
5.Long distance (needs high gain antennas) - cost and ease of use
6.Managment of the network (lots of similar data) - bandwidth and memory
7.Routing between nodes (ooops they are asleep) - see 2
8.Caching of data (for the devices that are asleep) - memory
9.Important router asleep or ran out of power - potential loss of entire segments.
10.Security - needs horsepower

There's more I'm sure. The more I look at things, the solution of best fit for power/features is also the simplest a slave/master arrangement. I suggest forgeting trying to mesh route or it'll be cyclic downtime vs response time no matter how "natty" the device. Static routing is fine, thats quite simple but dont sleep it (that's the draw back) sorry Drac, not what you want I know. The quick solution is however a simple one, buy a bigger panel, perhaps augment it with a homebrew turbine. The other simple potential is to cache the data and sync sides periodically of the static router, just impacts the reaction time. If seconds or minutes aren't an issue its an easy win. I suspect most won't value this draw back over using a smaller/cheaper panel.

There's no solution to fit all, sad, but in my mind totally true.

This is my last post on the subject.

I'll keep out of this now and stay in my own XBee (or 802.15.4 derivative of choice) world of slave and mastery, where power saving is easy


Miles
________
volcano vaporizer reviews

 

[moxhamj]

Last post Miles? I'm not giving up on this!

Ok, the model I'm working on is to have cheap and cheerful picaxes and $2 Tx units. They can be sensors - eg moisture in the soil or temperature or whatever. Deliberate short range eg sub 50 metres so many clusters can be 50+metres apart and share the same frequency. Battery powered, sleeping most of the time, solar charge but hardly need any power - microwatts. Random on times. Might only come on for 1 second every hour.

Next is the mothership. This is much smarter, running CP/M and collecting data from all the little sensors. On all the time. Using about 0.3W. Charged with a 10W solar panel and Talking to other motherships within range via any longer range module (brand does not greatly matter and the more generic drop in replacements the better, though so far Yishi is the only one we have). Then somewhere might be a PC though this isn't a critical feature. On all the time so used for things that need reliable data transfer eg turning on a sprinkler, right now, because we don't want a delay. So yes, you can't devolve that function down to the "sometimes on" nodes.

Some specs. Even though CP/M can go to 38400, CP/M boards are communicating at 1200 baud, because this is slow and reliable and compatible with picaxe. So if a picaxe does happen to be near a power supply and can afford to listen all the time, you can talk to these too. Critical pieces of software which are all coming together include a Serin with timeout , file transfers, shell processes, batch files, collection of statistics on link reliability, directory listings and compare with nearby nodes, auto send files that a node is missing, local keyboard/display for debugging nodes. Then there are some boring bits of code that are needed in the background - eg true random number generator, LCD drivers, keyboard drivers.

From the CP/M boards perspective, the rules are fairly simple. Listen to the airwaves. If quiet for a while, wait a random time, then send out pings to random board numbers. As pongs come back, collate these and build up a database of links. Collect list of local files. When a link is 100% reliable to a nearby board, establish comms with that board and transfer that boards list of directory listings via xmodem. If they are missing one or more, send just one of those files. (don't want to hog the airwaves).

Once boards have established their link reliability, send a packet into the network. Boards wait a random time and then forward it on to only those boards they know they can talk to.

With the help of a PC, or maybe via software on the board, it should be possible to build up shortest path tables so that messages go via the minimum number of hops.

Want to upgrade software? Put a copy of the new version eg myprog25 on one board. Other boards will discover they don't have this and the file will propogate through the network. If you can send files and send commands you can request files, change filenames, send new files, run custom programs etc.

I think xbee could be an important part of this network. If you feed in data at 1200 baud into an xbee, can you get the same data out at 1200 baud from another one?

 

[xnederlandx]

Dr_Acula started me thinking... so I came up with this system.


Idea: "HOPS to Master"

Terminology:

Master: An important/control module/unit on the network.
Module: A router and/or monitoring (e.g. soil temp, humidity, etc.) module/unit on the network

Implementation proceedures:


Ping:

A)The master control unit sends out a ping. This ping starts with a counter value ("Hops to master" value) of 1.

B)The Module(s) that recieves this "Ping" will remember the pings "Hops to master" value (only if the value is lower than the current "hops to master" value or if the Ping number is different to the previous ping), the Ping number(which is used to check if further pings received are new or old).

C) It sends out another ping, this time with an incremented value of (e.g 2).
D) Loops back to Step B untill all modules and masters have a "Hops to master" value for the sending master


Data transfer:

A module will only pass the package onward if it's "HOPS to Master" value is lower or higher (depending on if the data is going to a module [higher] or to a master [lower]) than the module that's sending it.

For Communication between master and module:

Each module and master has it's own "Serial Number", so when a Master want's to communicate to another module on the network, It simply sends out a "packet" containing its destination "Serial Number". As the destination is not a master, it has to be sent to everyone on the network. To avoid the packet circling endlessly, it gets passed down (not up) the "Hops to master" chain of the master that sending it. It may be better to have modules automatically sending data, rather than a master requesting it. However, This could still be used as an updating system, as it reaches everything connected to the network

Communication from master or module to master

The master or module sends out a packet containing the destination Master's Serial number. All modules & Masters in between will recognize the masters serial number, and use the "HOPS to Master" system to send the data to the master in the quickest route.



Notes:

A relatively long qualifier (or pre-fix) should be used on PING messages (so the results are repeatable. [not just a module picking up a weak signal]).

This ping should be done fairly quickly, possibly a whole network in 10- seconds ? , however this would depend on the size.

Preferably all modules should have the same range, to avoid situations where a module cannot reply to what is heard.

Pro's


This system ensures the fastest route is taken to Masters, without need for mapping.

More than one master can be on the network, with each module knowing the required hops to each master, e.g. stored in an EEPROM for lookup.

If modules are added or removed, the network can be updated automatically or manually with a Master, without need to redownload a routing or mapping table to everyone on the network.

 

[Dippy]

Have a look at the ZigBee stack code.
It makes very interesting reading.

You can get a lot of info from Microchip and download Zena.

Job done in a matchbox.

 

[ciseco]

Hi Drac,

Oh no, not 'the' last post I'm sure, just mine

Yep my last post on this 'sort' of thread, the old how to mesh using parts from here and there (changes often it seems). There's realism and idealism. We have a working network that achieves 90% of the ideal without too much cost or effort. It's capable of supporting 1296 devices per 2.4Ghz channel, there's 16 channels, so that's over 16,000 in any one single location per IP gateway. Each "cell" can be either RF bridged OR TCP/IP routed giving a theoretical infinate amount of devices (assuming the channels dont overlap). Planned minimum reaction time from host to device 100ms (leaves a huge amount of the 250Kbps bandwidth available for retries and announcements). Supports sleeping, mostly off, mostly on etc. However cyclic sleeping and routing havent been implemented as they aren't actually that useful in a real world situation, the "easy fixes" they represent can be overcome via latteral thought 99% of the time. I'm soon to deal with IR support then I will move to doing 315/433Mhz cell extenders (YEP YOU READ RIGHT 433), local devices are better served via 2.4Ghz/898Mhz 15.4 kit as there's already a defined solution for co-existance, encryption, channels, panid etc etc. All things you'd either have do without or re-invent.

Have to agree with the Dipster there, zigbee stuff, it answers most problems (mesh wise), copy it, you'll have to re-invent something akin to the 15.4 subsystem that supports it too, you'll have to forget about the baby picaxe though, I reckon you'll run out of memory and variables just on source/destination/crc before even having a payload. You'll get slightly further with a X part, that'll sort your background recieve too. Unfortunately it'll bump the cost up significantly, this is why we use raw PIC's in products but have a backward path to the PICAXE for people to play with making thier own sensors/devices. We have used Proton and Swordfish on the PIC, one guy has used an Atmel micro and I'm wanting to get into the HCS series by freescale, they do a 15.4 chipset for about $3USD. The end goal is a solution nearly as inexpensive that's based on a feasible initial design. Like you it'll be published freely for the solder iron community, comercial use however may atract a small fee.

I really do hope you find something you are happy with, it's sounding like you'll probably achieve something that performs just how you need and negate spending that $100 on another solar panel. For the general populous, I suspect it'll have little appeal over it's initial cost as you'll have enginereed in so many limitations to get another part to work sucessfully.

I do admire the community optimism in finding a solution, was a only a year ago, I was there too. Now that I've been doing this everyday for well over a year, in all I've learnt, I now conceed the problem has actually no realistic answer to the initial question

cheap, autonomous, self routing, sleeping & flea power

if one of these primary directives is broken things become entriely possible but thats not where it started

(Dippy has one, clarevoyant RF) he's yet to supply data on said vaporware care to explain?????


Miles
________
vaporizer forums

 

[Dippy]

My clairvoyant RF uses the worn out Crystall Balls that have been so handy in this Forum.
Carefull rubbing has made my balls small enough to resonate at 2.4GHz and therefore produces an interrupt to the Sleep routine. Obviously there is an analogy to real life here too, apart from the dimensional aspect.
You should be able to get less than 1microamp standby.
It's perfectly easy, just keep rubbing.

Trouble is, in a busy network, an 'unwanted' node never goes to sleep, so its almost a waste of time.

 

[ciseco]

Ah man, I nearly peed myself from that much laughing
________
buy iolite vaporizer

 

[Grogster]

Carefull rubbing has made my balls small enough to resonate at 2.4GHz and therefore produces an interrupt to the Sleep routine. Obviously there is an analogy to real life here too, apart from the dimensional aspect.

HAHAHAHAHAHAHAHA!!!!!!!

 

[Grogster]

I think xbee could be an important part of this network. If you feed in data at 1200 baud into an xbee, can you get the same data out at 1200 baud from another one?

Yes.
You can even CHANGE baud rates via the link.
EXAMPLE: Feed in data at 9600 baud in one end, suck it out the other end at 1200 baud or whatever you want. It works both ways, so you can setup whatever baud rate you want to at both ends. Naturally, for simplicity, most people opt for the same baud rates and protocols at both ends to make things easy to understand, but the flexibility is there to do it differently.

You can also alter the protocol using "Undocumented" info from the Digi website, or, in other words, commands NOT listed in the Xbee command reference manual to change the UART baud-rate and parity settings.(ATNB command)

Bog standard is 8N1, but I also use 8N2 on one interface, as the pager-transmitter the Xbee is controlling would only talk at 8N2, but ignores messages in the more standard 8N1 - go figure!(transmitter would simply respond with "ERR SYNTAX" if you sent it a message in 8N1)

Here is a link for those interested...

http://www.digi.com/support/kbase/kbaseresultdetl.jsp?id=2144

This is an extremely useful thing to know, if you ever need to change the baud-rate from one end of the link to the other, and I am not aware of any other modules which can let you do this.

 

[KIGX]

Dr Ac,

I'd be careful if I was you. I have this image of you caught in your viral mesh, pleading for Hal to open the pod bay door. Not good.