• Welcome to the Speedsolving.com, home of the web's largest puzzle community!
    You are currently viewing our forum as a guest which gives you limited access to join discussions and access our other features.

    Registration is fast, simple and absolutely free so please, join our community of 35,000+ people from around the world today!

    If you are already a member, simply login to hide this message and begin participating in the community!

Gan 356i smartcube review & issues

efattah

Member
Joined
Feb 14, 2016
Messages
518
So I got my first Gan 356i smart cube yesterday. First I had problems getting it to charge, the base adapter always shows a green light no matter if the cube is connected or not. There is no user manual of any kind, neither in the box, or online, anywhere. It turns out you need to have the white face 'up' when plugging the cube into the base charger (this is printed in tiny text on the bottom of the plastic). I downloaded the app and you need to shake the cube violently for 5 seconds for it to wake up and get detected and it needs to be charged for several hours before it can be detected.

Once it was detected I started solving. The orientation of the cube displayed didn't match the orientation I was holding it in, I tried various 'reset' options and eventually it sort of matched up. It did generally work as promised, tracking/matching my moves on the app, although the reconstruction is totally weird and not really correct. The reconstructions constantly show that I did tons of S moves and E moves which I never did, and they incorporate strange rotations that were not actually done, not to mention the app says I do over 60 rotations per solve when the real number is around 4-5. The timing function worked great, it always starts/stops right at the perfect moment which is awesome.

My biggest complaint, unfortunately, is a big one, and that is the cube comes with 3 sets of springs, all of which are WAY TOO TIGHT. Even on the lightest tension the cube is extremely hard to turn (my fingers would get exhausted after 20 solves when normally a 100 solve average creates no issues). Maybe more solves will break it in-- otherwise in my mind it is nearly useless for actual solving (maybe ok for some training analysis). I was losing about 2 seconds per solve on a 13-14 second average time because of the extremely tight faces. I tried removing the springs entirely and the cube exploded instantly and is extremely hard to put back together unlike most cubes. I might try to go on to mcmaster.com and see if I can buy other random springs that are of a similar size but much softer; with the correct tensions the cube would feel like a Gan 356 X, which I do like, although nothing (for me) ever beat the GTS 2M when set up properly.

I'm curious if anyone else has come up with an easy solution to the tension problem on the 356i.

One thing I do like is the ability to see your movecount instantly (and tps), this clearly shows how movecount decreases on slower solves with better lookahead, although to be fair I'm not sure I believe the movecount since the reconstruction includes all sorts of E and S moves that I never did.

EDIT: with the white face 'up' for charging, it occurred to me that after my cube exploded the white center piece may no longer be in the same place. As such I no longer know which side must be 'up' for it to charge.
 

efattah

Member
Joined
Feb 14, 2016
Messages
518
I use LMCF which uses a lot of M/U moves. I do one Z/Z' rotation after solving corners after which I only do X/X' rotations (maybe 3-4), but the Gan 356i app says I do a ton of Y/Y' rotations which I never do.
 

efattah

Member
Joined
Feb 14, 2016
Messages
518
OK I did some more tests and found out the cause of some of the issues. First of all for non-CFOP methods the move count is drastically wrong. For example on my last solve I finished with M2 U2 M2. This should count as 3 moves. Instead it was registered as M' x' M' F2 M' R' x' L [6]. Which is double as many as it actually was, although the 'reconstructed' sequence does show a functionally equivalent sequence.

The app is never able to register M2 moves, ever. It will register them as M' M' if you are lucky, and more often, M' R' L or some similar combination. Single M moves are often registered as R-L combinations. In my case I did some manual reconstructions and the reported move count is on average 10 moves more than what I actually took during the solve. For CFOP solvers I imagine the move count should probably be accurate unless you finish with EPLL and you use M/U to solve those cases in which case you will run into the inflated moves problem.
 

Kurainu17

Member
Joined
Apr 12, 2013
Messages
43
Location
Canada
WCA
2012ONGR01
YouTube
Cloppie
Interesting you found all the springs too tight, I find most of them too loose. The slice moves is something as far as I know Gan is aware of and hopefully can be fixed in software. Personally found the cube to be fairly decent, although I had to change turning style slightly since it's not as forgiving as the 356 X.
 

efattah

Member
Joined
Feb 14, 2016
Messages
518
When my favorite cubes are set up, they can all do U2's with a single strong finger flick. Perhaps that is 'low' tension by most people's standards? My Gan 356i can barely do a single U with a short flick; most often a quick flick does a 65-70 degree turn and doesn't even make it the full 90 degrees unless the finger flick is longer and pushes the face all the way across. Maybe my cube is a dud....?
 

RubCuber

Member
Joined
Oct 13, 2016
Messages
6
YouTube
rubiksmaster301
OK I did some more tests and found out the cause of some of the issues. First of all for non-CFOP methods the move count is drastically wrong. For example on my last solve I finished with M2 U2 M2. This should count as 3 moves. Instead it was registered as M' x' M' F2 M' R' x' L [6]. Which is double as many as it actually was, although the 'reconstructed' sequence does show a functionally equivalent sequence.

The app is never able to register M2 moves, ever. It will register them as M' M' if you are lucky, and more often, M' R' L or some similar combination. Single M moves are often registered as R-L combinations. In my case I did some manual reconstructions and the reported move count is on average 10 moves more than what I actually took during the solve. For CFOP solvers I imagine the move count should probably be accurate unless you finish with EPLL and you use M/U to solve those cases in which case you will run into the inflated moves problem.
In the WCA, M/E/S moves count as two moves, which is why an M slice is a DNF.
 

efattah

Member
Joined
Feb 14, 2016
Messages
518
In the WCA, M/E/S moves count as two moves, which is why an M slice is a DNF.
Indeed, which is absolutely contradictory since TPS is measured in STM where M slice counts as 1.
If M and E count as 2, then a Roux solver doing M2/E2/M2 combos has a TPS of 30 or more, which is not true.
 

efattah

Member
Joined
Feb 14, 2016
Messages
518
It has exploded a few times and it is EXTREMELY HARD to put back together. Hardest cube ever to re-assemble.
 
Top