Unfortunately, in this form, the automatic calibration undermines the usability of the firmware. This week, while actively riding, I turn the display on and off 20-30 times a day.
)
We have a number of motors that we cannot work out in a diagnostic way what the torque sensor is doing. Is there anyway we can have a diagnostic routine that changes the main display central large figure reporting say torque sensor, motor temp, board temp, volts, amps ( the small say calories display is too small to read whilst cycling ).
The EBiCS firmware cuts the power after four upcounted backwards PAS pulses. The backwards counter is increased/decreased with every PAS pulse. If you move the pedals back and forth very slightly because of a tremor caused by exhaustion, the counter doesn't go up to four, since it always counts up by 1 and then immediately counts back down by 1.
Sure, we can show what ever we want in the display fields. We just have to define a trigger to switch to the diagnostic mode. Maybe a similar "code" as used for the offroad mode.
Everything worked, thanks!Besides the config.h you have to edit the linker script also to set the right start address offset for the bootloader:
BAFANG_GD32F303RCT6/ldscripts/gd32f30x_flash.ld at 7c1d285ea0c4db5d25b163f17ad0d10177475837 · EBiCS/BAFANG_GD32F303RCT6
Firmware for Bafang E-Bike controllers with GD32F303 processors - EBiCS/BAFANG_GD32F303RCT6github.com
And of course, you have to add the 32byte header to the bin file by running the relating python script from the documentation folder.
The latest code is always on the repo. I recommend to use GitHub Desktop to syncronize your local files with the repo. If you want to change the code yourself, it would be even better if you fork the repo to your own GitHub account and commit your changes to your fork. If you think your changes are worth to be merged to the origin EBiCS repo, you can do a pull request.
Of course, after the test, I went back to the release version 0.008. Comparing the release version with 0.0085, I can highlight the following points:So simply don't use this version
Perhaps it's better to delete it from the repo.
Unfortunately, my battery isn’t well‑suited for this because it’s built with low‑current cells.
Hm, I don't understand your post.
Yes, unfortunately I didn’t get around to learning English.
Yes, it’s a good feature. I like it in versions 83+.
On startup — no. However, any short idle period causes incorrect calibration. Why? Because most riders rest their leading foot on the pedal while waiting. I’ve never had thermal drift. But due to recalibration, I had to restart the motor every time after a pause.
therefore, I've deactivated it with the last commit and deleted the 0.0085 bin files from the repo.
Of course, the motor will start with an Override threshold of 1mV, but without load nothing more should happen, the idle current is less than 1amp normally. So I guess the controller has been defective before already.
I’ve read your thread and followed the dramatic debate about trademarks and the project overall. It’s an interesting project. But even if it were finished and fully functional, in my case it’d be much simpler to just buy a bunch of original controllers for $60 each.
I’m sure it’s not that simple, but I can’t prove it
As far as I have analyzed, the controllers from the M510 and M560 are exactly the same. The main difference is the metal gear of the M560....
Hm, I don't know, if he read the Wiki. I think, if you read (and understand) it, you won't have the idea to set it lower than 750...
github.com
I ask you not to take this lightly. When you started porting the EBiCS code to M560 controllers, we encountered many cases where fuses and BMS protections would suddenly trip.
Maybe, as far as I remember I've increased the deadtime some day. Of course there are various hardware versions and they will differ a little. But the latest revision seems to share the same PCB at least, as M510 or M560 are marked manually on the PCB
There is a very detailed thread in the EMTB forum:
This would be easy to check.
Have you tried to reset the trip in the display?
static package1(packet) { // Data Block 1 (Mileage/Speed)
if (!packet || !Array.isArray(packet.data) || packet.data.length < 8) {
return { parseError: true, error: "Invalid data length for Display Data1" };
}
return {
total_mileage: (packet.data[2] << 16) | (packet.data[1] << 8) | packet.data[0],
single_mileage: (((packet.data[5] << 16) | (packet.data[4] << 8) | packet.data[3])) / 10,
max_speed: ((packet.data[7] << 8) + packet.data[6]) / 10,
};
}