[PD] TCP/IP communication from the unix server to the Pure Data
Nicolas Montgermont
nicolas_montgermont at yahoo.fr
Thu Mar 14 19:02:27 CET 2013
I remember having big trouble of communication between gnuradio and pd a
few months ago with udp.
If you can compile here is a (very crappy sorry) external to conversion.
It was done in a hurry but was working well for bytes to float.
I remember float2bytes was not good directly, you have to do:
[f]
|
[* -1]
|
[bytes/float2bytes]
|
[unpack f f f f]
| | | |
| | | [+ 128]
| | | |
| | | [% 256]
[pack f f f f]
before to send over udp.
hope that helps
n
Le 14/03/13 18:41, Petar Jercic a écrit :
> 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
>>>>>>>
>>>>>>
>>>>>
>>>>>
>>>>>
>>>>
>>>
>>
>
>
>
> _______________________________________________
> Pd-list at iem.at mailing list
> UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
--
http://nim.on.free.fr
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.puredata.info/pipermail/pd-list/attachments/20130314/67f6aca4/attachment-0001.htm>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: bytes.zip
Type: application/x-zip-compressed
Size: 78793 bytes
Desc: not available
URL: <http://lists.puredata.info/pipermail/pd-list/attachments/20130314/67f6aca4/attachment-0001.bin>
More information about the Pd-list
mailing list