[Autopilot-website] CVS: htdocs pcm.html,1.1,1.2
Status: Alpha
Brought to you by:
tramm
Menu
▾
▴
[Autopilot-website] CVS: htdocs pcm.html,1.1,1.2
|
From: Trammell H. <tr...@us...> - 2003-02-03 19:25:59
|
Update of /cvsroot/autopilot/htdocs In directory sc8-pr-cvs1:/tmp/cvs-serv25486 Modified Files: pcm.html Log Message: Added more details on data packets Index: pcm.html =================================================================== RCS file: /cvsroot/autopilot/htdocs/pcm.html,v retrieving revision 1.1 retrieving revision 1.2 diff -u -d -r1.1 -r1.2 --- pcm.html 3 Feb 2003 18:53:48 -0000 1.1 +++ pcm.html 3 Feb 2003 19:25:56 -0000 1.2 @@ -1,7 +1,15 @@ <h1>PCM vs PPM</h1> <p> -[ Image of PPM signal ] +<a + href = "images/ppm.jpg" +><img + src = "images/ppm.small.jpg" + width = 100 + height = 33 + alt = "[ Image of PPM signal ]" + align = "left" +></a> The PPM radio protocol is a very simple serialization of the servo PWM commands, separated by a 10 ms or longer syncronization pulse. In @@ -20,7 +28,15 @@ positions. For all these reasons, a better protocol is required. <p> -[ Image of PCM signal ] +<a + href = "images/pcm.png" +><img + src = "images/pcm.small.png" + width = 100 + height = 15 + alt = "[ Image of PCM signal ]" + align = "left" +></a> PCM replaces the pulse widths with a serial bit stream that encodes the servo commands as a binary value. An onboard microcontroller reads @@ -30,6 +46,9 @@ "fail safe" position if the transmitter is not heard from again after some timeout period. + +<p> +<h1>PCM internals</h1> <p> The actual encodings are considered trade secrets of each manufacturer and they are not compatible across different brands. We have reverse @@ -43,13 +62,158 @@ <p> The PCM frame consists of four fields, each 28 ms long. Each field starts with a 2.7 ms sync pulse of either high or low polarity, follwed -either six or eight bytes of frame ID, then by four data packets of 40 -bits each. Each of these data packets consists of four 10 bit words -that are encoded with a 6B10B system, to produce 3 bytes of actual data +either six or eight bits of frame ID, then by four data packets of 40 +bits each. Each of these data packets consists of four 10 bit MSB words +that are encoded with a +<a href="#6b10b">6B10B encoding</a>, +to produce 3 bytes of actual data per packet, 12 bytes per field and 48 bytes per frame. +From now on, we will assume that all data has been converted to the +natural representation. <p> The bit clock is 150 us. There does not appear to be any syncronization mechanism other than the accuracy of the onboard clock. Bits are sampled roughly 25 us after a transition and there never appears to be a single -bit alone (minimum pulse width is 200 us). +bit alone (minimum pulse width is 200 us). At first I thought the bit +clock was 300 us, but Coert L. showed me transitions that had to be sampled +at the 150 us rate. + +<p> +I've numbered the four fields starting with the first low sync pulse. +This is because the fail safe data are transmitted twice, starting with +the low sync pulse. However, since the data are transmitted twice, it +will overlap an entire frame regardless of which ordering you use. +There are two low sync pulse fields (1 and 2), followed by two high +sync pulse fields (3 and 4) which are nominally logical inversions of +the first two fields. + +<p> +The data packet format consists of 2 bits of type selectors, 4 bits of +position delta, 10 bits of absolute position and 8 bits of checksum. +Bit zero is transmitted first: + +<table + border = 1 +> +<tr> +<td> 0</td> <td> 1</td> <td> 2</td> <td> 3</td> +<td> 4</td> <td> 5</td> <td> 6</td> <td> 7</td> +<td> 8</td> <td> 9</td> <td>10</td> <td>11</td> +<td>12</td> <td>13</td> <td>14</td> <td>15</td> +<td>16</td> <td>17</td> <td>18</td> <td>19</td> +<td>20</td> <td>21</td> <td>22</td> <td>23</td> +</tr> +<tr> +<td colspan= 2>Selector</td> +<td colspan= 4>Delta</td> +<td colspan=10>Position</td> +<td colspan= 8>Checksum</td> +</tr> +</table> + +<p> +I have not fully analyzed the type selection bits yet, but they appear to +select between absolute data for servo Channels 7, 8, 9 and 10 in some +fashion, as well as indicating fail safe frames. +The delta value is treated as an offset from the previous absoluate +position frame for this channel, with a value of 8 meaning no change. +The position is treated as a 10 bit MSB value, hence the name PCM1024. +The checksum appears to be a sum of the position and other bits; I have +not fully analyzed it yet. + +<p> +As mentioned before, each field has four data packets that we're calling +A, B, C and D. The first packet in field 1 is 1A and so on. The position +and delta channels for each normal data packet appear to be: + +<pre> +1A: Select=2 Channel 1 absolute, Channel 2 delta +1B: Select=0 Channel 3 absolute, Channel 4 delta +1C: Select=2 Channel 5 absolute, Channel 6 delta +1C: Select=0 ??? +1D: Select=0 Channel 7 absolute, Channel 8 delta + +2A: Select=2 Channel 2 absolute, Channel 1 delta +2B: Select=0 Channel 4 absolute, Channel 3 delta +2C: Select=2 Channel 6 absolute, Channel 5 delta +2C: Select=0 ??? +2D: Select=0 Channel 8 absolute, Channel 7 delta +</pre> + +<p> +To be added: Fail safe select values, checksum algorithm, more screen shots. + +<hr> + +<a name="6b10b"></a> +<h1>Appendix 1: 6B10B encoding</h1> +Thanks to Coert Langkemper for his help in determining the encoding +pattern. Without his aid, this would have taken absolutely forever. + +<pre> + '1111111000' => 0x00, + '1111110011' => 0x01, + '1111100011' => 0x02, + '1111100111' => 0x03, + '1111000111' => 0x04, + '1111001111' => 0x05, + '1110001111' => 0x06, + '1110011111' => 0x07, + '0011111111' => 0x08, + '0001111111' => 0x09, + '0000111111' => 0x0A, + '1100111111' => 0x0B, + '1100011111' => 0x0C, + '1100001111' => 0x0D, + '1110000111' => 0x0E, + '1111000011' => 0x0F, + '0011111100' => 0x10, + '0011110011' => 0x11, + '0011100111' => 0x12, + '0011001111' => 0x13, + '1111001100' => 0x14, + '1110011100' => 0x15, + '1100111100' => 0x16, + '1100110011' => 0x17, + '1111110000' => 0x18, + '1111100000' => 0x19, + '1110000011' => 0x1A, + '1100000111' => 0x1B, + '1100011100' => 0x1C, + '1110011000' => 0x1D, + '1110001100' => 0x1E, + '1100111000' => 0x1F, + '0011000111' => 0x20, + '0001110011' => 0x21, + '0001100111' => 0x22, + '0011100011' => 0x23, + '0011111000' => 0x24, + '0001111100' => 0x25, + '0000011111' => 0x26, + '0000001111' => 0x27, + '0011001100' => 0x28, + '0011000011' => 0x29, + '0001100011' => 0x2A, + '0000110011' => 0x2B, + '1100110000' => 0x2C, + '1100011000' => 0x2D, + '1100001100' => 0x2E, + '1100000011' => 0x2F, + '0000111100' => 0x30, + '0001111000' => 0x31, + '0011110000' => 0x32, + '0011100000' => 0x33, + '0011000000' => 0x34, + '1111000000' => 0x35, + '1110000000' => 0x36, + '1100000000' => 0x37, + '0001100000' => 0x38, + '0001110000' => 0x39, + '0000110000' => 0x3A, + '0000111000' => 0x3B, + '0000011000' => 0x3C, + '0000011100' => 0x3D, + '0000001100' => 0x3E, + '0000000111' => 0x3F, +</pre> |
