I send a byte to the arduino from Flex using its built in socket.writeByte(byte), and have the arduino immediately send it back, reading it again using socket.readUTFBytes(arduinoSocket.bytesAvailable).
But my luck is as it is that I get stuff like this:
The first thing I can see is that you appear to be sending a byte to the arduino, which then echos it back as a decimal (base 10, string) and Flex is supposed to take the string and read it into a UTF character.
i.e. '\x08' 8 (UTF Character 8)
Keep the data the same format - byte, byte, byte and you will get the same back as you sent. (you appear to be sending byte, echoing decimal string, receiving UTF char) and that is why it isn't working for you as you expect.
The way I have it set up is that Listbox in the flex program is bound to an array of objects. When the arduino sends a byte back, it raises a flag, and calls my arduinoReadHandler function.
The function reads the byte in the socket, and then adds it to the array.
Then it does some other asthetic stuff like automatically add 1 to the stepper so I can just click Send to send new bytes, and makes sure the array doesn't get too long.
private function arduinoReadHandler(event:ProgressEvent):void
{
var intensity:int = arduinoSocket.readByte();
transactions.addItem((txtdata.text).toString()+": " +intensity);
}
I see the original arduino code for the project would print back a number, related to the AD value. (Lets say the value is 950...)
The proxy, I assume would send that text to a network port, which Flex can read.
Flex is somehow reading an ASCII string in the ReadUTFBytes - and returning a string ("950"). I guess this would work for numbers the arduino was sending, since UTF can be single-byte too.
However, I don't see how this would always work. :o
For example, if you start a read half-way through the samples (let's say Flex missed the '0' in the first sample because it started late...
The next read may be '0950'. If the network is slow, it may be 09. Nothing appears to be signalling to Flex when the end of transmission is. (or the beginning, for that matter).
If you changed the arduino code to report back only after you received a command to sample, you may have better luck. But - in the Flex code, you are still going to want to wait for a terminating character (like /r/n) to indicate the sample is finished.
Remember that the network or even the serial may wait until a buffer is full, or until a delay to actually pass the data onward - you may receive samples like '95' '0', or '9' '50'. If you put all the data into a buffer and then only reported that buffer when you received a '\r\n' you know you have the full sample.
I didn't realize the arduino was already looking for input before transmitting - I looked over it again this morning and saw I goofed a bit in my last post.
In flex, I would do basically the following: (Forgive me for not posting code... I have no idea about Flex-anything...)
Create a temporary buffer. Initialize it to "".
When data comes in, append the network data to buffer.
find the first occurrance of ] in the static buffer (not the just-received buffer). Walk backwards in the buffer until I find [.
3a) If I can't find [, then I started receiving late. Throw away the ] to the beginning of buffer and goto 3 again.
The characters between [ and ] have my sample number!
Remove the bytes up to ] from buffer and then loop back to 3 until I don't find more samples.
This way, you can make the arduino just spew the samples rather than waiting for byte inputs first.
You will always know that the sample is intact because of the markers [] around it.