0

I'm receiving data from my sensor via TCP and the output looks like this: <-0.040000 , -0.005000 , 0,025000 , 0,990000 , -0,000500 , 0.033000 >

It's a 6 times double value. I need only first three. Forces in X,Y and Z direction to get their resultant force. I was told I'm reciving 'sensor streams string representation of double' and that I should use atof function which takes a string representing of a floating point number and returns a double.

So, the problem is. I'm using following code to receive data from sensor

char recvbuf[DEFAULT_BUFFER_LENGTH];
int iResult = recv(ConnectSocket, recvbuf, DEFAULT_BUFFER_LENGTH, 0);

double n;
n = atof (recvbuf);

Output is always wrong, either I get wrong data, 30000 instead of 0.1414, or I read 0.15 as 0. Any tips on how should I get all 3 data? I use BUFFER=50, cuz I don't need to read more and I don't even know how long in total, string from sensor is.

AShelly
  • 34,686
  • 15
  • 91
  • 152
Smoky
  • 13
  • 3
  • 1
    I know it is scary but you are going to have to paste some of your code here or we won't be able to help you. – Hogan Nov 09 '15 at 21:50
  • You need to build the input string a piece at a a time as all chars in a message might not be ready to be read in one `recv` call. – 001 Nov 09 '15 at 21:51
  • 4
    1. Please copy and paste text into your question. The images are not helpful and the accompanying ads are annoying. 2. Please provide some code to explain your output. 3. In C, you always need to make sure strings are null-terminated. – rici Nov 09 '15 at 21:52
  • `recvbuf` is a sequence of bytes. They need to be collected and parsed. `n = atof (recvbuf);` treats the whole buffer as a single number. – ramana_k Nov 09 '15 at 21:56
  • Not into pictures of half naked girls that come along with those screen shots – Ed Heal Nov 09 '15 at 21:56
  • whatever you can only read a single value with a single `atof`… And your output seems to contain "<" and ">" that may be present in your recvbuf. So we need real input data to undestand what happens. – hexasoft Nov 09 '15 at 21:57
  • I would like to apologize because i wasn't aware that any adds were active because I use ad block. I see only clear picture. – Smoky Nov 10 '15 at 10:34

2 Answers2

2

You need to break this down into smaller steps. For example:

  1. Receive an arbitrary sized packet from socket.
  2. Search in the packet buffer (recvbuf) for a start-of-data marker '<'.
  3. Copy all the following characters from the packet buffer to a parse buffer (which you need to create. Make it big enough to hold the longest possible data representation of the 6 data points).
    • 3A. If you find an end-of-data marker '>', go to step 4.
    • 3B. If you run out of data, receive the next packet and repeat step 3.
  4. Break parse buffer at commas into N value strings.
  5. Convert each value string into a number with atof or fscanf.
  6. Go to Step2, starting from the character after the last end-of-data.
AShelly
  • 34,686
  • 15
  • 91
  • 152
2

You are calling atof at arbitrary points in the data stream. That will not work.

There are several steps needed to do this reliably.

  1. The data you get from recv can a partial data set that needs to be appended to the preceding and by the following recv calls's data. This is sometimes done in a pipeline fashion that reads characters from the recvbuf into a parsebuf.

  2. Your data looks to be framed with ( and ) so your copy routine can skip to the first ( and then copy data up to the following )

  3. When the copy routine hits the end of the recvbuf it should call recv again to fill the recvbuf and continue framing the data from the start of recvbuf where it left off in parsebuf

  4. At each ) the data in the parsebuf will always be <x> , <y> , <z> , ... so your atof call has something reasonable to deal with. Consider using fscanf

  5. Reset the pointer to the parsebuf after each conversion.

Doug Currie
  • 40,708
  • 1
  • 95
  • 119