It is not sent in hexa format, it is sent in binary format. You show an hex dump, but the data is still binary. But we don't know how it is encoded. Are there integer? Float? Big endian or little endian? How wide? Etc. Hard to decode without these information.
thanks but I'm a little confused about the type of data (hex String) . I check the data that is sending using wireshark and copied it here . if the data is binary why in wireshark I see hexadecimal format ?
I tried to use Double.longBitsToDouble(long) :
and this is the error :
[javac] C:\DOCUME~1\matdator\LOCALS~1\Temp\android9129833945929245585.pde\src\changethispackage\beforesubmitting\tothemarket\udp1\udp1.java:45: doubleToLongBits(double) in java.lang.Double cannot be applied to (double)
I noticed that this hypermedia library receive data in byte format and this is my main problem. A byte represents a number and a number does not have an associated base . If I give you a byte containing the number 1, can you tell me which base I gave that byte in?) it means that I want convert a number into a certain base, but actually the number doesn't have a base to start with, so what's there to convert ?
is there any other library for receiving udp packets ? or can I receive in String not byte?
which data? why are there 5 values there? which bytes are they?
if you're giving it ALL your data then there's no guarantee that you're starting at the correct 8 byte boundaries. you say yourself that there's a header to the data, you need to skip over that header...
Matlab/simulink pack the data with UDP Send binary block and I receive it in my device . it should start with 44.8500 , 0.4000 even if you look at 40 46 6c cc c0 00 00 00 it's equal to 44.8500 and 3f e6 66 66 60 00 00 00 is equal to 0.4000 .
I think the problem is saving the data as byte . the data change there and that's the problem
i think wireshark might be a red herring. it doesn't matter how the data looks on the wire - it can do anything it wants to the data as long as it does the reverse at the other end. how it looks when it gets into the bytes is the important thing. we need to see the input data and a hexdump of the bytes from your receive method.
I find the problem finally ! the problem is in simulink that sends the UDP packets ! it convert the data to double and that's why we saw it like this ! I should solve this problem there and maybe send the data as integer !
Leave a comment on kooogy's reply
Change topic type
Link this topic
Provide the permalink of a topic that is related to this topic