X
PrevPrev Go to previous topic
NextNext Go to next topic
Last Post 18 Dec 2007 02:55 PM by  anon
Getting continus streaming data from a serial port.
 1 Replies
Sort:
You are not authorized to post a reply.
Author Messages

anon



New Member


Posts:
New Member


--
18 Dec 2007 02:55 PM
    Hi, I try to understand how to use the IDL serial interface with an IMU device connected with bluetooth interface. I have 2 questions, one directly related to the serial procedure and the other more about data format. According to the documentation of the device, the data are output as follow: The data stream begins with the 'A' ASCII character followed by up to 13 measurements and ends with the 'Z' ASCII character. Each measurements is two bytes in the data stream. Each two-byte segment utilizes the lowest ten bits for the measurements (the upper six bits will be read as 0). Data are sent MSB first. So my stream would be something like: ...,[65B],[1Byte 26 times],[90B], [65B],[1Byte 26 times],[90B],... First Question: I've read the thread #2500:How to use serial.dlm(dll) for control the device via RS 232? to understand how to read data from the serial port. However, when I use this code to read the stream, each packet of data start randomly somewhere in the data structure... So, simple question, is there a way to make sure to ready the stream at each start (the 'A' code) of the data stream, or did I have to retrieve it manually ? Also, could it be possible to get a timestamp (base on the number on miliseconds since the first January 1970, if I remember correctly the reference) of each byte read using systime() ? Second Question: I did manage to get some data streaming from the device even if it's not synchronized... however I'm a bite perplex on how to convert a two-byte segment in a 10bits measurment ? Any hit would be greatly appreciate. Thank again for you time, all. Best Regards. Antoine C.

    Deleted User



    New Member


    Posts:
    New Member


    --
    18 Dec 2007 02:55 PM
    Let's start with your second question, because I think it is the most straightforward. If you are on a "little endian" processor (Windows, Linux or Mac Intel (but not Mac PPC)), then data streaming in MSB(most-significant-byte)-first needs to be reordered before its data can be extracted. Thus, let's say you find the 26 bytes that provide the "data payload" between an 'A' and a 'Z' marker at some specific subscript location of your read buffer byte array. Code like this might get those bytes into their own variable: newDataPayload = readBuf[aLoc+1:zLoc-1] ; this should be 26 bytes bigEndianShortInts = fix(newDataPayload, 0, 13) ; all we need for Solaris littleEndianShortInts = swap_endian(bigEndianShortInts) ; what we need for Intel PC's On most PC's the 'littleEndianShortInts will immediately provide your data values. Regarding Question 1: It is simply not an uncommon behavior of streaming data to go out in uniform-size packets that are sized according to the needs of the Internet, not of the application, and then to have non-uniform cut-off points for the data they delliver. Thus, it is common to have to "reassemble" the data with sometimes complicated explicit program logic after it arrives in the IDL process. The important thing with 'serial.dlm' is that its COMM_READ procedure be able to capture the streaming data accurately in the byte array assigned to its BUFFER keyword. And I believe that it is doing this fine, as far as you know, no? James Jones ITT Technical Support
    You are not authorized to post a reply.

    Forums Products IDL