Ah i understand, good thing both drv’s are coupled to the heatsink then
Yes, but the package sucks 
Your DRVs aren’t going to be failing because they are slightly higher ambient temperature due to buck regulator losses, that’s a silly notion. They will fail when the gate drivers are stressed outside of maximum limits. An extra 10 degrees Celsius isn’t going to be what makes a difference in your DRV surviving when transient voltage spikes etc burn out the gate drives. The ambient thermals wont even affect thermal dynamics during these fast time constant events.
1 Like
Shit, I shouldn’t have been so eager to buy dual focboxes on sale…now I want this 
But with the evolve/focbox heatsink almost being ready, I’m torn between a dual setup or waiting for the Unity…
1 Like
Buy 2 FOC boxes now
2 Likes
Maybe not quite “smear” level, but there’s certainly some miscommunication happening somewhere. I don’t know why, but I’ve always been of the opinion that the FoxBox runs a modified version of the VESC source code. There’s also been some instances of people asking Enertion for the code and being told by support they are “not authorised” to provide it. This no doubt causes some confusion.
Happy to take your word it is just a stock VESC firmware. Honestly I’d just stick a link to the official GitHub repo on the FocBox product page and be done with it.
I’m guessing (hoping) you forked from a recent version of the firmware. Any chance this will get merged back into Vedder’s repo? Can appreciate there’s a significant amount of effort and probably negotiation required to do this, but IMO forking should be a last resort. Although one MCU for 2 motors is probably going to break any hardware abstractions built into the existing firmware… so it may be justified.
3 Likes
Yeah these are good points. I think things do get confused in the chain of communication.
It is forked from an extremely recent version. I started with the intent of re-merging but it quickly became apparent that the interface/structure was different enough that leaving existing code functional would require a ton of extra development effort on my end and might produce some clunky artifacts/unexpected behaviours. Its possible that someone with more experience than I have at code versioning could figure out how to properly support a single and dual motor driver from a single code base elegantly, but I couldn’t think of a clean way. This is something that should be discussed and reviewed once the code is published and others can help us figure out if theres a sensible path to merging. We can start a new thread to discuss the way forward once everything is ready.
7 Likes
Appreciate you coming here and giving us an update! I think people were mad a Enertion only because they didn’t release modified gerber files for Focbox but then again it was not really released by anyone who modified the original design, like ollin or other manufacturers and further validated considering vedder did the same thing with hw6.4 by only releasing schematics. It also seemed fair to people who wanted to design something like Focbox as they could still start fairly close with reference hw4.2 design. This time its going to be interesting though, as there is no reference dual design… As you said you would release the code would that also include schematics? I doubt anyone would actually use the schematic to design anything but people get very cranky when they see licence violation on open source projects.
2 Likes
The issue with enertion is that they are violating the GPLv3 software license by not allowing the inspection of the source code for the firmware OR the tools on their website. They can actually be forced to stop selling the FOCBOX and be sued for damages as they are intentionally violating copyright law. Yeah, you read that correctly.
4 Likes
Again they use the standard firmware and a compiled version of BLDC tool. I don’t know why anyone even cares about that. They did not modify anything so they are not liable to publish anything.
The law is the law, and the folks who wrote the software copyrighted it to the public domain with specific terms.
@myreala Are you suggesting that following the law is optional?
The law is the law but it does not apply in this case, i don’t know why Enertion wouldn’t just link to github of BLDC tool and be done with it. Save your energy to fight against people that actually modify and use the code without publishing anything, there are plenty of those around. There is no good coming from fighting just for the sake of fighting.
1 Like
It actually does matter, and it would take them seconds to post their code. This is their decision, not mine.
It’s a trivial solution
They have said they are using fw2.54, why do you need another repo of that?
Instagram is life.
@myreala That’s not what I asked for, and I’m not here for you to try to tell me what you think I may or may not need or speculate why I may or may not need it. The copyright law per the authors of the software says when they distribute the software, they are legally obligated to distribute the source code.
It’s the law.
End of story.
1 Like
Well go ahead an sue them then lets see who the courts side with, my guess would be Enertion.
This is why you’re not giving legal advice as a profession. Yours is very low quality.
2 Likes
Jeez, I wonder why.
@b264 has apoint in this regard, it’s like trampa and the use of the word vesc due to the trademark, enerrtion has built an entire company off a product they merely made edits too, and when they chose to use this product they agreed to share whatever changes they made with the public and that would include software and hardware
3 Likes