[DATA] Martijn 2

[MrKev312]

Program output

Please keep this indented with 4 spaces
This is example data, which isn't real

a5 80 c4 19
03 14 63 a9

Fit Meter Data

This data probably isn't used in the handshake

• kCal: 480

• Steps taken: 1791

• Altitude: 24m

• Time: 20:48

• Date: 26-02-2019

• Temperature: 21.3 °C

• Mii name: Martijn

[MrKev312]

i decided to put some more in a xlsx

wii fit meter data.xlsx

[HenkKalkwater]

By the way, are you sure that the first line of the output you've put in this issue is correct?
The 8th byte is, as far as I've discovered, the CRC-8 (kind of checksum) over the first 7 bytes, and the CRC-8 doesn't match with the output in this issue, but those in your spreadsheet seem to give a correct CRC-8 back.

[MrKev312]

i think that this bit of data is a bit broken since the "id" is different

[HenkKalkwater]

Yeah, that is what I thought. It could be a coincidence, but the ID of your Fit Meter is the same as mine. It could be that they all use the same ID. I believe your 6th byte is also a bit off, because it's always the same in your spreadsheet, but it doesn't match up with the one in your issue. That basically leaves the 5th and the 6th byte left to guess. My initial guess for the 5th byte right now is that it is an indication of what kind of action the meter is looking doing. 0x3 could be announcing its presence, 0x4 could be that it is polling for other fit meters.

[MrKev312]

but now i wonder how a "conversation" between fitmeters would go or the connection between the gamepad and a meter? and what if we could replay data to the fitmeter? i think if we could send data to the fitmeter and see how it responds to certain data we can figure out how the protocols work!

[HenkKalkwater]

That's what I'm currently trying. Sending a5 00 84 01 04 04 4c back will make the Fit Meter immediately respond with "Connection failed" instead of "No connections found". Having the 5th byte set to anything else than "0x4" will cause it to display "No connections found" after a while (I tried it by brute focing). So presumably, I need to change the 6th bit and that's what I'm currently trying.

[MrKev312]

i just relayed your "id" and i got a ton of data back! i think i've managed to get it to think my 3ds is a fit meter!

[HenkKalkwater]

Can you post the data here, if you still have it? I apparently forgot to include the 8th byte in that message I posted before, which is the checksum. Maybe the fit meter ignores it?

[MrKev312]

speculation: by sending an id you make the fitnessmeter think its connecting to a real fitmeter, because it doesnt reply to it, it tries to reconnect to it, causing a lot of reconnect attemps
data:

[HenkKalkwater]

If that happens, it probably means I requested way too much Handles from the kernel. This "Error" disguised as "Success" should be fixed in the lasted release and commit.

[MrKev312]

i think also the reason the connection failed because you're sending data before giving your id making the meter think it has missed some data and cancelling because when sending the id you get a timed out

[MrKev312]

i'll launch a fork and try a few things

[MrKev312]

as i expected the same thing happens

[MrKev312]

any idea on how to fix this compile error: error: invalid conversion from 'u8*' {aka 'unsigned char*'} to 'u8' {aka 'unsigned char'} [-fpermissive]
i'm trying to do this:
u8 firstShake[8] = {0xA5, 0x00, 0x84, 0x01, 0x03, 0x04, 0x0A, 0x50}; bool firstshakedone = false; u8 secondShake[8] = {0xA5, 0x00, 0x84, 0x01, 0x04, 0x04, 0x4C, 0x00}; u8 dataSend; dataSend = firstShake;

[HenkKalkwater]

Use:
u8 dataSend[8];
std::copy(firstShake, firstShake + 8, dataSend);

instead. You might have to #include <algorithm> if it isn't already.

[MrKev312]

holy snap thank you so much, i gave up and one second later you reply! also it works, i'm now testing the changes i've made

[MrKev312]

as soon as the fitmeter recieves a 04 04 it gives an error:( also could you give me your response to a5 00 84 01 03 04 5f fc?

[MrKev312]

i think this is how the conversation between meters goes:
(03 04) type message
(03 04) type response
(04 04) type message
x type response

[MrKev312]

i got a step further by starting the conversation as the 3ds:
(03 04) type message
(03 04) type response
(04 04) type message
(04 04) type response

here with actual data:
03 04 0a 50 3ds
03 04 64 5d meter
04 04 f6 bc 3ds
04 04 fb 9f meter
x type message

[MrKev312]

ok so now it did this:
03 04 3ds
04 04 meter
04 04 3ds
04 04 meter
crash
here with data:
03 04 0a 50 3ds
04 04 03 79 meter
04 04 ff 83 3ds
04 04 04 6c meter
04 04 ff 83 3ds (error)

so 03 04 means that a meter starts a conversation since it should only happen once nvm this, its just an error in the program

[MrKev312]

also the wii u gamepad message is:
a5 70 81 02 7b
and
a5 70 81 0f 58

[HenkKalkwater]

Thanks a lot! So this means the Wii U gamepad uses messages of 5 bytes long. Interesting. This probably means the documentation should be changed partly.

[HenkKalkwater]

If you don't mind, I'll take the discussion of the protocol to issue #13, so it's more visible to other people.