Typos in Series 1 IoSample code?

[GoogleCodeExporter]

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 mbshah48...@gmail.com on 7 Mar 2010 at 9:32

[GoogleCodeExporter]

Original comment by andrew.rapp@gmail.com on 2 Feb 2014 at 6:33

• Changed state: Accepted

[GoogleCodeExporter]

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 comment by jmounte...@gmail.com on 22 Sep 2014 at 12:39