Hi to all, I need to read data from an old sensor which use a serial port to send packets. I think it would be better for me to use C/C++ under Ubuntu. Introduction To Materials Science And Engineering Chung Pdf Converter on this page. In the sensor manual, packet format is explained in this way: Each data packet begins with a header byte (255) and end with a checksum. The checksum is calculated in the following manner: 1.

If you’ve ever seen the serial output of a GPS reader, you’ve seen a mystery string at the end like this: That’s the checksum of the whole string. LabVIEW: how to calculate checksum for serial. Currently I am using the serial port property 'Read Bytes. I wanted to add some kind of error check.

Sum all packet contents except header and checksum. Divide the sum by 256. The remainder should equal the checksum. The header byte 0xFF will likely not be the only 0xFF byte in the data packet.

You must count the bytes received at your serial port and use the checksum to ensure you are in sync with the data sent by the DMU. This is especially critical when using the continuous data packet output mode. I attached to this topic a table with all fields contained in a single packet.

I also have a matlab code which is able to read the packet, but I'm not able to understand what it does. Input='FFFFB30029FF86FF8A0009FFD5FFB22AC20632A48CCB'; if strcmp(input(1:2),'FF') input=input(3:end); s=length(input)-2; n=s/4; for i=1:n a(i,1:4)=input(4*(i-1)+1:4*i); end for i=1:n str=a(i,:);%% Checksum%ch(i,1)=hex2dec(str); if hex2dec(str(1))>=8 o1(i,1)=hex2dec(str)-2^16; else o1(i,1)=hex2dec(str); end end o1 sfr=100*1.5/2^15; sfa=2*1.5/2^15; sfan=180/2^15;; o1sc(1:2,1)=o1(1:2,1)*sfan;% (deg) Roll and Pitch o1sc(3:5,1)=o1(3:5,1)*sfr;%deg/s Tilt rate o1sc(6:8,1)=o1(6:8,1)*sfa;% g accelerations o1sc(9,1)=((o1(9,1) * 5/4096)-1.375)*44.44;% Temperature (8C) x = int16(o1(10,1)); if x. Thank you again, JKR! I tried the code, but now it gives me the header mismatch error.

Buf and &buf have the same address for array variables. (this fact can be used to determine whether variables are pointer variables or array variables). If the short members are network order (big endian), i wonder whether the single bytes for header and checksum may not needed to be switched as well with the corresponding odd or even neighbor byte. This depends on how the send buffer was built. If it was an array of shorts or if it was a packed structure equivalent to that posted in the original post. Only for the latter case the bytes for header and checksum could be taken directly from byte stream.

If not, you first would need to fetch an array of shorts, then do the nhtos byte switch, and finally copy the results to a packed structure (there must not be any filler between the header byte and the first short member) like the one you posted. Are the information which you are talking about in your last post present in the previous attached sensor manual? No, I was talking about the byte stream where the code you got from jkr assumed that it starts with the FF byte and then there are 7 short integers and finally there is a checksum byte.

If the byte stream was created from short array in network order each short integer needs to swap its bytes for a stream that starts with BYTE buf[] = { 0x73, 0x00, 0x5a, 0xff, 0xfc, 0x00, 0x00, 0xec, 0x25, 0xed, 0xba, 0x00,. Select all it would mean that any pair of bytes must be switched after reading the stream: BYTE buf[] = { 0x00, 0x73, 0xff, 0x5a, 0x00, 0xfc, 0xec, 0x00, 0xed, 0x25, 0x00, 0xba,. Select all if that is correct it would have a crucial importance for detecting the header byte, for the bytes that would be used for calculating the checksum and for the checksum byte.

To test if that could be the issue you could make the swap on the buf elements before passing them to process_packet function. However, that might create some further issues which also must be considered. For example, if the byte stream you posted is real, the first packet would not start with FF but with 00. This is either an error or the packet starts with an offset of 2.

I would assume it is the latter. Then, the end of a packet is either determined by the fixed length of 16 bytes (as assumed by the current code) or it is determined by (any of the) next FF where a new packet starts. For the stream you posted the 0x73 proceeding the 1st FF could be a code to identify the packet structure (it also could be a length or size or the count of packages available). Anyway, if we assume that we have packets of different lengths perhaps prefixed by some type information, it is a new game. Input='FFFFB30029FF86FF8A0 009FFD5FFB 22AC20632A 48CCB'; when I use the matlab sample data for verifying the checksum it is ok. But the sequence has a length of 22 bytes while the length of the packet structure is 18 bytes.

Obviously only one of both could be describe a correct sequence. The matlab calculation is somewhat strange what perhaps is due to it cannot extract bytes or short integers but uses strings and numbers instead. Input=input(3:end); s=length(input)-2; n=s/4; for i=1:n a(i,1:4)=input(4*(i-1)+1:4*i); end for i=1:n str=a(i,:); if hex2dec(str(1))>=8 o1(i,1)=hex2dec(str)-2^16; else o1(i,1)=hex2dec(str); end Select all the code extracts the header FF from input string, and calculates the number of 4-byte elements (what is 5 for our case). It stores the 4-byte strings in array a. After that it does a loop on array a and converts each 4-byte string with hex2dec function.

Despite of the name 'dec' i think it converts to integer (binary) such that the 20 bytes were reduced to 10 bytes or 5 short integers. Note, because a string number has the most significant digit at the left side - same as for big-endian or network order - matlab implicitly makes a nthos swap of the bytes. Note a further detail: if the short number has the sign-bit set (high-byte >= '8') the number was made negative by substracting 2^16 from it. These numbers were stored in the o1 array (also 5 elements). O1sc(1:2,1)=o1(1:2,1)*sfan;% (deg) Roll and Pitch o1sc(3:5,1)=o1(3:5,1)*sfr;%deg/s Tilt rate o1sc(6:8,1)=o1(6:8,1)*sfa;% g accelerations o1sc(9,1)=((o1(9,1) * 5/4096)-1.375)*44.44;% Temperature (8C) x = int16(o1(10,1)); if x. The Matlab code was made by my friend who tried to make the sensor work with Windows and Matlab and so it might be not correct even if the output is surely correct because we did a compare between matlab output and the output of thw Windows sensor software and they are the same. For this reason, I was thinking to translate the matlab code in C code with the same algorithm even if in Matlab each received packet is 22 bytes even if in the manual there is specified that each packet should be 18 byte lenght.

The hex2dec function is described as. If using the algorithm of your friend you would need the 20 half-bytes which represent 5 short numbers. The packet structure holds 8 short integers, so actually it is more than used by matlab. Nevertheless there is a mismatch between the stream you read from the device and the one used in the matlab. Also from your description it seems to be that each read would return a full packet starting with a FF and a checksum byte at end. That also doesn't fit to the data you got. If you would post all bytes of the stream in hex (without other messages) we could try to find out whether there are some systematics.

At least we should be able to find the begin and end of sequences where the described checksum algorithm would apply to. Yes, I suppose to read floating point values. Yes, the manual describes the output format in this way: The IMU300CC, IMU400CC and IMU400CD are designed to operate as six-axis systems and can be set to operate in one of two modes: voltage mode, or scaled sensor mode.

The IMU Series of products do not support angle mode. The measurement mode selects the information that is sent in the data packet over the RS-232 interface. See “Data Packet Format” for the actual structure of the data packet in each mode. On page 9 and page 10 (and 16,17) there are some specifications about voltage mode and scaled mode. The main problem is that to set the sensor in each mode you have to send a command before.

For example, you have to send 'c' for scaled mode and 'r' for voltage mode. Then the sensor will reply with a 'C' or 'R' if everything was OK. I'm not able to get the correct reply from the sensor and so may be I'm not able to establish if the sensor is in voltage or scaled mode.

In any case, I think that the current output values are not correct because i do not get any negative value and the values don't change according on how I move it. Yes, manual says this: In general, the digital data representing each measurement is sent as a 16-bit number (two bytes). The data is sent MSB first then LSB. In voltage mode, the data is sent as unsigned integers to represent the range 0 – 5 V. In scaled and angle mode, the data generally represents a quantity that can be positive or negative.

These numbers are sent as a 16-bit signed integer in 2's complement format. The data is sent as two bytes, MSB first then LSB. In scaled and angle mode, the timer information and temperature sensor voltage are sent as unsigned integers. What's the best solution to print also negative values?

For example 07F9 in the 3rd row is 0xF907 when converted to little-endian what is -1785 when converted to decimal. Do I have to verify if values begins with '8'?

Use a union structure that maps the 10 short members to an array of short. Extract each short member from buffer in a loop and assign it after byte-swap to the appropriate short element. None of these alternatives actually does 'parsing'. The second method where you do a conversion to hex string is a 'detour' as told by jkr. The conversions to string and from string are unnecessary. Moreover it requires an additional conversion from string to (short) integer which you would need to add for each variable.

The method matlab used was similar to that but matlab can implicitly convert strings to numbers and can calculate with string numbers. In c and c++ you should not try to do it that way. Torrent Wii Iso Ita. The last choice uses a loop to fill a structure and convert the short integers. It avoids some pitfalls of the other solutions. Nevertheless, all ways would have the same results and you should choose the one which you best understand.

You also need to add calculation for floating-point results.

.and now for something completely off-topic. I realize this may not be the best place to ask for help regarding an actual MT-32, given that this forum is about Munt/MT-32 emulation, but on the other hand it seems likely that a greater number of people here will own actual MT-32s or similar modules than elsewhere. I own three sound modules - an MT-32, an SC-88, and an SC-88ST Pro. My laptop has no MIDI port [obviously], so I've had to connect the SC-88 to my laptop via a USB-to-Serial Port converter and the SC-88's 'Computer'/serial port.

I then chained the MT-32 to the SC-88's MIDI Out/Thru in Out mode [according to all of the SC manuals I've read, they don't pass on 'Computer port' MIDI data unless in Out mode -- Thru mode only passes data from MIDI In A], and chained the SC-88ST Pro to the MT-32's MIDI Thru. My problem is this: although I've set up the serial port to work at 9600 baud without flow control [slow enough not to cause buffer overflows when SysEx data is sent to the MT-32], and I've set up the SC-88 Serial Port drivers to use RTS/CTS Flow Control, I still receive errors when using the MT-32 under DOSBox or VDMSound [or in Winamp playing an MT-32 MIDI file, etc.]. Strangely enough, I get no errors when using it under ScummVM in Native MT-32 mode. The error I receive is 'Exc. Checksum error'. This happens whenever SysEx data is sent to the MT-32 -- especially when games first initialize. In LucasArts games that utilize SysEx instruments like Monkey Island 2, it doesn't seem to be a problem.

The MT-32 outputs the error but then all the instruments load properly and I notice no errors. In games like Silpheed or other Sierra games, however, only a number of SysEx instruments load properly and the rest remain the defaults, which is a problem. As I said before, the error never occurs under ScummVM and all instruments load properly. I don't know if this is because ScummVM sends data at a much slower rate than the other programs, or what. At any rate, does anyone know what's causing this? Is it because I'm passing data to the MT-32 via the SC-88 which is using the 'Computer port'?

Is there any way around this that anyone knows of? Will I have to buy a USB-to-MIDI adapter instead and chain everything else through the MT-32 like I did on my desktop?

Any help would be greatly appreciated! Newbie Posts: 25 Joined: 2004-7-11 @ 23:14. Kaminari wrote:The SysEx is being transmitted too fast. Just to let you know, this isn't the case. I've set the baud rate incredibly low as I mentioned before, and I've tried using MoSlo now to decrease the speed to almost unplayable levels, and I still receive the error. When it's too fast, I generally get 'Exc. Buffer Overflow' errors, so the two aren't related in this case.

I'm assuming the SC-88 MIDI Out must just be improperly passing on the data it receives from the COM port. Oh well, off to buy a USB-to-MIDI cable then, I suppose! Newbie Posts: 25 Joined: 2004-7-11 @ 23:14.