963Re: Using IV-17 smartsocket with usb>ttl adapter
- Dec 15, 2012--- In email@example.com, "julietmikebravo" <johanboonstra@...> wrote:
> Unfortunately (for me) , the smartsockets require ASCII, binary and decimal information to work properly.>
> Anyone here know how to send proper commands from a Linux server to the smartsocket?
I think the terms ascii, decimal and binary, in this context might be a source of confusion.
You can send all the values correctly through the use of hex.
As you've found, a simple header can be sent easily in ascii (CDT, etc) using just the keys of the keyboard. That's because the keyboard keys are all assigned a number in the (usually basic) range of 0-255. There are not 255 keys on a keyboard so some values are missing. You probably know this.
So if you want to send the number 17 as an 8-bit value (range = 0 to 255) and you want to send it using only the keys on the keybopard, what do you do ?
You can see from the ascii table of values http://en.wikipedia.org/wiki/Ascii_table
....that 17 is character 'DC1', and you don't have a key on the keyboard to easily represent that value. Unlike '0', ascii character 48, hex value 30 (0x30 or 30h or even #30 sometimes) yoiu can just press the zero key to send hex 30 (decimal 48)
However, 17 is also hex 11, or 11h , or if you like 0x11 and any computer can transmit that value if yoiu direct it to send the value as hex.
I found this snippet of JAVA code by someone who is sending hex values ot a com port http://stackoverflow.com/questions/8777042/java-hexadecimal
If you only have a single 4 tube IV-17 smartsocket, then it is easy to remember that when you want to address a particular tube, using it's decimal position, EG the third tube from the left, number 3 tube, then in your sending string insert 0x03 for the number 3
I hope some of this makes sense. I think through the use of lookup tables, or by storing instructions in various data constructs and arrays you only need to call them up to have the correct order and type of data to send for each instruction.
If you can send data quickly enough then yoiu can probably get away with sending data in chunks. There is a timeout timer in the Smartsocket which detects when the incoming data stream has ended and as long as yoiu send another byte of data before that timer expires you will reset the timer.
So for example, to put a message "HI" on the second and third tubes, you can do the following
(in pseudo code)
CALL 'Send header for static message, MS'
CALL 'Send position of the tube to put the message at' in hex, 0x02
CALL 'Send the message' - "HI" in ascii; 0x48, 0x49 in hex; 72,73 in dec
As long as the delay between each call is smaller than the time it takes to transmit one byte of data by the com port, and you have the next byte in the send buffer ready to go, the Smartsocket will see these three individual sends as one continuous datastream and process it as if you had sent "MS"<2>"HI"
I think C allows yoiu to send mixed radix messages very easily, but I tend to stick with ideas and concepts based on sending a long message as smaller parts, sometimes for no other reason than it makes for shorter code. Instead of using HSEROUT ["MS"] at the start of every message, I place the command 'HSEROUT["MS"]' in a subroutine and use CALL Send_MS to send the start of a direct display message. Then I might send the tube number in decimal, then I send the message body usually in ascii. Sent quickly enough the Smartsocket, which just reads data byte by byte, assumes it was all sent as a continuous message.
Of course, all of this assumes that you have variable data, such as different words which you need to display, perhaps captured from an RSS message reader.
However if you know exactly what the message is going to be and you're going to repeat the display sequence over and over, then you can simply write the complete message into a single data construct. In that case "MS"<2>"HI" could be stored, if you like in hex, as
0x4D, 0x53, 0x02, 0x48, 0x49
If yoiu move those chars to the serial port the smartsocket will see the appropriate message.
- << Previous post in topic Next post in topic >>