TCP Data stream

[lepina]

I cant find the protocol.. not even in the users manual

[Bob_Schor]

Lepina --

• Regarding Errors, most functions (and any VI that you write) has Error In and Error Out terminals on the lower corners.  Wire the Error line through these, so if one or more functions (such as TCP Read) throws an Error, you know precisely which one and why (assuming the Error Code is meaningful).
• Their T-Server SDK should describe how the data is being sent and "packaged".  I assume you are using their T-Receiver, which plugs into USB.  Note that they show T-Server communicating with "Third-Party Applications" (such as LabVIEW?) via TCP, so we have to ask -- do you have T-Server running?  Do it have a manual that discusses how it works, and how it communicates with Third-Party Applications using TCP/IP?
• My worry would be that the various pieces that make up the T-System you are using not hooked up properly to communicate with a Control Program written in LabVIEW.  You need to understand what they mean when they say that the T-Server SDK allows "simple integration for developers on other platforms".  How, precisely?

Do you have their manual in PDF form?  Do you have colleagues who have experience using this system, particularly with other software?  Ask questions!

Bob Schor

[lepina]

Hello everyone,since last time I posted here I was trying to get the information about the TCP etc from the manufacturer.

I got this answer from them.

1.       Open a TCP IP socket and connect to the server (note the T-Server client is created only when checking the case in the T-Server interface. Do not try to connect before it is created)

2.       Make a loop reading the data as soon as you receive a packet (T-server start streaming the data only when a record is start)

3.       For every received packet, extract the EMG data

If you are using binary format  every data is a double format (8 bytes) as describes below. Note that an EMG sensor has only one channel.

If you are using text format, the format is describe below:

So do you have any idea how I should proceed now, to get the real time EMG Signal Data displayed on a graph, and how to get that same data for a classification it in real time ?

[crossrulz]

Personally, I would use the ASCII format since that is easier to determine your packet.  If using VISA, just set the termination character to be a Line Feed (0x0A) and tell VISA Read to read more characters than you ever expect.  Then just use Spreadsheet String To Array with a space as the delimiter to make an array of your values.

If using the TCP/IP API, then use the CR/LF mode on the TCP/IP Read.  Like the VISA, set the number of bytes to read to be more than you ever expect.  The read will stop when it finds that CRLF combo at the end of the data packet.

[Mark_Yedinak · Accepted solution]

---

@crossrulz wrote:

Personally, I would use the ASCII format since that is easier to determine your packet.  If using VISA, just set the termination character to be a Line Feed (0x0A) and tell VISA Read to read more characters than you ever expect.  Then just use Spreadsheet String To Array with a space as the delimiter to make an array of your values.

If using the TCP/IP API, then use the CR/LF mode on the TCP/IP Read.  Like the VISA, set the number of bytes to read to be more than you ever expect.  The read will stop when it finds that CRLF combo at the end of the data packet.

---

I would use the binary format since it will be much more efficient When using the binary format each data element will consist of two double values and be 8 bytes of data. The first four bytes will be a timestamp and the send 4 bytes will be th the EMG value. You can simply read 8 bytes at a time and convert the two values to 2 doubles and graph the resulting values. This is an extremely basic data protocol. 

[Bob_Schor]

There is an Example called TCP Named Service that demonstrates sending a String (which is the only thing, basically, you can send with TCP/IP) from Client to Server.  Both Client and Server run on your machine, so you can "play" with them and see how they work.

Given that the LabVIEW TCP/IP Read/Write functions accept only String data, you can either use something like Flatten/Unflatten String or Format Into String/Scan From String to convert your data from "native" form (Time and EMG Data) to String and back.

If I were you, I'd write a pair of VIs, one to simulate the (I've forgotten what the gadget is that sends you EMG data) EMG-generator, which I presume will include the TCP Server (and you'll base this on the TCP Named Service - Server example code) and the other that simulates your "recording" LabVIEW Program.  Does your gadget have a Control protocol?  That is, are there instructions to "Send it the Go command and it will start sending EMG data back to you", or "Send it Speed = NNN to set the sampling speed to NNN Hz", or "Send it Chan = XX" to send data over XX channels"?  If so, then once you get the "streaming of simulated data" part working, you can think about "handle control/commands" part.

I hope you aren't working alone on this Project -- if you've never designed this sort of system whereby you send commands and receive data, you run the risk of getting lost very quickly (even if you are a fairly experienced LabVIEW or other software Developer).  You need someone with whom to discuss ideas.  If you are working alone, try writing (in what ever language you are most fluent) documentation about what you know about the Instrument (including its command structure, if any) and what you want to do with it.  Don't worry (yet) about how you are going to do it.  For example, you might say "The Gadget requires we send it Sampling Frequency and Number of data points.  Then every time we send it "Go", it sends back that much data.  We need to ask for data faster than it generates it, otherwise we might miss points."  [I made that up, as I have no idea how the Gadget works ...].

Once you have a good idea of What you want to do, you can start worrying about How you can do it.  Here is where the practice you've had with your two little simulation VIs that send simple data from "Server" to "Client" when the Client makes a connection will come in handy.  You can also make the "Server" send not just one point, but a TimeStamp and an Array of 1000 points.  If you do something like that, try to generate the array at, say, 1KHz to simulate actually generating "real" data, and see if you can keep up with your Client VI (be sure these VIs run in parallel -- there should be no wires connecting them, as you want the Client to run independently of the Server).

Bob Schor

[lepina]

---

@Mark_Yedinak wrote:

---

@crossrulz wrote:

Personally, I would use the ASCII format since that is easier to determine your packet.  If using VISA, just set the termination character to be a Line Feed (0x0A) and tell VISA Read to read more characters than you ever expect.  Then just use Spreadsheet String To Array with a space as the delimiter to make an array of your values.

If using the TCP/IP API, then use the CR/LF mode on the TCP/IP Read.  Like the VISA, set the number of bytes to read to be more than you ever expect.  The read will stop when it finds that CRLF combo at the end of the data packet.

---

I would use the binary format since it will be much more efficient When using the binary format each data element will consist of two double values and be 8 bytes of data. The first four bytes will be a timestamp and the send 4 bytes will be th the EMG value. You can simply read 8 bytes at a time and convert the two values to 2 doubles and graph the resulting values. This is an extremely basic data protocol. 

---

so it should work if I just copy this block diagram or I need to add something more to the diagram ?

I will try it all out, and of course I will post an update if it worked. I was busy with the Myo Armband lately, so I didnt really have time to work with the CAPTIV hardware

[lepina]

so the answer from Mark Yedinak worked actually, thanks a lot. I made the data stream visible in labview.

However the graph is not looking how it is supposed to be (probably needs some editing/processing on the signal), but Im happy that the hardware sends data in some way. I will keep you updated about the project.

If you have any ideas what I could do, to make the signal look better, it would help me a lot.

Here a screenshot of how it is looking at the moment

[GerdW]

Hi lepina,

have you been told that screenshots are hard to debug?

Please provide:

- what is the real data received by COM port? (Create a string constant containing a typical received string!)

- what is the expected value?

- what is the typecasted value?

[lepina]

---

@GerdW wrote:

Hi lepina,

have you been told that screenshots are hard to debug?

Please provide:

- what is the real data received by COM port? (Create a string constant containing a typical received string!)

- what is the expected value?

- what is the typecasted value?

---

Hey GerdW, im sending you the VI file so you can take a look if you have the time.

The data received by the tcp looks like this according to the manual

when I choose to send the data as binary

or it can look like this if I choose in the options to send the data as text

I want to get the data as a double, and the graph to display the EMG signals (channel 1 value) on the Y axis and X axis to be the time in ms. Im not sure if this is the best solution, any suggestions would be good.