25 Oct
2013
25 Oct
'13
4:34 a.m.
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?
25 Oct
25 Oct
5:03 p.m.
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
6:28 p.m.
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(a)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(a)hamradio.ucsd.edu
http://hamradio.ucsd.edu/mailman/listinfo/44net
http://www.ampr.org/donate.html
9:40 p.m.
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
26 Oct
26 Oct
8:05 a.m.
On Fri, 25 Oct 2013 21:40:13 +0100, Bill Hill <rtufty(a)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.
--
Geoff Joy - ke6qh -
AmprNet IP Address Coordinator for San Bernardino & Riverside Counties.
geoff(a)windomeister.com
1:53 p.m.
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)
2:09 p.m.
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(a)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(a)hamradio.ucsd.edu
http://hamradio.ucsd.edu/mailman/listinfo/44net
http://www.ampr.org/donate.html
27 Oct
27 Oct
4:53 a.m.
On Sat, 26 Oct 2013 13:53:51 +0100, Bill Hill <rtufty(a)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.
26 Oct
26 Oct
5:40 a.m.
On Fri, 25 Oct 2013 13:28:09 -0400, Mark Phillips <g7ltt(a)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?
28 Oct
28 Oct
5:32 a.m.
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(a)opentrac.org>
Reply-To: tracker2(a)yahoogroups.com
To: TAPR APRS Mailing List <aprssig(a)tapr.org>rg>, tracker2(a)yahoogroups.com,
opentracker(a)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
3839
days inactive
3842
days old
9 comments
5 participants
participants (5)
-
Bill Hill -
Bill Vodall -
Geoff Joy -
John Wiseman -
Mark Phillips