
JCipriani
Novice
Jul 11, 2007, 8:36 AM
Post #15 of 24
(3953 views)
Shortcut
|
|
Re: [nic] New Serial Input Plugin
[In reply to]
|
Can't Post
|
|
1 header byte 255 followed by information from 8 sensors in the next 8 bytes of values ranging from 0 to 127 data rate 38.4k, no parity, inverted, 1 stop bit (a standard serial configuration) First set up the serial port. Go to "Output -> Serial Port Setup" and set the appropriate port, data rate, parity, etc. Then be sure to enable the serial ports by selecting "Output -> Enable Serial Ports". Now, if the data is always arriving in fixed length 9 byte blocks, you can use the binary serial in watcher. Set the block size ("msg len") to 9 and use a pattern like so:
{{FF}} s0:int=? s1:int=? s2:int=? s3:int=? s4:int=? s5:int=? s6:int=? s7:int=? That matches a single header byte with value FF hex (255 decimal), matches 8 more bytes and outputs the value of each of them to the s0...s7 integer actor output parameters. Please note, though, the header byte is not being used as a sync byte here, per se. You're always receiving data in 9 byte blocks. This may work for you. However... The Serial In Watcher will not currently work with variable length binary data blocks, and does not provide a way to define a certain sync header that begins a block of data. This is because of limitations in Isadora that we haven't addressed yet. The code is all there on the inside but the binary actor itself only works with fixed sized blocks. Something definitely does have to be done about that. One quick fix might be for us to add a "block start" byte or something, similar in spirit to the "eom char" in the text actor. But that only defines one byte, and would only apply in very specific situations, such as yours. As far as the interface goes, one of the major problems keeping it simple is that one of our goals is to keep it as flexible as possible. You want to receive a sync byte of 255 followed by 8 bytes of value. I want to receive 2 sync bytes followed by a byte indicating the length of the data block, followed by that many bytes of data. Some other guy wants to receive data in fixed 4 byte blocks timing out after a certain amount of time. Somebody wants to send a series of 8 different commands to their Lanbox and receive responses with different meanings from each command. Somebody else wants to receive text data with carriage return line endings, but at the same time their buddy in the studio across the street wants to receive text data with linefeed line endings. And there could be 100 other people that might want to use different devices in different ways. One possible solution we've been tossing around is a more script-like language for dealing with this stuff. Unfortunately, this added flexibility comes at the price of making the syntax more complex and harder to learn, which is not good at all -- you are right, one of Isadora's strengths is its ease of use and anything that makes it overly complex is definitely no good. Another alternative, which likely won't happen, but we did talk about it, is a slightly more graphical interface where you don't have to learn and type a complicated pattern syntax. This does limit the flexibility of the actors though. Still other solutions are specific actors for reading from specific devices, leaving the "Serial In Watcher" as sort of a generic way for users to read data from devices that don't have their own serial input actors. Or, similarly, shipping preset patterns for certain devices with Isadora. The serial input stuff is still beta. There are a lot of possibilities for change. We're going to try to improve it, feedback and questions here are greatly appreciated because it helps us identify the biggest trouble spots. Speaking of trouble spots; what did you find bewildering about the documentation? There is a slightly updated version of the documentation that I had written that may not have made it into the latest Isadora release; I'm not sure. But it was only changes related to the fact that we initially didn't have a "binary" version of the Serial In Watcher. The documentation is missing examples, I can add some at the end. It should help. - Jason
(This post was edited by JCipriani on Jul 11, 2007, 9:30 AM)
|