On the first XLITE-12-V1 and with default firmware V6.00, as previously explained you might need to adjust shunt LC factor to get accurate current readings and to keep charging properly otherwise with wrong current readings, charging process might get interrupted.
For the MAC OS version of ENNOID-BMS-Tool, that would be nice to share it, so others can use it on their MAC too. I don’t know how to do that and I don’t have the hardware to compile it myself.
This is actually “normal” behavior for x-lite when plugged in to USB. It requires reboot to go back in to charging state. Not sure why it’s like that but it would have been my first question to help you troubleshoot. Pretty sure you can connect with TCP bridge if you have CAN connected to your VESC and it will behave the way you expect it to.
Also if you want it to fully charge, there’s some values you should adjust - soft cell overvoltage, shunt LC to make sure it’s measuring current properly, and charge current minimum (although the FW6 default of 0.1A is better than old versions that had 0.5A)
Sure, let me share it with you and you can add it to your release files.
I need external validation for MAC OS.
@mononaut maybe?
https://drive.google.com/file/d/166rlydVbxXlbWIIccHwIqhiAL4WxXAN_/view
@janpom I tried launching on 10.14, 10.15, and 10.15.7 and each time it gave me this message:
Right, so I guess things are rather difficult now with pre-compiled apps for Mac OS. First, there are incompatibility issues with various versions of the OS and second, we now have both Intel and ARM based Macs.
This is compiled on my Macbook, which has an Intel processor and it’s running the latest 13.2 Mac OS. It probably won’t work on (significantly) older OS versions and it definitely won’t work on the M1 and M2 chips.
@rpasichnyk has an ARM Mac. Roman, would you try compiliing the ENNOID app for M1/M2? On my system it was straightforward. Just:
qmake -config release_win
make
I just had a quick exchange with Roman and he pointed me to macdeployqt that creates a full .dmg bundle with all dependencies. I shared it here:
https://drive.google.com/file/d/16ECQykqvZLkOP_xCpHGEyyiofFR2YyPr/view?usp=sharing
@mononaut, could you please test that one. It may still not work because of the older Mac OS version but it’s worth a shot.
Also, one thing I wasn’t aware of (since I don’t have an ARM Mac) is that there’s a Rosetta plug-in that allows some (most?) Intel-compiled apps to run on ARM. So maybe no ARM-compiled version is needed.
Update: Roman tested the .dmg on ARM and it’s working for him.
File size is 29MB, which makes more sense as well.
I will add this .dmg file onto github and on the website XLITE-V3 google drive folder
Thank you very much
I think I may have triggered a bug in the FW when trying to setup the BMS params for my 20s2p pack using the Ennoid BMS tool :/. At some point, I must’ve entered the wrong setting for the Pack voltage factor and the BMS kept beeping a couple of times each time I’d try and revert the change to the default value, no matter what I tried :/. After trying a few more times, the BMS just disconnected and I haven’t been able to reconnect since. Power light turns on fine, no beep and I can see the Bluetooth device but BMS tool or VESC tool simply won’t allow me to connect to it, complaining abt not being able to read the firmware version. I’m thinking the FW and/or its params got corrupted somehow?
Anybody has some basic instructions on how to flash a clean FW onto an xlite v3 :}? I have an ST-link v2 clone which I’ve succesfully used in the past to flash a custom FW onto a VESC (Little FOCer v3) thru its SWD. I see the xlite v3 has SDA and SCL pins which would indicate I2C instead of SWD? Any addtl info. would be greatly appreciated :}.
BTW, this xlite v3 just came as a replacement for a xlite v1 (Thanks Kevin@Ennoid :)!) which simply stopped responding after a couple of weeks of light use (no messing w/ HW or FW, just stopped working from one day to the next). I have yet to send the faulty v1 module back to Kevin and was wondering if the v1 had any undocumented I2C pins as well to try and see if it’ll take a new FW flashed onto it to try and revive it in a similar way :}??
Just to clarify above… The BMS tool would simply not let me revert and write the default param onto the BMS after the seemingly faulty ‘pack V factor’ value was set (~2.48 IIRC). No matter what value I’d try next to correct the mistake, the BMS would simply beep a couple of times (indicating a fault), then the BMS tool would automatically set the value param back to its current (faulty) value as stored on the BMS (which I could easily confirm hadn’t changed from explicitly reading the currently stored settings from the BMS). One thing I noticed when the faulty pack voltage factor was entered incorrectly, the BMS stopped charging the pack (charger fan stopped spinning). Reading the current pack voltage as measured in the BMS tool showed a huge pack voltage of ~180V instead of ~74V as actually charged at the time (which I guess would be expected since this the ‘pack V factor’ was just set incorrectly), which would explain the BMS stopping the charging of the pack and possibly triggering an overvoltage fault subsequently causing the FW to go into some invalid state or smthing, not sure?
While a bug is not impossible, I think it is likely not the case.
What I can say is: Wear nitrile gloves (not latex) when handling the XLITE plugged to the battery. XLITE is small, body is conductive, distance between low voltage tolerant components and high voltages is small, so a naked finger can create damage if touching the very wrong spot.
In order to simplify things for users and after receiving several request, I finally made the change in newest V6.00 firmware release, so the pack voltage factor parameter does not require any tuning by default because it now uses sumOfIndividualCellVoltages instead of the ISL28022 I2C option, even if that can be reversed in ENNOID_BMS-tool…So I simply don’t understand why you would try to adjust it at all on an XLITE-V3. Maybe I should even remove the tuning options in VESC tool? Shunt factor and charger factors are also good enough to get it running without needing any adjustment.
Also, avoid using ENNOID-BMS-tool unless you know exactly what you are doing, I made things very easy to configure the XLITE with VECS tool mobile, minimal skill is now required to get it running and no finiky tuning is required at all to get running except adjusting the cell count… pretty basic stuff.
I2C is not the same as SWD. The SWD is simply unpopulated, but there
FWIW… The BMS has been encased inside a 3D printed enclosure before connecting to battery pack thus preventing any damage from potential shorting against the aluminum battery pack enclosure and/or touching from a naked finger.
I did indeed notice that the voltage readout was much more accurate than the xlite v1 which came pre-flashed w/ FW 5.03 instead of FW 6.0 for the xlite v3. Voltage was still off a bit by ~0.8V though thus my attempt at correcting it using the BMS tool params (albeit testing w/ completely wrong V factor value which caused the problems described above where it would not let me change the value back :/).
I had not yet connected the CANH/CANL wires coming from the VESC (I was waiting for an amazon order of JST-PH connectors of the right size (4 pins)), thus my using the BMS tool to configure the correct # of cells, etc.; Otherwise, I was ultimately planning to simply use the VESC tool app to connect to the BMS thru CAN.
Indeed, I2C protocol != SWD thus my original inquiry herein :}.
Yes, you can try comnecting an st link and flash with firmware file and stlink utility software
Well, believe it or not but I was able to revive the xlite v3 by flashing a fresh/clean FW v6.0 onto it using ST-Link thru SWD :)! Cells still nicely balanced and charging :)! Whoo hoo :O! I’m going to try the same thing w/ the xlite v1 next…
I have 2 questions-
Is there any way to keep the BMS permanently ON besides providing 5V to the CAN input? (Can I just jump the power button input?)
And, is there any reason it’d be a bad idea to power the I2C display with another 3.3V source and only use the SDA/SDL pins from the BMS? (Ideally using the 3.3V output from the little FOCer)
To explain my intention - I have exactly 4 wires available to connect between the two compartments of my onewheel, that I have been using for CAN bus. But I just got an idea that involves putting the I2C display in the front compartment, so I want to use the 4 wires for CANH, CANL, SDA, and SDL. I ride the board every day so the power drain from the BMS being alive isn’t an issue.
Yes, using the push button. There is the “not used timeout” setting that will eventually trigger a self shut down. It can be disabled either with a very high value or simply set to zero.
Don’t use I2C if it is being powered by another device unless you put isolation IC between. I had enough users breaking their XLITE due to the non-isolated CAN bus IC on V1 and V2 units even if it only required basic precaution and was a proper design choice. CAN bus was 58V rated. I2C is directly hooked to the MCU which is only 5V tolerant. Any external disturbance would likely kill the MCU.
Quick follow-up on this. I was able to flash a new v6.0 FW onto the faulty xlite v1 as well (Even though not labeled on the PCB, looks like the v1 is using the exact same unpopulated SWD pin layout as v3 :}). Unfortunately, xlite v1 BMS is still DOA / seemingly won’t fully boot (only one green light turning ON, impossible to connect to it either thru CAN or USB-C). I’ll just send that one back to Kevin @ENNOID for further analysis (time-permitting).
A V1 with a functional 3.3V LED that does not boot up is likely due to a dead CAN bus IC (TCAN332)
If you have the skills, you can try removing it and see if it boots up.
