Hi @Blasto … that’s not our experience. Our testing shows this does matter. I understand it fluctuates outbound (and inbound) if V is related to your RPM. In our case, it’s not. Our system runs constant V.
So, for example, if you sustain V at say 48-52 (our system) and then run 30a inbound continuously (say 1440w) per motor, how long will it last?
Are you saying it can run 48v and 80a inbound ‘all day’, that’s nearly 4000w constant; more than we’ve seen testing anything else.
Maybe that’s the total of both, so similar to 2 x VESC 6 with heatsink at say 2000w constant each.
We don’t have a good setup for loading the system with 4 kW output.
Yesterday I did a ride up a long hill and output total of 2 kW (~ 45-60 amps per motor at around 15-30 volts applied) for around a minute and a half and saw a temperature rise of about 15 Celsius. Video coming soon . Mainly this was limited by the battery current limits and voltage sag of the 10s4p pack.
My guess is that your suggested use case 30 amps per motor at 48V could be sustained beyond 30 minutes and probably indefinitely if you give the motor driver an interface to sink heat into the air (mount it to a metal plate or something). You’re going to run into problems with the power input if you try to output 8 kW, probably would want to up wire gauge and change connector so you could take in 160 amps at 50V… ultimatley only testing can show whats possible in these kind of upper limit scenarios which are outside the range of anything an eskate would use.
Did some reading on MTPA control, just to make sure we aren’t losing efficiency because of wrong algorithm choice. My reading suggests that the motors we are using in Eskate are nonsalient, which is to say the inductance of the motor doesn’t change whether you are along the d or q axis of the motor. This is where I’m gleaning the information from, someone tell me if this seems incorrect. These are equations for MTPA:
If our motors are nonsalient than Ld = Lq and simplifying the second equation for i_d yields 0. Setting i_d to 0 is what we are already doing… so problem that wasn’t a problem solved?
Setting isd=0 means that you operate at constant flux controll till you hit i_max. This method is more dynamic and is usually used in industrial aplications. In Electric mobility vehicles you would rather eliminate copper losses by sacrificing some responsiveness (moving i_sd is slow…). That’s why MTPA is used.
Regarding field weakening. The problem is that at higher speeds we would loose braking torque. On electric cars it is ok because of the mech. brakes, but on our application not…
MTPA was on Benjamin’s ToDo list. I guess it is way more complicated to code than it seems…
Based on what I have read it seems that MTPA for the nonsalient motors we are using is equivalent to setting Isd=0, Can you point me towards something to read on the topic that would suggest otherwise? Thanks!
I saw that there is some new software to go with this to make setup easier. I’m assuming this is computer software. Is there a matching IOS/Android app to go with it or will it be compatible with existing Apps or both?
@Colydog AFAIK whatever software they create for this will be open source. So like all Android apps out there for VESC programming, it will likely be made by a user here. Although I think that will only be possible if it is open sourced.
I was just looking at that and thinking about a group buy for EU.
comes to about €180 each with 21 plus orders and free shipping from China to EU.
Rough duty and VAT added on plus EU shipping would bring them to about €230-240ish delivered within the EU.
Not too bad considering buying just one with VAT added at the standard listing price would come to about €280
They said these world be ‘competitively priced’. The pre-sale price is great, but the price after that, really? That’s like $90 more than getting two singles. How is that a competitive price… Especially if one side breaks… well we know the concerns if/when that happens.
. Mainly this was limited by the battery current limits and voltage sag of the 10s4p pack.
