Can I drive a BLDC driver with this diagram?

Question

I'm a programmer and I've only started messing with hardware half a year ago, mainly with the Raspberry Pi. I now want to drive a brushless DC motor using my Raspberry pi. To do this, I've bought this BLDC motor driver (it's still on its way) which comes with the following diagram:

From this image I understand that I need to provide 5 different inputs to the driver (SV, COM, F/R, EN and BRK). And here's where I think I get into trouble, for two reasons:

1. the SV requires an analog input, but as far as I know the Raspi doesn't have an analog GPIO pin.
2. All these inputs require 5V, while the Raspi GPIO pins only supply 3.3V

So first question; am I correct in these problems?

I guess I can overcome these problems as follows:

1. I could use either PWM or a DAC as described here for the analog input, but since I want the motor to always run at top speed, I guess a simpler solution would be to always power the SV with 5V. Am I correct in this?
2. To power the other ports with 5V I could use opto-couplers in combination with the 5V powered GPIO pin to supply 5V to the other 4 ports.

So I created the following drawing:

Using the above diagram I guess I can power all those 5 connections on the motor driver with 5V and I can turn them on and off programatically using the regular 3.3V GPIO pins.

But since I'm really a beginner: does this make sense? Do you think this will work? Won't it damage anything?

All tips are welcome!

Answer 1

The manual is very poor. I would recommend you that upon receiving the item you open the case and see what's inside. The drive can already have the optocouplers inside, so you will only need a NPN transistor and base resistor to control the digital inputs. The external setpoint speed potentiometer is not necessary if you use a in-built one.

EDIT:

Possible scenario once you open the case (the good scenario):

PAy attention to the voltage source - it should be galvanically isolated type.

^{simulate this circuit – Schematic created using CircuitLab}

The other scenario (no galvanic isolation built in BLDC driver):

^{simulate this circuit}

See this:

The DI internals are depicted as LEDs (maybe optocoupler LEDs?)

Answer 2

1. Analog or Digital, it doesn't matter in this case. So this schouldn't be a problem

2. This is a problem but you can fix this with a Logic level Mosfet that switches the 5V using the RPI outputs

Answer 3

I'm going to take a different approach on this, that would probably work better anyway with your software background:

Forget the BLDC controller that you just bought and use a hobby/radio-control one instead. Here's a sample search from one manufacturer.
(make sure you actually get a controller and not just a motor - the search includes both)

This has a single 3-pin connector to a PWM generator of some kind (the Pi), and even provides you with 5V power to run the Pi.

However, the PWM is not 0-100%, but 1-2ms above the logic threshold followed by some time below. The time above is interpreted as the signal, and the time below is simply how often you want to update it. 50Hz is very common (one pulse every 20ms), but you do have to keep updating it; if you just leave it alone, it'll shut down from a signal loss. The fastest allowed is 400Hz (2.5ms) because it leaves only 0.5ms between max-length pulses.

These controllers are designed to drive cars, which typically run forward, brake, and run forward some more, with relatively little time in reverse. So the "negative" command (<1.5ms) is actually brake strength until the motor stops, and then it becomes reverse speed. Reverse-to-forward is instant with no brake.

---

Now, with all of that said, you actually want to run at full speed or off with no actual speed control. I don't think you actually need sensors for that. In fact, all of the controllers in that search link ignore the sensor above a certain speed and use the motor's back-EMF instead because it's actually more accurate. The same company also has a wide range of non-sensored controllers, which are a bit rougher on startup because they have no idea where the motor is yet, but are literally no different at speed because of what I just explained.

---

At any rate, my solution converts the problem from hardware to software by having you buy something that already handles the hardware problem, but has a bit of a "language" for you to figure out in software. If you want real-time telemetry (RPM, current, controller temperature, etc.), a lot of the same company's controllers even support that. Do some research to find out how.

You might need an Arduino or other bare-metal microcontroller (no operating system, just direct code) to make the telemetry part work because it involves changing the pin from input to output and back again with precise timing, which I doubt the Pi can do through its OS. In that case, the Pi would talk to the 'duino, however you decide to do that, and the 'duino would talk to the ESC.