It’s quite simple to fix really, put the newly discovered devices at the bottom of the list not the top… then it won’t shuffle your device further down as new ones are discovered. It isn’t that hard.
Tbh Ben needs to hire a UI guy - the tool is brilliant, but it’s not user friendly at all . Same for the mobile app, good, but not user friendly really. Hard to complain seeing as it’s all freeI guess. I’m hoping as variESC develops it can sort out a lot of issues we need. The freesk8 app is also shaping up to be a much more user friendly experience for setting parameters etc.
Yea but it’s wild cause Vesc tool on pc and Android and rt app was on on both and still nothing which is the thing that’s confusing me because on the unity I did the same thing I did on the Xenith and it was fine if the Xenith is exactly like the unity than shouldn’t it be the same and work with the Xenith that’s what I’m confused about
I have a local guy that just got a Xenith for his first diy board, ran detection following Jared’s instructions, and has a weird issue.
His motor cuts out ONLY when he sets the “duty cycle current limit start” to 85% as suggested. When at the stock 95% value, it doesn’t have the issue. Both motors spin up, both cut out, and one starts accelerating again.
I’ve quadruple checked with him that he changed “duty cycle current limit start” and not “duty cycle current limit” and he’s sent screenshots affirming.
His motor detection results look normal. He thought maybe it was only a no load issue but apparently not.
I can’t let him roll around with 95% “duty cycle current limit start” set safely so I’m trying to troubleshoot my way through the normal stuff. Hopefully he joins up here and gets it sorted soon, I need a local diy dude to cruise the woods with.
Had the same issue my remote connected with the 85% setting ramped to top speed and since the remote can’t do anything I had to turn the board off cause it would automatically do that I honestly don’t know what’s happening with the xeniths hopefully it’s user error honestly
The xenith is just a unity with different connectors and a reshaped heat sink running a different firmware than the old unitys ran but still a current one that old unities can still run.
A user programming them is where the real differences pop up.
I mean the same firmware that goes into the unity goes into the Xenith right if so than it’s hardware cause the same firmware that went into my unity went into my Xenith and the unity worked fine and the Xenith didnt so idk what to say
The unity came out before FW 5.1 was introduced and a lot of unities are still running a version of FW called 23.46. This was the unities own branch of vesc software, specifically for the unity.
Enertion went down financially so the unity no longer had a dev team supporting it.
BUT, when FW 5.1 came out, it was made for devices with similar architecture as the unity so the unity can run current 5.1 FW
This doesn’t mean every unity runs that version. This is why it is important to specify many details on what you are running and not just the device names.
Yep; to use an analogy, it’s like talking about your pair of Dell Precision M6800 workstations, but failing to mention one is running Windows 10 and the other is running Ubuntu 20.04…
Just look at your firmware version (examples: 5.2 or 23.46) and your tool name (examples: VESC Tool, variESC Tool, ESC Tool, FOCBOX_UI). What does it say?
Versions that start with 23.x are not going to be comparable to versions starting with 4.x or 5.x
Not sure if that’s the right place to ask, but Xenith is still a Unity
Is there some important reason to run 5.2 instead of latest Unity firmware? (FOC, Dual 6374, 10s if it matters)
