If I send you a dick pic without the hate can I get love in the form of a raptor 2.1?
The GPL license very clearly states that the software is copyrighted by the author (Benjamin Vedder) and given to the owner (you – the general public) and may be used without charge by anyone as long as the terms are followed. The terms are that you must release any changes you make to the source code under the same GPL license (give it back to you - the public) and offer the source code to anyone.
Enertion does not do this. They change your software and hide their changes from you, which revokes their right to use your software according to the license. So they are stealing it from you, and then selling it back to you. Because you own it - it’s free and open source, and it’s yours.
And no, I don’t think they are breaking laws – I have documented proof they are breaking laws. I work in the software industry and have to comply with these same laws myself.
The unbelievable thing is that it’s 100% free to comply with the law… they just chose to steal instead.
Just to reaffirm to those who haven’t read the threads spread across this forum (for maybe the 30th time, thanks @b264 for being constantly unclear in your comments), the FOCBOX Unity firmware and the Focbox UI code will have source code posted in a git repo before anyone has a unit in hand. I have all the code, believe in what vedder has done for the community and look forward to contributing my own work as well.
The best place to complain about the way the previous FOCBOX firmware wasn’t posted is not this thread. The Unity has completely different firmware made by different people which I’ve said repeatedly will be open sourced. Doesn’t make me feel great that the person who seems most eager to get their hands on my work is the same person badmouthing it every chance he gets (@Kug3lis) but that’s how open source works. You give it to the community and see where they take it, it’s quite exciting really. At least I can be sure @Kug3lis will make some crazy high power dual driver with a unique spin and not just clone it.
@onloop Excited for the unity, this is the missing key to finish my leiftech DIY! Was nice meeting you drunkenly over video chat in Vegas, though brief!
Unity incoming! Got all the smart switch features implemented today, so happy to never push the power button on my R2 again. Was great hanging with you in vegas, can’t wait for you to test what we’ve been working so hard on. Should be a game changer for simplifying DIY builds and provide heaps of power to any setup. Maybe lauren and I could come get some rides in before the next renegade weekend?
Please, come visit! Would love to have you out!!
I am interested with the answer so if you found a way, please share it =)
I think that you can control the FOCBOX from Arduino, like if you are using a servo.
You have to put everthing in the arduino: lights, horn, BT receiver, and everything you want.
I didn’t test anything, cause I’m earning for the FOCBOX, maybe I will buy it this month.
¿Do you already have it?
thought about this yesterday while riding my 6shooter build on bldc and being annoyed by the loudness.
there is a persistent braking problem with larger wheels (pneumatics, 6"+) locking up at low speed on FOC.
at the moment none of the vesc tools exposes the “Max ERPM at full brake” parameter for FOC (it’s only for BLDC right now).
user @SkaterBoy58 found editing the xml file directly to be one “solution.”
point is, is this a value that you can expose for the unity?
VESC BASED CONTROLLERS - Brakes locking at low speed for larger wheels in FOC - possible Unity Fix
This please 100%. It’s just brushed under the carpet and very frustrating
Yes I already have 2 Focbox (dual motor builds rock!!!) and a classic mini remote/receiver. I tried several stuff with arduino but I haven’t found yet what data I am supposed to send to the vesc (PWM, Analog…) and how (same pin as mini remote receiver, UART directly…).
I also found this video showing how to get data from the running vesc (like temperature, voltage, speed etc) but I have to dig more into that also to understand better what’s under the hood of the app (I’m not interested in Android while riding my board )
Sure, is this sensorless or sensored motors where the issue appears? I’ll investigate and see what I dig up. It sounds like something that might be better served by a FW fix then a vaguely named setting one has to change somewhere in an advanced tab.
The config value that @SkaterBoy58 suggests changing in the XML file isn’t used at all in FOC mode. See this link here, note that the value shows up in mcpwm.c (bldc source code) and not mcpwm_foc.c (foc sourcee code). Did changing this value really fix the issue for you guys or is it possible it just SEEMS a bit better (placebo effect). Either way I’ll get to the bottom of the issue.
Is the voltage monitor output from the Unity switched along with the rest of the electronics? So when using the push to start feature, would the voltage monitor also be intelligently switched on an off by the Unity?
Also, how much current can be sourced by the voltage monitor output?
Yes, it is switched along with unity power. Fused to 300 mA at raw battery voltage to prevent meltdown if the lcd wires were to get shorted.
It’s been going on a while Jeff.
Ok, so if someone wanted to add a device that is powered directly from the battery, switched on/off by the Unity, but draws more than 300mA, is there any option other than replacing the fuse to accomplish this?
I think we’ve kind of all just adapted and accepted it but it seems crazy that something like this can persist in such a mature hardware and firmware environment.
Please do. If you solve this issue you’d quite literally please thousands of us