Hey! Thanks again for confirming the can bus wiring. Finally borrowed a working rated vesc (stormcore 100d) to test after the doa solo and everything connected and ran like a champ! I was feeling pretty gun-shy with how weird the solo was acting and it was really nice to at least temporarily take advantage of the xlite v3 too. 
@ENNOID hey having issues with the xlite v3. It seems to work fine standing alone but connecting it to can is causing dropouts - full throttle and brake control loss for up to about 2-3 seconds.
As this presents as a remote signal loss issue i have tested thoroughly with the vx4, zmote, and puck in ppm mode and the vx4 in uart/ppm/ppm&uart and all three remotes have no effect on the dropouts with line of site from the remote to receiver. (Recever mounted inside/ external antenna/ external receiver in a colostomy bag on top of the deck). There is no issue with any of these remotes.
I used both the d100s from makerx and dual skp solos and the issue is independent of of the vesc.
No faults were thrown at any point, i have been logging all my test rides with the megan.
The can network cabling is very robust, i have reworked it three times in order to create the best possible connectivity using twisted pair for the canh canl and isolating as well as possible to prevent interference and get 99-100% communication with all devices on the network except the xlite which is in the 70-80% range with a 10tpi data cable and less than 60mm length.
I tested every combination of connected devices (d100s, skp solo, megan, xlite, tja1050-esp32) and i get cutouts only when the xlite is in the network.
The xlite is on FW6.1beta2 which is what it shipped with to me.
How many devices are powered by your VESC aux power 5V and 3.3V? Other device likely donāt have an isolated CAN, but XLITE needs a 5V_CAN and CANGND power source.
Likely that your 5V & cangnd are fluctuating too much when you are pushing the vesc or during hard braking. Other devices are probably vesc gnd referenced and xlite is battery gnd referenced, this can create some apikes on the can bus too.
It could also be something else, you can try different baud rate, update to latest 6.02 firmware.
1 Like
With nothing but the xlite and the vesc i was getting cutouts. No other devices on the can. The solo is rated to 1 amp on the 5v rail. Only other device was a ppm receiver powered from the other vesc and the receiver does not connect to the can. The solos do not share a 5v and are discrete single motor esc and only share a heatsink for space.
I will update the firmware
2 Likes
using 125kb/s instead of the default 500kb/s could possibly help and will likely be enough in speed for your needs
Also, there are some VESC CAN bus setting that could overload the XLITE, try reducing the frequency at which the VESC talk on the bus. The computing power of the XLITE is quite limited compared to the VESC
I never heard of such cuts when using a single VESC. Maybe there are collision/overload with the xlite when two vescs or more devices are talking on the bus. The only other report I remember about those cuts was reported by a company using 6 VESC+6BMS+main controller on the same bus. They somehow fixed the issue, but I donāt know if it is via firmware or hardware changes
There are a few others thing that I could investigate/try in the firmware if you cant solve your issue.
One of the measures i took initially but was partially fruitless was to rename the can id for all connected devices as can address designates the priority of the device messaging on the bus, the lower the address the higher the priority as well as allowing lower number designations to talk over higher numbered addresses.
By default vesc self address two or three digit addresses (11/26/70/101 etc) and bms on vesc architecture are assigned 10 as the static address. I change the addresses of the VESCs to lower numbered addresses to 7 & 5 and the xlite i left as 10 and all other devices as 16 or higher. As addresses of 7or less differentiate sooner in binary and the address differentiation is supposed to cause higher addressed devices to cancel send and wait for the next transmission window.
it was my hope to force the ESCs to talk over the xlite and prevent it from possibly overriding the esc messages on the network. All other devices I used in testing (i tested every possible combination of devices on the network) had higher addresses to force a lower priority on the network. I was successful in getting noisy devices (megan on maximum logging fidelity ) to work without interrupting vesc communication as long as the xlite wasnāt connected
As testing involves some not insignificant risk of injury, I canāt really justify flying down the road with a known issue just to see if it kills me as an option right now. In testing i was able to reduce the occurrence from once every few minutes to less than once in 5 miles (average speed of 12-20mph) by arranging the network addresses as above as well as using very well isolated cabling.
though I didnāt test those improvements independently and canāt be certain which had the greatest effect or if one had no effect. Troubleshooting is faster if i can isolate by half and i was trying to isolate the issue quickly by this point - i have been working on this since October because of the testing being weather dependent.
1 Like
Quick question:
Have tou tried to disable VESC BMS protections SOC & TEMP in VESC-tool? Just untick those checkbox on your VESC in the BMS section and try again. I think it should solve your issue based on the new info you provided.
I initially assumed that you had a sofisticated testing methods for testing CAN bus reliability, signal integrity, packet collision etc. If testing is done in the field with the user experiencing the cutoffs, we cannot really assume that the XLITE is creating noise on the bus or create any CAN bus signal issue. It is likely more related to the additionnal data the VESCs are receiving from the XLITE and how they react to this extra information. . We already asked Benjamin Vedder to improve the BMS protection or disabling it by default. For some reasons, he has not moved much so far on that topic.
This is the can analyzer I am using but it doesnāt log and Iām low on the learning curve:
https://www.amazon.com/gp/product/B0B1L4MTCM/ref=ewc_pr_img_3?smid=A1YP59NGBNBZUR&psc=1
I donāt have an easy way to log can data without a laptop and bench testing doesnāt present the issue, it is only a random occurrence during operation. Short of setting up a dyno or riding with my laptop. im working on an esp32 to take logs when riding but its not ready yet
I have not tried disabling the BMS tab SOC and TEMP protections. Is there a simple way to disable the can communication via the Bluetooth connection to the app? would be nice to turn it off if i get a cutout so i can cruse home safely
What is the expected fault that the BMS over temp or soc limit would create? Would it not cause a fault or cause one that is exempted from the Fault stop time settings as all cutouts i have experienced have not caused any fault to log in metr or vesc as well as causing dropouts far larger than my fault timing would allow. I have even run with no fault time temporally and i was experiencing the same issues just to see if it would have an effect but no luck.
have also no ever exceeded the temp limits set by default nor approached the soc limits so maybe this is just not implemented correctly in vesc or something?
once i have my logger built i should be able to find the root of this or at least come up with a work aroundā¦ maybe
Manā¦why not trying what I just told you?Just disable those settings im vesc tool and you will be fine.
A lot, I mean a lot of people in the onewheel community disable those parameters, use CAN bus between their XLITE and VESC and never get cutoffsā¦
Surfdado even made a video due to this a while ago:
No faults are reported in VESC tool, just cutoffs. It usually happens when SOC is purely based on ācell voltage lowā like VESC BMS and older XLITE firmware. I improved SOC on newest firmwares, so those cutoffs are less likely to happen when those settings are enabled. SOC is now using vesc ahCounter data combined with cell voltage correction when vesc current is low.
Benjamin hasnt worked much on those details and the behaviour is a bit rough.
1 Like
Thanks for the help isolating this.
I am going to try those settings. This issue - kinda a big deal - was never mentioned or brought up in any of the text on your site, never spoke of on this thread, not referenced on this site: I just assumed you were talking out of your ass a bit here and trying to be helpful and that it wasnāt a known issue. There is literally no mention that comes up in searches about these settings needing to be toggled unless you include the word yeet 
and only that one video.
Ive also only ridden my battery between 90 and 70% soc so it would be a pretty big voltage sag/temp spike, the xlite has never had the buzzer go off for low soc or temp. Im sure you can understand why running at 3.4v per cell on a floatwheel battery thatās 1p or 2p vs an 18s8p battery at 4+v per cell running low amps might not seem to me like the same issue at first glance. I HOPE that disabling these settings resolves the issue but i donāt trust it to not yeet me like those two guys from the video.
Arnt you a bit curious to see what is going on? This isnāt the first time Iāve had issues on can connected xlites (v2 12s that this is the replacement for) but because Iāve got a reactive lighting project that will be using can data from the vesc, Ive already got the supplies to program up a logger.
Hopefully this issue is resolved by the settings and firmware but Iāve got nothing to do while waiting on the rain to dry and little to no trust ĀÆ_(ć)_/ĀÆ fool me once and all that - until my setup with the xlite proves itās reliable ill be cautious and collect as much data as possible.
3 Likes
Your issue with the XLITE-12-V2 was likely due to a bad handling of CAN bus. V1 & V2 were subject to CAN bus damages when mishandling CAN bus during the VESC pre-discharge/anti-spark sequence. Most other CAN bus device that connects only to a VESC are not subject to such damage due to different physics in play.
V3 & V4 have inherited of an isolated CAN bus IC due to the fact that many users were not following the instructions.
Again :
- update to V6.02 firmware which is non-beta BTW, some 6.01 beta firmware version had weird SOC behaviour
- Disable those VESC settings
- Report back if you are still having issue
There are many things outside of my control. Those settings fits well in this category. Sure I could do better, but honestly I just do the best I can, I think that Iām also quite supportive/responsive to feedback
tbf
your documentation is pretty garbo
4 Likes
Yep i agree it could be better, I mean a lot better, but it is 3 pages, but still too long for some people, so Iām stuck. maybe videos.
Initially it was needed, but not really anymore.
If someone is buying something as important as a BMS and is too lazy to read a few pages of decent documentation, they should not be buying your product, especially when your product has a somewhat complicated, and seemingly unintuitive setup. Stuff like this needs some pretty deep documentation with photos for the idiots that dont feel like reading.
2 Likes
it has evolved a lot since, it is now very straigthforward and easy to use as it should have always been.
And from my past experience, people donāt read, so it must follow the KISS principle keep it simple stupid.
V4 canāt be simpler honestly. V3 still had a complicated balance wiring harness for most.
1 Like
That seems like good progress. Iāve never worked with a VESC bms bc they seem like a nightmare (historically). Main point is lazy end users isnt really a valid reason to skimp on documentation. If 3 pages is enough, thatās fair, but Iām a firm believer in always having extensive documentation, even if actually writing that documentation can be really miserable.
That was also part of the strategy to be honest. I would have preferred to be perfect from the start on all front: hardware/firmware/software/documentation, but things evolves together unless you have the ressources to make everything happen at the same timeā¦
On the other side, creating good documentation might have brought more people not qualified enough to build their own battery, so keeping things a bit hidden force people to do their homework before ordering.
A BMS will always be tricky to install properly because of the many wires and precaution required when building a pack. Teaching this part is not my intention and most issues arise when the pack is poorly constructed and experience is lacking
Small feature request: configurable (turn off/time between beeps) alert for connected charger using xlite onboard buzzer.
Me and I guess a lot of daily PEV users charge their wheels immediately after ride. I often forgot to disconnect the charger, leaving it unnecessarily connected all night. Usually I hear that fan in the charger stopped, but the batteries still charging / balancing and later I forget about it.
Vesc float package has similar feature (beeps every 5 minutes when not used for 20 minutes) for controllers (for those without momentary buttons and autoshutdown) and itās proven to be very useful.
3 Likes
That sounds like a nice feature.
1 Like
I was thinking about someting similar recently and yes, I will try to implement something for next 6.05 beta firmware.
i dont know if it needs to be configurable. i guess that one second beep every 5 minutes would be ok.could have both alarms set for soc below 5% and when charge is complete.
1 Like