Update on the pre release Version
Although initial tests with a sensor less motor were successful, I ran into trouble when testing the vesc with a sensored onewheel motor. Hall sensor 3 always stayed 0, therefore the motor was recognized as sensor less. I figured out that Hall 3 was shorted to gnd. I followed the trace on one of the unassembled spare boards and found this:
Unfortunately, this trace is not accessible on an assembled VESC and the Pin is routed over a via from below the STM32, so no chance to fix it on an assembled FOC KING, without removing the pill. I did not want to remove the pill, too much pain.
My workaround was to assign Hall3 to a spare pin, I chose PC13 which is not used and accessible on the pill. Re-built the binary with adapted hw_FOC_KING_core.h.
It would work and merge the code, but the maintainer may not be able to review the changes in any decent human-consumable way. It would likely be an almost blind merge or require extensive documentation from the submitter, greatly complicating and lengthening the process, and it doesn’t sound like @jens_overby has a lot of extra time to devote to any of that. And if Jens is going to approve blind merges, then they might as well make the person a maintainer on the repository, so they have -zero- time commitments going forward.
I was thinking about the imu situation, what if we added pads on the back of the board for an imu piggyback board, i will add some screenshots later, but I do something similar with my vesc express board here I have pads for the esp32-c3 supermini on the back and stuff assembled by jlcpcb on the front. I add the supermini myself. I am thinking 5 pins on each side would be sufficient for power i2c and spi.
That would work but as die IMU takes very little space it would be much easier if it was on the mcu pill. Assembly process is complicated enough already. If we find a part that can be sourced for the next couple of years, I think it would be better to integrate the IMU as it was with the bmi160.
It is supported, i’ve used it as external imu for a bit on my first ow build, however there are not many success stories with it, people usually had some sort of issue, but that could be caused by it being an external imu.
I am trying to use UART to read out some vesc data, but it doesn’t seem like the data packet is constructed correctly. I can get the FW version alright, but when I try to get the data package (i.e. current, temp, rpm, duty cycle, etc), I am not getting the entire packet (it is supposed to start with 2 or 3, and end with 3, but the program never read the 3).
Seems unlikely any of this would be mod’d.
I suspect It might have varied across vesc fw version though. are you looking at the same version of the vesc code that you’re running?
I was reading through the bldc repo by vedderb and it seems like they are still using 3 as the stop byte. Plus, if I try to get the FW version, the packet seems fine ending with 3 and I was able to unpackage that into readable data, just not the VESC values.
I suppose I can try recompiling the FW using the fwconf in the repo and vedderb’s bldc fw source code.
The only part that differs from vedder git is the specifig hwconfig files. I compiled 6.05 FW and it works, but I havent tested Serial communication. I don’t see why it should not work, or behave differently from other vescs with the same fw version.
I was digging through the FE source code yesterday and found that the controller no longer processes the get values command, instead they only read for the get values selective. It doesn’t explain for the weird packet I’m reading but it makes sense that I’m not getting the values I wanted. I will edit the arduino lib for uart comm and see if that does anything today.
