Lishui "Open Source Firmware" project / KingMeter 5S

No, on master everything work flawlessly regardless of voltage! :)
Would you suggest which priorities I should lower? For now all are set to 0, 0 which is the highest, right?
 
If you change pids do you have to rerun the the autodetect routine? I have motorcurrent max now on 50 amp. Battery current max on 15.000 what would be the de max safe value for battery current max? I have 17,9 48v battery and 12a rated and 25A max current controller and 750w motor. I use my scooter for mtb trails in the woods so can use all the power i can get.

My display sticker says
apt 800s A0348 LC2.10 V1.3DW cant get debug working on it. could this be apt 1.3 protocol?
 
Last edited:
If you change pids do you have to rerun the the autodetect routine?
No.

what would be the de max safe value
That's your own risk. The maximum, that the ADC can read, are about 75A motor current. (2048*38 in mA, 38 is the cal_I factor)

For the display protocol: as I said before, listen to the bytestream it sends, then we can see, if it is something known.
 
UART, Exti, timer 2 and timer 3 can get a lower priority.
Hi,
I modified interrupt priorities as per your suggestion and still ending up in E30 after power on at 48,6V.
Below are my interrupt priorities and debug session results - it still sits in error handler :|



1743716226257.png
main.c
HAL_NVIC_SetPriority(SysTick_IRQn, 0, 0);
HAL_NVIC_SetPriority(DMA1_Channel1_IRQn, 0, 0);
HAL_NVIC_SetPriority(DMA1_Channel4_IRQn, 0, 0);
HAL_NVIC_SetPriority(DMA1_Channel5_IRQn, 0, 0);
HAL_NVIC_SetPriority(EXTI0_IRQn, 2, 0);
HAL_NVIC_SetPriority(EXTI1_IRQn, 2, 0);
HAL_NVIC_SetPriority(EXTI2_IRQn, 2, 0);
HAL_NVIC_SetPriority(EXTI9_5_IRQn, 2, 0);
HAL_NVIC_SetPriority(EXTI15_10_IRQn, 2, 0);

*msp.c
HAL_NVIC_SetPriorityGrouping(NVIC_PRIORITYGROUP_4);
HAL_NVIC_SetPriority(MemoryManagement_IRQn, 0, 0);
HAL_NVIC_SetPriority(BusFault_IRQn, 0, 0);
HAL_NVIC_SetPriority(UsageFault_IRQn, 0, 0);
HAL_NVIC_SetPriority(SVCall_IRQn, 0, 0);
HAL_NVIC_SetPriority(DebugMonitor_IRQn, 0, 0);
HAL_NVIC_SetPriority(PendSV_IRQn, 0, 0);
HAL_NVIC_SetPriority(SysTick_IRQn, 0, 0);
HAL_NVIC_SetPriority(RCC_IRQn, 0, 0);
HAL_NVIC_SetPriority(ADC1_2_IRQn, 2, 0);
HAL_NVIC_SetPriority(ADC1_2_IRQn, 0, 0);
HAL_NVIC_SetPriority(TIM1_UP_IRQn, 0, 0);
HAL_NVIC_SetPriority(TIM1_TRG_COM_IRQn, 0, 0);
HAL_NVIC_SetPriority(TIM1_CC_IRQn, 0, 0);
HAL_NVIC_SetPriority(TIM2_IRQn, 1, 0);
HAL_NVIC_SetPriority(TIM3_IRQn, 2, 0);
HAL_NVIC_SetPriority(USART1_IRQn, 1, 1);
HAL_NVIC_SetPriority(DMA1_Channel5_IRQn, 1, 0);
HAL_NVIC_SetPriority(DMA1_Channel4_IRQn, 3, 1);

1743716247412.png
 
still ending up in E30 after power on at 48,6V.
Strange, you would have to compare the master with the sensorless branch in detail. One difference is for example, that the regular ADC is triggered with 8kHz by timer3 in the master. In the sensorless branch it's triggered with 16kHz by timer1. (as far as I remember ;))
Perhaps you can ask at mikrocontroller.net for help. Some strange guys there, don't care about them. In most cases I got important hints there.

regards
stancecoke
 
Last edited:
Stancecoke, would it be possible to compile this firmware to be flashed on a vesc? Might sound ridiculous, but I sincerely prefer the simplicity of your code. Main reason is that it's easier to understand and boots faster; plus nowadays vesc-clones are acutally easier to be sourced than lishui's. Spintends' are a great value in my experience for ebike build.

The idea would be to use hw configuration files a la vesc that could be loaded into your code during compilation.
 
Of course it would be possible to port the code to the VESC hardware, but EBiCS is optimized to run with 32kB flash memory and without a floating point unit. The VESC hardware offers much more possibilities.

Why do you think it is easier to source a VESC than a Lishui?! Many VESC derivates like the Flipskies are crappy, have no EBike suited housings, are expensive for that what you get. The Lishuis are made for EBike use, have excellent hardware with many measures to meet the EN15194 requirements and are cheaper than most VESCs.....
 
Last edited:
Of course it would be possible to port the code to the VESC hardware, but EBiCS is optimized to run with 32kB flash memory and without a floating point unit. The VESC hardware offers much more possibilities.

Why do you think it is easier to source a VESC than a Lishui?! Many VESC derivates like the Flipskies are crappy, have no EBike suited housings, are expensive for that what you get. The Lishuis are made for EBike use, have excellent hardware with many measures to meet the EN15194 requirements and are cheaper than most VESCs.....
I share your opinion on flipsky - have one here and regret it. But honestly, the spintend ubox single I just got beats all the controllers I had before, for about $100: no potting to remove, no soldering on the pcb to be done, ok hardware with phase filtering and a very handy ignition header, good cooling capacity and it fits into a 66*43 mm alu enclosure that you can buy online.

It comes with an interesting design choice of 2 layers: one for the microcontroller circuitry and one for the power circuitry (see pictures) which should be beneficial for heat management and future repairs.

Maybe I'm getting old, but after 8 years of fighting with cheap chinese controllers, I'm just happy the thing works. All I have to do is drill the holes into the cap of one of my enclosure, use some rubber grommets and plug in all the wires. And of course program it... Having learnt to use your code, I got frustrated with the vesc and was looking for something simpler. Nevertheless that Lisp scripting is really starting to grow on me!
 

Attachments

  • 1.jpg
    1.jpg
    575.5 KB · Views: 7
  • 2.jpg
    2.jpg
    540.8 KB · Views: 6
Maybe I'm getting old, but after 8 years of fighting with cheap chinese controllers, I'm just happy the thing works
What is your problem with the "cheap Chinese controllers"? This spintend ubox thing is a "cheap Chinese controller" also ;).
I wonder if it would pass an EMC test, as I see no ferrite beads or similar on the logic PCB, to filter signals properly....
 
Last edited:
What is your problem with the "cheap Chinese controllers"? This spintend ubox thing is a "cheap Chinese controller" also ;).
I wonder if it would pass an EMC test, as I see no ferrite beads or similar on the logic PCB, to filter signals properly....
Not sure how emc would be an issue considering the double aluminium layers, but I get your point, though i woudn't consider a hundred bucks to be cheap. In comparison to the first KT controller I got 8 years ago, this is definitely an improvement.
 
Back
Top