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
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@iem.at
mailing list
UNSUBSCRIBE and account-management ->
http://lists.puredata.info/listinfo/pd-list
_______________________________________________
Pd-list@iem.at mailing list
UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list