Sorry about the ambiguity - I have either a server processor or a communications processor connected to an Arduino, but in both cases there is a control server either directly, or indirectly talking to the Arduino and expecting responses. The problem is that because one processor doesn't know what the other is doing things are asynchronous.
Eventually this will become a network with 100's of Arduinos. So the problem is non-trivial.
An Arduino/Arduino combo is not that far-fetched if I run out of other ideas.

I'm a bit stuck in that I have a co-processor arrangement where the machines talk to each other, but I don't always know when they do it; it could happen while one machine is streaming data to the other.
Without separate i/o buffers on the port or equivalently full duplex comms I may have trouble.
Is there any foreseeable possibility of full duplex operation?

You don't mention if you are using Win7 pro in XP mode - I can foresee problems in Win7 native mode myself. About to go there.

I chose the Nano to be embedded in a pcb, but I notice in testing that when the device is powered via Vin (12V), when the usb connector is plugged in, Windows complains that the port does not work. This is annoying as it means an extra jumper in the pcb to disconnect power if the usb connect is ever needed. Anyone else come across this or am I doing something stupid?

Hi Andrew,
I'm using a modified development board that I wire-wrapped; it has 3.3V ttl/RS232 level converter, led's and grounds, etc. Works well. I am keeping the wire-wrap between pins 9 and 10 on the Xbee on that board. I must say X-CTU presents a steep learning curve for a simple program, but...
NOW your libraries seem to work!!!!!!!! Got RemoteAtCommand.pde to work, anyway - proceeding with rest. I'll download your new version first. Thanks for doing that.

Yup, sampling works as well - good stuff!

Hi Andrew,

Looks like my problem is that I'm using an Xbee as a Zigbee when it should be a Znet 2.5 - Digi is driving me nuts. I also didn't pay attention to something you mentioned earlier because I didn't know the difference between Zigbee and Znet. This explains the error return from your calls. I am trying to write this (coordinator) file now:

Code:

XB24-B_ZigBee_1147.mxi
80
0
251
1147
0
[A]ID=234
[A]SC=1FFE
[A]SD=3
[A]NJ=FF
[A]DH=0
[A]DL=FFFF
[A]NI=
[A]BH=0
[A]AR=FF
[A]DD=20000
[A]NT=3C
[A]NO=0
[A]PL=4
[A]PM=1
[A]EE=0
[A]EO=0
[A]BD=3
[A]NB=0
[A]D7=1
[A]D6=0
[A]AP=2
[A]AO=0
[A]SP=20
[A]D0=1
[A]D1=0
[A]D2=0
[A]D3=0
[A]D4=0
[A]D5=1
[A]P0=1
[A]P1=0
[A]P2=0
[A]LT=0
[A]RP=28
[A]PR=1FFF
[A]IR=0
[A]IC=0
[A]V+=0

Note it's called Zigbee, but drop down in X-CTU calls it Znet 2.5. It just will not do the write - keeps coming back with an error for EE. Changing EE and E0 produces an error for BD, etc.
Probably time to talk to the X-CTU boys...

Yes, fantastic - I even solved my x-ctu problems (see under xbee issues thread).
Did you update your library so I can download new version? Then I'll have another go at it.

Forgot to mention - my problems were solved thanks to another posting of yours.

I'm getting a compiler error on Arduino v15 in the second statement:

RemoteAtCommandRequest remoteAtRequest = RemoteAtCommandRequest(remoteAddress, irCmd, irValue, sizeof(irValue));
remoteAtRequest.setApplyChanges(false);
 
error: expected constructor, destructor, or type conversion before '.' token

Tried casting but that didn't work either.

The sensor xbee is connected to only vcc, gnd and d0. There is no serial i/o connection (din/dout.) The d0 input is fed by a voltage divider to bring it down to a max of 1V.

Hi,

Delay - had to deal with government(takes time.)

How did you print those hexes out?
I must have made some kind of error last time. When I display your command using getFrameData() I see FF FE as well, but things are not escaped (yet) - I guess that happens at send() time.

Anyway, I have no working end device - am trying to track down the needed connections for a sensor without serial i/o. Manual is ambiguous.
Might have fried sensor xbee?

Andrew,
It would be nice to have a setFrameData(pos, byte) to parallel the getFrameData(pos) call.
Mike

There is a common ground on both boards. I have a question on the library's string for a RemoteAtCommandRequest; it issues this:

7E 00 7D 31 17 01 00 7D 33 A2 00 40 3C 88 88 20 FE 01 49 52 7D 33 88 72                                                                       (15)

The byte at position 15 is 01, but the manual says it should be 00 or 02.
Also, the two immediately preceding bytes should be FF and FE; they represent the 16-bit address of target which I assume is unknown.

Two things Andrew :
does your Xbee serial port interfere with nss port somehow?
I get this now:

ŠCommand returned error code: 2
Sending command to the \bee
Command [D0] was successful!

and the lines clear up if I remove your xbee comms.

I'm wondering if I get the error code 2 (invalid cmd) because
D0 should be sent prior to IR. I'll check this.

Your help so far has been very valuable. Your last comment was right on and worked for the corrdinator. With the end device I have similar problems but I cannot seem to fix them this time. I hope I'm not imposing too much; here is its .pro file:

Code:

XB24-B_ZigBee_1320.mxi
80
0
251
1320
0
[A]ID=234
[A]SC=1FFE
[A]SD=3
[A]JN=1
[A]NJ=FF
[A]NI=
[A]DD=0
[A]AR=FF
[A]PL=4
[A]PM=1
[A]BD=3
[A]NB=0
[A]D7=1
[A]D6=0
[A]AP=2
[A]AO=0
[A]SM=2
[A]ST=1388
[A]SP=20
[A]SN=1
[A]D0=2
[A]D1=0
[A]D2=0
[A]D3=0
[A]D4=0
[A]D5=1
[A]P0=1
[A]P1=0
[A]P2=0
[A]RP=28
[A]PR=1FFF

Hm, it was failing during NVR write, so I installed a brand new chip and although there were some hiccups it finally did write correctly.
Now to try your very promising library.... and thanks for your help.

Andrew,

I can see one problem - X-CTU did not write AP=2 as I thought it had.
I am having one hell of a time with it. I do a read, then show defaults, then set the value, then on write it fails during setting AT parameters,
then shows all errors. A subsequent restore sends it into a loop that requires it to be killed. I had to turn off the end device because it doesn't match new parameters and I get a complaint about network formation. Need to find a way of managing X-CTU.

Andrew,

I will do that asap. I think I found something of interest in the meantime; these are the strings you send to end device:
for IR command:
7E 7D 31 17 01 7D 33 A2 40 3C 88 88 20 FE 01 49 52 7D 33 88 72
(I changed sampling time to 5 sec.)
for A0 command:
7E 10 17 01 80 7D 33 A2 60 3C 88 88 20 FE 01 44 30 02 32

I think you will notice the byte counts are excessively large.
Also notice the address of the end device are different, they also seem incorrect (should be 0x0013a200, 0x403C8888.)

I'm going to try to verify these strings in case I did something wrong again.