Any thoughts as to why canbus bad behavior was only present on one set of motors and not the other?
I initially thought it was a damaged canbus transceiver, and I could easily swap that out as I have same-pin replacements on hand (barring potential warranty voiding, these aren’t my mk3), but the fact that the same behavior was not present on the second set of motors has given me pause.
Nothing specific other than inductive loads can be funny sometimes. Was the misbehaving set of motors lower inductance than the others?
They are nearly identical. We saved the detection results as well. And all motors work fine individually, so nothing to indicate faulty motors immediately.
I’ll be digging in deeper next week, so far we’ve only had a little bit of hands on time to test.
Strange indeed. I’ll be interested in how this plays out. Let me know if there’s anything I can do to help when the time comes.
I’ve probably run through detection on 50 distinctly different sets of ESCs and motors at this point, and this is the weirdest behavior I’ve run into yet. Definitely puzzling. I was happier when canbus was not working, now it’s just weird.
We didn’t pull out the stlink until the end of testing, but testing the same vs 3.60/3.62 will be telling.
@BenjaminF you’re up to bat!
The outcome of that should inform where to go next, but I’m guessing we need to scope the canbus comms and ensure we have expected behavior there next, as @shaman suggested.
Maybe a silly question, but when doing detection for multiple ESCs, does the realtime data / motor commands for detection get sent over canbus, or does canbus just tell the other ESCs to do their own individual detections? If it’s not the latter, then why not?
Individual detections for all the motor related settings. But the settings for battery current and pulley ratio etc are written as config passed over canbus.
The canbus is powered off 5v line. Are the motors sensored? If you unplug sensors does anything change? Possible transients getting injected there through poorly insulated sensor wires.
5char
Will do, unless my gf murders me
Cool. Ill probably try vesc to vesc SWD if it comes to that, and if that doesnt work I’ll swing by and grab that.
This community is great, i appreciate everyone helping out
Like you were inside my head last night. This was one of my initial thoughts when I realized it was tied to that first motor set, but we tested with/without sensors to no change aside from expected ones (cogging on startup when testing each side individually). Both sets of motors had sensors but it had zero impact.
Also worth noting this behavior is 100% reproducible, so we can get some video to better show the strange detection/cogging behavior. It didn’t seem to kick any faults either- @BenjaminF ran into abs_overcurrent at an earlier point but I verified that was settings related.
@Deodand has a valid concern. The CAN bus is extremely sensitive to the 5V rail. Any noise or disturbance from the 5V supply will be reflected in the CAN bus waveforms and can cause missed bits. I figure the noise tolerance for hall signals is higher than that of CAN bus signals which may cause the condition in which the sensors work but the CAN doesn’t. Might be worth putting a scope to that 5v supply as well along with the other things I mentioned
I just want to thank you sincerely for all the energy, abilities, cooperation… you are spending to bring more rationality into the vesc “black box”.
PS: sometimes, I’m thinking about brushed motors
Oh man I just saw this. So fucking cool!
Just did a full discharge of my board with HFI and it was amazing. No worries about doing the little shuffle to get going, I was even starting from a stop on 15% grade hills like it was nothing. This is soooooo much better than unsensored. The noise is nothing compared to BLDC mode. Great Work on this FW.
Just my 2 cents.
I’ve just learned completely how CANbus work mostly because I couldn’t figure out how collision were rejected.
It appears that tge priority goes to the highest ID node !
So, could you test also to put the master vesc at CAN ID 254 and see if it can help ?
I’m really confused since I read that specidication because ir can’t make sesnse that the slave that we put at 1 before the automatic numbering, could receive command from master(ID 0) because it’s keeping polling status on the bus.
The only explanation I have ATM is that’s not really a CANbus comm but something in-between.
You have that reversed, priority on CAN BUS always goes to the lowest ID, so ID 0 will dominate the bus, and so on.
Why is it reversed ?
Why not comply with the standard ? (Which tells are coded on 11bit BTW)
Nodes with lower ID numbers are given priority on the bus, thats the standard CAN BUS convention, and this is what the Vesc follows.
This is largely due to the wire-AND convention, where a 0 bit data is encoded as dominant state ( Can high > Can low) and 1 bit data as recessive state (Can high < Can low). You can read more about it https://en.wikipedia.org/wiki/CAN_bus
any idea how long till HFI on unity?? 
i’m also wondering this.