FLIPSKY new 20s 100A tiny controller (vesc based)

[afzal]

... It looks like TI's datasheet says 18JD corresponds to INA181A1IDBVR/INA181A1IDBVT, and mouser says 20 V/V so I think we are good with the original setting.

Yes, TI datasheet also says that A1 devices are 20V/V gain.

And if the gain is wrong, resistance detected would have been different by big factor (2.5 & so on)

BTW, 'measure_res' command gives different resistance for different currents, here for e.g. 0.26Ohms @1A, & 0.31Ohms@4A

Let me know if you see any strange performance. We have snow here with temps below 0C so I haven't done much road testing.

Sure, if any thing surprising (positive or negative), I will let you know.

I had to make some changes w.r.t pin configuration to suit my setup here, no load runs fine, would be doing the test ride shortly.

Oh now I can make it the playground & give Trampa VESC the respect it deserves

 

[kubark42]

Here is what Flipsky said when I emailed asking if they could provide the source code

This esc doesn't support firmware update. We have set it before shipping out. Our engineers have done some changes based on vesc, not opening source. Sorry.

That's disappointing, and is downright contractual violation. The GPL is quite clear in their obligation, and if they're not honoring it then it's cut and dried fraud.

Obviously no one should buy this until this issue is resolved. VESC can pursue them legally, but in the meantime anyone who has already bought one of these might have a route to getting a free ESC out of it. If buyers file credit card disputes on the basis of fraudulent goods, then this is very hard for the seller to dispute. Purchasing a VESC means buying both hardware AND software, and they're only delivering one. This leaves the seller on the hook for the full refund plus the price of return shipping plus the fees imposed by CC companies for disputed charges. That'll be a costly mistake for Flipsky.

Done small scale, they'll ignore it but you'll likely get a free ESC because they won't want to pay shipping and duties on something they then have to trash. Done large scale, they change their tune. Either way is a win.

 

[john61ct]

Why would they trash it?

With such a proven lack of ethics likely just gets resold as new.

At best "refurbished" at a discount

 

[chuyskywalker]

Hey party people, does anyone here know if this controller is able to run a led headlight? I have an led that can handle 12-72v. Or do i need any additional hardware to be able to run it, like a dedicated led controller?

No, probably not. It does, technically, have a 5v / 1 amp -- but you'd burn that out on any half decent light.

 

[kubark42]

Why would they trash it?

I guess it depends on whether they feel they'll get a working board back or not. Up to the RMA sender to decide if applying mains to the board beforehand is the ethical response.

 

[afzal]

Here is what Flipsky said when I emailed asking if they could provide the source code

This esc doesn't support firmware update. We have set it before shipping out. Our engineers have done some changes based on vesc, not opening source. Sorry.

That's disappointing, and is downright contractual violation. The GPL is quite clear in their obligation, and if they're not honoring it then it's cut and dried fraud.

BTW, VESC source is GPLv3+, AFAIU, it not even enough to provide the sources (which is enough with GPLv2), they have to provide sufficient details to update the software and cannot block updating it.

I did thought about initiating some action again them at least by informing Benjamin. But then I felt my motive is personal (flipsky VESC was bought on behalf of another person, now with me, I could it use it for risky experiments than doing it on my Trampa VESC), rather than the principles for which GPL stands for.

Obviously no one should buy this until this issue is resolved. VESC can pursue them legally, ...

I think to take on legally, only a person who has bought the unit can testify or be the victim in court. Per my understanding, with GPLv[2,3], it is not necessary to provide the source to anyone, they are liable to provide the source only to one whom they have provided the binary, i.e. in this case some one who has bought it from flipsky, but IANAL.

 

[mxlemming]

What if there is no source? What if they just took the 75300 binaries that you can get direct from vesc tool/vesc project and looked at the linker script to just edit the values in the binary?

This makes more sense than it first sounds, if there's a known good binary, that doesn't crash and burn/whatever, then editing the values in that (and realistically it's probably only the OV/UV voltage, current, default motor settings and name) then you can guarantee good behaviour.

I've hit compile using GCC several times in a row and got different binary file sizes so it's clearly not quite deterministic.

 

[kubark42]

BTW, VESC source is GPLv3+, AFAIU, ...

I did thought about initiating some action again them at least by informing Benjamin...

I believe your understanding of GPLv3 is correct. It arose out of the Tivo debacle.

We pinged Benjamin on the VESC Discord server, and he knows.

What if there is no source? What if they just took the 75300 binaries that you can get direct from vesc tool/vesc project and looked at the linker script to just edit the values in the binary?

If it came delivered with firmware, then there's source. They can just point to the VESC github as the source, and include their linker mods and that honors their obligations (although not if they've modified the firmware in some other way).

Or are you asking about what happens if they use the linker to figure out where to overwrite a specific section with their own independently compiled firmware blob, which is held at arm's length and so is functionally an external executable?

I've hit compile using GCC several times in a row and got different binary file sizes so it's clearly not quite deterministic.

That sounds like either a build which is dependent on the system, or a bug in the build setup-- quite possibly due to parallel build threading, but could in general be due to Makefile setup. Unless the build integrates outside data, such as compiling in a git hash in order to identify the build branch, a single-threaded compile should always return identical data bit-for-bit. It's just following rules and there's no RNG so it will always follow the rules deterministically.

 

[Bucket Residence]

Hey party people, does anyone here know if this controller is able to run a led headlight? I have an led that can handle 12-72v. Or do i need any additional hardware to be able to run it, like a dedicated led controller?

No, probably not. It does, technically, have a 5v / 1 amp -- but you'd burn that out on any half decent light.

Thanks, that's a bummer, i thought i had found a decent controller which fit My space constrained build. Which cable on the controller that has that output? This is what i'm using, standard cheap-o Ebay led: https://www.ebay.com/itm/392626951563 aswell as a rear light with matching specs.

 

[mxlemming]

BTW, VESC source is GPLv3+, AFAIU, ...

I did thought about initiating some action again them at least by informing Benjamin...

What if there is no source? What if they just took the 75300 binaries that you can get direct from vesc tool/vesc project and looked at the linker script to just edit the values in the binary?

If it came delivered with firmware, then there's source. They can just point to the VESC github as the source, and include their linker mods and that honors their obligations (although not if they've modified the firmware in some other way).

Or are you asking about what happens if they use the linker to figure out where to overwrite a specific section with their own independently compiled firmware blob, which is held at arm's length and so is functionally an external executable?

I mean literally opening the binary in a hex editor and changing the hex codes. It is not that hard, I tried this earlier and succeeded - I changed my Vesc like object's binary to have a different name (had to use the same number of digits... I kind of cheated here by using the .list file to find the address of the codes) and searched for the floating point encoding of 450.0 (the abs max current limit I set) using conversions from https://www.h-schmidt.net/FloatConverter/IEEE754.html found a few instances and changed them all to 200 in floating point.

I flashed that image, and amazingly, it appeared to work, connected and when I pulled the default config values in VESC tool, I got 200A abs max. Might have messed something else up, but in principle it is now proven to work.

This is more than a useless oddity, what it means is that if you replicate the pinouts exactly, you can use a binary that has been extensively tested by Vedder himself. This is very useful since I have (as you know from the Discord channel...) routinely messed up the compilation and flashing process to the point that it simply does not work on perfectly good hardware. I have observed different behaviour and stability with identical .h and .c files just different compilation times and no obvious cause (to me, I am sure there is a root cause).

 

[mxlemming]

I know I could have faked this, in many ways, but here you go, evidence I did it.








Total effort... 15 minutes, including writing this, and it still spins fine.

 

[kubark42]

I mean literally opening the binary in a hex editor and changing the hex codes. It is not that hard, I tried this earlier and succeeded - I changed my Vesc like object's binary to have a different name (had to use the same number of digits... I kind of cheated here by using the .list file to find the address of the codes) and searched for the floating point encoding of 450.0 (the abs max current limit I set) using conversions from https://www.h-schmidt.net/FloatConverter/IEEE754.html found a few instances and changed them all to 200 in floating point.

Those are all good questions, and I don't have an easy answer. There's substantial greyness in copyright laws. For instance, it's well-understood that you can't copyright boilerplate definitions, because they're not "creative works". But at what point does a boilerplate definition become creative? For instance, during my dissertation we spent several months to calculate a number to 13 digits: that seems like it would be more protected than changing a current limit to match the published MOSFET specs. This kind of IP stuff is thorny and typically decided by the courts.

In general, if you take a binary and change parts with a hex editor, it would be hard to argue that you're changing the source code. Indeed, you're only changing the compiled expression of the original code and machine generated content has no copyright (the courts have established that machines are not "creative"). So how well the GPL protects here is a function of many things, almost all of which I am not qualified to opine on.

The GPL, like a bike lock, is not invulnerable protection against theft (which, pedantically, copyright violation isn't). It is a deterrent and companies which skirt it risk losing on many fronts, but all too often they escape scott-free.

 

[mxlemming]

I mean literally opening the binary in a hex editor and changing the hex codes. It is not that hard, I tried this earlier and succeeded - I changed my Vesc like object's binary to have a different name (had to use the same number of digits... I kind of cheated here by using the .list file to find the address of the codes) and searched for the floating point encoding of 450.0 (the abs max current limit I set) using conversions from https://www.h-schmidt.net/FloatConverter/IEEE754.html found a few instances and changed them all to 200 in floating point.

Those are all good questions, and I don't have an easy answer. There's substantial greyness in copyright laws. For instance, it's well-understood that you can't copyright boilerplate definitions, because they're not "creative works". But at what point does a boilerplate definition become creative? For instance, during my dissertation we spent several months to calculate a number to 13 digits: that seems like it would be more protected than changing a current limit to match the published MOSFET specs. This kind of IP stuff is thorny and typically decided by the courts.

In general, if you take a binary and change parts with a hex editor, it would be hard to argue that you're changing the source code. Indeed, you're only changing the compiled expression of the original code and machine generated content has no copyright (the courts have established that machines are not "creative"). So how well the GPL protects here is a function of many things, almost all of which I am not qualified to opine on.

The GPL, like a bike lock, is not invulnerable protection against theft (which, pedantically, copyright violation isn't). It is a deterrent and companies which skirt it risk losing on many fronts, but all too often they escape scott-free.

Critically here, if I started with one of Benjamin's images and made the changes as above and supplied them to you, it would not even be possible for me to supply you further source, at gunpoint or otherwise. The true source is already supplied.

 

[badgineer]

Hi

.... Critically here, if I started with one of Benjamin's images and made the changes as above and supplied them to you, it would not even be possible for me to supply you further source, at gunpoint or otherwise. The true source is already supplied.

Come on mxlemming, you're surely playing the devils advocate here for the lulz, aren't you .

I mean, I know editing the binary is not that uncommon, but it is done more to hack some ready made proprietary product (or?). Also, I don't think it's the case here, especially since they gave a black on white response to jaykup: "Our engineers have done some changes based on vesc, not opening source. Sorry."

And the argument that it's for hardware protection and/or something to do with warranty is... unconvincing.
Not releasing the source is ineffective, as you yourself actually told us it would be earlier in the thread. And as you correctly predicted, people have easily figured out how to flash software! Not releasing the *supported* software just makes the situation worse, since people are flashing anyway. There's far better ways to detect tampering for warranty purposes.

I think it's just that they can and probably will get away with it, and they don't give a rats ass about our GPL whining as long as they considering keeping their changes proprietary good for business.

China. As long as the cat catches mice, they don't care what color it is. True story.

The only way they'll stop this practice is if it's bad for business.
Either bad press resulting in bad sales, or some legal action where it hurts, like they can't sell it anymore outside of china (can't really imagine how that could happen).

Br,
badgineer

 

[afzal]

We pinged Benjamin on the VESC Discord server, and he knows.

That is good and thanks.

 

[mxlemming]

Hi

.... Critically here, if I started with one of Benjamin's images and made the changes as above and supplied them to you, it would not even be possible for me to supply you further source, at gunpoint or otherwise. The true source is already supplied.

Come on mxlemming, you're surely playing the devils advocate here for the lulz, aren't you .

I mean, I know editing the binary is not that uncommon, but it is done more to hack some ready made proprietary product (or?). Also, I don't think it's the case here, especially since they gave a black on white response to jaykup: "Our engineers have done some changes based on vesc, not opening source. Sorry."

And the argument that it's for hardware protection and/or something to do with warranty is... unconvincing.
Not releasing the source is ineffective, as you yourself actually told us it would be earlier in the thread. And as you correctly predicted, people have easily figured out how to flash software! Not releasing the *supported* software just makes the situation worse, since people are flashing anyway. There's far better ways to detect tampering for warranty purposes.

I think it's just that they can and probably will get away with it, and they don't give a rats ass about our GPL whining as long as they considering keeping their changes proprietary good for business.

China. As long as the cat catches mice, they don't care what color it is. True story.

The only way they'll stop this practice is if it's bad for business.
Either bad press resulting in bad sales, or some legal action where it hurts, like they can't sell it anymore outside of china (can't really imagine how that could happen).

Br,
badgineer

Tbh, i just hate GPL and the"what's mine is mine and what's yours is mine"attitude. I got really kicked off the other day when I found the entire python source code with the MIT license striped out and replaced with GPL v3 on GitHub. Hopefully that's been nuked by now...

I also hate:
B264 derailing all technical discussions into this debate the second they smell a GPL infringement (which I'm not helping by continuing to be fair)
The way the GPL licence allows manufacturers to shirk their responsibilities to provide a statutory warranty (there are examples of trampa publicly telling buyers they're not getting warranty because they did something like change things in code) (i advocate for me by advocating for warranty on hardware)
The general disposition of the GPL community of "the only licence that needs obeying is ours" (see casainho and the recommending buying fake seggers debate).

I'm sure you're right. Flipsky probably did recompile the code. But GPL is one part of law and there's a ton of safety and warranty related bits of law it really isn't compatible with, which is far more relevant to the 99%.

Why do you think they refuse to release it then if not warranty related? Of course it won't stop me but it will stop the other 99% of people who don't know anything about power electronics. Let's be honest, there's no IP to protect in the header files, none of their time and effort to protect and that's all they'd need to release.

 

[Woly]

I don't care about the software that came in it. It's already been shown it is easy to change.

To me this topic was about whether or not this "tiny" controller would live up to its advertised specs. Even at half the amperage the controller is a bargain.

I'd like to see some more real world tests and discussions about the hardware capabilities rather than GPL rants.

 

[badgineer]

Tbh, i just gate GPL and the"what's mine is mine and what's yours is mine"attitude. I got really kicked off the other day ...

B264 derailing all technical discussions into this debate the second they smell a GPL infringement ....

OK, now I understand
I am of a slightly different opinion... I understand GPL more as in "what is mine is *everybody's*, ..." As in, I really appreciate the HUGE amount of effort that went into the VESC, both Benjamin Vedders own, other contributors, and the huge amount of work he/they built *on top of*. (and there are even bigger impact projects that started like this). So I can't condemn anybody for publishing their work under GPL.

But I also do see the point of more flexible open source licenses.

Regarding fliplsky, I think they implemented some cost optimizations they consider clever / a competitive advantage.
I mean the 75100 is half the price of the their own 7550 / the spinted ubox, none of which can take a 20s battery. So they are a "market leader" of some sorts. I guess they try to protect their competitive advantage.

That's my guess. But it's just a guess.

PS: just noticed that flipsky are not offering 7550 anymore. Maybe the 100$ 75100 has bigger profit margins than the 200$ 7550 had! That would be a really good product to sell.

Br, badgineer

 

[badgineer]

I don't care about the software that came in it. It's already been shown it is easy to change.

Are you sure the "normal Vesc code" works OK on it? somebody mentioned higher current than with the off-the-shelf-custom-code...
Maybe it runs ok-ish but poorly. maybe it blows up under some conditions

Or maybe it' is the *exact same code*, and flipsky only cheaped out on components and stuff and they are hiding it with the "so fancy custom engineering - no way we give it away" masquerade

Br,

 

[Koxx]

it's nice to have doubts about flipsky, but considering how many 'protected' vesc designs they have stolen, i have no doubt.
simple example : A200S https://circuitmaker.com/Projects/Details/Euan-Mutch/A200S-V3

 

[mxlemming]

I don't care about the software that came in it. It's already been shown it is easy to change.

Are you sure the "normal Vesc code" works OK on it? somebody mentioned higher current than with the off-the-shelf-custom-code...
Maybe it runs ok-ish but poorly. maybe it blows up under some conditions

Or maybe it' is the *exact same code*, and flipsky only cheaped out on components and stuff and they are hiding it with the "so fancy custom engineering - no way we give it away" masquerade

Br,

They didn't cheap out on components. Every part in there is well considered and appropriate for the function as far as I can see.
TI op amps with good specs
Low rdson 100Vfets
Sensible (if unheard of brand) gate drives
TI DC DC
All components appropriately specified to cope with the rated power...

Just provide enough airflow and cross your fingers there's no subtle errors.

 

[badgineer]

They didn't cheap out on components. Every part in there is well considered and appropriate for the function as far as I can see.

Hi. Was just a joke . I really do think they did some custom stuff they deem worthy of protection as a competitive advantage. And judging by the volume of products they have on sale and the pace they are developing them, they probably have the engineering skills and experience necessary to do this kind of competitive advantage engineering.

I still think it's a ... lets say "unethical" move not to publish the software and changes. They make a pretty penny off the work that went into the VESC, and off the free publicity the products based on VESC get.
Just calling it "based on vesc" is kinda false advertising if it does not run the VESC code

I would be singing their praises if it weren't for this, instead I'm calling them unethical.

Br, badgineer

 

[jaykup]

Regarding fliplsky, I think they implemented some cost optimizations they consider clever / a competitive advantage.
I mean the 75100 is half the price of the their own 7550 / the spinted ubox, none of which can take a 20s battery. So they are a "market leader" of some sorts. I guess they try to protect their competitive advantage.
[...]
I still think it's a ... lets say "unethical" move not to publish the software and changes. They make a pretty penny off the work that went into the VESC, and off the free publicity the products based on VESC get.

I think badgineer nailed the reason why Flipsky won't release the source code.

Anyway, back to this unit's performance. You can't expect a ton of continuous amps from a small 6 fet controller. The beauty of this device is that it runs the VESC firmware which is extremely configurable and has a ton of addons from the community.

For the uninitiated, here is a short list of 3rd party VESC addons:

• metr (&robogotchi, ilogger) - A powerful web & android data recording device that produces beautiful GPS graphs of each ride that displays motor current, battery current, voltage, motor temp, esc temp, speed, etc. Metr's website now has an LTE and GPS enabled model.
• Davega display - A UART based display that can display all VESC telemetry in real time including range estimates & BMS data
• FlexiBMS & Ennoid BMS - smart CAN enabled BMSs that can send data to the VESC so it can make decisions based on p group voltages or other parameters
• LED controllers(Maxkgo, TelTail TTL) that read UART data to change LEDs based on throttle, brake, standby & reverse (example1, example2)
• uSplit - A UART splitter to add more UART ports

As for performance, the current control mode and thermal throttling is what makes this roughly 100A. There is no industry standard for continuous amps that I know of, so when Flipsky says continuous what they really mean is less than a minute at that current. No surprise, it's 6 fets and amps are amps. However you can safely pull 100A on take-off or up a hill until the fets reach 85C and it will slowly start to reduce the current to the motor to keep the temps between 85-100C to prevent frying the controller. It can also reduce power based on motor temps.

What's the true, continuous rating of this controller? The all day long amperage? If it was run at 100A, it would probably thermal throttle down to 40A after 5-10 minutes if I had to guess based on similar controllers, but the beauty of the above data logging is that you can figure what current you need and for how long. If you allow it to cool down between heavy bursts of current it may be a great low cost controller. Maintaining speed doesn't require a whole lot of current.

For a high performance ebike VESC based controller, I think the A200S based MakerX Go-FOC HI200 or Trampa's 75/300 or 100/250 is a much better option, though they cost 2.5-6x as much.

I've got this installed on an ebike and have been riding it around a bit. I plan to do some testing including field weakening in the next week or two and will post some metr logs.

 

[Koxx]

and for low cost, we created the SESC
partially VESC based, open source, vesctool compatible but running on a 25€ xiaomi hardware. sorry out of topic.

 

[mxlemming]

and for low cost, we created the SESC
partially VESC based, open source, vesctool compatible but running on a 25€ xiaomi hardware. sorry out of topic.

This looks very very good. Tidy codebase, runs on cheap as anything hardware... Uses ST MCSDK which supports field weakening, MTPA... out of the box. Does it work well already? This is great.