ActiView TCP Packet Fromat
ActiView TCP Packet Fromat
Hi,
I am writing a post-processing program which receives data from ActiView through TCP/IP communication.
Do you know the packet format of ActiView TCP?
With thanks and regards
Ting
I am writing a post-processing program which receives data from ActiView through TCP/IP communication.
Do you know the packet format of ActiView TCP?
With thanks and regards
Ting
-
- Site Admin
- Posts: 1148
- Joined: Fri Mar 26, 2004 7:00 pm
- Location: Amsterdam, Netherlands
- Contact:
Using the LabVIEW client as example and basis for further development is the best route. Several customers have successfully copied the client in another programming language, using the LabVIEW code as an example.
Basically, the client receives data in packages with a size displayed in ActiView. For example, ActiView shows:
Bytes in TCP array: 984
Channels in TCP array: 41 (32+8+status)
TCP samples/channel 8
The client receives packages of 984 bytes. Every group of 3 bytes is a sample (little endian). There are 42 channels, and 8 samples per channel. The data comes in like:
S1C1, S1C2,......S1C41, S2C1............S7C41,S8C1.........S8C41
(S = sample, C = channel)
So, it is basically a matter of rearranging bytes in in order to retrieve the 41*8 array (41 channels * 8 samples).
Best regards, Coen (BioSemi)
Basically, the client receives data in packages with a size displayed in ActiView. For example, ActiView shows:
Bytes in TCP array: 984
Channels in TCP array: 41 (32+8+status)
TCP samples/channel 8
The client receives packages of 984 bytes. Every group of 3 bytes is a sample (little endian). There are 42 channels, and 8 samples per channel. The data comes in like:
S1C1, S1C2,......S1C41, S2C1............S7C41,S8C1.........S8C41
(S = sample, C = channel)
So, it is basically a matter of rearranging bytes in in order to retrieve the 41*8 array (41 channels * 8 samples).
Best regards, Coen (BioSemi)
-
- Site Admin
- Posts: 1148
- Joined: Fri Mar 26, 2004 7:00 pm
- Location: Amsterdam, Netherlands
- Contact:
The client code is available from http://www.biosemi.com/download/ActiveTwoClient_4.zip
(32+8+status) means: 32 headcap channels plus 8 EX (flat electrode) channels, plus the extra channel for trigger and system status bits. So, a total of 41 channels.
Best regards, Coen (BioSemi)
(32+8+status) means: 32 headcap channels plus 8 EX (flat electrode) channels, plus the extra channel for trigger and system status bits. So, a total of 41 channels.
Best regards, Coen (BioSemi)
Client code for receiving Biosemi data via TCP/IP
Hello,
This link is no longer active ("404 Not Found"):
Can you please point us to the correct location for downloading the client code?
Thank you.
This link is no longer active ("404 Not Found"):
Can you please point us to the correct location for downloading the client code?
Thank you.
Matlab code for receiving Biosemi data via TCP/IP?
Thank you.
Do you know of any Matlab freeware for reading in the TCP/IP stream from Biosemi?
Do you know of any Matlab freeware for reading in the TCP/IP stream from Biosemi?
Meaning/ use of packages?
Above you describe the following example:
Bytes in TCP array: 984
Channels in TCP array: 41 (32+8+status)
TCP samples/channel 8
The client receives packages of 984 bytes. Every group of 3 bytes is a sample (little endian). There are 42 channels, and 8 samples per channel. The data comes in like:
S1C1, S1C2,......S1C41, S2C1............S7C41,S8C1.........S8C41
(S = sample, C = channel)
So, it is basically a matter of rearranging bytes in in order to retrieve the 41*8 array (41 channels * 8 samples).
My question:
How are packages used, and what is the significance of the TCP samples per channel?
Irrespective of the number of samples per channel, it seems that the data is going to stream in as follows
S1C1, S1C2,...S1C41,...S8C41, S9C1,...S9C41,...S99C1,...S99C41, etc.
In other words, it loops through each channel on a per sample basis.
So, I must be missing something about how "packages" are sent or arranged....?
This is further suggested by the fact that my fairly straightforward Matlab code of rearranging the samples only successfully reads in the first channel of data, but not subsequent channels (they are clearly not EEG)....
Thanks,
dw
Bytes in TCP array: 984
Channels in TCP array: 41 (32+8+status)
TCP samples/channel 8
The client receives packages of 984 bytes. Every group of 3 bytes is a sample (little endian). There are 42 channels, and 8 samples per channel. The data comes in like:
S1C1, S1C2,......S1C41, S2C1............S7C41,S8C1.........S8C41
(S = sample, C = channel)
So, it is basically a matter of rearranging bytes in in order to retrieve the 41*8 array (41 channels * 8 samples).
My question:
How are packages used, and what is the significance of the TCP samples per channel?
Irrespective of the number of samples per channel, it seems that the data is going to stream in as follows
S1C1, S1C2,...S1C41,...S8C41, S9C1,...S9C41,...S99C1,...S99C41, etc.
In other words, it loops through each channel on a per sample basis.
So, I must be missing something about how "packages" are sent or arranged....?
This is further suggested by the fact that my fairly straightforward Matlab code of rearranging the samples only successfully reads in the first channel of data, but not subsequent channels (they are clearly not EEG)....
Thanks,
dw
-
- Site Admin
- Posts: 1148
- Joined: Fri Mar 26, 2004 7:00 pm
- Location: Amsterdam, Netherlands
- Contact:
ActiView sent the data over TCP/IP in bursts (packages). Each package size is determined by the minimal display scroll step used in ActiView.
Your description of the total data stream (sum of packages) is correct, so it seems that there is still an error in your code. Please refer to the LabVIEW code of the client as an example.
Best regards, Coen (BioSemi)
Your description of the total data stream (sum of packages) is correct, so it seems that there is still an error in your code. Please refer to the LabVIEW code of the client as an example.
Best regards, Coen (BioSemi)
little Endian
Dear Coen,
Just to confirm, little Endian here is referring to *byte order*, not bit order, correct?
Thank you,
Diane
Just to confirm, little Endian here is referring to *byte order*, not bit order, correct?
Thank you,
Diane
Just a very short example in C++ so that people not understanding Labview or not willing to can get started more quickly.
[code]
recv(soc, buffer, numBytes, 0);
for(int j=0;j<numBytes/3;j++){
std::bitset<8> firstByte(buffer[3*j]);
std::bitset<8> secondByte(buffer[3*j+1]);
std::bitset<8> thirdByte(buffer[3*j+2]);
std::bitset<32> total;
total.reset(); //make sure the ending bits are 0
for (int k = 0; k<8; k++)
total[k+8]=firstByte[k],total[k+16]=secondByte[k],total[k+24]=thirdByte[k];
double data = (int32_t)total.to_ulong();
[/code]
Sorry for indentation, [code] tags are not enabled
[code]
recv(soc, buffer, numBytes, 0);
for(int j=0;j<numBytes/3;j++){
std::bitset<8> firstByte(buffer[3*j]);
std::bitset<8> secondByte(buffer[3*j+1]);
std::bitset<8> thirdByte(buffer[3*j+2]);
std::bitset<32> total;
total.reset(); //make sure the ending bits are 0
for (int k = 0; k<8; k++)
total[k+8]=firstByte[k],total[k+16]=secondByte[k],total[k+24]=thirdByte[k];
double data = (int32_t)total.to_ulong();
[/code]
Sorry for indentation, [code] tags are not enabled
Hi,
I think I read all the messages from the forum concerning the TCP packet format but I am still not able to make my own client (needed to create an one line application).
So if I understood correctly the data sent over TCP is in the same format as the BDF files. I can see from the BDF format (http://www.biosemi.com/faq/file_format.htm) that not only the bytes are in a "reversed" order but also the bits. Is it the case for the TCP packets (do not seem so if I check narsil's code)?
Are the numbers coded in C2 as for the BDF ? Or are they coded as unsigned integers that I can then map to the associated BDF interval [-8388608 8388607] by division and subtraction? I can see from the proposed C code (narsil) that the number is considered as an unsigned long (with the HSB set to 0) then if I want negative values I should use the mapping solution right ?
Thanks in advance for you answer,
Guillaume Chanel
I think I read all the messages from the forum concerning the TCP packet format but I am still not able to make my own client (needed to create an one line application).
So if I understood correctly the data sent over TCP is in the same format as the BDF files. I can see from the BDF format (http://www.biosemi.com/faq/file_format.htm) that not only the bytes are in a "reversed" order but also the bits. Is it the case for the TCP packets (do not seem so if I check narsil's code)?
Are the numbers coded in C2 as for the BDF ? Or are they coded as unsigned integers that I can then map to the associated BDF interval [-8388608 8388607] by division and subtraction? I can see from the proposed C code (narsil) that the number is considered as an unsigned long (with the HSB set to 0) then if I want negative values I should use the mapping solution right ?
Thanks in advance for you answer,
Guillaume Chanel
-
- Site Admin
- Posts: 1148
- Joined: Fri Mar 26, 2004 7:00 pm
- Location: Amsterdam, Netherlands
- Contact:
In the TCP/IP stream, the bytes themselves and the sequence of the 3 bytes are the same as in the BDF file. However, the sequence of the data words (a word of 3 bytes, original 24-bit output words of the ADC) is different, see above.
The 3 bytes are converted to a 32-bit integer by adding a zero least significant byte. The MSB of the resulting 32-bit integer is the sign bit (two's-complement notation).
Best regards, Coen (BioSemi)
The 3 bytes are converted to a 32-bit integer by adding a zero least significant byte. The MSB of the resulting 32-bit integer is the sign bit (two's-complement notation).
Best regards, Coen (BioSemi)
Thanks Coen,
here is a small pseudo code for the packet processing, please confirm that this is correct and hopefully you will avoid anymore question on the topic
packets = read packet from socket
for all packet of 3 bytes p in packets
-- strValue = p // this string code for a sample of a channel and has 3 bytes
-- strValue = strValue [2] + strValue [1] + strValue [0] //reorder the string bytes, + means concatenate
-- strValue = strValue + 0x00 // add a LSB of 0
-- signedIntValue = C2toInt(strValue) //perform the 2's complement operation
-- signedIntValue = signedIntValue / 256 //to remove the 0x00 LSB addition
-- signedIntValue = signedIntValue / 32 // to get the ranged data
-- strore the signedIntValue in a table data
endfor
rearrange data order to fit the number of channels and samples
I this correct ?
Guillaume
here is a small pseudo code for the packet processing, please confirm that this is correct and hopefully you will avoid anymore question on the topic
packets = read packet from socket
for all packet of 3 bytes p in packets
-- strValue = p // this string code for a sample of a channel and has 3 bytes
-- strValue = strValue [2] + strValue [1] + strValue [0] //reorder the string bytes, + means concatenate
-- strValue = strValue + 0x00 // add a LSB of 0
-- signedIntValue = C2toInt(strValue) //perform the 2's complement operation
-- signedIntValue = signedIntValue / 256 //to remove the 0x00 LSB addition
-- signedIntValue = signedIntValue / 32 // to get the ranged data
-- strore the signedIntValue in a table data
endfor
rearrange data order to fit the number of channels and samples
I this correct ?
Guillaume
Several TCP clients
Hello,
I would like to know if it is possible to connect to the actiview TCP server with several clients.
The idea is to have one client taking care of the EEG signals another of the GSR etc...
If not do you have any cues about possible actiview modifications to handle that ?
Guillaume
I would like to know if it is possible to connect to the actiview TCP server with several clients.
The idea is to have one client taking care of the EEG signals another of the GSR etc...
If not do you have any cues about possible actiview modifications to handle that ?
Guillaume
-
- Site Admin
- Posts: 1148
- Joined: Fri Mar 26, 2004 7:00 pm
- Location: Amsterdam, Netherlands
- Contact:
Current ActiView only support a single client. However, it is certainly possible to expand the ActiView code to support multiple clients, see:
http://zone.ni.com/devzone/cda/tut/p/id/3982
Best regards, Coen (BioSemi)
http://zone.ni.com/devzone/cda/tut/p/id/3982
Best regards, Coen (BioSemi)