Looking into networking some XBee Pro 900 Zigbee modules into a mesh network on 902-928 MHz. I have the Digi development package and it looks like I will need to either invent a TCP/IP stack for PC thru USB to the Digi XBIB or else host the S3B radio on Raspberry Pi or Beagleboards.
What are the groups thoughts on pros/cons on each?
Hi, I had an Xbee in a RaspberryPi talking to another one in a linux laptop, using SLIP on the USBserial/Xbee converters. Trying to ping through I found that a ping every 5seconds worked fine, but more frequently than that and the reply time just kept climbing until the connection errored out. Haven't yet dug in to figure out what was going on. Bill
What speed were you running across the Xbee? I've found with AX25/JNOS that at 1200bd it takes about 3 seconds to do a ping across the bench. If you have to add an ARP to that then things go south real fast.
Mark
On Fri, Oct 25, 2013 at 12:03 PM, Bill Hill rtufty@gmail.com wrote:
(Please trim inclusions from previous messages) _______________________________________________ Hi, I had an Xbee in a RaspberryPi talking to another one in a linux laptop, using SLIP on the USBserial/Xbee converters. Trying to ping through I found that a ping every 5seconds worked fine, but more frequently than that and the reply time just kept climbing until the connection errored out. Haven't yet dug in to figure out what was going on. Bill _________________________________________ 44Net mailing list 44Net@hamradio.ucsd.edu http://hamradio.ucsd.edu/mailman/listinfo/44net http://www.ampr.org/donate.html
That may well be it. The ATBD command reads "7" which is 115200: is that just the Xbee-to-USB communication, though, rather than the actual radio pathway baud rate?
A ping -i5 gives an average og 63mS and no packets lost, but ping -i1
root@raspberry:~# ping -i1 192.168.24.16 PING 192.168.24.16 (192.168.24.16) 56(84) bytes of data. 64 bytes from 192.168.24.16: icmp_req=1 ttl=64 time=65.9 ms 64 bytes from 192.168.24.16: icmp_req=2 ttl=64 time=4038 ms 64 bytes from 192.168.24.16: icmp_req=10 ttl=64 time=21170 ms 64 bytes from 192.168.24.16: icmp_req=16 ttl=64 time=28444 ms 64 bytes from 192.168.24.16: icmp_req=17 ttl=64 time=30579 ms ^C --- 192.168.24.16 ping statistics --- 35 packets transmitted, 5 received, 85% packet loss, time 72092ms rtt min/avg/max/mdev = 65.951/16859.755/30579.670/12549.475 ms, pipe 13
On Fri, 25 Oct 2013 21:40:13 +0100, Bill Hill rtufty@gmail.com wrote:
That may well be it. The ATBD command reads "7" which is 115200: is that just the Xbee-to-USB communication, though, rather than the actual radio pathway baud rate?
Yes, the ATBD is the interface baud rate, the radios will have their own rate depending on the model. The S3B is a 200kbps radio.
A ping -i5 gives an average og 63mS and no packets lost, but ping -i1
root@raspberry:~# ping -i1 192.168.24.16 PING 192.168.24.16 (192.168.24.16) 56(84) bytes of data. 64 bytes from 192.168.24.16: icmp_req=1 ttl=64 time=65.9 ms 64 bytes from 192.168.24.16: icmp_req=2 ttl=64 time=4038 ms 64 bytes from 192.168.24.16: icmp_req=10 ttl=64 time=21170 ms 64 bytes from 192.168.24.16: icmp_req=16 ttl=64 time=28444 ms 64 bytes from 192.168.24.16: icmp_req=17 ttl=64 time=30579 ms ^C --- 192.168.24.16 ping statistics --- 35 packets transmitted, 5 received, 85% packet loss, time 72092ms rtt min/avg/max/mdev = 65.951/16859.755/30579.670/12549.475 ms, pipe 13
That's definitely a problem. This would appear to be either a weak radio path or interference if not for the fact the longer interval yields no loss. A bad RTT estimate in the stack for that interface might be a factor. I suspect the higher ping rate is just forcing the radio to transmit sooner and it never sees the reply because you've forced collisions between the radios. IOW, you're creating your own interference.
No CSMA? No duplex? Which model XBees are you using?
I'm still learning my way around CodeWarrior and the XBIB so I don't know how much code I can stuff into the kit.
I've got two units sending text to each other in bypass mode in their out-of-the-box configuration via RealTerm. Initial baud to the XBIB is 115200 but I have to switch the terminal applications to 9600 baud to get valid data across the link. The radios go to sleep when not transmitting data and the signal strength indicators on the XBIB's light up when the link is active. I'm using the third as my hack-toy on the debugger.
I'm more interested in thoughts about using the Raspberry Pi versus the Beagleboards as a platform. I might just buy both and run a comparison but I won't have much time to toy around until November.
Hi, the Xbees are XB24-BCIT-004, which are Series 2, chip antenna, radio data rate 250Kbps. The path length is about 2'6" I'd suspected that it was something with packet collision/overlap - I'll have a poke and see if there's anything to change with RTT. It's not critical, I got the Xbees for a greenhouse temperature sensor and just "repurposed" them to remind myself how to do serial comms. I haven't used the XBIB; just cheapie USB boards.
I've got both the RasPi and a BeagleBone Black, though I've used the Pi more. (I've got 2 of model a sitting waiting for me to solder up the TNCpi kits, which is what prompted me to join this group.) The RasPi is (slightly) cheaper and a lot better at multimedia - XBMC and the like. The BBblack seems to have more resilient, and just more, GPIO. The BBblack has a much nicer hard real time system, the Programmable Reatime Units (PRU). The LinuxCNC guys love it. The RasPi seems to have a much larger user base, and lots more accessories. For example, the Cooking Hacks "Raspberry Pi to Arduino shields connection bridge" which has Xbee socket connecting straight to the RasPi; or the TNCpi. (I'd love a TNCbeagle!) The BBblack has support for "USB gadget" api, so you can program it to act as, for example, a USB keyboard, mouse or network dongle. For talking to an Xbee I'd go for a RasPi, but pretty much for the feeling that the BBblack was too good, and the RasPi, model b, has 2 USB sockets. Bill (M1BKF)
Bill,
There may well be a TNC-Beagle before too long. I was going to hack a TNC-PI to see what changes would be needed, but then I killed the USB port on my BBBlack, and haven't got round to replacing it yet. But I will get back to it.
73, John G8BPQ (designer of TNC-PI)
-----Original Message----- From: 44net-bounces+john.wiseman=cantab.net@hamradio.ucsd.edu [mailto:44net-bounces+john.wiseman=cantab.net@hamradio.ucsd.edu] On Behalf Of Bill Hill Sent: 26 October 2013 13:54 To: AMPRNet working group Subject: Re: [44net] Raspberry Pi vs. Beagleboard
(Please trim inclusions from previous messages) _______________________________________________ Hi, the Xbees are XB24-BCIT-004, which are Series 2, chip antenna, radio data rate 250Kbps. The path length is about 2'6" I'd suspected that it was something with packet collision/overlap - I'll have a poke and see if there's anything to change with RTT. It's not critical, I got the Xbees for a greenhouse temperature sensor and just "repurposed" them to remind myself how to do serial comms. I haven't used the XBIB; just cheapie USB boards.
I've got both the RasPi and a BeagleBone Black, though I've used the Pi more. (I've got 2 of model a sitting waiting for me to solder up the TNCpi kits, which is what prompted me to join this group.) The RasPi is (slightly) cheaper and a lot better at multimedia - XBMC and the like. The BBblack seems to have more resilient, and just more, GPIO. The BBblack has a much nicer hard real time system, the Programmable Reatime Units (PRU). The LinuxCNC guys love it. The RasPi seems to have a much larger user base, and lots more accessories. For example, the Cooking Hacks "Raspberry Pi to Arduino shields connection bridge" which has Xbee socket connecting straight to the RasPi; or the TNCpi. (I'd love a TNCbeagle!) The BBblack has support for "USB gadget" api, so you can program it to act as, for example, a USB keyboard, mouse or network dongle. For talking to an Xbee I'd go for a RasPi, but pretty much for the feeling that the BBblack was too good, and the RasPi, model b, has 2 USB sockets. Bill (M1BKF) _________________________________________ 44Net mailing list 44Net@hamradio.ucsd.edu http://hamradio.ucsd.edu/mailman/listinfo/44net http://www.ampr.org/donate.html
On Sat, 26 Oct 2013 13:53:51 +0100, Bill Hill rtufty@gmail.com wrote:
Hi, the Xbees are XB24-BCIT-004, which are Series 2, chip antenna, radio data rate 250Kbps. The path length is about 2'6" I'd suspected that it was something with packet collision/overlap - I'll have a poke and see if there's anything to change with RTT. It's not critical, I got the Xbees for a greenhouse temperature sensor and just "repurposed" them to remind myself how to do serial comms. I haven't used the XBIB; just cheapie USB boards.
The platform is interesting and the development environment is a bit of a challenge and messes me up a bit since I am used to Visual Studio and CodeWarrior's IDE is close enough to it to make you comfortable but far enough from it to make it difficult. Needs more coffee. :)
I'm still learning my way around and it took me a while to learn to use X-CTU to configure the modems. I'm playing around with their AT command set too.
Something to be aware of: they don't set any flow control by default and I've been experimenting with them with a terminal application and Digi's X-CTU app. The buffering seems to be unreliable and just streaming chars to the modem, they will fail to transmit a char or two, just from the keyboard at high repetition rates.
Copy-paste loses hundreds of chars. The XBP9B's I am using have 256 byte frame sizes and you can reliably send up to about 1024 bytes in a single frame... once. After that it only forwards 256 bytes per transmission and the only way they will recover is if you send a smaller frame of less than 256 bytes. I can get them to send 260 byte frames at just about any repetition rate at 115200kbps and they don't fail to transport them but there seems to be something near 512 to 1000 bytes where they start to lose it. Make sure your SLIP driver can't blow past the modem's buffers on a single frame and has initialized proper flow control.
I've got both the RasPi and a BeagleBone Black, though I've used the Pi more. (I've got 2 of model a sitting waiting for me to solder up the TNCpi kits, which is what prompted me to join this group.) The RasPi is (slightly) cheaper and a lot better at multimedia - XBMC and the like. The BBblack seems to have more resilient, and just more, GPIO. The BBblack has a much nicer hard real time system, the Programmable Reatime Units (PRU). The LinuxCNC guys love it. The RasPi seems to have a much larger user base, and lots more accessories. For example, the Cooking Hacks "Raspberry Pi to Arduino shields connection bridge" which has Xbee socket connecting straight to the RasPi; or the TNCpi. (I'd love a TNCbeagle!) The BBblack has support for "USB gadget" api, so you can program it to act as, for example, a USB keyboard, mouse or network dongle. For talking to an Xbee I'd go for a RasPi, but pretty much for the feeling that the BBblack was too good, and the RasPi, model b, has 2 USB sockets.
The LinuxCNC reference has me intrigued also. I come from a CNC background and have dealt with RTOS all my career. I think I will probably end up buying two of each. :)
I have specific requirement to fulfill that's not Ham related where I'd like to be able to plug Ethernet into the devices and transport CNC part programs from a host to a machine wirelessly without having to deal with driver installations on the CNC. An XBee on a BBblack might be what I am looking for.
On Fri, 25 Oct 2013 13:28:09 -0400, Mark Phillips g7ltt@g7ltt.com wrote:
(Please trim inclusions from previous messages) _______________________________________________ What speed were you running across the Xbee? I've found with AX25/JNOS that at 1200bd it takes about 3 seconds to do a ping across the bench. If you have to add an ARP to that then things go south real fast.
I'm not sure what adding ARP to that means. No ping should be emitted until the ARP is satisfied, and ARP would only be involved in the local wire. Why would SLIP care about Ethernet address on a ping?
Looking into networking some XBee Pro 900 Zigbee modules into a mesh network on 902-928 MHz.
Here's a new (potential) product that's similar to the 900 MHz application but on 430-440 so we should get a bit better range out of it. It has the potential of being both 9k6 standard and may mucho faster in the near future. Nice form factor too.
I hope to be using at least two of these for Mesh networking (as a NW-MESH extender) probably trying out Babble routing. The price is certainly right.
Bill
----
From: Scott Miller scott@opentrac.org Reply-To: tracker2@yahoogroups.com To: TAPR APRS Mailing List aprssig@tapr.org, tracker2@yahoogroups.com, opentracker@yahoogroups.com Subject: [tracker2] T3-9670 1-watt 70cm 9600 baud data radio - $72 pre-order price
Hi all,
In recent years a ton of low-cost high-speed radio modules have hit the market, but until now there haven't been any that were compatible with existing amateur modulation standards. I recently got my hands on some new modules that I was able to get to work with standard 9600 baud G3RUH gear. It took a bit of hacking, but the trickery is handled by a modified Tracker3 processor that hides the details from the host and works as a standard USB KISS TNC.
Right now we're at the prototype stage and there's still tuning and polishing to be done, but everything's looking very good. My bench test unit is happily talking to a TH-D7A at 9600 baud and if parts arrive in time I'm hoping to fly a 9600 baud balloon payload by the end of the week.
It's a very small and simple device - just a USB connection, SMA jack for an antenna, and a DC jack for optional external power if you want to run it as a standalone digipeater. The prototype pictured looks a little rough because the end panels are 3D printed. The final product should have machined or stamped end panels.
I'm not sure how much interest there is in such a device, so I'm putting it out there as a pre-order item so we can gauge how many we need to produce in the first batch, whether it'll be worth stamping the parts, and so on. Final price is likely to be a bit higher than the pre-order price of $72. We should be shipping by the end of November, and maybe even a bit sooner than that.
I'm planning to make this the first in a series of products that I'm hoping will kick-start some higher speed, more advanced APRS networks.
You can place your pre-order here:
https://www.argentdata.com/catalog/product_info.php?products_id=171
And if anyone has any ham gear that does higher than 9600 baud that they'd like to lend me for compatibility testing, I'd be happy to try it out. The modules will do at least 128 kbps talking to each other in their native format, but G3RUH compatibility imposes some restrictions and I'm not sure yet exactly how fast I'll be able to crank them up and still stay compatible.
Thanks and 73,
Scott, N1VG Argent Data Systems
-
Bill Hill -
Bill Vodall -
Geoff Joy -
John Wiseman -
Mark Phillips