Arduino - DAT Serial In

Download Arduino 0018 and also the ftid driver for the COM Port:
(if you buy a new Arduino from June2010 you don’t need the driver annymore)

Downaload and Install FIRMATA from this link:

  • open from the Examples of Arduino the AnolgInSerial example

this is the script:

void setup() {

void loop() {
// read the analog input into a variable:
int analogValue = analogRead(0)/4;
// print the result:
Serial.println(cancel ln)(analogValue,BYTE);
// wait 10 milliseconds for the analog-to-digital converter
// to settle after the last reading:

I wrote in RED what you have to change before uploading


Now open Touch077 and place a DAT Serial In

In this jpeg you can see what you have to change in the Parameter of the Serial DAT


IT WORKS REALLY GOOD!! :slight_smile: This is the value from an anaolg in attached to a light sensor…

Try it and make your own controller!

ciaaooooo! :smiley:


i’m new to arduino and i’m a bit confused.

why use FIRMATA? Where are you using it?

in your sketch the line:
Serial.println(cancel ln)(analogValue,BYTE);

what is (cancel ln)? it keeps coming up as an error for me.

Like i said i’m new to arduino and i’ve been trying to get it to talk to touch. I’ve got it working using a straight Serial.print command but my sensor reading comes out as a message and not a value. It seems i’m off in the wrong direction.



What do you mean comes out as a ‘message’ and not ‘value’ ?
Can you try changing the Format in the Serial In DAT to ‘per line’ ?
The trick is to match the Arduino output format with the Touch Serial In DAT.

If you println(value, DEC) for example, it will output ascii bytes followed by an end of line,
as so you should set the SerialIn DAT format to ‘One Row Per Line’.
You should be able to catch any values that fit in a 4-byte integer.
You could also print them as floats too for example.

If you print(value, BYTE) (print, not println) it will output individual binary 8-bit bytes,
so Touch should be set to ‘One Row Per Byte’

(Using the latest experimental Touch)

Hope that helps



Seems like i was using the regular build and not the experimental build of touch. The serial DAT on the experimental build is a bit more comprehensive and i got it to work great!

Although I could only get multiple serial messages properly using BYTES. When using ASCII i get a blank line after each value. So to receive all my messages i need to have the double number of lines.

for examples if i do:

value = 2

Serial.println(value, DEC)
Serial.println(value2, DEC)
4, DEC)
Serial.println(value/2, DEC)

the serial DAT reads:

blank line
blank line
blank line
blank line

Well Bytes work great for now. But it would be great to nail this thing.

thanks for the help!


Found the problem.

When you ‘println’ in Arduino, it actually outputs both the carriage return (13) and the line feed (10) characters.

Touch uses either one to delimit end of line, so unfortunately it sees the line feed as an empty line.

(You can always see what bytes are actually received in the DAT by turning on the ‘Value Column’ parameter in the last tab of parameters)

Now the most reliable way of sending numeric values to the DAT would be to leave its Table Format to ‘One Row Per Line’ but change the Arduino script to only output a carriage return.

Heres a brief example.
Note you’re free to use values greater than 1 byte, including floating points:

Hope that helps,

[code]void setup()
// start serial port at 9600 bps:

void loop()

int i = 1234;
Serial.print(i, DEC);

float f = 321.7;

Ive encapsulated the above in a new wiki page:


Hey Rob!

Is it possible to have the toe file from your video?


As I’m reading those examples, and the one on the wiki, it seems to me that the sender and receiver can fall out of sync. Unlike TCP/IP packet based protocols, there’s no clear ‘start’ and ‘end’, so any byte or part of a byte could be construed as any part of the package. One missed piece of data (pretty certain to happen) would flip the order of what is coming in.

The example should probably have, at least, different delimiters between data chunks and the end of the whole data. It would probably better to wrap the whole data into some sort of delimiter, such as putting a ‘[’ at the start, and a ‘]’ at the end. That helps make sure you only update if all the data is received (i.e. not updating b unless the corresponding r and g were also correctly received.

Historically, the STX and ETX characters should be used, since they can’t accidentally arise in a readable or typed piece of data. Easy enough to send in the Arduino side, maybe the wiki could cover how to split based on them? That would make the wiki entry more useful for learning to parse other serial protocols.


Sorry, I somehow missed this direct question last year :frowning:
Is this the component you’re referring to? … sample.tox

Hi Bruce.
Those are good suggestions.
Ive never heard of STX and ETX to be honest (ascii characters 2 and 3?)
We’ve found in our Arduino dealings, that the serial communication is reliable enough for most peoples usage, but we’ll add your RFE to the list for parsing between known characters.
I like your suggestion of ‘[’ and ‘]’ better as those are easier for Arduino coders to include.

Serial.print (02, HEX);
// Other data
Serial.print (03, HEX);

Hi Bruce.
Wouldn’t it be just as simple to keep it delimited per line (newline or carriage return),
and wrap the contents of each message in say, square brackets.
Then the receiving end, on receiving each line could make sure the message began with [ and ended with ] ?
No special byte-by-byte parsing required.

Yes, but then you would be vulnerable to those characters appearing in normal text. The same could apply with a carriage return - what if you want to send a two line block of text?

Either way is better than hoping TD and the sender just happen to stay in sync.


Edit - I should point out, I’m not making this up. This is what the STX and ETX characters are for, and using them was common when serial was the only game in town.

The other option (to do it for production quality) would be to escape certain characters, in your example, to use [, ] or return they would have to be escaped. That could be as simple as /[, /], /CR (plus you then need //).

Sure I realize the issue is that it requires reserving delimiting characters, but the vast bulk of Arduino->TD communication will be human readable ascii with a known format. (ie, labelled numeric values).
Even sending 0x2, 0x3 would make sending binary data problematic.
Most general solution would be escaping characters as you mention, or including simple checksums or other redundancies.

Well, putting aside your proposing human readable and binary formats in the same sentence… :wink: you are correct that there’s no perfect solution. In old serial systems, the protocol was always ascii - so STX and ETX were free, or binary, and other mechanisms are used (start headers, checksums etc.).

As discussed, formats like XML and JSON use escape sequences. But that does make binary data a rigamarole, and parsing too (more of a problem in the Arduino than in TD). Are there standard ‘escape characters’ and ‘unescape’ functions in python or an OP?

Anyway, I know you’ve understood my point. I’m sure what you put in the docs will be safe without being confusing. Thanks for paying attention, and Merry Christmas!



I am using an Arduino with 20 or so different potentiometer, button and toggle inputs that I am controlling a visual and sound with. Most of the time the readings are stable and accurate, however occasionally it seems the SerialDAT misses a character or two, throwing the whole thing off momentarily, glitching the visual and soundtrack.

I have been reading for days trying to send the data in different ways, but it seems that this is the way to do it. My problem is I can’t figure out how to set up a CallResponse/handshake type setup between Arduino and Touchdesigner. Could you point me in the right direction or explain how to code this type of communication. Thanks in advance,


It sounds like you’re a good candidate for checksums of some kind.

But first - do you have any debug (print statements, screenshots) of when the problem happens?

It’s possible that the serial message/s are just being split between callbacks and you need a different approach.

PM me a touch file if you want. Don’t have time to spin up an Arduino and electronics :wink: but I can have a quick look.


Hi Bruce,

Ahh interesting, checksums aren’t something I had heard of! Will see if I can wrap my head around them and implement.

I have put a couple of images, the Arduino and touch files into the .zip, you might not need it but it may be handy to see them. The SerialDAT is set to receive 31 lines purely to show the error more clearly.

Ideally the process would be as speedy as possible to reduce lag from a controller being used to drive visuals etc.

Debugging (962 KB)