Cheap FOCer (VESC 4.12 based design)

wil said:
I understand trying to go local to save on shipping time but it will probably work out a lot cheaper to wait a few extra days for a "production" run from a Chinese board fab house.

A lot of PCBA services don't source components themselves, you need to sort that out for them, or charge a fair bit extra to do so. I found the cheapest pretty much always came out to be Seeedstudio and using parts from their part libraries/the Shenzhen sourcing library as much as possible as that was almost the equivalent of buying in bulk due to them being shared between peoples orders.

Anyway a Gofundme or Kickstarter is definitely the way to go forward for your first run, you get the money before hand so you don't need to rely on people promising you money and never paying after the boards actually get fabbed. I'll chip in for one when you are at that stage.

I'll investigate Seeedstudio as per your suggestion and see what kind of quote I get. I'll shoot for the gofundme/kickstarter. I think I'll have decent contribution between here and esk8(I have a thread there too).
 
I tried to PM you but it's stuck in outbox... what do I need to do to send a PM round here??
 
Hey there Shaman, this is bgdwiepp from the VESC project forum, sorry for my absence over christmas/new years, spent quite a bit of time with family, but now I'm back at work I have more thinking time.

I've been going through the design and replacing components and circuits with generic equivalents, allowing mixed sources for better pricing and availability, as well as expanding the operating range and adding functionality and safety, that seems to be missing from almost every design.

Since your current design is catering to 6FET controllers I thought I should design for 12+ FET solutions, in 6 FET solutions, the control and "infrastructure" of the dominate the price and the "default" enclosure dominates the power handling capabilities, where as in 12+ FET solutions the FETs usually dominate, giving a bit more flexibility for optimisation and safety.

Additionally, my design is not particularly priced around single unit construction, more in the order of 10-30+ units, this reduces the costs dramatically, if the design is successful I would be more than happy to manufacture boards in bulk, less MOSFETs and cables and pass the savings on.

I did a high voltage buck converter design that would work from 38-150v, allowing 12 to 35s operation and uses generic inductors rather than "unique" transformers, rated output 13V @2A~, about half of this would be used for internal operation, the rest could be used to connect auxillary circuits, like a 5W led headlight or some signal lights, or a 12-5v phone charger etc, removing the need for a separate dc-dc.

I did some circuit optimisation, putting the power switch as a high impedance input that gets switched to ground, rather than the very common (and dangerous) "switch to battery positive" design a lot of controllers do.

Switched to individual gate drivers and current sensors rather than the DRV solution, the current (cheap) gate drivers are probably good enough for driving FETs capable of 150V@80A/60V@150A, or more at lower switching frequencies. The gate driver is also pin compatible with higher power, more expensive drivers that would allow more FETs or higher switching frequencies.

Using ACS758/ACS770 hall effect current sensors and universal footprints to their lower current (and cheaper) siblings, basically using shunts is impossible over 100V, or at least incredibly impractical. Whilst the hall effect sensors are expensive if compared to a DRV, they are quite cheap compared to a shunt and an appropriate amplifier circuit and if using the smaller lower current sensors the cost is also much less.

Adding a LOT of I/O protection. Goddamn controllers are shit for this. If you short the 5v throttle or brake line to the ground on most controllers you will brown out your controller, if this happens while riding you controller will probably popcorn, and if it doesn't it may lead to unsafe situations where the phases don't freewheel, this is a good way to hurt people or controllers. The same can also be done with halls, the number of motors that spin in dropouts, rip out halls etc potentially shorting the 5v/gnd/halls to a phase connection is pretty big, protecting against this kind of this is pretty important.

Fixing small things, like potential damage to 3v3 regulators when powering the 3v3 rail from a programmer whilst the rest of the controller is turned off, or simply even allowing the controller to be programmed without a battery connected and instead a USB or programmer supplying power.

And much more.

BOM cost is pretty low, $15-20/board less FETs and cables in QTY 30, but I haven't finished the design so this is subject to change.

There is a bunch of other stuff I am looking at too but I am managing changes vs cost pretty strictly, I don't want this to balloon out at all.

Looking forward to your reply soon.
 
bamitsram said:
I've been going through the design and replacing components and circuits with generic equivalents, allowing mixed sources for better pricing and availability, as well as expanding the operating range and adding functionality and safety, that seems to be missing from almost every design.

this is so true! at work we only spec the very minimum in our bill of materials, so the EMS company is free to choose parts within those specs. this works way better than what i have seen at other companies, where they even spec part numbers for (generic) resistors.
 
@bamitsram

Your design sounds incredible! I love the attention to safety details and making the gate drivers swapable for more powerful versions. 150v max voltage is incredible and definitely suites a 12 FET design. I do have a few questions.

How far along are you in the design?

What are the approximate board dimensions?

Do you plan on releasing it open source? If so, are you doing it in KiCAD?

I want to integrate the same safety features and I/O protection in my next 6 FET design so I would love to be able to see how you're doing that. I'll definitely be following your progress if you choose to post updates somewhere.
 
nieles said:
this is so true! at work we only spec the very minimum in our bill of materials, so the EMS company is free to choose parts within those specs. this works way better than what i have seen at other companies, where they even spec part numbers for (generic) resistors.

This is exactly a point I wanted to make when I finally release the BOM. Currently the BOM is 100% from LCSC but an 0805 10k 1% resistor isn't going to vary much from one manufacturer to the next. Specing in a generic way allows more freedom for sourcing the components for sure.
 
Swapped out the LDO for the correct one. The blue "Vcc" LED lit right up. Nothing was shorted that I could tell. Will try and load software into it tomorrow and drive an unloaded motor. Will be monitoring for voltage spikes and ringing. Gotta suppress any of that before moving to loaded motor tests.
 
shaman said:
I want these to able to fit in 1590B or other common aluminum enclosures.
shaman said:
Additionally, the enclosure might be able to retain mineral oil inside.

I've realized how you can do this without oil wicking down wires being a concern, it will require a bit more of a hassle in assembly though.

All external wiring will need to attach from the bottom of the board, not the top (where side with the FETs and caps sticking out is the top). Through hole or surface mounted doesn't matter, the solder will seal the holes. You will need also need to make all vias covered by silk screen (to seal them).

Board will mount into the case with the FET side facing into the case (ie so board is closer to the thin plate lid.)

Use polyurethane sealant to glue the board into place suspended in the case just below where the lid goes into place, with enough clearance for the wiring to run.

Tap a hole into the side of the case that you will seal with a bolt, fill with mineral oil through this bolt, then put bolt back in, sealing it with some RTV silicone.

As all the wiring sheathing will not be in the oil itself, due to the pcb separating it, it will not a chance to wick out.

You will still get slight leakage from heat cycling, but it shouldn't be too bad I don't think. It will be better if the board continues facing downwards when installed on the bike.
 
wil said:
I've realized how you can do this without oil wicking down wires being a concern, it will require a bit more of a hassle in assembly though...

I follow and it seams like it would work. The downside I see, other than the hassle, is disassembly if one needed to repair the board. Polyurethane seems rather permanent. Regardless, this could very well be how one can eliminate wicking. Maybe we can think of a way to create an oil-tight wire covers/conduits of sorts that would achieve something similar? The conduit could be urethaned or siliconed at the base on the board and then again where it meets the enclosure wall. Or maybe implement watertight panel mount connectors for everything but the power/phase wires and use use the conduit idea for the power/phase. Either way this idea opens up possibilities. Keep the good ideas rolling wil!

wil said:
You will still get slight leakage from heat cycling, but it shouldn't be too bad I don't think. It will be better if the board continues facing downwards when installed on the bike.

I've been in contact with AGM Container Controls on how to prevent this and try to equalize pressure during operation. I'll let you know what I find out.
 
shaman said:
@bamitsram

Your design sounds incredible! I love the attention to safety details and making the gate drivers swapable for more powerful versions. 150v max voltage is incredible and definitely suites a 12 FET design. I do have a few questions.

How far along are you in the design?

What are the approximate board dimensions?

Do you plan on releasing it open source? If so, are you doing it in KiCAD?

I want to integrate the same safety features and I/O protection in my next 6 FET design so I would love to be able to see how you're doing that. I'll definitely be following your progress if you choose to post updates somewhere.

Schematics done, doing the last bits of layout at the moment.

Approximate dimensions are to fit a 15 Fet green time/xld controller case, so 168mm long, 73mm wide, max component height 25mm.

I do plan on releasing all of the design files.
No, I am using Altium, its what I use in my day job and what I have libraries for. I understand that makes it more difficult to contribute/modify, so I will try and make the design flexible in that regard, as well as releasing appropriate gerbers, PDFs and BOM.

I probably won't post regular blog type updates but will definitely reply to threads etc.

I have a couple of popped sabvoton controllers which are much larger that I might do a 24 FET board for, or a TO-247 board.

I see there are a lot of comments about weather sealing and heat dissipation.
In my opinion, whilst it is good to have weather resistant controllers, the effort, costs and tradeoffs of fully weather sealing a case is often just not worth it. A bit of silicone around the end caps, a sealed I/O connector and some screw type cable glands for the phase wires should be enough to ride in shower of rain with no concern. If you are riding in very wet weather for extended periods then the controller is probably pretty low down on the weather sealing list, I'd be looking at throttles, displays, your battery, all of the connectors once they're broken out of the controller etc before worrying about the controller.

If you wanted maximum power inside one of the smaller cases, you could mount high power SMD MOSFETs to a MCPCB and mezzanine a control board on top, then screw the MCPCB to the case with some thermal goop in between. But that is going beyond the idea of this controller, no? Being cheap and all?
 
Deeeeeee said:
Have u loaded the software. How is everything going on.

:!: Project Update

I've got good news and bad news.

Good news:
I got the software loaded up. I was able to see real time temperature and stuff.

Bad news:
No spinning motors yet. I have a weird situation surrounding the USB and ST link connection. The VESC tool only maintains a connection when both the ST link AND the USB cable are plugged in. Removing one or the other causes the VESC tool to lose connection. Don't know if it's a software/driver issue or a hardware issue. Probably the latter. I can still probably spin a motor tomorrow under this condition. Will have to eventually resolve this issue.
 
When you unplug the stlink its likely that the board will reset and perhaps its not recovering from that.
Did you flash the bootloader?
 
marcos said:
When you unplug the stlink its likely that the board will reset and perhaps its not recovering from that.
Did you flash the bootloader?

I did flash the bootloader using the ST link from a hex file I found here https://fishpepper.de/2017/10/31/tutorial-initial-flashing-a-new-born-vesc/

I assume the hex is file was ok as I was able to then update the firmware from the actual VESC Tool. I didn't update the bootloader though so I wonder if that has to do with anything.

I may have to power cycle the VESC after utilizing the ST link to try and relieve any reset issues. I didn't actually do that before.

P.S. glad to have you on this thread. I'm a fan of your work.
 
You could test that hex image in another vesc, or if you happen to have a discovery f4 board it should also boot like a vesc and show up as an usb cdc device.
I do the good'n old make && make upload to be sure what I'm working with.

Also make sure BOOT0 is not high during powerup, it could be booting the bootloader stored in ROM. Pin next to BOOT0 is CAN1_RX (usually set high), I had a solder bridge in there once.

Also possible is that your 5v supply from the usb cable can't provide a good enough 3.3v rail by itself and needs help from the stlink supply if you happen tu feed 3.3v from the debugger.

Could be a million things, good luck!
 
marcos said:
You could test that hex image in another vesc, or if you happen to have a discovery f4 board it should also boot like a vesc and show up as an usb cdc device.
I do the good'n old make && make upload to be sure what I'm working with.

Unfortunately I don't have real VESC handy. It's either do or die making one from scratch!

marcos said:
Also make sure BOOT0 is not high during powerup, it could be booting the bootloader stored in ROM. Pin next to BOOT0 is CAN1_RX (usually set high), I had a solder bridge in there once.

I'll double check this once i'm back in the lab.

marcos said:
Also possible is that your 5v supply from the usb cable can't provide a good enough 3.3v rail by itself and needs help from the stlink supply if you happen tu feed 3.3v from the debugger.

I'm powering the VESC from the main DC supply with 12v. I'm not utilizing the USB 5v at all and I'm not connecting the 3.3v pin from my cheap-o ST link.

I appreciate the debug tips and hopefully I can work this out!
 
Do you have a external pullup or larger than default capacitor on the NRST pin? This can cause issues with not resetting/starting up correctly
 
bamitsram said:
Do you have a external pullup or larger than default capacitor on the NRST pin? This can cause issues with not resetting/starting up correctly

I didn't add an external pull-up and it should only be 100nF cap at the pin as per the 4.12 schematic. This doesn't mean I didn't accidentally populate a larger one. This will be another thing I check for debug though. Thanks!
 
:!: Project Update

Good news:
I got past the USB/STlink issue. Just seems like a good ol fashioned "turn it off and back on again" did the trick. Probably had to do with the reset thing mentioned before. The controller now connects as expected with USB alone.

Bad news:
I get a weird "ghost current" reading from the Real Time data. It shows motor current at 0.35A when everything is idle and no motor is connected. My power supply doesn't register this much current being drawn. I believe there's something up with the current sense portion of the system. Could be a bad reference voltage or solder bridge somewhere. Could also be the DRV. I'll be troubleshooting this today and on into the week if need be.
 
So I went through an elaborate debug to try and fix the "ghost current" issue. Swapped out both the DRV and STM32 without much improvement. I did discover the TRUE reason why I was having the USB/STlink issue. Simply leaving the STlink connected to the VESC even without being plugged into the computer hijacks the reset pin. Must remove STlink completely after loading bootloader.

Nothing I did resolved the "ghost current" and the minute amount of duty cycle percentage that was being displayed. I found out that this seems like normal behavior of an idle VESC after viewing the video from the link below and other screen shots of people's VESC real time data. Real time data at 1:18 in the video is the same as mine showing approx. 0.3A and 0.1% duty cycle.

Can anyone else confirm that this normal behavior?

https://www.youtube.com/watch?v=UmlLNGOSL6w
 
So I made a mistake on the schematics. I accidentally mixed up the phase and current sense signals. I have SENS1 to H1_VS, SENS2 to H2_VS, and SENS3 to H3_VS. I have SH1_A and SH1_B measuring H1 current and SH2_A/B measuring H3 current.

The correct schematics have SENS1 to H3_VS, SENS2 to H2_VS, and SENS3 to H1_VS along with the current sense opposite of mine.

It bothers me that I didn't catch this with as many hours I spent staring at the schematics of both my controller and the official VESC 4.12. I don't think this is contributing do the "ghost current" readings but we'll see.

Regardless, I'll have to do either a hardware fix by doing PCB surgery to swap the signals paths around or modify the firmware to accept the hardware configuration as is. Either way, I'm fixing my schematics and PCB design so that they align with the original VESC 4.12. I don't want people to have to upload custom firmware for my controller if it's not necessary.
 
Back
Top