Develop Reference

How to decode and read unity udp packets?

I am capturing the udp traffic of my mobile device to understand how the unity messages are sent, with what format, etc.
Currently I am not being able to even read them, I only see their hexadecimal value and if I want to transform it into ascii it does not make any sense. Only sometimes do you see a meaningful value like my username.
As I was able to speak with the developers of the game, unity sends by udp packages values ​​such as the position, the speed with which the character moves, the strength of the shots etc. But I need to be able to see those values ​​and now I can't figure out how.
Most of the packets are short and look like this:
Hexa: 450000282e4c40002711d6cb12c07b11c0a80034b55aeeff00146cac000185649a8b002080000000
Ascii: E(.L#'ÖËÀ{À¨4µZîÿl¬d
The biggest one with some information are similar to this:
Hexa:450002f6d07040002c1115bf12d79214c0a800349c8aff0a02e2d47a0001974c02cf0020c0000000ff82cb00020082c60201000c000001000c00016302030001604df870f965340ea85076954c4641b5cdcccdc20ad7233dcdcc90c2340200000000cdcccdc20ad7233dcdcc90c20100b44200000000000000000100b4420100b442fa000000803f010000000000000000000000000000000400c236ee4343498644a42ef08bbd67c4e8f168eb9d20563004c96d41d68b427abdd2843fe59f909904f8e91cc9b542033100000c00546573747465737474657374000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000001000000010000000000000000000000020000001300000010000000510200004b000000e1fb64def58d5524fbaf9b5cf0547b9a0001000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000030000006cd5317f111d42141a2481f7e95223c005000000dba0d79272a295c4a9a968a669a3650905000000fd301ab653c6cc548bb9862b0f9b3aa005000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000300000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000030000006cd5317f111d42141a2481f7e95223c00500000000000000000000000000000000000000dba0d79272a295c4a9a968a669a365090500000000000000000000000000000000000000fd301ab653c6cc548bb9862b0f9b3aa005000000000000000000000000000000000000000000000000000080f404353f00000080f204353f02000400010036000a0002010000000000000000000000002600000000000000000000000000010000000000000000000000000000000000000000000000000010000a0003020000000000000000000000000000
Ascii: EöÐp#,¿×À¨4ÿ âÔzLÏ ÀÿËÆc`Møpùe4¨PvLFAµÍÌÍ ×#=ÍÌÂ4ÍÌÍ ×#=ÍÌ´B´B´Bú?Â6îCCID¤.ð½gÄèñhë V0ÉmAÖBz½Ò?åøéɵB1TesttesttestQKáûdÞõU$û¯\ðT{lÕ1B$÷éR#ÀÛ ×r¢Ä©©h¦i£e ý0¶SÆÌT¹+: lÕ1B$÷éR#ÀÛ ×r¢Ä©©h¦i£e ý0¶SÆÌT¹+: ô5?ò5?6 &
Where Testtesttest is my Username
Any ideas?

Android BLE - determine characteristic's stored value type

My issue is with lack of ability to determine the type of the value, that read BLE characteristic has been storing. According to bluetooth spec. https://www.bluetooth.com/specifications/assigned-numbers/format-types those types are predefined by the standard and therefore GATT client should be able to read them.
My app is an attempt to create generic GATT client with ability to read any service and any characteristics it stores. For this I must have some universal way to read the type of characteristic, so that I am able to read it properly. For this I lack BLE API, that would allow this
I think simillar question is asked here: How to get BluetoothGattCharacteristic value format type? but question did get no answer.
Unfortunatelly current workaround would be to map UUID of specified in bluetooth characteristic, with the stored value's type. This solves lots of daily cases, but still is not enough to create completely generic GATT client.

Ok, I found the answer. For the people having simillar issue the answer lays not in BLE android API, but in bluetooth GATT specification.
It turns out, that some descriptors are mandatory and one of this is characteristic presentation format, specified here:
https://www.bluetooth.com/specifications/gatt/viewer?attributeXmlFile=org.bluetooth.descriptor.gatt.characteristic_presentation_format.xml
there we can find the "hard coded value type", which is 8bit value and enum, which represents this value as the type. Based on this value we can deduce the characteristic's value type and read it properly.

Encrypting Altbeacons

I am attempting to create UUID's that incorporate security measures that prevent replay attacks. I plan to attach a timestamp to the UUID and Encrypt the beacon. The encryption creates a 16 byte object but The Beacon Transmitter requires the UUID to be a string of consistent length. Is there a way I can transmit a Byte object instead of string. Also, I need the encrypted beacon to change with the time. Should I do a:
beaconTransmitter.startAdvertising(beacon);
timeout(1 second);
beaconTransmitter.stopAdvertising(beacon);
and recursively call my beacontransmit method?

If your encryption really makes a 16 byte object, then you should be able to convert it to a UUID, which is also 16 bytes long. It should be as simple as:
Identifier uuid = Identifier.fromBytes(byteArrayOfLength16, 0, 15, false);
However, encryption algorithms typically make a much longer byte array as the output. You could remove all but 16 of the bytes from the encrypted output to make a hash (this is basically what Eddystone-EID does), but this won't be able to be decrypted. The receiving device would have to perform the same encryption calculation for a given timestamp to see if it calculates the same value. If it does, it knows it has found a match.
Yes, the approach of starting advertising based on one timestamp, waiting for a delay, and starting advertising based on a new timestamp is certainly the way to go.

Android bluetooth chunk size

I'm experiencing a strange behavior of bluetooth socket (in my opinion), and I would like know if anybody can clarify it to me.
The situation:
I have two Android applications connected together by a Bluetooth socket:
The first makes a simple write(byte[] message) on the output stream.
The second makes a simple read(byte[] buffer) on the input stream.
On the reader side I use a buffer of 1024 bytes. The sender send a message a little bit larger than the receiver buffer size: 1024 + 108 bytes (always the same message).
Ok now the behavior:
On the reader app I receive the most often a first chunk of 1024 bytes which fills up the buffer (as expected) and then a second one of 108 bytes.
But really often (maybe 40% of the time) I receive a first chunk of 1008 bytes and then a second one of 124 bytes.
I really would like to understand this because I'm affraid to miss an important bluetooth concept. At first I was thinking to compare the count of byte read with the buffer size to know if the entire message had been received but this experimentation shows that it's maybe not a good idea.
Is anybody can explain to me this behavior?
Thanks in advance.

For the record, I now use Google Guava methods for read/write on streams and all works fine.

I'm finding the same thing- it seems to be because Bluetooth sends data over as a stream instead of packets.
So if I send 4 500 byte packets, it might end up sending a 1600 byte one and a 400 byte one, or the way I sent it. Over stack overflow questions say to use some random value in the byte array to tell when a message is finished (How to read all bytes together via Bluetooth?).
There should be a better way, but I plan to use a very unlikely character set to try to find the end of the message- and pad it onto the end of each of my messages going out. Some of the other stack overflow questions suggest using '\n', but I might end up using several to make it more unlikely, such as: "\t~\t"- something that should never be typed in my game (or hopefully not extracted from the enormous amount of other stuff going on).
Hope that helps!

Temperature converter in Arduino

I'm doing a project which requires me to use a TinkerKit thermistor sensor to get the room temperature. After detection, the Arduino BT board must send serial data back to an Android phone via Bluetooth. And the temperature need to be display on the phone screen in Celcius.
I have already make the serial communication link work. But the reading from the thermistor seems weird. It reads at 173/174/175, but I'm not sure whether it read in Fahrenheit or Celsius (as I could not find any datasheet and details on the thermistor's reading unit).
Must I include any temperature convertor coding with the values?
The output values will be mapping # : outputValue = map(sensorValue, 0, 1023, 0, 255);

Are you sure there's no data sheet for reading the thermistor, or documentation for the kit explaining what it returns? I'd guess the value you're getting is an unsigned byte (or possibly more than one byte, based on the '1023' value in your map) indicating the 'percentage' of temperature between two ranges.
Like if it were a single unsigned byte between -40'C (0) and +40'C (255), 174 would be 14'C (174/256 * 80 - 40) or thereabouts. You could probably do the math to figure out what the correlation is between the actual observed temperature in your room is and the thermistor value with a known-good thermometer as well.
Perhaps there's a library for the kit that interprets its values for you?