I am trying to aquire a TCP/IP stream from a sensor module using Labview, but my output makes no sence to me. The sensor is supposed to send a synchronizationbyte on the following form: 11XXXXXX 00XXXXXX 00XXXX00 and the data is supposed to follow(Copied from the instruction manual below). However, my .VI's seem to do something wrong when they search for the synchronization byte, or something else is wrong with my code. As I see it, each column in the output array from the MannerGlobal.vi should contain 8 bits, but this is not what happens. The stream comes without any spaces or other interruptions, just a pure, simple, but enourmous amount of 1, 0 digits on the form : 11000101010101... seeming random. When I try the included software it can obtain a sample rate of many thousands of samples/s, so I guess my code with a solution or two every other second cannot be correct.
Any tips, help or clues to how to solve it would be greatly appreciated!
User manual is following:
Start of transmission
Transmission is started immediately after opening of the connection in the mode TCP/IP-Server
In mode udp-server, there has to be sent
after opening the port.
After that, the data will be transmitted continuously. The size of the paket will be adapted dynamical.
It could be up to 1452 bytes.
a random character (for example a blank) from the client to the server
Computation
The computation could be done in this way:
- read of all data from the port and save it to an input-buffer
- check the data for the first occurence of the synchronisation-byte (frame)
- cut out of one complete dataset until the next synchronisation-byte (frame), decode and transfer the data to another process.
- leave all other data, which are not part of a complete frame in the input-buffer and append the new incoming data.
- repeat this steps
On next pages, the definition of the synchronisation bits are described.
MA MANNER SensortelemetrieR
Data format Ethernetinterface V1.0 “simple protocol”
Telemetry
Coding for 16 Bit Transmission
‘16 Bit 11DDDDDD 00DDDDDD 00DDDD00 10DDDDDD 00DDDDDD 00DDDD00 10DDDDDD 00DDDDDD 00DDDD00 ......
Startidentifier new Frame Startidentifier next Values
Each transfered byte is divided into synchronisation-bits and data-bits
(MSB) 7 6 5 4 3 2 1 0 (LSB)
1 1 B15 B14 B13 B12 B11 B10 Byte 0 1. transmitted datavalue
0 0 B09 B08 B07 B06 B05 B04 Byte 1
0 0 B02 B01 B00 0 0 Byte 2
1 0 B15 B14 B13 B12 B11 B10 Byte 3 2. nd transmitted datavalue
0 0 B09 B08 B07 B06 B05 B04 Byte 4
0 0 B03 B02 B01 B00 0 0 Byte 5
..
..
..
1 0 B15 B14 B13 B12 B11 B10 Byte n last transmitted datavalue
0 0 B09 B08 B07 B06 B05 B04 Byte n+1
0 0 B03 B02 B01 B00 0 0 Byte n+2
(MSB) 7 6 5 4 3 2 1 0 (LSB)
1 1 B15 B14 B13 B12 B11 B10 Byte 0 1. transmitted datavalue of the next frame
0 0 B09 B08 B07 B06 B05 B04 Byte 1
0 0 B03 B02 B01 B00 0 0 Byte 2
Synchronisation is done by analysing of Bit 7 und Bit 6 of each transmitted byte.
The sequence “11” means the start of a new frame, the sequence “10” means the start of the next datavalue.
With this coding, it is possible to react on the receiving side to changing channel/datacounts.
The sequence “01” is reserved for special purposes.
