PPM Standards: Does a BL ESC read a spike or a drop as the pulse?

[JPZ]

Hello,

I'm working on a project which involves converting a PWM to a PPM so I can drive a BL ESC and use a brushless motor instead of a brushed motor. My question is this: What does a standard BL ESC interpret as the signal pulse? Does it read a short voltage spike as the pulse(fig A.) or a quick voltage drop(fig B.) as the pulse?

Fig A.

_____--__________--__________--__

Fig B.

------__------------__-----------__---

[vintage1]

pretty sure its a variable length logic 1..

[Gary Warner]

Figure A is correct.

[JPZ]

Thanks for the responses. You guys are certain that figure A. is correct?

I have another quick question if anyone knows the answer. I have heard about differential ppm, where the timeframe begins at the end of the previous pulse. In other words, each pulse is a sync pulse. Is that what your average bl ESC uses, or is there a fixed time frame of about 2ms?

[Gary Warner]

Thanks for the responses. You guys are certain that figure A. is correct?

I have another quick question if anyone knows the answer. I have heard about differential ppm, where the timeframe begins at the end of the previous pulse. In other words, each pulse is a sync pulse. Is that what your average bl ESC uses, or is there a fixed time frame of about 2ms?

Sure it's A.

I don't keep this kind of link on my computer but the web is full of great sites that explain all you'll ever need to know about servo (and BL - same thing) drive pulses. It sounds like what you are asking about it the pulse train in a receiver (PPM) before it's dished out to each of the channels. The same could be said about the transmitter's output drive to the RF section. You shouldn't need to worry about this if you are 'just' driving a BL ESC.

[JPZ]

It sounds like what you are asking about it the pulse train in a receiver (PPM) before it's dished out to each of the channels.

Nothing of the sort.

You shouldn't need to worry about this if you are 'just' driving a BL ESC.

I have everything to worry about. This is for a quad rotor heli. If everything isn't perfect, the thing will be literally unflyable. Right now there are four brushed motors. They are controlled by a PWM signal. I nead to put a converter at each motor that changes the pwm to ppm. Then I have to drive a brushless ESC with that PPM signal so that it controls the brushless motor exactly as the original PWM signal controlled the original brushed motor.

Let me make my question clear:

A normal PPM operates on a fixed time frame. Every 2 ms a new frame is started. Depending on where the pulse is positioned in that frame determines the speed. In this case, the transmitting and receiving devices must be in sync from the beginning.

There is another type of PPM called differential pulse position modulation. This works exactly the same way, except that at the end of each pulse, a new time frame is started and the devices are synced.

Here is an example. Time frame of 2 MS. At 1.8 ms, you emit a pulse. The receiver interprets that as full throttle. 0.2MS later, a new time frame begins, and 1.8MS after that, another pulse is emitted and interpreted as full throttle. Meaning that there is a 2MS space between the two pulses.

Differential PPM works like this. Time frame of 2MS. At 1.8 ms, you emit a pulse. The receiver interprets that as full throttle. A new frame begins right here. 1.8MS after that, another pulse is emitted and interpreted as full throttle. However, there is only 1.8MS between each pulse.

The result in mixing the two would be catastrophic, resulting in total failure of syncronization.

[jsirkia]

Hi JPZ,

seriously, look up "servo pulse" anywhere as suggested, or in fact, "servo tester".

A standard servo pulse is not PPM, it's still PWM since it's the length of the pulse that is the information. 1ms for off, 2ms for full throttle, and one of these pulses in about 20ms should give a decent control over a normal BL ESC. So you need to convert your existing PWM signal to a 50Hz (or so) PWM with duty controlled over the range 5-10%. These four PWM's you need don't have to be synchronized to each other since each ESC only receives it's own pulse and doesn't know anything about the others.

Four rotor heli sounds interesting, hope you have success!

-Jussi

[Gary Warner]

Yep, more information can help a lot. ;)

Is this one of those spinning-loop-4-prop-hover thingies?

Sorry, but something doesn't add up as to why you are worried about this.

Tell me what's wrong with this understanding of what you originally stated: You want to convert the brushed motor ESC output pulses into servo type pulses to run a BL ESC replacement setup.

If my understanding is correct then there is no reason to worry about frame sync.

Again, if I understand what it is you are trying to do then here's the jest of 2 possible ways of handling it. First, make an analog PWM to voltage converter then put that into a microprocessor on an AD input and read the throttle setting. Then output the associated servo drive pulses to the BL ESC.

Another way using a micro would be to use a high-speed counter in the micro to time the PWM. Again have the micro output that reading in servo fashion to the BL ESC. The first one requires a lot of analog work. The second one would have a control resolution limited by how fast the PWM pulses and the clocking speed of the micro's counter. Slower PWM and faster micro would allow for highest resolution.

[vintage1]

Thanks for the responses. You guys are certain that figure A. is correct?

I have another quick question if anyone knows the answer. I have heard about differential ppm, where the timeframe begins at the end of the previous pulse. In other words, each pulse is a sync pulse. Is that what your average bl ESC uses, or is there a fixed time frame of about 2ms?

Er..this is a cinfusin between teh pre-decoded pulses and teh actual output pulses.

In PPM, the carrier is kicked one way to mark PPM width boundaries, these are short duration pulses, whose width has no meaning..the leading edge of each 'notch' defines the end of the previous channel and the start of the next. A particularly LONG pulse is used to start the whole sequence and reset the decoder.

There is no necessary fixed frame rate. Some transmitters use a fixed frame rate and whatever is left over is the synch break. Others simply add a fixed length sync and let the frame rate overall depend on the sum of the channel widths..and the synch.

PPM receivers don't care. The way it all works is the long sync pause is applied to a charge pump, and that goes high after the sync pause, resetting a '1 of N' counter, and then a fixed logic one is applied to the data input, and the PPM waveform to the clock. Each succeeding edge clocks the one along the chain,where it sits until the next edge clocks it out again. The finish of each edge is ignored - only the start is the marker.

Each output forms a channel output to a servo (or ESC) so it becomes a variable width pulse between typically 1 and 2 ms, positive going, whose frame rate is indeterminate, but is typically around 20-30ms.

Analogue style servos compare this with an internally generated pulse whose width is derived from the servo position, and drive the servo to make pules widths equal. The difference pulse is amplified and stretched to provide a longer time to 'drive' the servo, but even so an analogue servo receives discrete 'bursts' of drive as it approaches the correct position - you can hear them tick and buzz.. ESCs and digital servos use logic to do the comparisons and can therefore drive based on a more complex algorithm. They tend not to buzz...:D

[JPZ]

Wow, this is getting to be a very confusing thread. There are a few things I must clear up.

1. I am talking about PPM signals. Not PWM. The length of each pulse is short(100 microseconds) and the length of the pulse does not matter.

3. I'm talking about a single channel PPM signal. This signal is not coming from a transmitter or receiver. There is no signal train. Just a series of pulses all for a single channel, the same motor.

4. Speed, accuracy, and reliability is of utmost priority. Any delay over 1-2MS will cause catastrophic failure and complete loss of stability of the helicopter, resulting in a flip crash.

5. I already have a working quad rotor heli. But the motors and brushed, highly inefficient, and low power. I am simply replacing them with brushless motors(which isn't a simple project).

6. What I want to know is whether a brushless electronic speed controller interprets the high or the low signal as the pulse, and whether a BLESC uses normal PPM or DPPM(differential PPM).

[JPZ]

Here is a picture to show the difference between PWM and PPM.

[vintage1]

Wow, this is getting to be a very confusing thread. There are a few things I must clear up.

1. I am talking about PPM signals. Not PWM. The length of each pulse is short(100 microseconds) and the length of the pulse does not matter.

3. I'm talking about a single channel PPM signal. This signal is not coming from a transmitter or receiver. There is no signal train. Just a series of pulses all for a single channel, the same motor.

4. Speed, accuracy, and reliability is of utmost priority. Any delay over 1-2MS will cause catastrophic failure and complete loss of stability of the helicopter, resulting in a flip crash.

5. I already have a working quad rotor heli. But the motors and brushed, highly inefficient, and low power. I am simply replacing them with brushless motors(which isn't a simple project).

6. What I want to know is whether a brushless electronic speed controller interprets the high or the low signal as the pulse, and whether a BLESC uses normal PPM or DPPM(differential PPM).


It uses the high pulse, and what comes out of a PPM decoder is a PWM positive going pulse of variable frame rate, but accurate width. In short the ESC understands a pulse about every 20ms, positive going, varying between 1ms width (low throttle) and 2ms width (high throttle). If the ESC doesn' t see a pulse at all after about 50-100ms, it will usually go into low throttle/failsafe mode. In some ESC's if it doesn't see a pulse for about 250ms,it will need re-arming as well by (typically) a high/low/high throttle sequence.


You may be able to up the PRF to some good effect..I assume its being driven from some digital logic - but I don't know where the limits lie.

[vintage1]

Here is a picture to show the difference between PWM and PPM.

What you call PPM is not what comes out of our transmitters.

What you call PWM is more or less what comes out of our decoders, but its not quite like that as explained previously.

RC transmission standards were optimised a long time ago for the simplest possible decoder. When a TTL ring counter was Large Scale Integration and very sexy. And you built receivers out of three pin transistors, and miniature IF coils, and 'superhet' was a sexy marketing term. And it was all AM anyway. THAT is the reason why the boundaries only are sent..you want as much carrier all the time to settle the AGC down, so your LOW signal doesn't result in noise..when NBFM came along they just copied the modulation scheme.

NBFM made it much easier to control the sidebands as modulation was much more efficient and done at far lower power..switching a power stage on and off slowly enough to restrict sideband generation fir AM required a beefy sort of modulator transistor..and the regulations changed such that the transmitters had to occupy only a 10Khz slot.

We couldn't use true PPM without some transmitted timebase to compare against..in essence the system is a sort of bastard PWM but what is transmitted is not the PWM signals themselves, but the boundaries of them as I explained. In addition since the pulses are sent one after the other with no breaks between them, and there is no concept of a frame size at all, it wasn't really PWM either.

Its a sort of variable rate asynchronous PWM.

Stop trying to understand it in terms of things you have learnt in communications textbooks, and understand what it is and how it works.

Feel free to come up with a new term for it, but accept that for whatever reason people call it PPM.

[JPZ]

Ok. I'm having a little bit of trouble understanding what you are saying. Actually, I understand everything but this:

It uses the high pulse, and what comes out of a PPM decoder is a PWM positive going pulse of variable frame rate, but accurate width. In short the ESC understands a pulse about every 20ms, positive going, varying between 1ms width (low throttle) and 2ms width (high throttle).

So what would happen if I took the PWM signal from the picture in post 11, converted to the PPM shown in the same picture, and sent that to a brushless ESC?

[vintage1]

So what would happen if I took the PWM signal from the picture in post 11, converted to the PPM shown in the same picture, and sent that to a brushless ESC?

"Sweet Fanny Adams"

I don't know what you are having trouble with. What the ESC needs is a positive going pulse, of width 1-2ms (low to high throttle)and a PRF of about 50HZ. OK?

[JPZ]

Sorry, this is getting a little mixed up. I missed your double post. Making sense of it right now. For the time being, what does PRF stand for?

EDIT: It's Pulse Repitition Frequency.

[pmackenzie]

It has been explained already, but I will try as well.
The correct signal to drive a servo or esc is a pulse of from 1 to 2 msecs, repeated every 20 msec. The pulse is logic "1".
Most controllers will take 1.1 msec as "off" and 1.8msec as "on". You need to experiment a bit with your specific ESC.

This is obviously a form or pulse width modulation since the width of the pulse contains the information, but it is not the type you showed in your diagram most commonly referred to as PWM.
This is likely the source of your confusion.

PPM is the method of encoding used to send all of the servo information over the RF link. The decoder in a normal rcvr takes the PPM pulse train and produces separate servo signals.
Hope that helps,

Pat MacKenzie

[JPZ]

Its a sort of variable rate asynchronous PWM.

Yes. From what I have understood here, it is basically differential ppm, or dppm. Which I asked about in the very beginning.

Now how the **** do you convert normal pwm to ppm? It looks like my converter won't work at all.

Stop trying to understand it in terms of things you have learnt in communications textbooks, and understand what it is and how it works.

I'm trying to understand it in terms of what I have spent hours reading about on the internet. Now I'm asking here to find out how it actually works because I understand the theory.

PPM is the method of encoding used to send all of the servo information over the RF link. The decoder in a normal rcvr takes the PPM pulse train and produces separate servo signals.

I know this. Knew it before I started this thread. I don't have a pulse train. I don't have multiple channels. I have single channel input and single channel output.

I will bold here what I understand:
The correct signal to drive a servo or esc is a pulse of from 1 to 2 msecs, repeated every 20 msec. The pulse is logic "1".
Most controllers will take 1.1 msec as "off" and 1.8msec as "on". You need to experiment a bit with your specific ESC.


What is this about repitition and 20 ms? And what is this pulse logic?

[JPZ]

Is this now correct? The 3rd(new) diagram is what is sent to a BL ESC?

[pmackenzie]

I have written code to both generate "servo signals" to drive speed controls, and also the code in the speed control ( brushed only) to read them convert them to the 0-100% PWM.
The application of the generators was the same as yours- drive a brushless controller without using a rcvr and transmitter.

Generating is fairly easy:

Each frame ( 20 msec):
set timer to desired output width ( 1 -2 msec)
start timer
turn on output bit
wait for timer to underflow ( or overflow if it only counts up)
turn off output bit
repeat

If you processor has two timers it is easy, otherwise you will have to calculate the off time as 20 msec minus the on time and re-use the single timer.
For a single servo signal you don't need to use interrupts, but if you have other tasks then using them for the pulse generation takes very little CPU time.


Pat MacKenzie

[pmackenzie]

I will post a correct signal diagram shortly....

[JPZ]

The application of the generators was the same as yours- drive a brushless controller without using a rcvr and transmitter.

That is NOT my application. I AM driving it with a transmitter. However, I cannot just send the transmitter PPM into the BL ESC. If I did, the quad rotor heli would crash as soon as it left the ground. A quad rotor heli needs constant gyro input(every 2ms) in order to remain in the air. The problem is that the output from the mainboard(which reads from a gyroboard with multiple gyro's) is PWM. There is no output with gyro input in the form of PPM. So I have to convert it. With minimal delay.

Take a look at page 5, the top left diagram. Specifically the PWM to PPM converter. It consists of a delay, an inverter, and a NOR gate. Simple as that. But I don't see how that would work for anything but synchronous PPM.

http://www.brain.kyutech.ac.jp/~morie/pub/icann99-ando.pdf

[pmackenzie]

I think I understand.
You have a 0-100% PWM signal intended to drive the brushed motors and you want to take those signals and generate the correct servo pulses so you can use brushless motors. Correct?
This could be done with micro controllers, and probably also with analog circuits, but not as easily as your circuit. It is not a direct 1:1 translation.
Here is the "correct" servo signal required to drive an ESC.
As mentioned earlier most ESCs do not use the full 1-2msec range but that is only a minor detail.

[JPZ]

You have a 0-100% PWM signal intended to drive the brushed motors and you want to take those signals and generate the correct servo pulses so you can use brushless motors. Correct?


100% Correct. Simple as pie, yes?

This could be done with micro controllers, and probably also with analog circuits, but not as easily as your circuit. It is not a direct 1:1 translation.


That is my problem. That is why I started this thread. I understand that it is not 1:1. I asked about that quite a few posts ago, and it has taken until a few posts ago for someone to tell me that this is dppm and not true ppm.

I would prefer to stay away from microcontrollers. I'd be quite interested in doing projects with them, but I do not want to spend the money or the time at the moment. I shall figure out a way to do it with analog signals.

Now I just have some questions to clear up your diagram.

1. When you give the ESC a 1.1ms pulse, it continues for the next 18.9ms or so at that same speed? Basically, what happens during the 18-19ms of down time?

2. What would happen if you sent more than one pulse in a 20ms cycle? I need to be able to change the speed atleast every 3-4ms.

3. What would happen if you sent the signals shown in the third diagram of my last attachment? That is the proper type of ppm, yes? Would that change the speed as shown in the picture?

EDIT: Thank you very much for your time and patience. I know it must be frustrating. You can't imagine how much I appreciate this.

[pmackenzie]

1. When you give the ESC a 1.1ms pulse, it continues for the next 18.9ms or so at that same speed? Basically, what happens during the 18-19ms of down time?


speed is only changed every frame (~20 msec)

2. What would happen if you sent more than one pulse in a 20ms cycle? I need to be able to change the speed atleast every 3-4ms.
This would depend on the software in the ESC. Some might respond to shorter frame width. The GY401 gyro has a special digital servo output mode that increases the frame rate to something like 300 hz to allow for a tighter control loop.
Most good ESC software will look at the frame rate and input pulse widths in order to do glitch filtering, so there is a limit to how short a frame you can use.
]
3. What would happen if you sent the signals shown in the third diagram of my last attachment? That is the proper type of ppm, yes? Would that change the speed as shown in the picture?

There is no "proper" PPM. PPM just describes using the position of a pulse in a pulse train to transfer information. The details are up to the designer.
The PPM method used in R/C is perfectly valid and capable of quite high data rates in a fairly narrow bandwidth.
For example the PPM output from a transmitter in FM mode is slightly higher resolution than the equivalent PCM output from the same transmitter.
To answer your question, the ESC will only respond to the standard servo pulse width information. Anything else will be filtered by the software as "junk".

The 20 msec between pulses might seem like a long time, but it is the same time interval between your input commands from the transmitter.
Also consider the delays inherent in the spool up and spool down times of the motors.
How do you know that the processor updates the existing motor PWM signals every 2 msec based on the gyro outputs?
If a single micro is handling the PPM decoding, gyro inputs and 4 motor PWM outputs then to me that seems like an optimistic estimate of the system performance.
( I have a Roswell Flyer, the predecessor to the Draganflyer. I doubt the processor in it had anywhere near that performance)

If you want to avoid micros, then try to find some schematics of older brushed controllers.
Some of them took the servo signal, converted it into a DC value and then used a chopper to generate the PWM.
Although I think the PIC route would be easier, those circuits might be reworked to do it the other way.
Take the PWM, convert to a DC value and then output a servo signal based on that. It would require some clever circuit work to get it all working properly.

Pat MacKenzie

[Bruce Abbott]

this is dppm and not true ppm.No, it's pwm.

If you really need minimal delay, you could try modulating the motor voltage directly from your 0-100% pwm signal. Either use it to control a step-down switching voltage supply, or find a way to replace the ESC's internal pwm with your own. It might even be easier to make your own ESC (like this (http://homepages.paradise.net.nz/bhabbott/sensored.html), but without the microcontroller!).

[pmackenzie]

FWIW,
another potential delay is the ESC response. A very common way of filtering noise from the input in embedded applications is to average the last "n" pulses.
Pat MacKenzie

[JPZ]

Thanks for the help again. I've spent probably between 20 and 40 hours reading through pretty much everything on the forum where all of the German inventors of my helicopter reside. There are also quite a few electrical engineers over there who modify the **** out of the X-UFO.

There are many processors on the stock electronics. And when I say that I need to convert the signal in 2 ms or less, I mean just that. Convert it. Not get the output from the gyro all the way to the prop. That is the reason why the converter must be so fast; the delays over the course of decoding and encoding signals, processing gyro input, and the actual time it takes for the motor to react to the signals it gets from the esc leave pretty much no room for any more delay.

Hold on a second... couldn't you just hook up the pwm to the esc? Based on the information you have given me, I don't see why that shouldn't work. The ESC would take the width of the first signal and run at that, and then disregard everything after it. Then it would just run at whatever the PWM says in another 20 ms...

[JPZ]

No, it's pwm.

If it's pwm, then why can't I just ram my PWM output into a BL ESC and drive my bl motor?! :p

[jeffs555]

If it's pwm, then why can't I just RAM MY PWM OUTPUT INTO A BL ESC AND DRIVE MY BL MOTOR?!

As has been repeated over and over, the input to an ESC is PWM with a specified range of pulse widths and repetition frequency. Anything outside the the 1-2mS pulse width and 20mS repetition rate is undefined and the results will depend on the algorithms used by your particular ESC. It is highly doubtful that the PWM output from your X-UFO would match these specs, especially since PWM from a motor controller generally has pulse widths from from 0 to 100% of the repetition rate and most have repetition rates much less than 20mS.

PS Just a friendly hint. Shouting is not a good idea. The guys who have been answering your questions are very sharp, and they are usually willing to help anyone. However, if they detect an attitude from someone, the help will stop.

[JPZ]

PS Just a friendly hint. Shouting is not a good idea. The guys who have been answering your questions are very sharp, and they are usually willing to help anyone. However, if they detect an attitude from someone, the help will stop.

Perfectly understood. But I wasn't shouting. Read it as if it were bold instead of caps. Easier to hold shift for a few works than to bold and unbold the text.

Thank you very much for your time and patience. I know it must be frustrating. You can't imagine how much I appreciate this.

especially since PWM from a motor controller generally has pulse widths from from 0 to 100%

They go from 50~55% to 90~95%.

Anything outside the the 1-2mS pulse width and 20mS repetition rate is undefined and the results will depend on the algorithms used by your particular ESC.

Was told above that it would be ignored.

Hmmm.... this seems like it is going to be tricky... so let's see.... PWM to analog voltage, and analog voltage to PPM(cross between pwm and a botched version of ppm).

[Gary Warner]

Hmmm.... this seems like it is going to be tricky... so let's see.... PWM to analog voltage, and analog voltage to PPM(cross between pwm and a botched version of ppm).

By George, I think he's got it. :cool:

If you try this in analog and speed is required you might be disappointed. The slew rate of charging/discharging capacitor circuits can take more time than you think. Then again, it can be fairly fast with good design. Maybe fast enough since you'll have 20ms to read the PWM.

By far, the use of a microprocessor would be blinding fast. You would have the value of the throttle setting in microseconds. Your biggest delay then would be waiting for the 10-20ms frame rate that the BL ESC is expecting.

BTW, though ~20ms is 'standard', it's not written in stone. Many servos and ESC's can run on a frame rate of as fast as 4ms; it's all up to the equipment's designer. As I've designed many servo driving devices, I come to a 'personal' conclusion to not use frame rates any faster than 10ms.

Also, sorry we were having such a hard time comunicating. Such is live on the web. ;)

[Gary Warner]

Also, something so obvious it's the definition of 'can't see the forest through the trees' is that your existing brushed ESC is using a servo pulse to begin with. Can you tap that pulse and feed it strait into the BL ESC instead of using this up-convert/down-convert/up convert method?

[JPZ]

Also, something so obvious it's the definition of 'can't see the forest through the trees' is that your existing brushed ESC is using a servo pulse to begin with. Can you tap that pulse and feed it strait into the BL ESC instead of using this up-convert/down-convert/up convert method?

I know about this, but I think that if it were that simple someone over in Germany would have tried it. The problem I believe is that the only PPM signal that exists at the moment is the one coming from the receiver. That goes into a massive microprocessor along with the gyro input that has already gone through two or three microprocessors, and then a PWM comes out. I believe that is how it works, but I haven't looked too closely at the stock electronics yet.

If you try this in analog and speed is required you might be disappointed. The slew rate of charging/discharging capacitor circuits can take more time than you think. Then again, it can be fairly fast with good design. Maybe fast enough since you'll have 20ms to read the PWM.

I know, I really think I'm going to have to get into PIC programming. 20ms is too long.

By far, the use of a microprocessor would be blinding fast. You would have the value of the throttle setting in microseconds. Your biggest delay then would be waiting for the 10-20ms frame rate that the BL ESC is expecting.


Yes, I agree that a microprocessor would by far be the best solution if I could get an ESC with a PRF of under 20ms.

BTW, though ~20ms is 'standard', it's not written in stone. Many servos and ESC's can run on a frame rate of as fast as 4ms; it's all up to the equipment's designer. As I've designed many servo driving devices, I come to a 'personal' conclusion to not use frame rates any faster than 10ms.


So I have heard. The problem is how to tell what the PRF is before you buy it, and even when you have it in your hands. Also, why have you decided that under 10ms is bad?

Also, sorry we were having such a hard time comunicating. Such is live on the web.

That's what happens when there is so much controversial information on the internet. And when someone has no clue what they are talking about so it appears to them that no one else has any clue what they are talking about. :D

[Gary Warner]

why have you decided that under 10ms is bad?

It's because much of my work has commercial applications. I'm not always in control of what my customer's applications are or what equipment they are running. It's just 'safe' to say 10ms should be that fastest frame rate. If I were to make devices dedicated to particular hardware and I was in need of the fasted frame rates, I'd explore the limits of that hardware and use the fastest frame rate I could. Again though, being in commercial business I can't afford to have someone's project fail just because of their choices in hardware.

[JPZ]

So is there any way to tell what the frame rate is for bl esc's on the market?

I very well might have to program a PIC to convert the signal and then make my own BL controller.

[Gary Warner]

So is there any way to tell what the frame rate is for bl esc's on the market?

I very well might have to program a PIC to convert the signal and then make my own BL controller.
My first choice would be to consult the manufacture/designer. Most are willing to say what it is if they have knowledge of that data. Secondly you would need to ask someone who's tested it to its limits. Lastly you need to test it yourself, at some expense of time and hardware.

Try the first idea before re-inventing the wheel.

[JPZ]

OK, thanks for the advice. How hard would it be to use a PRF of 4ms if I were to make a BL ESC myself? I think that is going to be the way to go.

[Gary Warner]

If you make your own BL ESC you can go much faster than 4ms. There will be an ultimate limit based on the frequency of the PWM and the code run-time overhead, but faster than 4ms should be easy to get (read:easy as a relative term ;) )

[JPZ]

read:easy as a relative term

Yes. I believe building an ESC(especially brushless) is a project and a half on it's own. Anyway, thank you very much for all the help. I guess I'm going to be busy for the next year or two...

I have to make 4 BL motors from scratch
4 BL ESC's.
4 PWM2PPM PIC converters
4 devices to get the PWM output from the mainboard(it generates the signal by disconnecting the ground)
And I have to make my piezo gyro board into a HH piezo gyroboard for better stability.

Sounds like fun!

[Gary Warner]

A thought:

Before jumping in too deep with making hardware, make sure the PWM frequency and the microprocessor timer speed will allow for a high enough resolution data.

Here's an example using a 8 pin PIC 12F629.

Clocking: Internal 4mhz
Timer module speed: 1mhz
ESC (original one) PWM freq: 20,000hz
Timer module interval:1/1,000,000 = 1us
PWM time verses timer speed:1/20,000 = 50us

So the best resolution would be in 50 steps. This might be too course.

So you can move the microprocessor speed up to say 16mhz with external crystal. Now the resolution would be 4 times higher at 200 steps. 20mhz (IC limit) would take the resolution to 250 steps. This would be what I'd consider to be the lowest resolution you should use. Again, it depends on the PWM frequency as to just how fast you'll need to clock the microprocessor to get the desired resolution. Find out what the PWM frequency because it will set the other hardware parameters.

[JPZ]

OK, thanks for the info. I don't really understand much of that right now, but I get the basic message. I will be measuring the PWM frequency with an oscilloscope when I get the chance, which probably won't be atleast for another couple days until I can bring my UFO into school. For some reason I don't have an oscilloscope lying around my house....

[pmackenzie]

There are PC based scopes (freeware/shareware) that use the soundcard for input.
You do have to be a bit careful about input voltage levels.
Here is one:
http://www.zelscope.com/

Pat MacKenzie

[JPZ]

Thanks. I came across that site a few days ago actually. I will think about doing something like that. However I have no electronic materials on hand to build an input device to feed the signal into the soundcard. I'll probably end up using the oscilloscope at school, but this is a possibility.

[JPZ]

Lastly you need to test it yourself, at some expense of time and hardware.

How would you test a BL ESC to find out what the PRF is?

[pmackenzie]

You would have to try driving it with shorter and shorter frames until the ESC stops working.
Pat MacKenzie

[JPZ]

Ok, thanks a lot. I took a very very brief look into making ESC's and it looks like a lot of work... a LOT of work. :D

Would it be possible to modify a commercial ESC to run with a shorter PRF?

[pmackenzie]

No.
You have no access to the software and the frame rate limits are set by it.
The reason the ESC checks the frame rate is to reject "bad" signals.
A typical error mode for a rcvr decoder would be to react to noise and send the wrong signals to the servos.
By making sure the control pulses are separated by the frame width the ESC can reject them.
It should also check for pulse widths outside the 1-2msec width and reject them.
Pat MacKenzie

P.S. you are correct. A BLDC motor controller is a complex task.

[JPZ]

Thanks again. I'd be interested in making a BL ESC, but not at the moment when I have a dozen other projects(all the mini projects in the BL project that I mentioned above, plus I am making a liquid cooling system from scratch for my laptop). What are my options for getting a hold of a Bl ESC with a PRF of under 10ms, preferrably under 5?

[trashmanf]

JPZ, you could save yourself a couple years by going with COTS components for your ESCs and BL motors. The UFO has an inherent design flaw in that it modulates speed rather than pitch of the rotors... there will always be a lag and variation in speed control of them, leading to instability. You should use some tail rotor control systems off helicopters... then you can run all four of them off the same motor (or use separates if you like) and you can use servos to control the pitch of the blades for MUCH faster response. Simply plug in some gyros to those control servos as their axis lies. anyways I know that's a totally different direction than where you're heading but I believe it will save you time and money in the long run of accomplishing your eventual goal of better stability control and duration. Ballistic Tech's BTR would be a good choice :D

edit: I added some pictures. it seems you could reduce your weight too by having one central motor instead of the overhead of 4 separates.

[JPZ]

Thanks for the suggestion. Many other people have suggested that, especially over on the german forums(www.xufo.de). As you said, though, the idea takes the entire project in a completely different direction.

My goal is not more stability or longer flight times. My goal is more lift. I need it to just be stable enough to fly. I'm using a homemade piezo gyro based on the plottermod. If I cared about perfect stability, I would have bought an X-3D.

Hoestly, though, I am looking forward to the project just for the sake of messing around with microcontrollers. I'm in it just as much for the sake of learning(and expanding as a programmer) as well as getting my UFO to fly a bit better.