-
Notifications
You must be signed in to change notification settings - Fork 17
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Missing Events? #29
Comments
I'll have to look at it in more detail but I think the issue is you have no guarantee of when the XBee "flushes" your data. There may be settings that relate to that, I can't remember. But certainly it is incorrect to think of a write to the serial line as a "frame" of any sort. Similar to a uart, the XBee does not guarantee it will deliver things in any particular quanta. Is it possible that's basically what you're experiencing?
…________________________________
From: MeijinGandalf <notifications@github.com>
Sent: Wednesday, July 12, 2017 2:07:35 PM
To: jefffhaynes/XBee
Cc: Subscribed
Subject: [jefffhaynes/XBee] Missing Events? (#29)
I'm not sure if this is an issue or not, but I will explain what is going on. Right now I am doing some testing with the XBees to learn how to use your library with them. Each remote XBee(S2B with AT Router Firmware) is paired with either an Arduino or a PIC micro controller. All these do is receive serial data from the host(S2B API Coordinator) and echo it back. My program sends a packet of data to each XBee one at a time. After I send a packet I wait until I receive a response before sending a packet to the next one. I also set a timer to send a packet to the next one if I don't hear back in a certain amount of time. If I receive a packet I compare it to what was sent to make sure that it is correct. I do this in a continuous loop.
Currently I am just sending "Stardust\n". The "\n" is used as a terminator character on the remote devices.(I have those devices send back "Stardust"). Most of time the everything runs great and I get the correct data back before the timer expires. Some times I don't get a response back and the timer expires and I move on to the next one. This is also OK as I expect it to happen sometimes. Then sometimes I go through the loop a few times not getting a response from the same XBee then all of the sudden I get a response that has the word I am expecting only repeated a few times(Something like "StardustStardustStardust"), which I flag as incorrect. I am pretty sure that the remote devices is sending this. The code that I am using is this:
void setup() {
// put your setup code here, to run once:
Serial.begin(115200);
Serial2.begin(115200);
}
const char terminator = '\n';
String data;
void loop() {
// put your main code here, to run repeatedly:
if(Serial2.available() > 0){
data = Serial2.readStringUntil(terminator);
Serial.print(data);
Serial2.print(data);
}
}
So is the DataReceived event just not firing? I will include a couple of files that contain some logging info. The normal file shows a couple of normal loops and the other file shows the issue.
normal.docx<https://github.com/jefffhaynes/XBee/files/1142885/normal.docx>
problem.docx<https://github.com/jefffhaynes/XBee/files/1142886/problem.docx>
—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub<#29>, or mute the thread<https://github.com/notifications/unsubscribe-auth/AJSKR5X339csh4wJWhwEoIl9Kj0YYkqXks5sNQtngaJpZM4OWAAp>.
|
Yeah I think that is a possibility. I see what I can find as well. |
I've never really played with it but maybe try changing the Packetization Timeout (Get/SetPacketizationTimeoutAsync). Although generally the way I would solve something like this is by adding a framing layer to the protocol. For example, it's probably better to send something like ID | Length | Message and not really assume anything about the packetization on the other end, simply use the structure of your data to process frames (ideally handling timeouts if you don't get "length" bytes, etc.). |
I think I will leave Packetization Timeout at its default and do something like you suggested with an ID and Length. Thanks for the help! |
No worries. |
I'm not sure if this is an issue or not, but I will explain what is going on. Right now I am doing some testing with the XBees to learn how to use your library with them. Each remote XBee(S2B with AT Router Firmware) is paired with either an Arduino or a PIC micro controller. All these do is receive serial data from the host(S2B API Coordinator) and echo it back. My program sends a packet of data to each XBee one at a time. After I send a packet I wait until I receive a response before sending a packet to the next one. I also set a timer to send a packet to the next one if I don't hear back in a certain amount of time. If I receive a packet I compare it to what was sent to make sure that it is correct. I do this in a continuous loop.
Currently I am just sending "Stardust\n". The "\n" is used as a terminator character on the remote devices.(I have those devices send back "Stardust"). Most of time the everything runs great and I get the correct data back before the timer expires. Some times I don't get a response back and the timer expires and I move on to the next one. This is also OK as I expect it to happen sometimes. Then sometimes I go through the loop a few times not getting a response from the same XBee then all of the sudden I get a response that has the word I am expecting only repeated a few times(Something like "StardustStardustStardust"), which I flag as incorrect. I am pretty sure that the remote devices is sending this. The code that I am using is this:
void setup() {
// put your setup code here, to run once:
Serial.begin(115200);
Serial2.begin(115200);
}
const char terminator = '\n';
String data;
void loop() {
// put your main code here, to run repeatedly:
if(Serial2.available() > 0){
data = Serial2.readStringUntil(terminator);
Serial.print(data);
Serial2.print(data);
}
}
So is the DataReceived event just not firing? I will include a couple of files that contain some logging info. The normal file shows a couple of normal loops and the other file shows the issue.
normal.docx
problem.docx
The text was updated successfully, but these errors were encountered: