Gan 356i get up/front color issue

[caichunjian520]

Before connecting with the web page, if I place gan's cube on the table with white color on up side, the up/front color is correct. But if with other colors on up side. It will get wrong result. Any solution?

[AshleyF]

If I understand correctly, you're expecting the diagrams to match the colors on the GAN 356i cube? In fact, the up color in the diagrams should be randomly chosen from those selected in settings and have nothing to do with the physical cube.

The real benefit of the site is to completely ignore the colors of the cube in your hand and to pretend you're holding the one on the screen. In fact, I use a Giiker with the stickers removed. This way, you can quickly drill algs without setting them up.

A feature whereby the up color on the physical cube dictates the diagrams might be nice. It might be confusing too though for some (e.g. myself with CMLL algs for Roux that expectedly leave the centers flipped).

I hope this helps. If I've misunderstood the issue, please correct me!

Have fun!

[caichunjian520]

In experimental/gan356/gan-simple.js file, it decodes the bluetooth data from cube. Characteristic FFF5 is for angle and battery info. From the first 6 byte value, we can get its eular angle and up/front color. But it only works when the cube’s white color is on UP side before Bluetooth connection. In Cube Station app, it doesn’t have this issue.

The another question is why use both 6 bytes to get its eular angle? 024 always change even the cube is on stable condition.

I am now working on an iOS app to synchronize the 3D rubik’s cube as real app, that means when I tilt the real cube, it does the same in my app. I translated the JavaScript code to Swift, but it worked not as expected on angle part.

[AshleyF]

Ah, I mistakenly thought the "web page" you were talking about was the main site. Things in /experimental are just my weekend side experiments. I had some fun reverse engineering the GAN 356i but, as mentioned above, didn't actually need to use the physical orientation. The Bluetooth protocol is more of a puzzle than the puzzle itself :P

From what I've gathered so far:

• fff1 is a single byte, always 1 as far as I've observed
• fff2 seems to be the state (changes and restores depending on scramble)
• fff3 is the last 18 twists (a rolling counter, plus 18 bytes each representing 0=U, 2=U', 3=R, ...)
• fff4 is a notify only characteristic but I've never seen it produce anything
• fff5 is multiple things packed in one: 6 bytes quaternion (as expounded on below; 3 little endian int16s), 6 bytes of relative encoders (-6 .. +6 signed bytes; 0 being flush in URFDLB order), then a count and last 6 twists (as in fff3, but fewer)
• fff6 seems to be some kind of state, but not purely a function of cube state (changes with each twist but, for example, solved state is not always the same). First byte is count. The remainder seem to be in pairs (int16s?)
• fff7 is full encoders with 0-48 for full twist, similar to fff5 but full rotation. URFDLB order. The following bytes are a mystery; either not changing or, in the case of bytes E-Perm in 2LPLL #7 and 8, changing randomly when nothing on the cube has changed.
• fff8 is the name of the device in 10 ASCII bytes (e.g. "GAN-f2c790")

All of that said, the first 6 bytes of fff5 are a quaternion, I believe, rather than Euler angles. Just from pure experimentation, I'm guessing that it's the x/y/z of a quaternion with the w component missing. This line is meant to recover it, given the property that the sum of squares should total 1 so w = 1 - sqrt(x^2+y^2+z^2). I then convert to Euler angles for my own sanity.

I'm guessing also that this rotation value is determined in firmware on the cube by integrating an accelerometer and gyro. I've done this for a balancing robot. The accelerometer is noisy, but helps to determine gravity while at rest (not experiencing centripetal forces) and the gyro helps determine angular velocity but isn't grounded and so drifts over time. Integrating with high/low pass filters on these signals produces a relatively stable value and I believe this is what they're doing.

It will "settle" while not moving. It may still drift around the vertical axis. This is why the Cube Station app allows the user to spin the cube to the correct front-facing color. After this, in their app, you can still observe a drift over time. The values will always jitter to some degree because that is just the nature of IMU sensors. The reason you see the 0, 2 and 4 bytes changing most is that they are the low-order byte of each value.

The reason that my Up/Front color detection only works when the cube is initially connected with White/Green is that I'm taking an initial reading here and then diffing against the current reading thereafter (and assume White/Green initially). That's not necessary (although some kind of calibration and diff may be necessary just as in the GAN app).

Hopefully this helps!

Good luck with your iOS app! BTW, another project you may want to watch is Lucas Garron's CuBLE.js.

[caichunjian520]

Thanks for your detail explanation, I find I need to learn a lot to handle this for my project.

[AdamPrimer]

This has been super handy to get me started on this long journey of trying to decode this cube into something meaningful.

The most important thing I want to mention, because this confused me for a long time, is that as far as I can tell, the values for the gyro are actually ordered (w,x,y) and z needs to be recovered. The math I was using that made no sense all fell into place with this realization.

Also, if you haven't figured it out yet, fff6 is the timestamp since the last move, for the last 18 moves (same moves as fff3).

Byte 8 of fff7 appears to be the battery level.

[willin]

Hardware Version: 3.5.1 (NEW)

R twice:

Twists
Count: 71
undefined undefined undefined undefined undefined undefined undefined undefined undefined undefined R' undefined undefined undefined undefined undefined undefined undefined

Count: 243
undefined undefined undefined undefined undefined undefined undefined undefined undefined L undefined undefined undefined undefined undefined undefined undefined ?

seeemed cannot decode

[decha1]

Ah, I mistakenly thought the "web page" you were talking about was the main site. Things in /experimental are just my weekend side experiments. I had some fun reverse engineering the GAN 356i but, as mentioned above, didn't actually need to use the physical orientation. The Bluetooth protocol is more of a puzzle than the puzzle itself :P

From what I've gathered so far:

• fff1 is a single byte, always 1 as far as I've observed

• fff2 seems to be the state (changes and restores depending on scramble)

• fff3 is the last 18 twists (a rolling counter, plus 18 bytes each representing 0=U, 2=U', 3=R, ...)

• fff4 is a notify only characteristic but I've never seen it produce anything

• fff5 is multiple things packed in one: 6 bytes quaternion (as expounded on below; 3 little endian int16s), 6 bytes of relative encoders (-6 .. +6 signed bytes; 0 being flush in URFDLB order), then a count and last 6 twists (as in fff3, but fewer)

• fff6 seems to be some kind of state, but not purely a function of cube state (changes with each twist but, for example, solved state is not always the same). First byte is count. The remainder seem to be in pairs (int16s?)

• fff7 is full encoders with 0-48 for full twist, similar to fff5 but full rotation. URFDLB order. The following bytes are a mystery; either not changing or, in the case of bytes E-Perm in 2LPLL #7 and 8, changing randomly when nothing on the cube has changed.

• fff8 is the name of the device in 10 ASCII bytes (e.g. "GAN-f2c790")

All of that said, the first 6 bytes of fff5 are a quaternion, I believe, rather than Euler angles. Just from pure experimentation, I'm guessing that it's the x/y/z of a quaternion with the w component missing. This line is meant to recover it, given the property that the sum of squares should total 1 so w = 1 - sqrt(x^2+y^2+z^2). I then convert to Euler angles for my own sanity.

I'm guessing also that this rotation value is determined in firmware on the cube by integrating an accelerometer and gyro. I've done this for a balancing robot. The accelerometer is noisy, but helps to determine gravity while at rest (not experiencing centripetal forces) and the gyro helps determine angular velocity but isn't grounded and so drifts over time. Integrating with high/low pass filters on these signals produces a relatively stable value and I believe this is what they're doing.

It will "settle" while not moving. It may still drift around the vertical axis. This is why the Cube Station app allows the user to spin the cube to the correct front-facing color. After this, in their app, you can still observe a drift over time. The values will always jitter to some degree because that is just the nature of IMU sensors. The reason you see the 0, 2 and 4 bytes changing most is that they are the low-order byte of each value.

The reason that my Up/Front color detection only works when the cube is initially connected with White/Green is that I'm taking an initial reading here and then diffing against the current reading thereafter (and assume White/Green initially). That's not necessary (although some kind of calibration and diff may be necessary just as in the GAN app).

Hopefully this helps!

Good luck with your iOS app! BTW, another project you may want to watch is Lucas Garron's CuBLE.js.