Closed GoogleCodeExporter closed 8 years ago
Hi Victor
The steps you outline will indeed fill up the computer's memory.
Calling xbee_conTx() will simply queue the packet to be sent and return.
If you want it to wait until confirmation that the packet has been set before
returning, then please enable the 'waitForAck' option for the connection.
Use the code snippet below:
struct xbee_conOptions opts;
/* enable waitForAck... this allows us to see if the packet was sent
successfully! */
xbee_conOptions(xbee, con, &opts, NULL);
opts.waitForAck = 1;
xbee_conOptions(xbee, con, NULL, &opts);
Please implement this and report back.
Original comment by attie@attie.co.uk
on 10 Jan 2012 at 8:25
Ok, now the memory is not affected.
however, i'm receiving data about 800 bytes/seconds. Xbee manual says 240kbps
wifi and 115200 serial maximum.
but, working perfectly!
the checksum are implement?
if there are problems sending, I get the error log automatically?
Thanks!
Original comment by Samuz...@gmail.com
on 10 Jan 2012 at 11:09
Glad to hear that it sorted the memory,
You will see a lower transfer rate. This is because the message is now being
sent, and then libxbee is waiting for a response from the remote node before
continuing. If no response is received then the transmission will timeout, and
xbee_conTx() returns an error (this can take a short while).
The data rates you mention are the raw interface rates.
The ~240kbps refers to kilo-bits per second (30kBps - kilo-BYTES per second).
This is the limiting factor in the communications. It is also worth noting that
it isn't 'WiFi', but another protocol. If you consider the overhead for this
protocol (say the size of the payload) then you can expect a maximum rate of
about 15kBps. In reality this is still a generous estimate - you measured 3kBps.
The checksum is implemented, yes. If there is a problem sending then your call
to xbee_conTx() will return an error (because you enabled waitForAck).
The maximum of 115200 baud, is again kilo-bits per second. This is just the
speed at which you can communicate with the processor on the XBee module.
This is noted in the Series 1 XBee manual to be unstable, and is actually
111,111 baud. This is why I tend to use 57600.
It is also possible that before you were suffering from data loss, which would
have gone un-noticed because you were sending the same single byte payload each
time. Retry your test with a rolling byte, and then ensure that the data at the
other end is correct.
You may have unearthed an issue with my implementation of hardware flow
control, so I will investigate this.
Original comment by attie@attie.co.uk
on 11 Jan 2012 at 8:08
Please retry your original program (without waitForAck enabled) with the latest
commit (f40f89087b4c).
Your program will still over-consume memory and crash, but the 'errors' should
have disappeared.
Original comment by attie@attie.co.uk
on 11 Jan 2012 at 8:16
Yes, errors disappear.
When i said "wifi" was trying to say "over the air", In Brazil it can mean wifi.
I have not forgotten conversion, is what I expected something around 10kBps.
But now, seems working good!
Original comment by Samuz...@gmail.com
on 11 Jan 2012 at 5:15
Great! Thanks for confirming that.
I just wanted to keep things straight :) In the UK WiFi is used all the time
for 802.11 wireless networking.
Original comment by attie@attie.co.uk
on 11 Jan 2012 at 11:21
Original issue reported on code.google.com by
Samuz...@gmail.com
on 10 Jan 2012 at 2:57