Transforming a PWM signal correctly

Hi All,

As part of a larger project, I'm wondering if the connections in the screenshot will cause any problems with common power connections. I'm not proficient in using logic level converters.


I want to get a 1500us PWM signal out of the microcontroller wiht 3.3v logic levels feeding into a flight controller expecting 5 volts. A high voltage battery is running through a BEC to create a 5V source. The 5V is going into the microcontroller (which accepts a 5V power input). I PWM signal coming out of the MCU is 3.3v logic level so I'm using a generic logic level converter to go back up to a 5V output signal.

Is there an issue sharing the power lines coming from the BEC as both the input to the MCU, and the step-up voltage on the converter? Secondly, is this the best or easiest way to get a 5V PWM signal from a 3.3v MCU?

Thanks. Russell.

Typically, power is wired so that all GND lines from each device are connected to a single point, as close to the power supply as possible (star topology). They also do the 5V line.
Power Supply Lines-2
If it is a low-current device like a 3.3V-5V level converter, you can connect it to the controller.
Power Supply Lines-3
Often both GND lines (5V GND and 3.3V GND) of the level converter are already connected to each other, there is no need to connect each of them to GND of the power supply.
Some of them have no GND pin at all.
Bi-Directional Logic Level Converter

Try to avoid a ring topology like your schematic.

More about level conversion How to interface a 3.3V output to a 5V input

+1, heed @Boffin’s advices on ground connections.

But the approach is sound; I would say good and easy just because I don’t like making statements that have maxed out.

Anything you do to level shift up from 3.3 to 5 volts is going to be a few components. So the level shifter, if you only need one line, is overkill.

If it fits in your budget, money, size and weight the go for the module. Done, and done correctly.

If not, or you in the mood to spend time otherwise, the schematic of the module is available on the website linked above - you could make your own single channel level converter by stealing copying the way they do all four.

Two resistors and a mosfet, leaving how to handle it mechanically up to you. I build a tiny circuit like that on a scrap of copper clad unetched PCB, cutting traces (or more accurately speaking insulation between traces) using a razor knife.

You can get copper clad PCB so thin you can cut it with scissors, I’ve made PDBs and audio amplifiers this way, works good and would be not easy but very small and light weight.



What is the PWM signal going into? Have you tested it with 3,3V?

Thank you all for the advice.

@Boffin your explanation was very clear, I appreciate you taking the time. I’ll revise to your second topology. There are several other components in the whole system that share the common power supply, so hopefully I’ve avoided any other ring topology issues in the rest of the circuit.

@alto777 Yes the converter is overkill for one signal, but I purchased a set of five boards several years ago for about $2 and they never got used. This is all going in an RV plane as well, size size and weight is a factor,and these boards are very small and compact.

Steve you are right, I should actually check first whether I even need the shifter. The signal is passing through a multiplexer board and ultimately going to a KoPilot flight controller. Maybe 3.3v will be enough to trigger it. I did email the suppliers that exact question as I can’t find any technical specs which say exactly but haven’t heard back.

The other concern with just a bench test to see if it does work, is how close to the trigger threshold the level may be. If it worked but is borderline, then while in the air if the voltage dropped and the signal failed, I don’t want to lose control of the plane. I’ll have to double check how the failsafe will operate under those conditions.



Even if it worked without, even if the manufacturer said I would be fine fine I’d probably just put the level shifter on in there and sleep better…

It’s not his aircraft or problem if he is wrong-o. :wink:


1 Like

Mind you, a 74HCT14 with two gates in tandem will give better performance for high speed signals, than the "bidirectional level converter" with its open-collector output.

One should be careful using inverters for PWM as the duty cycle is reversed.

My project is probably not the optimal solution for my application, as there's a few too many bits hooked up to one another to jam into the fuselage of my glider, but if I can get the concept working with the random gear I have on hand, I can then look at refining the design for a more compact and permanent solution later.

My skills are more at the circuit plugger level than the circuit builder at this stage too. I still have a lot to learn about the basics. Just hope I don't blow anything (or anyone) up in the learning process. :smirk:

Good to know or be reminded about, but are the OP's circumstances

a 1500us PWM signal out

(probably a standard 50 Hz 1 - 2 ms pulse width) be considered "high speed"?

Also, while we're thinking about it, does the open-collector throw an asymmetry by being fast to switch one way, but slow the other? I'm googling meanwhile, yes.

In the r/c case, telling me every pulse would be a bit too fat or thin wouldn't be a problem, up to point.


So I have some interesting info. I found the PCScope program which is an old Arduino Oscilloscope. I know the Arduino isn't very precise at this stuff, but here's a screenshot of the signal I want to reproduce. The input to this is directly from the receiver as a 1500us pulse which sets the mode of the flight controller. I want to reproduce this signal from the microcontroller to hold the mode, so I can then use the receiver channel for other plane control instead.

The specifications for the receiver say an input voltage of 4.5 - 8.5V, and given the BEC's output 5V, I assumed the receiver signal voltages were coming out at 5V as well, but it appears not. So PCScope is showing a max voltage of 3.45v (not sure how accurate this program is) and that is sufficient to trigger the flight controller at that level, so maybe 3.3v will work after all.

I just remembered I have some other generic MCU's based on 8266 chips that I was going to use for wifi control. I might see if I can find them and try and create a test 3.3v 1500us signal and see what happens.

This seems odd. More typically a PWM signal to set a mode (or position an aileron) would vary as you changed a switch on your tx or moved a joystick.

A two position flight mode switch might produce 1 ms pulses for mode 1 and a 2 position switch for mode 2.

A three position switch would produce 1, 1.5 and 2 ms pulses as you went from mode 1 to mode 2 to mode 3. All coming every 20 ms or 50 Hz.

What flight control software and hardware are you using? There may be several different ways to do what you want without the trouble you are going to…

Just curious.


@alto Sorry I'm not trying to post a novel so your eyes don't glaze over, so I'm skipping some details.

I'm trying to control a ZOHD KoPilot. It uses a 3 position switch for the middle position (1500us) it is in manual mode. I need 8 channels for a full house glider setup (7 channels for the plane, and one for the KoPilot mode). My receiver only has 7 channels, so I'm trying to hack it to get more channels by multitasking the channel outputs to flip the mode of the KoPilot at the right time.

My initial design was using a Pololu multiplexer (which requires it's own mode switch channel) which works but it means I have to Y-lead the flaps. This is OK, as I only really lost full scale ailerons, which I can live without, but the challenge of getting that last "channel" added so I can dual-flaps is where I am at.

So, when the KoPilot is in it's control modes (down and up switch positions), the glider ontrols are dumbed down so it can do it's thing stabilising or running return-to-home mode. When in the middle position (manual mode) I want full 7 channel control of all servo's and the motor.

The final piece of this puzzle is using the multiplexer to swap the KoPilot's mode channel control over to a servo when in manual mode, but to do this, I have to provide an alternate signal to the KoPilot to keep it in manual mode during this time. Injecting the MCU 1500us signal into the KoPilot channel pipeline at this time is my plan. At least that's the idea.

It would all have been much easier if I just used a full feature flight controller, but that's more $$ and requires soldering 1001 header pins, and header soldering is not my idea of fun. My other option was get something better than a 7 channel receiver, but the one I got is the only one with full telemetry built in. All of the other receivers available with higher channel counts require multiple extra sensors to be added for all the telemetry options I wanted.

So, that's (almost) the full story. I managed to get a Wemos outputting a signal into my Uno oscilloscope. Here's the signal coming from it.

so we're down to 3.25v using this controller. I'll update soon when I get the KoPilot hooked up and see if it recognised the mode signal.


Just realised that's not the signal I want, code tweak incoming.


OK code problem producing the signal. The sample I started with (and didn't read through the comments originally) pointed me to the fact that using a basic delay between the high and low signals won't work, as the max useable delay period for "delayMicroseconds" is 16383. Given a 20,000 microsecond period, and only a 1500 pulse, it was falling back to "delay" which is in milliseconds, so nowhere near granular enough.

So question now is, how to create an accurate signal, and how to keep it in sync with the RC gear. I don't even know what sort of synchronization is required to keep the gear operating correctly. As for how to start, I see the micros() function has limited resolution depending on the MCU chip, so even manual timing the writes may not work.

Who'd have though just outputting a stable PWM signal would be tricky? Time top brush up on my google-fu.

Well, after a day of testing, rewriting, reading and learning many things, I think I've finally got it all nutted out.

Checking my bits box, it seems I'd gone on a buying spree many years ago. I found an Uno R2, an Uno clone R3 plus, two Wemos D1 R1, and an Wemos D1 R2 board, as well as other 8266 mini boards but they didn't have headers on, so I ignored them.

I started from scratch on a sketch to just use a dummy while loop checking micros() for elapsed time for the pulse and the cycle length, and then ran every board against my makeshift oscilloscope. Here's a picture of one of the final results

So the Wemos boards are outputting 3.35 - 3.48ish volts. None of them has a smooth floor, with them all showing around 0.12 - 0.16v when set low. I'm not sure if the oscilloscope is picking these values up as a signal, but as you can see in the picture, this snapshot showed a frequency of 59.1hz, and I saw occassional peaks into the 70's, but most of the time it hovered around 49.7 - 50.2 Hz. The Uno boards when running the same sketch returned a very solid 50Hz, with only 0.1 fluctuation either side, but at a (very steady) 5 volt level. Given the Wemos are supposed to run at clock speeds of 80Mhz, I'd have thought they would have given a more stable signal. I guess this probably reflects the better architecture and design of the Uno boards.

So with a voltage and frequency (and I guess pulse width, as the PCScope software doesn't show a value for that unfortunately) about where my current receiver is transmitting, I hooked all the parts up to see how the KoPilot reacted to my introduced signal.

The result, in a word, was SUCCESS! I had the KoPilot mode switching from the receiver as normal, then pulled the signal wire which it was not in nornal mode. The KoPilot retains the current mode when it loses signal. I'll have to change this in the failsafe settings as I normally want it to go into return-to-home mode, but it was fine for testing. I then plugged the signal from my WeMos generator into the input of the KoPilot and (according to the mode lights on the unit at least), it went into manual mode, which is what I wanted. Plugging the receiver signals back in, in changed to the mode the transmitter was in when I left it.

Just to be sure, I changed the pulse width to try with 1000us and 2000us outputs from the WeMos, and the KoPilot lights changes as expected.

So, after all that, it seems I won't need the logic level shifter after all, but thanks very much to everyone for the help and insight. I've learned a lot and know what to do in future if I do need one.


LOL that was literally exactly crossing my mind when I got to that line in your novel.

Thank you for the report. Good work! I'll reread to understand better why the level shifter is unnecessary, but you obvsly got this.


FWIW, when I started I chose equipment with a personal insistence upon having access to the source code, tool chain and ability to download any software of any component of a flight system.

Transmitter, receiver, flight controller and ESC. Mostly because I like to read code and see how it works. Abject curiosity.

With the exception of the receivers I use, I can see and alter all the code. I have done so, but could have avoided doing.


1 Like

Which software did you use? There's several "PC Scope" links.
Also, how does it handle triggers?

This is the one I used
Efys PC Scope

I looked at several, but a lot just show you the signal graph and not much else. There was another promising looking one here but it doesn’t seem to do anything, no signal is displayed. I see some recent comments from others saying the same thing, so maybe something changed in the software.

Is it really? :face_with_raised_eyebrow:

One wouldn't have thought so...

Currently, the largest value that will produce an accurate delay is 16383.

perhaps that's what @rcsixbynine has in mind.