<html>
<head>
<meta content="text/html; charset=ISO-8859-1"
http-equiv="Content-Type">
</head>
<body text="#000000" bgcolor="#FFFFFF">
Martin , thank you for everything, I got it working now even with
floating point numbers, here is the rundown of the method<br>
<br>
[solved]<br>
BUT BEFORE FOLLOWING THIS, NOTE THAT FLOATING POINT NUMBER IS
SOMETHING THAT YOU DON'T WANT TO PARSE, IF YOU LIKE YOUR NERVES.<br>
<br>
The first problem is<br>
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. <br>
Just receive it reversed and manually work out the conversion, you
HAVE to do it manually anyways :P<br>
<br>
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.<br>
Follow this thread for Mantissa, that one is the hardest <a
href="http://stackoverflow.com/questions/15393113/convert-floating-point-number-from-binary-to-a-decimal-number/">Convert
floating point number from binary to a decimal number</a><br>
<br>
Good luck ^^<br>
<br>
//Petar<br>
<br>
<div class="moz-cite-prefix">On 13/3/13 1:51 PM, Martin Peach wrote:<br>
</div>
<blockquote cite="mid:BLU0-SMTP70321F57244A3F1D63ED24EDE30@phx.gbl"
type="cite">I attached a patch that should reconstruct a long if
it's bigendian, although it doesn't give 1000000 for the sequence
you provided...
<br>
<br>
The floating point numbers are more difficult, you need to
separate the sign, exponent and mantissa and then put it all
together.
<br>
<br>
Martin
<br>
<br>
On 2013-03-13 06:08, Petar Jercic wrote:
<br>
<blockquote type="cite">Wow, these methods you proposed made me
realize that I was using the
<br>
wrong endian method on my UNIX server, it has to be ntohl(). Now
I got
<br>
it correct, and I am receiving data (bytes) in the correct
order.
<br>
<br>
*>>>: 0 0 0 2 0 10 114 26 0 0 0 51 0 16 242 78
<br>
*
<br>
Sample data might be 2 1000000 51 2000.56, which could be read
in the
<br>
data ... somewhat :)*
<br>
<br>
**Now my question is, how do I get four compact numbers to work
with?*
<br>
Now I have a series of bytes, but at least in the correct order.
<br>
<br>
I haven't been able to extract the data using [bytes2any] and
[route],
<br>
so I prepared a small patch to demonstrate the problem, maybe
you can
<br>
show me by modifying it?
<br>
<br>
//Petar
<br>
<br>
On 11/3/13 2:31 PM, Martin Peach wrote:
<br>
<blockquote type="cite">On 2013-03-10 17:58, Petar Jercic wrote:
<br>
<blockquote type="cite">Sorry, I can't use ASCII text as
communication method, since I plan to
<br>
send large quantities of data at high speed rates, I need to
optimize it
<br>
as much as possible. Compared to streaming bytes, ASCII is
inefficient
<br>
up to a several orders of magnitude.
<br>
<br>
Is there a method for correct endianness in Pure Data, like
these C
<br>
functions:
<br>
<br>
ntohs()--"Network to Host Short"
<br>
ntohl()--"Network to Host Long"
<br>
</blockquote>
<br>
You can do that with Pd like this (ntohs):
<br>
<br>
[unpack 0 0]
<br>
| |
<br>
[* 256] |
<br>
| |
<br>
[+ ]
<br>
|
<br>
[ \
<br>
<br>
or
<br>
<br>
[unpack 0 0]
<br>
| |
<br>
| [* 256]
<br>
| |
<br>
[+ ]
<br>
|
<br>
[ \
<br>
<br>
for littleendian.
<br>
<br>
Floats are harder but still possible. The main difficulty is
in
<br>
splitting the incoming stream in the right places. (I think
ASCII is
<br>
not orders of magnitude slower, and it is also less
ambiguous).
<br>
<br>
Martin
<br>
<br>
<br>
<br>
<blockquote type="cite">
<br>
On 09/3/13 5:15 PM, Martin Peach wrote:
<br>
<blockquote type="cite">It's probably safer to get the
server to send the numbers as ASCII
<br>
text, to avoid disagreements about endianness and
floating-point
<br>
representation.
<br>
Then, to extract the numbers, you could use
[moocow/bytes2any] or make
<br>
a custom parser using [pdlua].
<br>
<br>
Martin
<br>
<br>
<br>
On 2013-03-09 10:55, Petar Jercic wrote:
<br>
<blockquote type="cite">Apparently [netclient] on the Pure
Data side cannot receive nothing
<br>
else
<br>
than ; delimited messages.
<br>
So the solution for the problem:
<br>
*My question is, is there a way to send something other
than string
<br>
message to Pure Data, like byte-stream or serialized
number stream?
<br>
Can
<br>
Pure Data receive such messages?*
<br>
<br>
The solution is to use [tcpclient], it can receive
byte-stream data.
<br>
<br>
Now I have another problem regarding the data read, on
how to
<br>
convert it
<br>
back to usable numbers.
<br>
<br>
From my UNIX server I am sending a structure
<br>
<br>
typedef struct {
<br>
int var_code;
<br>
int sample_time;
<br>
int hr;
<br>
float hs;
<br>
} phy_data;
<br>
<br>
Sample data might be 2 1000000 51 2000.56
<br>
<br>
When received and printed in Pure Data I get output
like this:
<br>
<br>
>>>: 2 0 0 0 104 34 9 0 51 0 0 0 235 50 48 69
<br>
<br>
You can notice number 2 and number 51 clearly, I guess
the others are
<br>
correct as well. Might be some network inversion of
LSB/MSB.
<br>
<br>
*How can I get these numbers back to a usable format and
get them in
<br>
separate variables?
<br>
<br>
*//Petar*
<br>
*
<br>
<br>
<br>
_______________________________________________
<br>
<a class="moz-txt-link-abbreviated" href="mailto:Pd-list@iem.at">Pd-list@iem.at</a> mailing list
<br>
UNSUBSCRIBE and account-management ->
<br>
<a class="moz-txt-link-freetext" href="http://lists.puredata.info/listinfo/pd-list">http://lists.puredata.info/listinfo/pd-list</a>
<br>
<br>
</blockquote>
<br>
</blockquote>
<br>
<br>
<br>
</blockquote>
<br>
</blockquote>
<br>
</blockquote>
<br>
</blockquote>
<br>
</body>
</html>