Author Topic: RC PPM/PWM protocol ?  (Read 12864 times)

0 Members and 1 Guest are viewing this topic.

Offline 3roomlabTopic starter

  • Frequent Contributor
  • **
  • Posts: 825
  • Country: 00
RC PPM/PWM protocol ?
« on: October 26, 2014, 08:46:36 am »
good day folks,

im trying to find out how the RC PPM signal stream is like. below is what i have gathered (or not gathered  :palm:). i am trying to look into the use of ESC (electronic speed control) for 3phase motor. so im trying to understand what is the signal format like in order to send "artificial" generated PPM to it (without a arduino, just cooking up some pot of logic gates to time it)

1) a frame of data is said to be 20ms, this 1 says its 22.5ms, and that it is maxed at 8channels. http://www.mftech.de/ppm_en.htm. i saw a frame capture plot from futaba in rcgroups forum, and it is actually 27ms. so in actual, there isnt really a 50Hz standard today am i right? i assume that the limit is up to how the RX is configured to receive streams in its own limits, yes?
2) there are 2 major camps of PPM stream format, a positive mark type, and a spaced type (inverted, futaba style). i am assuming that the norm is actually the positive style that is used in all ESC?
3) some sites denote the header (like a analogue start bit) of each channel is 0.3ms, some say it is 0.7ms. but in actual, it seems the "start" bit have a very wide variance amongst different PPM TX models/brands, so it doesnt matter or does it still have to boil down to a maximum 2ms "bit" width for EVERY gear manufacturer? i assume that if something is more than 3ms, it gets read as a blanking?
4) i have not seen any standard about the blanking width, i assume it has to exceed 1.5 "bit" widths (ie : more than 3ms ?)

thanks for reading, any replies appreciated
 

Offline Simon

  • Global Moderator
  • *****
  • Posts: 17814
  • Country: gb
  • Did that just blow up? No? might work after all !!
    • Simon's Electronics
Re: RC PPM/PWM protocol ?
« Reply #1 on: October 26, 2014, 08:52:35 am »
The link is broken.

does the controller manufacturer not tell you ? I've been controlling a motor driver with PCM again it's a 20ms frame with a 1-2ms pulse 1ms being off and 2ms being full power but as it's a single motor there are no channels for me. I did find that it worked fine even with a 30ms frame that I tried out because the the extreme temperatures my uC could be in and the consequent variation in clock speed and therefore PCM timings.
 

Offline Simon

  • Global Moderator
  • *****
  • Posts: 17814
  • Country: gb
  • Did that just blow up? No? might work after all !!
    • Simon's Electronics
Re: RC PPM/PWM protocol ?
« Reply #2 on: October 26, 2014, 09:36:14 am »
no just what is effectively 5-10% PWM
 

Offline awallin

  • Frequent Contributor
  • **
  • Posts: 694
Re: RC PPM/PWM protocol ?
« Reply #3 on: October 26, 2014, 01:07:14 pm »
oh PCM too? TBH, after reading so many RC sites, is PCM actually = the same PPM/PWM? i thought PCM is actual logic binary bits (fixed bit width) and not partially PWM. i suspect that althought a manufacturer call it PCM, it could be it is just the same PPM/PWM. or maybe i should call it PPM/PWM/PCM !

My impression was always that PCM refers to the radio transmission between Tx and Rx. It has little or nothing to do with the electrical signal between the Rx and a servo.
Anyways these PCM systems were state of the art 20-15 years ago, and since then everyone switched to 2.4GHz wifi technology (SpectrumRC was there first, other then followed)
 

Online mikerj

  • Super Contributor
  • ***
  • Posts: 3237
  • Country: gb
Re: RC PPM/PWM protocol ?
« Reply #4 on: October 26, 2014, 02:51:24 pm »
oh PCM too? TBH, after reading so many RC sites, is PCM actually = the same PPM/PWM? i thought PCM is actual logic binary bits (fixed bit width) and not partially PWM.


You are correct, PCM (Pulse Code Modulation) is the scheme used by modern RC systems that actually transmit a binary data frame.  The older "PPM" systems (which are really closer to PWM than PPM) encode the servo position as a single pulse per channel.
 

Offline macboy

  • Super Contributor
  • ***
  • Posts: 2254
  • Country: ca
Re: RC PPM/PWM protocol ?
« Reply #5 on: October 27, 2014, 01:11:09 pm »
It seems to me that what you need in is the protocol that is used to talk to a servo or a speed controller (ESC). What you are looking at however, is the data stream send between the transmitter and receiver. This is not the same.

To talk directly to a servo or ESC, you only need to understand the very basic serial protocol that is sent between the receiver and the servo. This can be defined in a single sentence: A positive pulse with a width between 1.0 ms (fully CCW/Brake) and 2.0 ms (fully CW/Throttle) is sent at a rate of approximately 50 Hz.

That's all you need to know. Generate a pulse at around 50 Hz, with a width variable from 1.0 ms to 2.0 ms (1.5 ms is throttle idle/steering centered). A simple 555 timer can do it.
 

Offline RedOctobyr

  • Contributor
  • Posts: 34
  • Country: us
Re: RC PPM/PWM protocol ?
« Reply #6 on: October 27, 2014, 02:11:41 pm »
Finally, something I can contribute to (however small the contribution may be) :)

Yes, you just need to provide the pulse that macboy described. If sending something directly to the ESC, the simple PWM signal is all you need.

If you're looking for manual speed control, maybe like with a knob, you don't even need to build anything. You can buy a servo tester for about $4 on eBay. And use its PWM output to control the ESC.

Mine has a knob so I can control the servo position (PWM width, or in this case, ESC output) directly, or it can output a centered signal, or sweep continuously through the range.

Some ESCs (like the ones I've used from Castle) want you to configure the signal range to what they're looking for. You keep going higher on the signal (closer to 2ms) until you get a beep, then closer to 1ms until it beeps again, and that's the range you use for controlling the ESC.

This is my servo tester:
http://www.ebay.com/itm/3CH-ESC-Servo-Tester-CCPM-Consistency-Master-Checker-/310802826496?pt=Radio_Control_Parts_Accessories&hash=item485d4ac500
 

Offline RedOctobyr

  • Contributor
  • Posts: 34
  • Country: us
Re: RC PPM/PWM protocol ?
« Reply #7 on: October 29, 2014, 12:34:00 am »
Very cool :) No, I haven't looked inside my tester. I am not an electronics person, so I wouldn't really know what I was looking at anyhow, I'm afraid   ::)  But I can take the cover off and get a picture, if you'd like.
 

Offline Pack34

  • Frequent Contributor
  • **
  • Posts: 753
Re: RC PPM/PWM protocol ?
« Reply #8 on: October 29, 2014, 12:47:14 am »
good day folks,

im trying to find out how the RC PPM signal stream is like. below is what i have gathered (or not gathered  :palm:). i am trying to look into the use of ESC (electronic speed control) for 3phase motor. so im trying to understand what is the signal format like in order to send "artificial" generated PPM to it (without a arduino, just cooking up some pot of logic gates to time it)

1) a frame of data is said to be 20ms, this 1 says its 22.5ms, and that it is maxed at 8channels. http://www.mftech.de/ppm_en.htm. i saw a frame capture plot from futaba in rcgroups forum, and it is actually 27ms. so in actual, there isnt really a 50Hz standard today am i right? i assume that the limit is up to how the RX is configured to receive streams in its own limits, yes?
2) there are 2 major camps of PPM stream format, a positive mark type, and a spaced type (inverted, futaba style). i am assuming that the norm is actually the positive style that is used in all ESC?
3) some sites denote the header (like a analogue start bit) of each channel is 0.3ms, some say it is 0.7ms. but in actual, it seems the "start" bit have a very wide variance amongst different PPM TX models/brands, so it doesnt matter or does it still have to boil down to a maximum 2ms "bit" width for EVERY gear manufacturer? i assume that if something is more than 3ms, it gets read as a blanking?
4) i have not seen any standard about the blanking width, i assume it has to exceed 1.5 "bit" widths (ie : more than 3ms ?)

thanks for reading, any replies appreciated

I'm mostly familiar with Spektrum receivers. With those, you'll get your first pulse about every 21ms with center stick at 1500.

Min and maximum varies but typically +/- 700 will be a safe range. So all the way low will be 800 and all the way high will be 2200. With whatever equipment you're working with, this will most likely be trial and error to find the exact extents of what your black box.

One thing I will note is that you may need to be mindful of your bit order. Your rudder, aile, gear, etc will leave the receiver in a specific order. I know this is crucial when you're reading from a receiver or if whatever widget you're transmitting it to is expecting multiple pulses.

I would suggest starting with a pulse with of 1500 and then modify the width of your "packet" until nothing moves. Then explore the extents of what the black box will recognize by incrementally increasing your maximum pulse width.

It wouldn't hurt to acquire a working receiver that's compatible and just wiring it into a USB logic analyzer to verify.
 

Offline Xpendable

  • Contributor
  • Posts: 14
  • Country: us
Re: RC PPM/PWM protocol ?
« Reply #9 on: October 30, 2014, 07:01:14 pm »
I've got a neat little project that I did for my dad.  He wanted to build a WWII Fletcher-class destroyer RC model with realistic engine controls.  He wanted to be able to operate the port and starboard engines independently and he wanted to set the engines with semi-realistic Engine Order Telegraphs (EOT's).  Nothing like that exists on the market, so I built him a custom RC transmitter that does that.

Here's a couple of videos:




So here's roughly how I did it:
Originally I bought a cheap 2.4Ghz HobbyKing 6 Channel transmitter and receiver.  This cost me only $25 USD + shipping.  I hacked into the transmitter and took out the circuit board.  I disconnected the joysticks and their potentiometers and connected i2c digital potentiometer chips that I controlled from an Arduino UNO.  So I was basically driving the analog input into the transmitter.  This worked phenomenally well until one day it didn't.  I somehow managed to kill something and the micro no longer did what it was doing before. 

I studied the circuit board from the original transmitter and discovered that all of the 2.4Ghz radio transmission is handled by a separate 1"x1" module that had 4 wires going to it.  The PCB on this module was helpfully labelled with "5V", "GND", "PPM", and "XMIT".  I did some research and found out all about what PPM was.  Turns out all the microcontroller in the original transmitter board does is read the analog inputs and then encodes the input values as a PPM frame, which is nothing more than a series of pulses in a fixed frame length, usually 21 ms.  Each pulse has a minimum length and a maximum length, and a minimum separation between pulse.  So I ditched the crusty transmitter board completely (along with my digital pots) and I connected an digital I/O pin from the Arduino directly to the PPM on the radio module.  I set the XMIT pin high with 5V and I began experimenting and watching what happened on the receiver end. Fortunately I do have an oscilliscope (which I was still learning to use at the time) so this helped quite a bit.  I ended up finding some PPM Arduino code on the internet that somebody else had written that is interrupt-based to ensure accurate timings.  I had originally used somebody else's code that was glitchy as heck but this one was better.  It's pretty elegant in that it sets the interrupt timer to interrupt at exactly the right time when you need to send the next HIGH or LOW based on where you are in the PPM frame.  That is to say, the interrupt timings are dynamic, not fixed.  I was also using Adafruit's RGB NeoPixels which require precise data pulses, so I built some code to ensure that the communication to the NeoPixels would only occur during the PPM frame's "reset" length.  If I didn't do that, the NeoPixel data would get scrambled when an interrupt occurs right in the middle of the NeoPixel data transfer.  By syncing the data transfer to when I know the interrupt will not be called, I solved that problem.  Worked a treat.  Anyway, I have a whole build thread on this over on rcgroups.com here:  http://www.rcgroups.com/forums/showthread.php?t=1800914

The point of me telling you all this is if you really needed to do PPM, you could grab the same code I used as a great starting point.  On the other hand, if you just want to drive an existing ESC (electronic speed controller), then all you would need to do is output PWM.
« Last Edit: October 30, 2014, 07:08:58 pm by Xpendable »
 

Offline RedOctobyr

  • Contributor
  • Posts: 34
  • Country: us
Re: RC PPM/PWM protocol ?
« Reply #10 on: October 31, 2014, 01:43:06 am »
Very cool :) No, I haven't looked inside my tester. I am not an electronics person, so I wouldn't really know what I was looking at anyhow, I'm afraid   ::)  But I can take the cover off and get a picture, if you'd like.

*arms up* yea please .... tear down ! haha !

No problem, pictures attached. I hope these help a bit.
 

Offline 3roomlabTopic starter

  • Frequent Contributor
  • **
  • Posts: 825
  • Country: 00
Re: RC PPM/PWM protocol ?
« Reply #11 on: October 31, 2014, 02:11:31 am »
THANKS!

interesting ... must be a small MCU
 

Offline macboy

  • Super Contributor
  • ***
  • Posts: 2254
  • Country: ca
Re: RC PPM/PWM protocol ?
« Reply #12 on: October 31, 2014, 04:41:22 pm »
thanks for the info *salute*. nah i wasnt going to dive into an arduino to churn out the PPM/PWM, i wanted to make a knob-ed kind of signal generator, leaning more to analogue (non MCU that is)
Try https://www.google.com/search?q=555+servo&tbm=isch
 

Offline Xpendable

  • Contributor
  • Posts: 14
  • Country: us
Re: RC PPM/PWM protocol ?
« Reply #13 on: November 17, 2014, 08:59:02 pm »
btw the video you have those ship bells going ... where did those come from haha?

I have a serial-controlled MP3 player inside the transmitter along with a D-class amplifier board from Adafruit and a 4Ohm speaker.  The transmitter responds to the engine orders with pre-recorded verbal messages (I actually recorded my own voice) for each order, and I mixed in the EOT bells.  I actually used a recording of an old telephone ringer as the bells.
 


Share me

Digg  Facebook  SlashDot  Delicious  Technorati  Twitter  Google  Yahoo
Smf