VESC tool V6 is out… you can now configure XLITE directly with your phone when connected via Bluetooth:
6 Likes
Will I get this new version with isolated CAN and integrated BT when ordering xlite-24-v2 now or if not when I could expect it to be orderable?
Hard to tell, but if everything goes well, I think end of January should be possible.
4 Likes
Would it cause any problem for the CAN bus connection on V1 X-LITE to be powered by a 5v converter from the main battery? I want to add power to the CAN bus for Metr, and I think the most economical way to do it is with a converter inside the battery compartment. This way only the CANH/CANL wires would be connected to the VESC, through the Metr modules.
That would work, but it would slowly drain the battery if powered ON at all time.
Simply connecting CANH and CANL will also work, but only when the XLITE is active (during charge process)
Power button input on V2 was thought for avoiding to do this kind of setup.
Last night I upgraded my X-LITE-24-V1 firmware to 5.5 and started using VESC tool to configure it, having some trouble with it. I’ve gone through the setup a few times with 5.4 and the Ennoid tool over USB, and each time I do a full charge while the USB is still plugged in to work out any kinks, and then never have a problem with it. Since VESC tool doesn’t show operation state and fault state, when it just stops charging for no apparent reason, it’s impossible to figure out why. I can’t get this to charge to full, I can manually press “allow charging” and it goes for 30 seconds and then shuts off again -
Here are the settings:
Also VESC tool lets you input values that would be out of bounds on Ennoid tool, which causes unexpected behavior. I initially put 0.03A for sleep current, and it would shut off periodically even at 5A.
You can use wireless bridge to connect with EBMS-tool desktop in the “connection->TCP” section if you need to diagnose the issue with fault code and opstate.
I think I’m observing what is going on in the video, I see a sudden voltage jump for a second or so. I observed that behaviour recently on a few units running V5.05. I don’t know yet if it is related to using a new compiler version for V5.05 on my side and what conditions create this issue. (I’m moving back to the old compiler for the next release due to this and will see if it goes away). It might also be hardware related, but I’m now using genuine ISL28022 due to its recent availability instead of previously using aftermarket ones that might cause such issues. For now, I know that you can bypass the problem by using parameter on ENNOID-BMS->signal->Pack voltage data source == sumOfIndividualCellVoltages instead of == ISL28022 (I2C). It will simply take pack voltage readings with sum of cells instead of relying on ISL28022 and no more error should occur.
I will likely try to push those fault code reporting into the VESC tool software repo for next release. That would make it easier to troubleshoot the XLITE on VESC tool. I just don’t know why vedder has not implemented it yet, he might be quite busy on other topics.
Out of bounds values, I will check if there is anything that could create this when using both EBMS tool and VESC tool, but it should not be a problem.
1 Like
Excellent, thank you, I am not good at navigating github so I couldn’t find the 5.05 version of Ennoid tool at first and thought you were going to VESC tool only… I found it and got it linked with TCP bridge, very helpful, super glad I don’t have to dismantle my board for BMS configuration anymore.
It is randomly stopping mid charge even at middle percents (3.7V/cell) and giving Max UVP/OVP fault state, I guess it wasn’t anything to do with the sleep current threshold after all. I am changing the pack voltage source and will see if that makes a difference.
Edit: here is a screenshot from right after it cut off and gave the fault state (the jump in voltage earlier in the graph is from disconnecting and then reconnecting a few minutes later)
Edit2: just downgraded to 5.04 now that I know how to use TCP bridge, gonna stay on this version for now.
I have a new issue that I don’t have any idea what to do about, ever since I connected the CAN bus to the VESC, the top half of the battery (C11-C19) is dropping significantly lower than the bottom half. I’ve never had an issue with this pack falling out of balance before… I’ve had maybe 80 full charge cycles on it, I tinker with the board at least once a month for which I’ll plug in the USB to check on things, it’s always well balanced. Any idea what could be causing this, or how to proceed with diagnosing the issue?
Are you using thermistors?
Have you changed/rearranged the balance wiring since?
Is your XT30 battery is solid?
You can always measure with a meter each cell group and see if the values correspond to whats measured by the XLITE. If all connections are good and measurements are offset, it is likely related to balance wire internal resistance that creates some offset.
Hello
How many mosfets the esc has and can be paired with an other for e-scooter and if so is there port for e-brakes?
The ESC has all the same I/O as a usual VESC and can usually do what other VESC can do.
The amount of main power mosfet is 6, but that is mainly irrelevant from a user standpoint. Some vesc have 12 and some even more depending of the mosfet type and current desired.
@ENNOID, I’m running XLITE-12 with the firmware v5.2. I just tried updating to v5.5 and it didn’t work. I grabbed the firmware file from here and I uploaded it using the VESC Tool. This finished successfully but when I reconnected the BMS, it’s still reading v5.2. I then tried doing the same with the ENNOID Tool. Same result:
I even tried power cycling the BMS, just in case. Didn’t change anything.
I’m puzzled. Could it be that the .bin file actually doesn’t contain the expected firmware version?
1 Like
It is likely bootloader related. Try uploading the bootloader first in ENNOID-Tool. I might have forgotten to upload it.
It also takes a while sometimes on VESC tool to finish installing the update. Like for VESC, a reconnected is also needed to refresh the Firmware version in the VESC tool.
1 Like
I’m testing a VESC package battery dashboard written in LISP for VESC APPUI 6.00 and above. Works on both desktop and mobile. It gets the datas from XLITE over CAN bus and calculate battery internal resistance and show some other critical datas.
6 Likes
Is there any reason to use ISL instead of ‘SumOfCellVoltages’ for pack voltage source? Seems like that’s a lot less noisy and more accurate.
Also I noticed on FW6.0 the option for SoC tracking method has been removed… is it only voltage based now? I liked coulomb counting.
It is for some extra safety reason that I’m still using ISL instead of SumOfCellVoltages by default, but that could be changed. Both options are available in ENNOID-BMS-Tool.
Current tracking SOC will be re-enabled in the ENNOID-BMS-Tool options for the next release, but was simply replaced for now by low cell voltage SOC tracking. This is to prevent some XLITE users to nosedive while using their not properly configured VESC and/or XLITE
That was it. I uploaded the bootloader and now the firmware update works just fine. Cheers!
I got a strange issue after the firmware update. The BMS started reading the total voltage at around 70V when the actual voltage was 44V. Consequently it refused to enable charge. I had to adjust the Pack Voltage Factor significantly to compensate. Not sure if that’s expected.
Now I can charge but it’s a bit flaky. Sometimes the BMS refuses to enable the charge for no obvious reason. I noticed that this is more likely to happen when ESC and DAVEGA are powered on. This already happened with the older v5.02 firmware.
Is there a way to see why the charge is disabled? Any logs?
Last but not least, USB connection stopped working. I get “resource busy” both in VESC Tool and in Ennoid Tool when trying to connect.
I can still connect to the BMS using Metr and TCP bridge. This is a forwarding hell. I’m surprised it actually works. The communication goes like this:
VESC Tool on MacBook --(TCP)–> Metr on iPhone --(BLE)–> Metr module --(UART)–> VESC --(CAN)–> Ennoid BMS
Your XLITE-V1 probably has a different pack voltage/shunt IC INA226 instead of ISL28022 which create a scaling difference for the voltage readings. I now use only ISL28022 and the firmware is now inline with this. I used INA226 on a few batches due to the part shortage, but this created some issue for users.
You can use sumOfIndividualCellVoltage instead of relying on ISL28022 I2C in the pack data source setting. This will eliminate the scaling issue and will likely also solve your charging issues.
For the USB, it can be laptop driver related or simply a dirty USB port. My cleaning agent was not good enough when I started producing XLITE and I had some USB port getting clogged after some time. Try wetting the tip of your USB C with some alcohol and it should be back on track if the laptop is not the issue.
With ENNOID BMS tool you can diagnose the fault code and opstate in the rt data tab. In VESC tool, the only way right now is to poll “status” a few timea in a row in the terminal after a “reboot” command.
1 Like