Hello everybody,
I have started designing my own dual VESC 6 hardware for my electric longboard application. I am also integrating an antispark switch and accessory board support. I have just started laying out the board and figured I would start a thread for documentation purposes. Here is an image of the initial layout so far: 
I'll keep posting updates as they happen. If anyone has any questions, feel free to ask!
Cheers!
Pay attention to tracks routing, one of the the most important thing.
Have a Nice Day.
Thierry
Main thing is to keep the track loop length as low as possible to reduce inductance.
Thanks for the tips! I have been using the copper pour zones for most of the high power areas. I am almost finished with the layout and I will post some images soon! Also, is there a specific VESC logo/text I should put on the silkscreen layer? I want to make sure I give full credit to Ben for the design.
Cheers!
Hello everyone, I hope you are all doing well!
I have finished laying out the PCB and just need to make some changes to the integrated anti-spark circuit design. Once I do that, I will order a small batch of PCB's to test. Anyway, here are some images of the layout. Enjoy!
That's all for now. Let me know what you guys think!
Cheers!
Looking good! Where are the bulk caps going? I guess the current shunt amplifiers are in the same place on the vesc6, just looks really far away to me.
The large capacitors will be going in those through holes below the fets. Same general location as the original VESC 6, just above the PCB, not inline.
Cheers!
Hello everyone,
I have just received the first batch of PCB's! I should be getting the rest of the surface mount components later this week to start testing! I think the boards turned out really good although I already have some plans for a second revision. Here are some pictures of the boards:
That's it for now. I will flow and test the first board or two by the end of the week and report back. Let me know what you guys think!
Cheers!
Looks really nice :D. Good job!
A question I have for Ben and or Frank. I have included the VESC project logo with a link to this site on the PCB to give accreditation and to lead to the site. Since the logo is trademarked, will this be an issue if I sell these boards in the future? I noticed that all other third-party hardware does not include the VESC project logo. If it is an issue I can easily remove the logo and just leave the accreditation to Ben and a link to the site.
Cheers!
I just tested the anti-spark circuit and it works perfectly! I designed it with a dual input latching system so it can be controlled via digital signals from a host microcontroller while remaining extremely robust. Now I am just waiting on the DRV8301 IC's to come in and I will test out the full board. Hopefully, everything checks out so I can send off the second revision with added features quickly. Updates to come.
Cheers!
Hi Josh, you may not include the VESC-logo or write VESC onto the device if you want to sell them. You can describe the device as VESC-based in your product description and you can link back to this website. Detailed Information can be found here: https://www.vesc-project.com/trademark_policies
If you want to sell them commercially, please make sure to tell your customer that the device has OS-firmware installed and pass over the full text of GPLV3-license to the customer (e.g. via email) and make sure the customer can find the source code for the firmware you put onto the device.
Frank
Hey Frank,
Thank you for the reply. I read through the trademark policies and now understand. It will be some time before I try and sell any, I just wanted to get everything sorted out for the next batch of prototypes.
Thanks,
Josh
Thanks for caring. Copyright matters and opensource is a fantastic thing thing if everyone plays by the rules.
What's a thing thing? Is that different from a thong thong?
:-)
Hello everyone!
Well, I've been debugging the hardware for the last week or two and have sorted out a bunch of minor issues. However, I seem to be having an issue that I am having trouble with. I have managed to flash the firmware and can not seem to connect the USB with the 60 firmware version. After a reset, the 3.3v indicator LED is on, the fault LED is blinking three times over and over, and the green status LED is solid green. Windows says it can not recognize the USB device. I did also try flashing the 75_300 to it and was able to connect but some weird things were going on. Does anyone have any tips or experience with this? Also, what is the difference between the 60 firmware and the 75_300? Any help is appreciated.
Cheers!
I identified a copper pour island without a ground stitch that affected the DVDD, REF, and AVDD capacitors on the DRV8301. Jumping it over to ground solved the fault errors but the USB still is having trouble connecting. Windows shows it as a malfunctioned device still. I have tried replacing the SMT32 with the same issue still occurring. Anyway, I will continue working on it and post updates as they occur.
Cheers!
Malfunctioned device normally means it's drawing too much current.
I managed to get the USB working, must have just been a loose connection on the connector. However, the vesc is reporting an active duty cycle when idle. It seems unstable and jumpy. What is responsible for measuring the duty cycle of the VESC? I would assume the current shunt and their amplifiers? Everything else seems to be fine so far, just trying to isolate the duty cycle problem.
Cheers!
I would think your battery is not (yet) connected? Then you'll see a wildly fluctuating duty cycle because it is matching the voltage of the motor (0V + noise) to the dutycylce * Vin (0V).
Hey Roger,
Thanks for the reply! I had it hooked up to a 30v 3A power supply like how a battery should be. I went through and checked everything and there were some mislabeled resistors. I believe some of them were on the voltage measuring voltage dividers. I have just sent off a version 2 PCB with many fixes so I will test that out once it comes in. I haven't started reading through the firmware source too much yet but the duty cycle is determined by comparing the motor phase voltages to the battery supply voltage?
Cheers!
While bringing up new hardware I often start out by testing if the logic works. Do I get USB connectivity and such? So I remember seeing the weird dutycycles when the power is not yet connected. If you have an error in your PCB in that area, I'd wait out the corrections for that before you start worrying.... :-)
Hey Roger thanks for the reply. Yeah, that is typically how I go about testing when I design PCBs. It is a bit more difficult to troubleshoot something that is not of my design. I did check everything I could referencing the schematic and there should be very few issues with this next revision. I have reasonably high confidence that the duty cycle issue will be resolved since there were a few issues with the voltage dividers. I'll post updates as soon as I get the new boards in.
Cheers!
Hello everyone!
I have just received the new PCB's and have mounted and flowed them. All of the previous issues have been resolved and I have successfully flashed the firmware and connected over USB on both sides. However, I can't seem to successfully run the motor detection in BLDC or FOC mode. In each mode, the motor twitches twice and then nothing. I have been debugging the problem for the last few days and I am unsure what the problem could be so any help is appreciated. Here is what I know:
- The VESC throws an Under voltage Fault at around 5 volts when motor detection fails.
- The supply voltage does indeed sag to 5 volts when looking on the scope
- High currents are sent to the motor (10 times or more what it should be during detection)
- No bridges or typical hardware issues exist
It seems as if the controller is trying to give way more current to the motor than it should be. I am unsure what is responsible for sending the current (if it is passively set in code or actively monitored and adjusted during the detection). The only thing that seems to work properly as of now is the full break mode. I have checked the mosfets and made sure that they are getting proper contact and not shorting out. Do you guys have any ideas as to what could be going on?
Here are some images of some samples I took during the detects:
Are your current sensors connected to the right phases? I had a similar issue when I was doing my first board. Also if you have any capacitors on the phase voltage lines remove them.
Thanks for the reply. I read through your post the other day and checked to see if I had the same issue. I just did a pinout of the original vesc hardware and mine and the shunts are correct. I'm going to double check the voltage sense dividers and the mosfet gates. Not much else I can think to check after that. Let me know if you have any more ideas.
Cheers!
Ok guys, excellent news I have figured it out. When I made the current shunt footprints, the middle pad where the current sense amplifiers tie to were switched around. So basically, the shunts were being read backwards so it thought the current was negative when it was positive. I just cut the traces with a razor blade and jumped some blue wire the right way from the shunts and boom, it works beautifully! I have successfully run BLDC and FOC detections and am now testing the power handling of the board. I'll post some updates and pictures soon.
Cheers!
Nice job! That explains why it looked so similar to my problem then.
Ok so there is a new problem that I am fighting with. The controller on the other side of the board is having an issue. When it is powered on, it seems to short the phases together like full break. I have tried remounting the fets several times but I don't think it is a bridging problem. The gates of the GL_A, GL_B, and GL_C fets are high, between 11 and 20V. I believe the DRV chip is driving them but I don't know why. Any thoughts?
Cheers!
Tried replacing the drv? Are the control inputs to the drv for the low side fets high?
Hmm, yes I have replaced the DRV twice and just probed the control inputs. They are all low until a driving signal is applied from the MCU. Going to check output traces now. Not sure what else could be causing it.
I have measured the gate outputs and the problematic ones are the low side fets. So GL_A, GL_B, and GL_C. All the gates are driven to 10.75 volts. I am going to thourghly read through the DRV8301 Datasheet and see if there is something that could cause it to drive the low side gates high by default. I also captured a picture of the gate signals on the scope. It pulls down the line when the motor is trying to be driven. This seems to me like maybe something is pulling up the gate rails externally. See image below:
I found something in the datasheet: http://www.ti.com/lit/ds/symlink/drv8301.pdf that might be applicable to this situation. On page 24, it has a warning about the gate drivers not powering up properly if any of the SH pins are greater than 8.5V before the EN_GATE pin is brought high. Maybe this is the cause of the gates being driven high. I will probe and look at it on the scope to see if this is what is happening and report back.
Cheers!
So that does not appear to be the problem either. I probed the EN_GATE pin and the three SH pins. None of the SH pins exceed 5 volts before or during the EN_GATE transition. I will keep thinking of things to test, let me know if anyone has any ideas or thoughts.
Cheers!
Hello guys,
So I managed to fix the issue. I ended up flowing a new board and it works perfectly. I must have killed something on the first board during the previous testing and the board was getting overworked from replacing components. I would guess either some of the capacitors or solder pads went bad. Now there are just a few problems with my antispark I have to work out and then the next revision should be good to go! I'll post updates as they happen.
Cheers!
Nice work so far, any updates?
Hey Cory,
I actually just got the most recent PCB's in and tested last week. Everything is now working as expected. I will post a formal update with images and more information in the next few days.
Cheers!
Nice work! For reference, if the shunts are connected backwards, that can be corrected in the hardware configuration files. I will soon make a tutorial in the documentation on how to adapt the hardware configuration for custom hardware. Essentially all ADC channels can be remapped, different current sampling configurations can be used and different FET driver chips can be selected. For example, the DRV8305 is also supported, including SPI. Features such as the permanent NRF24 can be enabled or disabled, and soon there will be IMU support (starting with the MPU9250). The IMU will also come with a quaternion filter in the FW that provides easy to use orientation measurements.
I have been inactive here for a while because I have been really busy with my Phd and rebuilding my garage and home workshop, but the disputation date is now set in December, and after that I will put more effort into the VESC stuff again. Coming up next is polishing the app and adding RT data features that merges readings when multiple VESCs are connected. There will also be support for adding gear ratios, wheel diameters, motor poles etc. in the configuration to drive a dashboard page in the app.
That is my excuse for being inactive recently, in case anyone is wondering :-)
Hi josh, great work doing your own version, I have taken the same route for a single board. It seems that you run into some troubles, I also experienced some which I suppose are related to the layout and I want to redo-it and have a second version fabricated. I might post detail with my layout and boards in a new thread, along with the problems I encountered, like motor detection.
I see in the picture of your first version something that concerns me for my updated board, which are the tracks that come from the DRV to the mosfet's gates, they seem to me very thin, as I made then in my first version following some initial screenshots from VESC 6 development, which I am not sure that changed over time, maybe benjamin can advice about this. I think normally there is not much current on this tracks as we are driving mosfets but the DRV8301 is capable of driving ~2A trough these and in my next version I will dimension the tracks to these specs and also make them shorter.
Could you post a picture of your latest layout?
Also nice hearing from you benjamin as I saw your post about publishing a reference design for a 3 shunt VESC version, which will be really helpful, some people figured this out trough trials but this will make things much easier for future development.
Hello everyone,
It's nice to hear from you, Benjamin, I figured software edits could have been implemented to fix the reverse shunt measuring but I figured let's keep everything according to the schematic. I am looking forward to the updates and the possibilities they bring! I really like the idea of displaying multiple vesc information in the RT tab. If possible it would also be nice to have multi vesc control from the app as well. Also, now that my design is almost finished, what is the best way for me to publish the design? Would you prefer that I provide all the Ki-Cad files or just the schematic and layout as a PDF? Good luck finishing your PhD!
wkt, if you start a thread and post some details about your board and issues I can definitely take a look at it and see if I can help. I have a very good understanding of the hardware after debugging my prototypes. Regarding the DRV gate traces, I don't think they need to be very thick at all. I suppose it depends on your gate capacitance and switching frequency but the average currents should be pretty small for normal operation. I have never measured them so I can't say anything for sure but it has not been a problem for the official 6.4 HW or my boards to my knowledge. I imagine Benjamin would be able to elaborate on this more. I would probably not worry about it unless you are driving a higher number of or different MOSFETs than the IRF7749's.
Now for the SDRV update. In the latest revision (v1.3) all hardware issues have been fixed and all functionality is working as expected. It features a latching integrated anti-spark switch which can be latched on by bringing the on input high and then latched off by bringing the off input high. This is so a small signal from an external MicroController can be used to power cycle the controllers. The switch also has a quiescent current of less than 100uA when latched off. Below are some images of the PCB:
That's it for now, I will be working on the host daughter board that will mount on top of the controller and will feature a separate BLE MCU, CAN interface, and other peripherals. Let me know if you have any questions and I'll post updates as they happen.
Cheers!
Great progress, your assembled PCB's look really good. I am glad that you got everything working, also my PCB's I can say they are working functionally on the bench but I had problems when assembling on the longboard and testing in real life *not sure yet what broke* , so I would like to hear more news when you test them in high currents / voltage spikes.
Quick question: the PCB's are manufactured with standard 1oz copper or thicker copper layers?
Your anti-spark switch looks good, I was thinking to also design one and include over-current protection, I saw another user Roger Wolff that also designed a over-voltage protection circuit.
Hello wkt,
Thanks! I assemble them myself and it takes hours to do one. I have not had the chance yet to put them on a board yet and ride them but I have been testing them on my test bench rig which has loading capabilities and everything seems good so far.
I have the PCB's manufactured with 1oz copper due to the close track spacing on the logic side circuity. This close spacing is so the footprint can remain small. Since I am running all the power from one side of the PCB through the anti spark to the mosfets on the other side, I added solder pour areas to increase ampacity. If there are issues with this later in testing, I can look at having copper sheet laser cut and soldered to these areas for even more ampacity but I don't think this will be necessary for ~60A motor driving.
I based mine on the Vedder-Fechter antispark circuit and beefed it up with three irf7749's and the latching circuitry. I would be careful about including overcurrent protection in the anti-spark. Really that should be handled by your BMS which should also be communication with your host device. I am also building a custom BMS solution from the ground up that always knows the state of the board (if moving, etc) and has to ask permission to disconnect the pack if a fault condition is occurring and the wheels are moving. The worst thing that can happen is losing control without warning when riding especially if you are going down a hill, having a BMS act in this fashion will favor the user's life over the batteries lol. Anyway, here is a simulation of my antispark design: https://www.multisim.com/content/RTJjq6bSJ5WQSViSYVm2Rc/digital-vedder-a...
Cheers!
Looks REALLY nice! Good job!
I also use 1oz 4 layer boards for the A200S, for the high current bits there are bus bars.