[PD] TCP/IP communication from the unix server to the Pure Data
fls at rendera.com.br
fls at rendera.com.br
Tue Mar 19 07:16:59 CET 2013
First at all, you don't need to swap byte endianness just because you are
sending it to the network. You have to put in the network format just the
header data like port and IP. The network devices read the header but
don't use to touch the data section of the packet where your samples will
be.
You have to use it only if server and receiver are in different hardware
architecture.
The ntohl() converts only long integer values what means a 32 bit integer.
there is another function called ntohs() that converts short integer (16
bits). So, you can't pass a float to the function. The float structure has
a mantisse, a biased exponent and a signal. A integer doesn't. One
solution is to convert your float point to long integer, use the byte swap
function and convert back to integer. Other solution is to check if your
machine is little or big endian and create a byte swap to float manually
and do not use htonl().
Cheers
Schiavoni
> Martin , thank you for everything, I got it working now even with
> floating point numbers, here is the rundown of the method
>
> [solved]
> BUT BEFORE FOLLOWING THIS, NOTE THAT FLOATING POINT NUMBER IS SOMETHING
> THAT YOU DON'T WANT TO PARSE, IF YOU LIKE YOUR NERVES.
>
> The first problem is
> 1. Error was in using on the server side an ntohl() on a float number,
> which corrupts it heavily. Mark my words, ntohl() is an enemy of the
> float.
> Just receive it reversed and manually work out the conversion, you HAVE
> to do it manually anyways :P
>
> 2. Float is a complex standard, even more complex when Pure Data
> converts everything to decimal partially per byte. Separate Mantissa,
> Exponent and Sign using bitwise operators [<<][>>], and work out the
> float conversion.
> Follow this thread for Mantissa, that one is the hardest Convert
> floating point number from binary to a decimal number
> <http://stackoverflow.com/questions/15393113/convert-floating-point-number-from-binary-to-a-decimal-number/>
>
> Good luck ^^
>
> //Petar
>
> On 13/3/13 1:51 PM, Martin Peach wrote:
>> I attached a patch that should reconstruct a long if it's bigendian,
>> although it doesn't give 1000000 for the sequence you provided...
>>
>> The floating point numbers are more difficult, you need to separate
>> the sign, exponent and mantissa and then put it all together.
>>
>> Martin
>>
>> On 2013-03-13 06:08, Petar Jercic wrote:
>>> Wow, these methods you proposed made me realize that I was using the
>>> wrong endian method on my UNIX server, it has to be ntohl(). Now I got
>>> it correct, and I am receiving data (bytes) in the correct order.
>>>
>>> *>>>: 0 0 0 2 0 10 114 26 0 0 0 51 0 16 242 78
>>> *
>>> Sample data might be 2 1000000 51 2000.56, which could be read in the
>>> data ... somewhat :)*
>>>
>>> **Now my question is, how do I get four compact numbers to work with?*
>>> Now I have a series of bytes, but at least in the correct order.
>>>
>>> I haven't been able to extract the data using [bytes2any] and [route],
>>> so I prepared a small patch to demonstrate the problem, maybe you can
>>> show me by modifying it?
>>>
>>> //Petar
>>>
>>> On 11/3/13 2:31 PM, Martin Peach wrote:
>>>> On 2013-03-10 17:58, Petar Jercic wrote:
>>>>> Sorry, I can't use ASCII text as communication method, since I plan
>>>>> to
>>>>> send large quantities of data at high speed rates, I need to
>>>>> optimize it
>>>>> as much as possible. Compared to streaming bytes, ASCII is
>>>>> inefficient
>>>>> up to a several orders of magnitude.
>>>>>
>>>>> Is there a method for correct endianness in Pure Data, like these C
>>>>> functions:
>>>>>
>>>>> ntohs()--"Network to Host Short"
>>>>> ntohl()--"Network to Host Long"
>>>>
>>>> You can do that with Pd like this (ntohs):
>>>>
>>>> [unpack 0 0]
>>>> | |
>>>> [* 256] |
>>>> | |
>>>> [+ ]
>>>> |
>>>> [ \
>>>>
>>>> or
>>>>
>>>> [unpack 0 0]
>>>> | |
>>>> | [* 256]
>>>> | |
>>>> [+ ]
>>>> |
>>>> [ \
>>>>
>>>> for littleendian.
>>>>
>>>> Floats are harder but still possible. The main difficulty is in
>>>> splitting the incoming stream in the right places. (I think ASCII is
>>>> not orders of magnitude slower, and it is also less ambiguous).
>>>>
>>>> Martin
>>>>
>>>>
>>>>
>>>>>
>>>>> On 09/3/13 5:15 PM, Martin Peach wrote:
>>>>>> It's probably safer to get the server to send the numbers as ASCII
>>>>>> text, to avoid disagreements about endianness and floating-point
>>>>>> representation.
>>>>>> Then, to extract the numbers, you could use [moocow/bytes2any] or
>>>>>> make
>>>>>> a custom parser using [pdlua].
>>>>>>
>>>>>> Martin
>>>>>>
>>>>>>
>>>>>> On 2013-03-09 10:55, Petar Jercic wrote:
>>>>>>> Apparently [netclient] on the Pure Data side cannot receive nothing
>>>>>>> else
>>>>>>> than ; delimited messages.
>>>>>>> So the solution for the problem:
>>>>>>> *My question is, is there a way to send something other than string
>>>>>>> message to Pure Data, like byte-stream or serialized number stream?
>>>>>>> Can
>>>>>>> Pure Data receive such messages?*
>>>>>>>
>>>>>>> The solution is to use [tcpclient], it can receive byte-stream
>>>>>>> data.
>>>>>>>
>>>>>>> Now I have another problem regarding the data read, on how to
>>>>>>> convert it
>>>>>>> back to usable numbers.
>>>>>>>
>>>>>>> From my UNIX server I am sending a structure
>>>>>>>
>>>>>>> typedef struct {
>>>>>>> int var_code;
>>>>>>> int sample_time;
>>>>>>> int hr;
>>>>>>> float hs;
>>>>>>> } phy_data;
>>>>>>>
>>>>>>> Sample data might be 2 1000000 51 2000.56
>>>>>>>
>>>>>>> When received and printed in Pure Data I get output like this:
>>>>>>>
>>>>>>> >>>: 2 0 0 0 104 34 9 0 51 0 0 0 235 50 48 69
>>>>>>>
>>>>>>> You can notice number 2 and number 51 clearly, I guess the others
>>>>>>> are
>>>>>>> correct as well. Might be some network inversion of LSB/MSB.
>>>>>>>
>>>>>>> *How can I get these numbers back to a usable format and get them
>>>>>>> in
>>>>>>> separate variables?
>>>>>>>
>>>>>>> *//Petar*
>>>>>>> *
>>>>>>>
>>>>>>>
>>>>>>> _______________________________________________
>>>>>>> Pd-list at iem.at mailing list
>>>>>>> UNSUBSCRIBE and account-management ->
>>>>>>> http://lists.puredata.info/listinfo/pd-list
More information about the Pd-list
mailing list