Ok, I'll try my best to explain, warts 'n all.
I eventually met a guy called Rauul from Digi, I briefly explained what you had witnessed with the packet loss.
I was greeted by what I can only describe as a face of indignation with such ferocity you of thought I?d of asked permission to defile his daughter. His following comments were little better. To paraphrase ?miles you are an idiot? was how it reached me, then to be told ?and if you?d looked at the manual you?d know?.
Now as some of you might be aware I?ve not got the slowest of fuses, but on this occasion managed to refrain from knocking him off his feet.
Thankfully he switched to a far more useful and less patronising mode. In this he stated this is what you would expect from a broadcast and to rely on the device you need to set the destination, along with all sorts of other stuff.
My mind immediately switched to ?well that?s not what I?d call drop in networking? so left before getting into one with him.
As I was driving back I was going thorough in my mind how I could describe this to you all and it dawned on me, he was right and I was being an idiot.
How best to describe this, mmmmm, this is how it figured in my mind as I?m from a computer background.
If we look at the way computers talk, there?s UDP and TCP comms.
UDP is essentially broadcast (same terminology there)
TCP is unicast
When you send a UDP message it?s like shouting in the middle of the street ?WANT TO BUY MY APPLES? some people hear you and some don?t (10-30% message or packet loss)
If like TCP you tap someone on their shoulder and then tell them the message you know they have heard you (0% loss)
Then I remembered one of the features of these devices, unlike simple data cards which echo incoming bytes to the serial interface and you have to decide through programming if the message is valid or not.
These do it for you, BUT the rub or benefit(depends on your view) is that any incomplete or corrupted message is simply dropped.
So this explains a lot.
In broadcast mode the sender XBee fires your message into the air without a care in the world. If another XBee receives that message and it?s valid all is well (70-90% of the time in your test hippy). If however just like with a 433 card (where at least you can actually see it happen) you get a corrupt byte, it works out it?s not valid and drops it (hence the loss)
In unicast mode you specify I want to talk to (back to computer speak) 192.168.0.1 (or however they represent it) and the conversation starts, is acknowledged and retries if errors are found, hence a more dependable method.
Now here?s the issue,
I never relied upon XBee acknowledgements, routing and retries because I program each sensor and the pc software to do it. I use the ?zigbee? network in broadcast mode and mop up the errors and just rely on the XBee doing CRC etc. If all?s not well I like it discarding the packet. For me that?s cool, stuff either gets there correct or never at all. An easy situation to cope with and why we can use IR, cable, tin cans or indeed any other method with our protocol. There?s a guy in NZ using it over 433 already but has to modify it to contend with the issues it brings (think he adds two extra bytes for error checking). I also like the XOR idea already floated here by someone.
If I were to utilize their method I?d have to do a little extra work to say at point of sending to say ?send HERE?. That?s then going to exclude me from these other transports unless Digi release the code so that I could use the same process for IR, cable, tin cans etc.
As with everything in life pro?s and cons.
For me (personally) I still feel the XBee offers much better value than radio cards. Admittedly 433?s can be as little as a quarter of the price, but what they wont do without me writing code is give me a message I can actually depend upon getting there or not, I have to code for gibberish being received (not difficult). I can have multiple overlapping and non communicating networks (quite difficult). Also I can depend upon it?s security and encryption (very difficult and impossible on a picaxe).
My next move is to see if I can meld the new digimesh into what we do, I think for us it will just work because we rely on so little of the zigbee stack and doing 3 retries through software with even a loss of 70% isn?t too bad as 70% of the remaining 30% is 21% and 70% of 9% is 6.3%, so expected overall good transmissions should be around 97.3%.
If I can suggest something to Drac. What would be of great personal interest is if you could write a wrapper that provided a similar mechanism over 433, then embed (or affix) it onto the radio card so anyone could add a picaxe (or whatever) on top of all that (seems like you are already going that way with Z80/Picaxe). Only thing, the cost is then increasing, add that $20 3uA card and it?s now more expensive for less features.
Saving serious power in my mind needs to be time based, this doesn?t need long term RTC accuracy. This is I assume why the digimesh nodes can only go 4 hours max is because they are using the internal MCU to do it and that?s the best they can achieve without a proper clock.
I?ve already mentioned in a chatty mesh those 27mA/3uA jobbies will spend most of their time being awoken by traffic not destined for them or by stray other transmissions, if they stay up for even half the time that?ll only be 13.5mA average.
IF (I stress) it?s possible, bringing a 50ma/1ua device up for 100ms (120 bytes at 9600bps) in every second would equate to an average of 5mA+0.9uA.
If that?s possible, perhaps our simple 12 byte protocol would only need 10ms, so an average of 0.5mA+0.99uA.
I bet in real life I could get no where near this but you see where my mind is going, reducing duty cycle is the way, unless there is a device that can be awoken on an individual basis.
Nothing is ever easy
Time for a cuppa
Miles
________
MB/T/X Series
