Open MrKev312 opened 5 years ago
i decided to put some more in a xlsx
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.
i think that this bit of data is a bit broken since the "id" is different
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.
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!
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.
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!
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?
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:
If that happens, it probably means I requested way too much Handle
s from the kernel. This "Error" disguised as "Success" should be fixed in the lasted release and commit.
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
i'll launch a fork and try a few things
as i expected the same thing happens
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;
Use: u8 dataSend[8]; std::copy(firstShake, firstShake + 8, dataSend);
instead. You might have to #include <algorithm>
if it isn't already.
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
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?
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
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
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
also the wii u gamepad message is: a5 70 81 02 7b and a5 70 81 0f 58
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.
If you don't mind, I'll take the discussion of the protocol to issue #13, so it's more visible to other people.
Program output
Please keep this indented with 4 spaces
This is example data, which isn't real
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