You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
What steps will reproduce the problem?
1. Receiving a 64-bit addressed I/O sample from a Series 1 XBee,
configured with digital channels 0-2 set to digital in, channel 2 set to
analog in, and channel 3 set to digital out.
2. One sample per transmission, transmissions every 10 seconds.
3. The raw hex returned in the X-CTU terminal is as expected: 7E 00 12 82
(8 address bytes) 42 00 01 10 17 00 07 03 FF (checksum byte)
What is the expected output? What do you see instead?
The isDigitalEnabled() function should return all of the enabled channels,
but it just returns those that are 'on'. Also, the analog reading which
should return a 10-bit value always returns 0.
What version of the product are you using? On what operating system?
1. Boarduino (328) and Series 1 XBee on hardware serial port
2. Arduino 17 IDE on WinXP
Please provide any additional information below.
If I change the code in XBee.cpp to make the function return frame data
from getSampleOffset() + 2 instead of 4 and getSampleOffset() + 1 instead
of 3, the digital channels enabled are returned as expected:
bool RxIoSampleBaseResponse::isDigitalEnabled(uint8_t pin) {
if (pin < 8) {
return ((getFrameData()[getSampleOffset() + 2] >> pin) & 1) == 1;
} else {
return (getFrameData()[getSampleOffset() + 1] & 1) == 1;
}
}
I'm not exactly sure where the analog sampling issue is, but my quick and
dirty solution was to comment out the following code, which returns the
correct values:
for (int i = 0; i < pin; i++) {
if (isAnalogEnabled(pin)) {
start+=2;
}
}
PS - Thanks so much for an outstanding piece of work and for sharing it
with everyone!
Original issue reported on code.google.com by [email protected] on 7 Mar 2010 at 9:32
The text was updated successfully, but these errors were encountered:
I've recently been using this library and had very similar issues with this
part of the code. I believe I've pinpointed the cause of this, which is not
very well documented in the manual.
If you check page 50: MM (MAC Mode) Command
"By default (MM = 0), Digi Mode is enabled and the module adds an extra header
to the data portion of the 802.15.4 packet."
During testing I noticed that when disabling AES encryption this header would
no longer appear within the packet and the method
"RxIOSampleBaseResponse::getAnalog" functions as intended. Obviously the
inclusion of this header will throw off any access to the data portion of the
frame.
I was unable to find any further information about this header, as to whether
it's size can vary based on configuration I'm unsure, but for my purposes it
seemed to consist of four bytes in the position stated. I no longer have access
to an xBee radio to test so it's unlikely I'll be able to contribute further
than this.
Original issue reported on code.google.com by
[email protected]
on 7 Mar 2010 at 9:32The text was updated successfully, but these errors were encountered: