HESC V1 150v 600Amp VESC based motor controller

[j bjork]

For those here that dosent read my yamaha thread, I will post basically the same thing as I did there.
I have a CL1400 and a QS180 90h, early model with hall sensors.
There has been problems from the start to get it running properly, and hackey thinks that it all should be solved with changing to encoder instead of hall sensors.
I get that it is better, but I am not convinced that it will solve the issues.
What do you think?

There has 2 problems that I thought were the same or related, but maybe the weren't.
1: The small stutter/hesitation at low speed when it switches from hall sensors to observer.
2: A stutter that stays over the rpm range, a lot of lost power and rough running.

1 was probably solved with some tuning and the beta fw 6.05

2 started the second time I was riding it on a track, I noticed the rough running and went back home.
At home it was gone, and the bike worked normal again.
Around that time we did the switch to 6.05, tuned it a little at home and it seemed fine.
Tested more, after a while the problem 2 came back. It came more often, and now it seems to be constant.
Eventually I tried doing a motor detection again:

The saved values with 2,8mOhm and about 65uH should be about right, 600mOhm etc. not so much..
It looks like it is time to change back to the fardriver, or what do you think?

 

[JRP3]

Have you tried detecting it again but using the app? Do you see the same values in the app?

 

[pwd]

Does that entail something more than just being on the same wifi connection? I tried connecting as shown in this video and the laptop does not show the phone as a possible connection.

You may have to enter the IP address of your phone manually into the PC Vesc Tool. The IP address should show up on the phone when you enable "Wireless Bridge to Computer (TCP)"

 

[JRP3]

As the address for the TCP client?

 

[eee291]

It looks like it is time to change back to the fardriver, or what do you think?

Could you show me all your settings? Or send a motor config file.
I also had issues with sensorless and after trying some settings hacked immediately recommended the encoder, but after some fiddling I managed to get the motor spinning much faster.
Can't promise anything though.

 

[j bjork]

Encoder is already on the way, the problem is I dont think it will help.
I mean, can there be anything else than a hardware problem in the motor, controller or phase wires when I get 20 times the phase resistance I am supposed to?
I dont think it is the motor or phase wires.. Hackey said earlier that if there was a problem with one phase (like a bad connection or so) there would be a fault code for uneven current between the phases.
I dont want to keep waiting. I havent been able to ride for weeks, and soon it is time for a big competition.

 

[j bjork]

When I do the motor detection I set amps, frequency and dead time compensation according to hackeys video, not like in the file. See pictures:

The same way I did it when it worked too. I can get induction close to the right value sometimes, but resistance is always out there with 500-600+mOhm

 

[eee291]

Looking at the current settings I would try the following.
1. Run the Setup Motors foc from the welcome screen, personally I get bad values from manual detection.
2. Increase sensorless ERPM in the Hall sensors tab.

3. In the advanced tab I would play with the following settings:
Current controller decoupling, Observer type,
MTPA Algorithm mode and Speed tracker position source.

This is what my settings look like running just sensorless (4Kw motor)

 

[pwd]

As the address for the TCP client?

Correct, use the IP address of your phone as the address under "TCP Client" on the PC VESC tool.

 

[j bjork]

Thanks eee291, but the problem is "solved". I got hold of Hackey and he played around with it. Eventually he confirmed that it was a dead phase in the controller.

 

[eee291]

Wow did not expect that, is he offering a warranty replacement?

 

[j bjork]

Yes, he said he will send a replacement soon without any fuss
You would sure have been reading about it here otherwise..
I messed with it as little as possible myself, just to make sure I could not be blamed if there would be any problem like this.
I saw some other guy blew up one of the smaller ones when messing with HFI

 

[JRP3]

Correct, use the IP address of your phone as the address under "TCP Client" on the PC VESC tool.

That worked. The real time data reaction isn't smooth when connected that way compared to the USB connection, I guess because of delay.

 

[pwd]

That worked. The real time data reaction isn't smooth when connected that way compared to the USB connection, I guess because of delay.

Glad it worked. Right, the data has to go through two paths (Bluetooth and TCP); so that is likely what the RT data isn't that smooth compared to USB.

 

[eee291]

There is no hard limit, you can set it so high that it will burn itself before the overtemp even kicks in.

 

[Hummina Shadeeba]

There is no hard limit, you can set it so high that it will burn itself before the overtemp even kicks in.

He was answering my question I removed to keep it on topic. So can download any firmware?

 

[eee291]

you will have to ask Hackey for a firmware file as they don't seem to be added to the vesc repository yet.

 

[ddosoff]

I am continuously asking them for source code of hwconf to compile my app without any reply.

Please share hwconf files to make it possible to compile custom VESC application.

Thanks.

 

[JRP3]

Anyone get temperature sensing working with a QS motor, and if so what sensor type did you enter? There is a list of different choices but I don't know which one is correct, if any.

 

[pwd]

Anyone get temperature sensing working with a QS motor, and if so what sensor type did you enter? There is a list of different choices but I don't know which one is correct, if any.

On my QS260 hub I'm using KYT83/122, it may vary depending on which motor unit you are using. I went back to the page I bought the motor from and it listed the temp sensor there.

 

[JRP3]

Thanks, mine has the same sensor, don't know how I missed seeing it.

 

[Hummina Shadeeba]

With the cl350 I’m getting overtemp shutdowns after short periods and not much current.
Set to 85c
The temp sensor response time is under 2 seconds which is nice but maybe too nice

Here’s amps (I'll add motor amps or overall wattage later), temp, time, and duty cycle. You can see like 35c temp rise in under ten seconds.

(Last two pics are a different test with quicker throttle setting)

 

[Powervelocity.com]

For those here that dosent read my yamaha thread, I will post basically the same thing as I did there.
I have a CL1400 and a QS180 90h, early model with hall sensors.
There has been problems from the start to get it running properly, and hackey thinks that it all should be solved with changing to encoder instead of hall sensors.
I get that it is better, but I am not convinced that it will solve the issues.
What do you think?

There has 2 problems that I thought were the same or related, but maybe the weren't.
1: The small stutter/hesitation at low speed when it switches from hall sensors to observer.

This is typical for most hardware running vesc - I brought this up back in 2020 (Sensorless Transition and Deadtime Distortion | VESC Project) and there has been a lot of discussion about it in other threads. There are a few theories on why this is happening but my personal finding is that it's the hall sensor signal distortion at low speed and high current. And this makes sense considering that halls almost always have long wires bundled tightly with phase wires, but, even if they are not, they do pick up a lot of noise just because the length of the wires. Early versions of vesc designs had low pass filters on hall inputs but then removed to allow easy compatibility with other types of sensors, etc. I've pretty much resolved the issue by re-introducing the filters and the issue has been since long gone. And yes, another way to fix this is eliminate the hall sensor but then you can't use most motors as is. Kind of a pain.

2: A stutter that stays over the rpm range, a lot of lost power and rough running.

The roughness while you are running on hall sensors, right until you reach the eRPMs transition threshold. At this transition a few things may happen:
- You temporarily lose power, you can fill a thud, but the observer successfully picks up (best case scenario)
- You lose power and get overcurrent or another fault
- You lose power, overcurrent and the controller is fried

1 was probably solved with some tuning and the beta fw 6.05

Maybe. Maybe not.

2 started the second time I was riding it on a track, I noticed the rough running and went back home.
At home it was gone, and the bike worked normal again.
Around that time we did the switch to 6.05, tuned it a little at home and it seemed fine.
Tested more, after a while the problem 2 came back. It came more often, and now it seems to be constant.
Eventually I tried doing a motor detection again:

This is another typical issue for vesc and/or rather FOC altogether. As the motor's stator warms up, the copper winding resistance changes (goes up). Correct resistance value is important for FOC operation. I think as of 5.02, vesc has a temp compensation method for this, however, it relies on good motor temperature readings. Most Chinese motors, like qs, etc. use PTC 1k or so type of thermistors and most vesc hw implementations use 10k divider input for motor temperature reading. This combo yields pretty inaccurate motor temperature reading, so the whole compensation thing doesn't work reliably. A possible solution would be replacing the motor thermistor to NTC 10k but, again, this requires opening up the motor, etc., it's a pain. What I ultimately did was designing a circuit to dynamically change the thermistor divider circuit based on the type of the thermistor selected, and therefore, making motor temp readings accurate. This can't be fixed in the software only, so it makes sense you get the same result regardless of the firmware version.

2.8mOhm of resistance on large heavy motor like qs180 doesn't look anywhere right, as well as 64mH of inductance. Both values should be way higher. This motor will run rough or will not run at all if the values are some much off. The problem of FOC detection is the whole separate story. In brief, the detection results can vary quite a bit across various hardware and voltage spectrum, so detection routine can't be just copied from one hardware to another without proper adjustment.

The saved values with 2,8mOhm and about 65uH should be about right, 600mOhm etc. not so much..
It looks like it is time to change back to the fardriver, or what do you think?

 

[j bjork]

Thanks for the reply, but as you can see in the other posts in the thread it is solved since a few months back. Problem 1 works after some tuning, I think it was mostly at what rpm the transition happened and dead time compensation. I am on 6.02 now, so 6.05 dosent seem to have anything to do with it.

2 was a hardware fault in the controller.

Are you sure about the motor? When I have measured myself I got 5mOhm phase to phase, so about half of that for one phase seems right to me. Same thing with inductance, if I remember correctly I got 100-130uH when measuring phase to phase. So I suppose half seems right for one phase?
When I tried to tune sevcon and used about 130uH it worked, but got low power in the chart. 65 also worked, and gave better power in the chart (and reality). I think a z-force 75-7 has about half of this inductance, at least that was how it was in the sevcon maps I looked in.

 

[Powervelocity.com]

You can certainly play around issues by tuning values and it can work for a particular situation. The sensorless transition issue can be mitigated by pushing the switchover eRPMs higher when the power demand during acceleration tapers out the switchover is not as dramatic. It may work good enough for one motor and maybe for a certain operation scenario but as soon as get to the next setup, you are at square one. Chances are if the use case is different, that exact solution or value will not work the same. The permanent and repeatable solution is to fix the issue as the core which is noisy hall signals.

Regarding #2, the stator resistance value floating with temperature is something that affects FOC operation. It's usually motor rough operation as it gets warm/hot. Again, the issue may or may not be immediately evident and can be worked around, for example, by running lower current or going with a larger motor, therefore reducing the temperature drift. FOC is tricky in a way that it may run fine on the bench. But things change as you start applying the load. Temperature is yet another variable, a moving target to deal with.

The only way I can be sure about your specific motor parameters is by measuring them. All I am saying is that 2.8 or 5mOhm is an unusually low value for that kind of motor.