Added XBEE_2_STOP_BITS option to enable the use of 2 stopbits

[Junky2008]

When disabled, 1 stopbit is used.
Added default config for armhf

[attie]

Hi Junky!

Thanks for the pull request... The 2 stop bits are used to slow the communication from a host that is correctly configured for 115,200 baud.... I believe that XBee modules will actually be running on a 111,111 clock, a discrepency of about -3.5% - which is just about on the edge of acceptability.

To improve the reliability of the link we can add a second stop bit to 'stretch' the host's frame slightly. There is a great write up of the problem here:
http://www.digi.com/support/forum/4787/using-the-xbee-at-115-200-baud-updated-16-march-2010

Do you know if the newer modules are actually able to more faithfully produce a 115,200 baud clock? If so, could we have a per-mode setting... e.g: the "xbee1" mode uses two stop bits for 'higher' baud rates, but the "xbeeZB" mode does not.

Either way, I don't think that an additional stop bit should prevent communication. I think it'll just decrease the utilitzation of the link (which isn't likely to be great anyway).

Have you had problems communicating while two stop bits were enabled?

Attie

[Junky2008]

Hey Attie,

Sorry for the late reply, I'm not sure if XBee has improved their clock (I doubt it) but when I was testing at 115200 baud, the messages I got back were just garbage, when I disabled the 2 stop bits, it worked again. I am testing on an embedded Linux platform on ARM, might be related.
Because the issue only appeared in my situation and I didn't check on regular x86 or x64 hardware I proposed an option to enable or disable the stop bits. Making it universal for the application you are using.

I will let you know about the clock when I know more about it, we are in contact with Digi, so I will certainly ask them.

I hope this helps you, at this moment I am using your library with my addition and it works well!

Greetings,

Junky