Another early drill video (sorry this one is sideways to get the laptop screen in the picture):

BLDC drill running at (close to) full torque, sensorless running on saliency... meaning the phase information for the FOC control loop comes from additional code that measures the differences in the motor inductances.
This is an early version, later versions have improved accuracy for the phase detection (and so require a bit less phase current). At this point there was no transition to standard sensorless FOC yet.

Note: the voltage indicated on the laptop is double the actual voltage, a mistake in the LabVIEW program...

I am not a company starter. I cannot really do anything with this tech except build a one-of-a-kind ebike . Want to get rid of it (sell it), maybe get a consultancy job with the buyer...

I'd recommend doing a reference design - a PWB that you can build 20 of, that will also drive a motor. (Pick a motor you like and design for that.) That gets you your controller, and it gives you the ability to easily demo it to other people. Get them to sign a non-disclosure that states they will not reverse engineer it or tell other people how it works. That's your legal protection.

Maybe not a Zero, but something similar... in the meantime we have 2 Quantya's sitting around unused with broken DC-Controllers and I would be happy to bring you one (street legal) for experimenting as long as you want. For the motor I'm thinking about buying a Revolt RV-160Es, not a monster (~20kWp) but enough to have fun if combined with the right controller. A nice combo for demonstration/prove of concept purposes?

Thinking about what to do now with this tech. I do not plan a controller IC with this as for me it is more of the same, basically lots of not interesting work. Also setup might be too difficult and would ideally require a PC with Labview for drawing performance diagrams. I was thinking about building an ebike with this, but again lots and lots of work with no real return... Am busy trying to get other companies interested, but found the whole process with the first company very stressfull, just not my cup of tea. I am a researcher, not a business person. Coming up with the concept, build a working prototype, but after that I loose interest and want 'to throw it over the wall' so to say (expression we used in Philips meaning giving it over to a product division who then build the consumer version).

Just wanted to let you guys know where I'm at with this...

What about crowd funding an initial open source release then charging for technical advice and feature requests? When it comes to open source FOC controllers there's very little around despite the demand, the only real option is the VESC which is quite good but Benjamin who made it is usually too busy to work on it and turns down paid work.

Every open source project I've found has a very happy and enthusiastic "paying customer" base. I can't speak for everyone, but from my perspective, my support of an "open source" product over proprietary is that I know if the company (or original creator) abandons the updates and support, there is a community that can (and will) provide answers to questions.

When something proprietary goes bankrupt, the products will often get orphaned. One recent example is BionX kits. Places like ES will have answers to some questions, but the best way to quickly get an orphaned BionX kit working is to hack an external controller and throttle. If the BionX controller was "open source" then many more enthusiasts would feel comfortable buying a used BionX.

One example is the KT controllers, and specifically, the KT-based Tong Sheng TSDZ2 controller. The ES thread on them is over 100 pages. It has been reported that the open-source firmware performs much better than the stock settings. Not only that, a used TSDZ2 would gladly be snapped up on sale, over a used BionX.

ES posters typically have a soldering iron and know how to use it, but there are millions of potential customers with money to spend who do not want to take the time to learn something new, then download a program and adjust the settings. Don't look at the number of customers you will lose by being open source, look at the number of customers you will gain BECAUSE you are open source. The trend for the near future is open source...

SamD performs firmware adjustments remotely on Mobipus controllers, "for a fee", so keep some of the obscure techie settings difficult to access. Like Spotify, there is a large free section with ads, and for a small monthly fee, there are additional upgraded features for the platinum-member users.

Well, I am considering writing down how the 'standard' Lebowski controller works, but not releasing the code.

All I think about when I hear open source is lots of companies getting rich of my work without any kickback to me (even though I spent a few 100k$ worth of time and thousands of my own money on computers, lab equipment and parts). Second, as an unemployed at the moment I also think about all the people who will not have a job because their company uses open source instead of a few engineers to develop their own solution...

All I think about when I hear open source is lots of companies getting rich of my work without any kickback to me (even though I spent a few 100k$ worth of time and thousands of my own money on computers, lab equipment and parts). Second, as an unemployed at the moment I also think about all the people who will not have a job because their company uses open source instead of a few engineers to develop their own solution...

There's not much individuals or small businesses can do if someone is desperate enough to steal code, all closed source does is punish legitimate users by making it difficult to use due closed obfuscated libraries or having to try and ship locked physical MCUs. Making it opensource also doesn't mean you can't commercialize it either, you can easily release a GPL version while offering commercial licenses to companies that want to integrate it but not release all of their code. Quite a bit of software ranging from embedded stuff such as chibiOS to large game engines like unreal engine 4 use similar business models. You can also trademark the name of the software, if it becomes popular companies will pay to be allowed to use your brand in their advertising for controllers that run on the software. It's much more feasible to register and enforce a trademark vs multiple patents on software.

I don't think it would impact other engineers having jobs, Ti and many others offer sensorless software based off rotor saliency and induction, they just aren't on the public sections of their websites and are only offered to larger companies under NDA. It's unlikely many are writing their own implementations. I'm not completely sure why they have opted to be so secretive about it, I suspect the methods were patented decades ago and expired but only became relevant recently as MCUs became powerful enough. I have seen a few start ups trying to sell similar things but they never seem to appear in products or be bought out, which makes me suspect there's too much prior art for them to be bought out. Here's one I stumbled upon recently.

I don't think it would impact other engineers having jobs, Ti and many others offer sensorless software based off rotor saliency and induction, they just aren't on the public sections of their websites and are only offered to larger companies under NDA. It's unlikely many are writing their own implementations. I'm not completely sure why they have opted to be so secretive about it, I suspect the methods were patented decades ago and expired but only became relevant recently as MCUs became powerful enough. I have seen a few start ups trying to sell similar things but they never seem to appear in products or be bought out, which makes me suspect there's too much prior art for them to be bought out. Here's one I stumbled upon recently.

I assume it is considered valuable IP (giving a real advantage over competitors) so they keep quiet about it. TI for instance can patent their method but everyone can read the patents and copy the system. Including the whole of China. So I can imagine they just keep quiet about it. You may also be right that they are using old expired patents and just don't want to point anyone to those.

But I build my system all on my own without any knowledge of TI's or anyone else's system. I don't think there is anything TI can do to stop me just publishing how my system works, and so take away their advantage. I have a 100 page pdf with detailed explanation on my other non-internet PC. I don't have an NDA with TI, I actually never used processors from TI because their software is/was not available for Ubuntu Linux. Maybe, without being aware, I'm using things already patented, but this also cannot stop me from telling how my stuff works.

I assume it is considered valuable IP (giving a real advantage over competitors) so they keep quiet about it. TI for instance can patent their method but everyone can read the patents and copy the system. Including the whole of China. So I can imagine they just keep quiet about it. You may also be right that they are using old expired patents and just don't want to point anyone to those.

But I build my system all on my own without any knowledge of TI's or anyone else's system. I don't think there is anything TI can do to stop me just publishing how my system works, and so take away their advantage. I have a 100 page pdf with detailed explanation on my other non-internet PC. I don't have an NDA with TI, I actually never used processors from TI because their software is/was not available for Ubuntu Linux. Maybe, without being aware, I'm using things already patented, but this also cannot stop me from telling how my stuff works.

I don't think there would be any issues with documenting it or making an open source version. I mean't when it comes to making some money off it, the business model of just selling it as locked down commercial software doesn't appear to work for other smaller companies trying to do similar. Open source projects that make money off support, feature requests and the occasional commercial license request seem to have more success.

I actually never used processors from TI because their software is/was not available for Ubuntu Linux.

TI C2000 processors come with an Eclipse-based IDE that works on linux. Been using it for quite a while in my ubuntu laptop, works ok provided your machine can haul Eclipse.
If your main value is your IP just try to jump ahead and use a FPU-enabled chip like the higher end C2000 or an STM32F4. Will save you time thinking about fixed point issues. ST can be built using much leaner tools on ubuntu (or use eclipse if you want). I prefer to develop on STM32 unless the spec requires automotive grade.

I actually never used processors from TI because their software is/was not available for Ubuntu Linux.

TI C2000 processors come with an Eclipse-based IDE that works on linux. Been using it for quite a while in my ubuntu laptop, works ok provided your machine can haul Eclipse.
If your main value is your IP just try to jump ahead and use a FPU-enabled chip like the higher end C2000 or an STM32F4. Will save you time thinking about fixed point issues. ST can be built using much leaner tools on ubuntu (or use eclipse if you want). I prefer to develop on STM32 unless the spec requires automotive grade.

Impressive job man.

I reckon the best way would be to make it into an abstracted library coded in C using floats. You could run it on any 32bit MCU with a FPU and appropriate PWM/ADC hardware. Getting it up and running would just be a matter of connecting the code to timers and other peripherals for each MCU.

My code is all written in assembly , I use lots of macros which are faster to execute than call / return combos. Those take around 10 cycles, while most floating point functions are also roughly 10 cycles (meaning that its better to waste 10 memory locations here and there, instead of doubling the execution time)...