mugur said...
Thank you Tracy. Should i suppose the X-CTU will not work on Win7-x64? It's not in their list of OS.
Anyone tried this in 64 bits environment ?
I haven't tried it, but I would guess that it'll work fine. It's really not much more than a terminal program with a specific purpose.
You can do much of what XCTU does (e.g., read and change XBee settings, save changes) through any generic terminal program, though I don't think you can update the firmware without XCTU.
Tracy, that's correct: I'm using nothing but Series 1 XBees in my rocket telemetry thingies. Sometime this year I'm going to change one over to a 900 MHz model, just to get more range, but I don't see any reason to get fancier than that anytime soon.
I just spent the morning working on the program to get my Propeller-based receiver to send the altitude, flight status, and pull-pin status data to Excel through PLX-DAQ. I probably got halfway through that task. I'm really enjoying this kind of project. I'm about 2/3rds of the way through a version that will send GPS position data of the rocket as well, with a receiver that can connect to a Garmin handheld (the old serial ETrex Legend type), so that you push a button on the receiver, and it sends a $GPWPL string to the Garmin setting the rocket's position as a waypoint.· I think I'll manage to get that working completely by mid-March: all of the little parts work, but I can't put it all together until I get my transmitter·boards from BatchPCB, which is going to be mid-February at the earliest.
In my really long-term, overly ambitious imagination, I can think of a reason to go with Series 2 (/2.5) modules in these projects. When a GPS-transmitter equipped balloon or rocket lands, the receiver loses contact, so your last known position is from some point a few hundred feet in the air, which will not be directly over the eventual landing point (close, but...). But if you put up ANOTHER XBee-equipped rocket or balloon somewhere in the area, it could pick up the signal from the one that had already landed, and relay that to your receiver, so you got the precise landing location, not just the last known one. This is exactly what happened last June when I participated in a launch of two balloons with Taylor University/Stratostar in Indiana: the balloon that had not yet landed relayed the position of the one that had already landed to our receiver in the chase van. The Stratostar system is all XBee, and at least as I understand it, it was the mesh networking part that made that possible. XBees are small/light enough that we could hang one from a small balloon over our launch range, and get exact position on the ground of any XBee-equipped rocket that had landed within a mile of the launch pad.
But now I'm dreaming.
Post Edited (sylvie369) : 1/17/2010 6:04:00 PM GMT
You can achieve the same effect with your series 1 XBees (either XB24 at 2.4 GHZ or XB09 at 900 MHz), by reflashing them to the Digimesh firmware. That will automatically take care of routing messages from your XBee that has landed in the bushes, up to the balloon, and back to your ground station. One advantage that Digimesh has over Zigbee is that all the XBees are can sleep at _very_ low power for deployment on batteries or scavenged energy, but still relay messages. Digimesh achieves that by tight time synchronization. With Zigbee, the end points can operate at low power, but all the routers and the coordinator have to be awake at fulll power at all times. That is great for, say, a hospital or factory where you can have wall-wart routers plugged in wherever you need them, but it is a different thing out in the field where the whole network has to operate on low power. I am not knocking series 2 XBees or Zigbee--It a great for its intended purpose and as an industry standard. However another advantage of Digimesh is that it has a very small firmware footprint and all devices in the network run the same firmware. There is no need to flash the different nodes to be end-point, router, or coordinator.
There are a couple of informative white papers on the Digi web site, "Demystifying 802.15.4 and Zigbee®" and "Wireless Mesh Networking ZigBee® vs. DigiMesh™".
There is no coordinator as such in a Digimesh network, but one XBee becomes by a process of election (or by command) the one that acts like a coordinator to select the clearest channel, maintain the routing map, etc. etc. If that one drops out for some reason, the network self-heals. It is easier to understand "802.15.4" out of the box, but it is neat to have Digimesh is an option on the same series 1 XBees. I'm still getting my head around it.
This weekend I'm maintaining firmware for a network of stations in the mountains that have a wireless backbone using "Motes" from Dust Networks. Motes use their own proprietary mesh protocol built on the 802.15.4 baseline. The stations collect readings of snow depth and other parameters that are then packetized and hop through the network back to a central station that relays them out via a GSM modem. One issue in the mountains has been that the 802.15.4 wireless has trouble making the hops during snowstorms. I'm (once again) fiddling with the backup and resiliency code on the Stamp, in anticipation of a string of storms this week. Another tangle is that the snow depth sensor draws a lot of current when it operates, it gives poor readings during a storm, there is very little sun to recharge the batteries, and the battery capacity is diminished by cold temperatures.
I'll have to add that white paper about Digimesh to my reading list. It seems like just about the time I get one version of this working, I learn about something I could add that would make it even cooler (that's how the pull-pin thing became part of it). I guess there's really no such thing as "finishing a project".
I'd read something about "Dust networks" sometime in the last year. Interesting to see them put to use. 19mA transmit? I'm envious.
Post Edited (sylvie369) : 1/17/2010 10:12:21 PM GMT
The Dust Networks' Mote operates at least a year on one CR123 battery. My data logger just passes it packets of data when it requests them and does not have to supply it with power. It uses a rubber duckie antenna that is located high on a pole. The mote technology was commercialized in a couple of directions out of the University here, another one being the Crossbow motes. For the project I am involved with, a grad student here has been doing the networking and the bridge to the GSM modem. Motes are nice, but they are nowhere near as accessible as the Digi XBees, due in part to the marketing aims of the different companies.
The snow sensor is from Judd Communications and is based on the SensComp ultrasonic transducer.
-- P.S. Here is an interesting time-lapse video of snow level taken by a "tree-cam" at one of the sites. In mid January one year ago, a new pole appears on the site with one of our data loggers for snow depth. Note the general lack of sunlight and the snow that piles up on the solar panel. The project is part of the Southern Sierra Critical Zone Observatoory.
When it comes to the Stamp and XBee's. I would rate myself in the "novice" class, but I picked up a couple XBee's and have them talking so I am pleased about that. I couldn't find any "beginner" code samples so I thought I would post my program that checks the status of my XBee's and prints it. It just uses two wires (3 if you want to try flow control) between the stamp and the XBee. I set my XBee's to 1200 baud as it seems to work better with my BS2.
If this is helpful, I'll post more as I get it working. (If I should be uploading this in a file, please let me know that).
' {$STAMP BS2}
' {$PBASIC 2.5}
Baud CON 813 ' 1200 Baud
RX PIN 1
TX PIN 0
RTS PIN 6
i VAR Byte
RXBUFFER VAR Byte(20)
CHARS VAR Word
HIGH TX
DEBUG CLS, "-- Get XBee Config --",CR
PAUSE 2000
DEBUG "WakeUp XBee!", CR ' Guard time for command sequence
SEROUT TX,Baud,[noparse][[/noparse]"+++"] ' Enter command mode
GOSUB GetResponse
DEBUG "Get Node Name (NI): " ' Guard time for command sequence
SEROUT TX,Baud,[noparse][[/noparse]"ATNI",CR] ' Get Node Name
GOSUB GetResponse
DEBUG "Get Node Address (MY): "
SEROUT TX,Baud, [noparse][[/noparse]"ATMY",CR] ' Get Node 16 Bit Address
GOSUB GetResponse
DEBUG "Get Channel (CH): "
SEROUT TX,Baud, [noparse][[/noparse]"ATCH",CR] ' Get Channel we are talking on
GOSUB GetResponse
DEBUG "Get Network ID (ID): "
SEROUT TX,Baud, [noparse][[/noparse]"ATID",CR] ' Get Network we are talking on
GOSUB GetResponse
I'm using the API mode as I think in the long run that's the way to go and there are Java libraries that use that mode available. Like one of the earlier posts, I have trouble collecting all the data in the API packet when I send a lot of data. SERIN gives me every other byte. I'm thinking I can solve this by "SKIP"ing the bytes I am not interested in and keeping my packets a fixed length. I'd like to build something that can survive out by it's own on solar power for a while so keeping the power requirements low is important so I think the BS2's are the best bet.
You must not let your customers know as it distracts them from other projects. I would really love to play with these, but I am far to busy with other things at the moment.
Dr_Acula has other wireless modules running all over the place using props and ZiCog. see the prop DracBlade thread.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔ Links to other interesting threads:
Comments
Anyone tried this in 64 bits environment ?
You can do much of what XCTU does (e.g., read and change XBee settings, save changes) through any generic terminal program, though I don't think you can update the firmware without XCTU.
Tracy, that's correct: I'm using nothing but Series 1 XBees in my rocket telemetry thingies. Sometime this year I'm going to change one over to a 900 MHz model, just to get more range, but I don't see any reason to get fancier than that anytime soon.
I just spent the morning working on the program to get my Propeller-based receiver to send the altitude, flight status, and pull-pin status data to Excel through PLX-DAQ. I probably got halfway through that task. I'm really enjoying this kind of project. I'm about 2/3rds of the way through a version that will send GPS position data of the rocket as well, with a receiver that can connect to a Garmin handheld (the old serial ETrex Legend type), so that you push a button on the receiver, and it sends a $GPWPL string to the Garmin setting the rocket's position as a waypoint.· I think I'll manage to get that working completely by mid-March: all of the little parts work, but I can't put it all together until I get my transmitter·boards from BatchPCB, which is going to be mid-February at the earliest.
In my really long-term, overly ambitious imagination, I can think of a reason to go with Series 2 (/2.5) modules in these projects. When a GPS-transmitter equipped balloon or rocket lands, the receiver loses contact, so your last known position is from some point a few hundred feet in the air, which will not be directly over the eventual landing point (close, but...). But if you put up ANOTHER XBee-equipped rocket or balloon somewhere in the area, it could pick up the signal from the one that had already landed, and relay that to your receiver, so you got the precise landing location, not just the last known one. This is exactly what happened last June when I participated in a launch of two balloons with Taylor University/Stratostar in Indiana: the balloon that had not yet landed relayed the position of the one that had already landed to our receiver in the chase van. The Stratostar system is all XBee, and at least as I understand it, it was the mesh networking part that made that possible. XBees are small/light enough that we could hang one from a small balloon over our launch range, and get exact position on the ground of any XBee-equipped rocket that had landed within a mile of the launch pad.
But now I'm dreaming.
Post Edited (sylvie369) : 1/17/2010 6:04:00 PM GMT
You can achieve the same effect with your series 1 XBees (either XB24 at 2.4 GHZ or XB09 at 900 MHz), by reflashing them to the Digimesh firmware. That will automatically take care of routing messages from your XBee that has landed in the bushes, up to the balloon, and back to your ground station. One advantage that Digimesh has over Zigbee is that all the XBees are can sleep at _very_ low power for deployment on batteries or scavenged energy, but still relay messages. Digimesh achieves that by tight time synchronization. With Zigbee, the end points can operate at low power, but all the routers and the coordinator have to be awake at fulll power at all times. That is great for, say, a hospital or factory where you can have wall-wart routers plugged in wherever you need them, but it is a different thing out in the field where the whole network has to operate on low power. I am not knocking series 2 XBees or Zigbee--It a great for its intended purpose and as an industry standard. However another advantage of Digimesh is that it has a very small firmware footprint and all devices in the network run the same firmware. There is no need to flash the different nodes to be end-point, router, or coordinator.
There are a couple of informative white papers on the Digi web site, "Demystifying 802.15.4 and Zigbee®" and "Wireless Mesh Networking ZigBee® vs. DigiMesh™".
There is no coordinator as such in a Digimesh network, but one XBee becomes by a process of election (or by command) the one that acts like a coordinator to select the clearest channel, maintain the routing map, etc. etc. If that one drops out for some reason, the network self-heals. It is easier to understand "802.15.4" out of the box, but it is neat to have Digimesh is an option on the same series 1 XBees. I'm still getting my head around it.
This weekend I'm maintaining firmware for a network of stations in the mountains that have a wireless backbone using "Motes" from Dust Networks. Motes use their own proprietary mesh protocol built on the 802.15.4 baseline. The stations collect readings of snow depth and other parameters that are then packetized and hop through the network back to a central station that relays them out via a GSM modem. One issue in the mountains has been that the 802.15.4 wireless has trouble making the hops during snowstorms. I'm (once again) fiddling with the backup and resiliency code on the Stamp, in anticipation of a string of storms this week. Another tangle is that the snow depth sensor draws a lot of current when it operates, it gives poor readings during a storm, there is very little sun to recharge the batteries, and the battery capacity is diminished by cold temperatures.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Tracy Allen
www.emesystems.com
I'd read something about "Dust networks" sometime in the last year. Interesting to see them put to use. 19mA transmit? I'm envious.
Post Edited (sylvie369) : 1/17/2010 10:12:21 PM GMT
what kind of snow depth sensor are you using? just curious.
The snow sensor is from Judd Communications and is based on the SensComp ultrasonic transducer.
-- P.S. Here is an interesting time-lapse video of snow level taken by a "tree-cam" at one of the sites. In mid January one year ago, a new pole appears on the site with one of our data loggers for snow depth. Note the general lack of sunlight and the snow that piles up on the solar panel. The project is part of the Southern Sierra Critical Zone Observatoory.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Tracy Allen
www.emesystems.com
Post Edited (Tracy Allen) : 1/18/2010 12:31:01 AM GMT
If this is helpful, I'll post more as I get it working. (If I should be uploading this in a file, please let me know that).
' {$STAMP BS2}
' {$PBASIC 2.5}
Baud CON 813 ' 1200 Baud
RX PIN 1
TX PIN 0
RTS PIN 6
i VAR Byte
RXBUFFER VAR Byte(20)
CHARS VAR Word
HIGH TX
DEBUG CLS, "-- Get XBee Config --",CR
PAUSE 2000
DEBUG "WakeUp XBee!", CR ' Guard time for command sequence
SEROUT TX,Baud,[noparse][[/noparse]"+++"] ' Enter command mode
GOSUB GetResponse
DEBUG "Get Node Name (NI): " ' Guard time for command sequence
SEROUT TX,Baud,[noparse][[/noparse]"ATNI",CR] ' Get Node Name
GOSUB GetResponse
DEBUG "Get Node Address (MY): "
SEROUT TX,Baud, [noparse][[/noparse]"ATMY",CR] ' Get Node 16 Bit Address
GOSUB GetResponse
DEBUG "Get Channel (CH): "
SEROUT TX,Baud, [noparse][[/noparse]"ATCH",CR] ' Get Channel we are talking on
GOSUB GetResponse
DEBUG "Get Network ID (ID): "
SEROUT TX,Baud, [noparse][[/noparse]"ATID",CR] ' Get Network we are talking on
GOSUB GetResponse
DEBUG "End command mode (CN): "
SEROUT TX,Baud, [noparse][[/noparse]"ATCN",CR]
GOSUB GetResponse
END
GetResponse:
SERIN RX\RTS, 813,3000,Timeout,[noparse][[/noparse]STR RXBUFFER\20\CR]
DEBUG STR RXBUFFER,CR
DEBUG CR
RETURN
Timeout:
DEBUG "No response from XBee", CR
END
Here is the documentation that helped me out:
http://www.selmaware.com/appbee/AppBee_Doc.PDF
It looks as if you've figured out quite a bit of it yourself, but I'll bet there are some things in that document that you can use.
I'm using the API mode as I think in the long run that's the way to go and there are Java libraries that use that mode available. Like one of the earlier posts, I have trouble collecting all the data in the API packet when I send a lot of data. SERIN gives me every other byte. I'm thinking I can solve this by "SKIP"ing the bytes I am not interested in and keeping my packets a fixed length. I'd like to build something that can survive out by it's own on solar power for a while so keeping the power requirements low is important so I think the BS2's are the best bet.
Originally missed the thread (lucky for me).
You must not let your customers know as it distracts them from other projects. I would really love to play with these, but I am far to busy with other things at the moment.
Dr_Acula has other wireless modules running all over the place using props and ZiCog. see the prop DracBlade thread.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Links to other interesting threads:
· Home of the MultiBladeProps: TriBlade,·RamBlade,·SixBlade, website
· Single Board Computer:·3 Propeller ICs·and a·TriBladeProp board (ZiCog Z80 Emulator)
· Prop Tools under Development or Completed (Index)
· Emulators: CPUs Z80 etc; Micros Altair etc;· Terminals·VT100 etc; (Index) ZiCog (Z80) , MoCog (6809)·
· Prop OS: SphinxOS·, PropDos , PropCmd··· Search the Propeller forums·(uses advanced Google search)
My cruising website is: ·www.bluemagic.biz·· MultiBlade Props: www.cluso.bluemagic.biz
http://forums.parallax.com/showthread.php?p=882876
Thank you!
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
images-team.ro