PPM Translator Processor for Spektrum DX6 (Unigen) RF Deck.

[Mr.RC-CAM]

In the Radio Forum there is an interesting discussion that involves installing the Spektrum DX6 RF Module into a JR 6102 Tx. For full details please visit the sticky: Spektrumizing a JR6102 with DX6 Radio (http://www.rcgroups.com/forums/showthread.php?t=458314).

Some background: The Spektrum DX-6 RF deck utilizes a FCC certified radio modem made by Unigen Corp. This little RF module is fully FCC certified, on its own, and only requires a minimal amount of additional spectral testing (conformance validation) to meet the FCC requirements for use in ANY wireless product. Details are in the Unigen data sheet: JUNO-LPA Info (http://static.rcgroups.com/forums/attachments/5/9/2/0/695419.attach?FyWsH8Oyn8ElqJ6sHxMsGJ4xqJkyYaOxMwf7 BGH5ZGx2LKOjoTywLKEco79yZxMjMTL=). The FCC impact has been hashed to death in the other discussion, so please read it rather than post the same comments here.

The project discussed here is a small 8-pin microcontroller that can be used to incorporate the Spektrum RF deck with nearly any R/C Tx that has six or more channels. The integration requires someone with better than average electronic skills. So, keep that in mind.

The microcontroller is a Microchip PIC12F683 IC. It requires software, which is provided as a license-free-for-hobby-use download. The PIC accepts any Logic Level PPM encoded modulation, automatically inverts the PPM signal if needed, then outputs it as a negative going logic PPM signal that the DX-6 RF deck requires. It also truncates all servo data past the Ch-6 position, per the DX-6 reset gap requirements. Consider it sort of a universal PPM translator that "speaks DX-6."

The following posts will highlight the basic details. The rest is up to the technically competent user and their Tx's requirements. Please keep in mind that this project is not suitable to a beginner electronic tech. More importantly, the Part 95 FCC registration for the original R/C Tx will become invalid and the Unigen FCC registration ID will only be valid if the user performs the Part 15 spectral tests per the Unigen data sheet.

[Mr.RC-CAM]

The basic schematic is below.

(1) The PIC requires 3.0VDC to 5.0VDC. If you cannot easily steal the 5VDC from the host Tx, then just use a common LM7805 VReg IC. Be sure to include the stability caps, as proposed by the Vreg's data sheet. You can also use the DX6's local 3.3VReg to power the PIC (change the D1 zener to a 3.3V type if you do).

(2) The PPM modulation input (J1-4) is provided by the host R/C Tx. If it is an open collector TTL level, then the Zener protection clamp diode can be omitted. Starting with V1.2, this input includes an internal pull-up resistor, which eliminates the need for an external pull-up in those apps that need it.

(3) The PPM output connects directly to the DX-6 RF deck PPM input.

(4) The LED is for status only and can be omitted. During use, if a repeating 3-blink sequence is seen, then the PIC is not detecting PPM on its input. If it blinks constantly, then it is properly locked on the Tx's PPM signal and all is well.

(5) PIC Pin-7 is for non-DX6 applications. It is a "positive logic" PPM output.

(6) PIC Pin-5 is a special output. Starting with V1.4, it is used with some Futaba Tx's to help sync the DX6 during boot. Please see post #162 (http://www.rcgroups.com/forums/showpost.php?p=6108062&postcount=162) for full details.

.

[Mr.RC-CAM]

The Hex file for the PIC12F683 is attached here. It is license-free-for-hobby-users only. It cannot be resold in any form (including pre-programmed PIC's).

The PIC fuses are as follows:
WDT: ENABLE
MCLR: DISABLE
CODE PROT: DISABLE
BODEN0 = 1
BODEN1 = 1
FCM = DISABLE
PWR TIMER: ENABLE
EE MEM PROT: DISABLE
IESO= DISABLE
OSC: INTRC OSC I/O

[RickM]

sub

[Mr.RC-CAM]

The high end JR radios use a plug-in RF module. When it is removed, the five pin connector is exposed. This connector can be interfaced to obtain power and the PPM modulated signal.

(1) The photo below shows the connector.
(2) The schematic drawing shows a simple way to derive crude 5VDC power from the Transmitter's 6VDC regulated supply.
(3) The native JR XP8103 PPM signal is seen here. It is 8-Ch, positive logic.
(4) The last photo shows a scope display of what the processed PPM looks like (notice it reflects a 6-Ch PPM signal, even though the XP783 and XP8103 send 8-Ch data).

The PPM translator has been tested with both a JR XP783 and a XP8103 using the method shown in dwg 2. In both cases the translated PPM signal looks just like the encoded signal to the stock DX-6 transmitter.

.

[LukeZ]

Stupendifying! I just ordered a JR 9303 - now if I can only scrounge up enough pennies for a DX6, after the beating it gave to my wallet! :rolleyes: :D


Luke

[hilgert]

The XP6102DX mod is nice in that it is self-contained, but this is actually "THE" solution, as it enables one to use the Spektrum as a "module" on a wider range of TX's. The JR XP9303 or an EVO 9 are my next targets for this.

-Hilgert-

[clive45]

If only the DX6 module could be fitted into the JR plugin module.

[Nicetie]

Mr.RC-CAM

Is there any reason to use +5V instead of the +6V regulated for the circuit? I believe
most IC's are rated for 7V max so 6V is well within operating range. The logic levels
shouldn't change with supply voltage.

Ken K5MBV

[Mr.RC-CAM]

Is there any reason to use +5V instead of the +6V regulated for the circuit? The PIC should not be operated above 5.5VDC. In most cases there will be 5.0VDC regulated inside the Tx. The circuit requires <15mA to operate (less than 2mA if the LED is omitted).

In the case of the JR RF Module port, you can either use a LM7805 on the BAT+ pin, or use the JR port's +6VDC pin and do the crude two diode V-drop trick shown in the example circuit. The supplied voltage should fall between 4.7VDC to 5.2VDC.

Also, please note the D1 zener signal clamp on the PIC's PPM input. In the case of the JR series of Tx's, some have very large PPM signal amplitudes that would damage the PIC chip. For example, my XP783 sends PPM that exceeds 9V, but the XP8103 is standard 5V TTL logic. I suspect other Tx brands have similar situations. The Zener is needed to keep the input signal range under 5V. It is best to use an o-scope to see what the host Tx is providing, but if that is not possible then just include the Zener as a safety precaution.

FWIW, the circuit is Muntzed to its minimal parts count to keep it simple. If I was building a commercialized version (not going to happen) then it would be a bit more complicated. I think what is shown here should get the job done, but please feel free to expand the circuit to suit your needs.

[Nicetie]

"The PIC should not be operated above 5.5VDC."

I should have looked at the data sheet. ....my bad

Ken K5MBV

[Mr.RC-CAM]

If only the DX6 module could be fitted into the JR plugin module.Too bad that spare cases to the NET-J72P module are not available. With that, and some imagination, I think a nice looking plug-in solution could be devised for JR Tx's.

BTW, as a community effort, I'm hoping that the project details presented here will be utilized by a fellow that has access to a commercial RF lab. With the right talent (i.e., knows what he is doing, will work for free), we could resolve the FCC conformance validation issues. Please include a JR XP8103 in your tests. :)

[thanhTran]

Wow, cool idea! This should make DX6 works with 8-9-channel radios out there :)

[hilgert]

BTW, as a community effort, I'm hoping that the project details presented here will be utilized by a fellow that has access to a commercial RF lab. With the right talent (i.e., knows what he is doing, will work for free), we could resolve the FCC conformance validation issues. Please include a JR XP8103 in your tests. :)
Part 15.23 allows one to do untested modifications to Part 15 equipment (and we are not really modifying the RF deck here) on up to five units for personal use. As long as one does not sell his work for gain I don't believe one has to go through certification (for personal use).

When my XP6102DX was tested at an FCC-licensed testing facility it was not really necessary other than to get the curmudgeons at the AMA moving to acknowledge (after working with the FCC) that the mod was not illegal. Whether you take the PPM signal from a 6102 or a 9303 (or whatever), it's still a PPM signal from the host TX, no different than the orginal mod on the 6102.

IMHO

[hilgert]

Mr.RC-CAM, take a look at your PM - I have another idea.

[macr0t0r]

Well now! In other words, since only the command is being modified, rather than the RF board, this should still be FCC legal! Woo hoo!

Looking at my DX, you'd have to cut and stack the board to squeeze it into a JR Module. However, the blank sides can be trimmed so that it'll fit in the plastic cases that gyros and receivers are sold in. That should be pretty unobtrusive on the back of the radio, and it would give you a case to mount the antenna on.

- Jim

[Phil Cole]

Jim, be sure it's not a multi-layer board before you start trimming. At least make sure there's not a power-ground short before applying power. Do this by measuring the resistance of the 3.3 V regulator output to ground (unpowered) before and after cutting.

[macr0t0r]

Oh, I won't be experimenting. Someone else already did it successfully, and I will just be copying his work.

- Jim

[macr0t0r]

Alright, I've done plenty of soldering and adding/replacing components on PC boards. However, I do not have a PIC programmer (even worse, I use a Mac). I realize the whole profit thing, but would anybody be willing to program a chip I send them if I include the postage to send it back?

Otherwise, I've found some sources of hacked downloaders that enable OS X to use the Microchip Pickit 1 Flash Starter kit. Ugh...I'll need to find out what adapter it needs to program this chip. Yeesh.

FYI, I have a Spektrum DX6 and a JR 388 TX (with a JR XP8103 on the way). I'm going to gut an old ch42 AM module to work as a plug and hold these electronics.


For your info: here is the thread about turning the Spektrum into a Hitec Module (complete with cutting the board and fitting it into a plastic case):
http://www.rcgroups.com/forums/showthread.php?t=489403

- Jim

[macr0t0r]

I looked again at the oscilloscope pics. How many ms per division on that chart? It almost looks like we already have the requisite 6.5ms pause at the end of 8 channels (with possibly cranking down the 8th channel to give a better margin). If so, then a transistor mod should only be required!

I'll have to dig up that mod and try it out on the JR 388.

- Jim

[Mr.RC-CAM]

... almost looks like we already have the requisite 6.5ms pause at the end of 8 channels Agreed. Please see this post:
http://www.rcgroups.com/forums/showpost.php?p=5725033&postcount=1270

[Mr.RC-CAM]

Update: PPM Translator PIC Validation is Complete.
Mel was kind enough to let me use his DX6 system to validate the PPM translator software. Before his system had arrived, I updated the firmware with some last minute tweaks (newly posted hex file is the updated version).

I am happy to report that everything worked great. The chip accurately detects positive or negative polarity PPM signal logic. Regardless of input polarity, it re-formats the PPM in the require negative logic format. It truncates the channel count to six channels max, so the DX6 reset gap spec is met, regardless of Tx setup. There is no loss in servo resolution and I witnessed no servo jitter.

Other ways to skin this cat:
Moving past the PPM translator concept, I also took my JR XP8103's PPM signal and merely inverted it with a transistor. This Tx has a long 22mS frame period so there is still room for a 6mS reset gap, even with 8 channels. So, the DX6 still worked, despite getting sent eight channels. Keep in mind that aggressive ATV settings can create a situation where the 6mS reset gap is not met.

My thanks go to Mel and his generosity.

[macr0t0r]

Congratulations! The 9303 owners will love you.

Out of curiousity, what resistors did you use for the inverter with the NPN transistor? I know some use 10K and 4.7k, but I'm not sure if those are good values with the 8103.

Man, I really need to get my computer oscilloscope running again.

- Jim

[Mr.RC-CAM]

Regarding the transistor inverter solution, the resistor values are not fussy; 4.7K or 10K are fine. Be sure to design your inverter so that the PPM input to the DX6 module has reasonable TTL amplitudes.

FWIW, it would not be prudent to just install an inverter on the Tx's PPM signal, hook up the DX6 RF deck, perform a casual servo test, then assume the job is done. The Tx's PPM reset period needs to be measured, with each and every permutation of stick, knob, and switch position (while ATV/EPA mix is maxed out, or at least set at the max you will EVER use). You will want to ensure that the 6mS PPM reset threshold is not violated. It would not be good to discover the problem while in the air.

The advantage to the PPM translator chip is that it ensures that the 6mS reset gap is met. That, and it decides whether or not the native PPM signal needs to be inverted, which perhaps makes for a more trouble free installation. Or so I hope. :)

[macr0t0r]

Perhaps so, but I lack a PIC programmer. I DO have the ability to hook a probe to an audio cable and use my computer as an oscilloscope to confirm the spacing of the PPM signal. My intent is to dial down the ATV of any unused channel to provide sufficient margin.

- Jim

[Isaac F]

Regarding the transistor inverter solution, the resistor values are not fussy; 4.7K or 10K are fine. Be sure to design your inverter so that the PPM input to the DX6 module has reasonable TTL amplitudes.

FWIW, it would not be prudent to just install an inverter on the Tx's PPM signal, hook up the DX6 RF deck, perform a casual servo test, then assume the job is done. The Tx's PPM reset period needs to be measured, with each and every permutation of stick, knob, and switch position (while ATV/EPA mix is maxed out, or at least set at the max you will EVER use). You will want to ensure that the 6mS PPM reset threshold is not violated. It would not be good to discover the problem while in the air.

The advantage to the PPM translator chip is that it ensures that the 6mS reset gap is met. That, and it decides whether or not the native PPM signal needs to be inverted, which perhaps makes for a more trouble free installation. Or so I hope. :)


Hello Mr. RC-CAM,

Please check this SHIFT INVERTER Schematic. I found it at http://fritzthecat.250free.com/inverter.html I e-mail Fritz and he point me to the updated one with a Zener Diode and a 270 ohm Resistor.

http://www.honesty.com/imagedata/5/9/4/13586594.jpg

So what you think? Can I use it to shift from + to - my JR 783 output?
In my case, what I am looking for is that my 72mhz JR XP-783 Transmitter drive also 72mhz Futaba receivers.

THX,

Isaac

[Mr.RC-CAM]

HEF4030 Pins 4, 10, and 11 should not be grounded. Otherwise, it looks like it should work.

[hilgert]

Spektrumization of a JR XP9303 internally, so now glitch-free goes full-feature.

Spektrumizing a JR XP9303 (http://www.rcgroups.com/forums/showthread.php?t=546434)

-Hilgert-

[Thomas B]

Excuse my electronics ignorance, but will this PPM translator processor enable one to use a Futaba TX and that input to the translator and DX6 RF board??

I realise that a different PIC coding will likely be needed...but this seems like a ray of hope for Futaba users...:)

[Nicetie]

Excuse my electronics ignorance, but will this PPM translator processor enable one to use a Futaba TX and that input to the translator and DX6 RF board??

I realise that a different PIC coding will likely be needed...but this seems like a ray of hope for Futaba users...:)

That is what I understand. Also there would be no requirement for additional
PIC encoding. The intent of this circuit is to provide a universal translation of the polarity and reduction of channels to the 6 required without any operator input.

Mr RC-CAM can explain his programing. He has described the circuit in a previous post in this thread.

Ken K5MBV

[Mr.RC-CAM]

The intent of this circuit is to provide a universal translation of the polarity and reduction of channels to the 6 required without any operator input.Yes, that is a good summary of the PIC's trickery. The PIC is a universal PPM->DX6 translator that ensures the 6mS reset gap requirement is never violated. It should work with the native PPM signal from any major R/C brand, or so I expect.

[Thomas B]

What a killer project...I am very impressed.

Who will be the first to do a Futaba conversion???

[hilgert]

My goal is obscurity; if possible I don't want to see any evidence of a modifcation if at all possible. I want my TX's to look stock, just with a strange antenna. That's why it is important to me to have the XP6102DX and now the XP9303DX (http://www.rcgroups.com/forums/showthread.php?t=546434) mods internal to the TX's. I have seen some of the other "bolt-on" mods in some other threads, and while they work, they are not "stock-looking". The 6102 mod was neat in that the board was actually designed with this in mind; the 9303 mod was a bit of a challange. To be honest, I was going to go down the path of a bolt-on type module with the 9303, then Mr.RC-CAM PM'd me that he was going to try to do it internally to the module, and I could not have THAT - I HAD to be first!!!

However, he is quite ingenious as everyone knows, and it would not surprise me to see him come up at some point with a custom pc board with a transplanted Unigen module and PIC circuit totally inside a module, not just the module cavity.

[hilgert]

Mr.RC-CAM, for the 5V supply could we just use a resistor and a 5.1V Zener across the 6V pin on the 8103 (or 9303 in my case)? The current should be under 200ma at all times (Unigen + DX6 RF processor + PIC), so you would only be dropping less than 1/4 watt (200ma @ 1A). The Zener I uses (Radio Shack) is a 1W diode. Or, it could be even less if the RF deck was powered directly from the 6V (but then more heat is added to the small space of the module cavity).

With the switching regulator I drop way less than 1/4 watt, so I'll get longer run times on the TX, but for simplicity (I have a 2500mah lipo in the TX) it would save some space and some cost. And, Nicetie suggested just dead bugging it (no pc board) as an option as well, then wrapping it (could end up the size of a ParkBEC possibly).

Thoughts?

[Mr.RC-CAM]

You can zener power the PPM PIC (it draws less than 2mA) from the Tx's 6V power pin. But rather than using a Zener, the details in post #5 could be employed. Also, the PPM PIC would probably run fine from the Unigen's 3.3V supply, but the R1 resistor (PIC pin 3) should be increased to about 4.7K.

The JR Tx's 6V pin was meant for low current sourcing. I understand that the existing JR RF modules do not use it at all. I do not know if it would be happy driving 200mA. I suspect that there would be heat issues in another place, so the problem does not go away.

If you are trying to reduce the temperature on the 3.3V linear VReg that is on the Unigen board, then a series resistor on its input would help share the heat. If you are sure the Unigen draws a consistent 200mA, and the source voltage is 3-cell LiPO, then a 33 ohm 2 Watt resistor would probably work out. Be sure to keep the resistor away from things that can melt.

As a last idea, you could replace the 3.3V linear Vreg on the Unigen board with a TO-220 packaged DC-DC Vreg from TI. This would require a couple of extra caps too, but would result in a very efficient power supply. It is what I had planned to do on my "factory looking" conversion project (on hold until I can fit a DX6 into my hobby budget).

[Comatose]

I'm just throwing out that we do make a 3.3v version of our little switcher, and its only $12. It wouldn't require any extra caps. If you're running from an 11v battery and all the regulators are linear you're looking at about a 3x improvement in flight time going to a switcher.

http://www.dimensionengineering.com/DE-SW0XX.htm

Now I'm going to have to open my DX-6 and see if they are just using a linear reg to drop from 9.6v to 3.3v. That would go a long way to explain the terrible run-time.

[Mr.RC-CAM]

Now I'm going to have to open my DX-6 and see if they are just using a linear reg to drop from 9.6v to 3.3v.That is what you will find. For the intended purpose (low cost R/C system) it is a reasonable component to use. But a DC-DC Vreg would be ideal for eeking out longer battery operating time.

[Comatose]

Okay, so I opened it up. The regulator is a d2pak linear regulator, with a 7805 pinout. Thats good news. The even better news is that there's enough space on the board to fit one of our DE-SW033 switching regulator modules with zero modification to the PCB or case, and no dead-bugging. Desolder the regulator and replace it. I'll have a writeup later tonight.

[hilgert]

The JR Tx's 6V pin was meant for low current sourcing. I understand that the existing JR RF modules do not use it at all. I do not know if it would be happy driving 200mA. I suspect that there would be heat issues in another place, so the problem does not go away.

That's why I used the battery pin and switching regulator instead - I was not sure how much current the 6V pin could source.

Also, the PPM PIC would probably run fine from the Unigen's 3.3V supply, but the R1 resistor (PIC pin 3) should be increased to about 4.7K.
Do you think this would work? If so, then a 3.3v switching supply would be the way to go all around - only one power source instead of two. Would the PIC be at risk of not working with only 3.3V?

[hilgert]

I like the 3.3V idea with the switching regulator...the ParkBECs from Dimension Engineering are a required component in all of my aircraft.

[Mr.RC-CAM]

Would the PIC be at risk of not working with only 3.3V?I expect it to operate reliably at 3.3V.

[Nicetie]

I expect it to operate reliably at 3.3V.

Let me see if I have this correct: Replace the 3.3V linear reg on the
DX6 RF board with a DE-SW033 switching regulator and use this to supply
both the RF board and the PIC translator?

Ken K5MBV

[Mr.RC-CAM]

That is what is being proposed.

Howevever, changing the stock linear VReg is not required. The DC-DC Vreg upgrade would be wanted if you will be using a 3S Lipo instead of the stock 8-Cell. Even so, there are ways to handle that situation too (see comment about 2W resistor above).

[Comatose]

I'm doing it because the DX-6 with the stock 8-cell has really bad run time. Switching to the 3.3v switcher reduced the current draw from the battery from 280mA to 123mA.

[hilgert]

I'm doing it because the DX-6 with the stock 8-cell has really bad run time. Switching to the 3.3v switcher reduced the current draw from the battery from 280mA to 123mA.
Zowie!!! 280ma is almost HALF the size of the stock battery!!!

[hilgert]

If you are sure the Unigen draws a consistent 200mA
I was guessing from a quick glance (in the car, on vacation - wife is really happy I brought my notebook PC and Verizon broadband card) at the Unigen docs. Comatose has confirmed actual readings in the post above.

[hilgert]

Neat mod to vastly increase DX6 runtime, and buy association the runtime of a XP6102DX/XP9303DX:

Doubling Spektrum DX6 runtime (http://www.rcgroups.com/forums/showthread.php?t=548325).

I will doing this mod on both my XP6102DX and my XP9303DX.

-Hilgert-

[Thomas B]

Anyone willing to sell me the chip with the program pre burned in it? No PIC burner in my neighborhood.......

I want to try this ASAP in a Futaba. I am envisioning a snap on vac formed ABS thin fairing on the back of my 9CAP that is self contained with a place to mount the DX6 tx antenna. If I want to fly on 72, I simply unsnap the fairing and plug the 72 module back into the back of the TX.

[TeamTEOR]

That would be a nice idea, and I would love to see something like that for a 9CAP, even it it just snapped into the stock module area.

[JimDrew]

TeamTEOR - ever get out to Lake Havasu? If so, you can fly with one of our 9CAPs using our new module system.

[TeamTEOR]

Show us some pics buddy. Man I live here since 96, and I have not been to Havasu yet! Maybe I can get out there when it cools off a little.

[hilgert]

Mr. RC-CAM, what about the 5.1V into a 3.3V PIC input pin? The specs say Vdd + 0.3V max (3.6V). The Zener will only bring this down to 5.1V. Does the 4.7K just limit the current to an ultra-low level such that the voltage is no problem? Or is there some internal protection mechanism in the PIC that I am not understanding?

[Comatose]

If you limit the current into the pin, the protection diode will clamp the voltage to a safe level. The 4.7k will be plenty.

There are diodes high side and low side of all the pins on a pic (except MCLR)

[hilgert]

Thanks...I had PM'd the same question to Mr. RC-CAM and he indicated the same thing. As long as the current is small the static protection on the PIC would take care of this.

-Hilgert-

[Mr.RC-CAM]

It can even be done without the adjunct zener. But because of the wide variations in PPM Modulation logic levels, and to avoid long conversations with those that insist on the external protection, the Zener is included. This solves both of those issues. :)

With the 5V Zener, and the PIC powered by 3.3V, the protection resistor should be 4.7K ohms. This puts the input current at 360uA, which is within the allowed spec. When the PIC is powered by 5V, the 1K is plenty.

[mattijs321]

NICE !!!!!!!

I just started a thread on converting my EVO9..looks like a no brainer with the software already coded.



I heard the DX6 has low resolution and it shows in the air....i assume this is only due to low resolution servo calculations and the effect vanishes completely when coupled with the signal train of a 'good' radio..right?

[macr0t0r]

That was the case with the JR XP6102DX conversions. Putting the RF board in a better TX improved the resolution.

- Jim

[Cheech151337]

Would there be any objection of making a STAMP version/port of this and allowing it to be sold in preprogrammed chips?

[Mr.RC-CAM]

If you mean the Parallax stamp, then it's tokenized run time speed is probably not fast enough to maintain quality jitter free operation. I used an 8Mhz PIC and assy code. If you do create something, you'll have to write it on your own rather than use the hex code I provide.

[hilgert]

Attached are some scope pix from my XP9303DX with the PIC chip.

The first picture is of the 9303 (Ch2) input to the PIC circuit with the resulting PIC output (Ch1 as trigger) to the Spektrum deck. On the front end of a channel pulse (not shown in detail in these pix) is a 2us lag between the 9303 input and the PIC output (2us delay to the start of the PIC pulse out), which makes sense since there has to be some processing time for the PIC. On the PIC output is a 4us lag between the end of the 9303 input and the end of the PIC output. 2us is not a big deal here (about 0.2% deviation at a 10-bit resolution on the stick), and always "plus", so easiliy compenstated for, if one even cares. As a note there are *way* less than 1024 indents on the sticks anyway (for those that have them - my 9303 is the heli verison without indents).

The second picture is of the PIC output (Ch1 as trigger), greatly expaned to show channel 2 (aileron) as the first full pulse on the top left, and the same pulse (on scope Ch2) out of the AR6000 Ch2 (aileron). You can see 1.5ms from the end of the Ch1 pulse to the end of the end of the Ch2 pulse (start of the next pulse is the *end* of the previous pulse), and the corresponding servo pulse (1.5ms total width) out of Ch2 of the RX.

The third picture is the output of the PIC (Ch1 as trigger) and the entire set of servo pulses out of the RX. I tied them all together with diodes, and you can barely see the small dips between channels (at this time setting you do not see the actuall drop, but it's there). The spacing between channels out the RX is a bit over 25us if I remember correctly. Basically everything is delayed about one pulse between the TX and the RX.

-Hilgert-

[Mr.RC-CAM]

The AR6000's 1.5mS delay before output is of interest (that is quite huge compared to the 4uS delay from the PIC). How closely does the Rx's servo outputs follow the PPM pulse? That is to say, if you use the same criteria as with the PPM IN versus PIC OUT measurements, how well does the AR6000 data map to the transmitter pulse train?

[hilgert]

I'll have to check - standby...re-watching Season One of LOST in prep for Season Two on DVD in a few weeks. I've got to set the proper priorities.

In analog RX's the pulse at the RX could be delayed by only a few usecs, but remember that in the Spektrum system the entire pulse has to get to the DX6 TX deck (so it has to wait until the entire pulse is done) and measured before it can be digitized, and then sent digitally to the RX (which appears to be one channel at a time and not one frame at a time). So, the real lag appears to be about 500us, or 0.5ms. Basically, it's "digital lag", if there is such a term.

I'll check on the match-up requested in a few minutes (during ice cream break).

-Hilgert-
The AR6000's 1.5mS delay before output is of interest (that is quite huge compared to the 4uS delay from the PIC). How closely does the Rx's servo outputs follow the PPM pulse? That is to say, if you use the same criteria as with the PPM IN versus PIC OUT measurements, how well does the AR6000 data map to the transmitter pulse train?

[Mr.RC-CAM]

So, the real lag appears to be about 500us, or 0.5ms.It looks to me like it is one PPM servo pulse width, plus some change. Since it has to wait for the current channel pulse to end, before it can act on it, that would mean the DX6 servo positions will lag about ~1mS to ~2mS, depending on the native PPM pulse width that is sent.

Basically, it's "digital lag", if there is such a term.The processing delay could be much less on a more purpose built Tx. If they eliminated the PPM conversion on the RF board and had the Tx encoder speak directly via the I2C buss to the Unigen module, then the delay would be further minimized. But, the noted 1mS or 2mS delay is not a problem that needs a solution. But no doubt someone will expect zero delay. :)

[hilgert]

Confirmed - the "real" lag is about 500us from the END of the TX pulse to the BEGINNING of the output on corresponding channel pin on the RX. So, that's 500us to digitize the PPM pulse, send it to the Cypress chip, trasmit it to the RX, decode it at the RX and send it out the pin. That's not very long (1/2000th of a second delay) in RX terms, but it does seem like a long time in computer and RF terms (and this has nothing to do with the PIC chip; measurements were taken at the output of the PIC).

So, the total delay is about 2ms at stick center. I'd have to do some more measurements using the gear switch or something to determin delays at the extremes, but I would expect a 1.5ms to 2.5ms delay from min to max, etc. The first 1-2ms must occur before the DX6 starts transmitting (in order for it to determine what to transmit digitally as a value), and the next 500us is just "everything else that has to be done".

-Hilgert

[hilgert]

The processing delay could be much less on a more purpose built Tx. If they eliminated the PPM conversion on the RF board and had the Tx encoder speak directly via the I2C buss to the Unigen module, then the delay would be further minimized.
Disection of either a DX6 TX board or an AR6000 board would have to be done in order to determine which end the delay is in (or both). 500us seems like a long time, but I would bet the real delay is in the Cypress protocol for transmission (preambles, data, postambles, etc.). I bet the actual Spektrum part is a small part of the 500us.
But, the noted 1mS or 2mS delay is not a problem that needs a solution. But no doubt someone will expect zero delay. :)No doubt. :rolleyes:

[Mr.RC-CAM]

Thanks for the packet time measurement. Did you have a chance to measure the accuracy of the Rx pulse mapping?

[hilgert]

So, the REAL lag is between 1.5ms and 2.5ms (give or take), so that's about 1/500th of a second on average. I think there will be some complainers out there (already building my list of predicted whiners), but certainly there is no way any normal flyer could tell the difference. However, now that we know, people will start having all kinds of "delay" problems I'm sure...

[hilgert]

Thanks for the packet time measurement. Did you have a chance to measure the accuracy of the Rx pulse mapping?
Yes, for a moment (LOST was calling...), and a cursory look seemed to indicate a good 1:1 mapping. Of course, THAT "is what it is", since at that point it's up to the TX to record the pulse length accurately and up to the RX to decode the pusle length accurately from the digital packet. I would HOPE they would be the same; if not the code is off or the clock is off on the TX/RX MCUs.

[hilgert]

Picture says it call - look at the Ch2 Pos Width measurement on the right - I had the aileron stick at dead neutral. A good test would be to build a PIC with Ch1 constant at 1ms, Ch2 constant at 1.5ms and Ch3 constant at 2ms. Then it would be easy to measure. It did sometimes go to 1501/02 when returning to center, but that's just how fast I let the stick go back. When I let go and let it "snap" back it pretty much ended-up at 1500ms.

I'm pretty sure this is accurate, as I got into the 9303 service menu and calibrated the sticks the other day.

[hilgert]

Update: I recalibrated the sticks *very* carefully to *dead* center, and now I get a 1502us pulse width out the RX, which makes sense with the added 2us (4us-2us) out of the PIC. That's probably why it waivered a bit between 1500 and 1502 yesterday evening.

[Nicetie]

The AR6000's 1.5mS delay before output is of interest (that is quite huge compared to the 4uS delay from the PIC). How closely does the Rx's servo outputs follow the PPM pulse? That is to say, if you use the same criteria as with the PPM IN versus PIC OUT measurements, how well does the AR6000 data map to the transmitter pulse train?

Isn't this delay insignificant compared to the total delay of a 72Mhz PPM
radio? I've never seen a comparison between stick to servo movement tiime
of the two systems. Spektrum probably has this information. Maybe they
could be persuaded to publish it. (How about it Paul?)

Ken K5MBV

[hilgert]

Ken, I bet the delay is almost nil. In an analog system there is no "processing" of the PPM pulse per se - it just gets instantly transmitted to the RX. In the Spektrum (digitial transmission) system the analong PPM pulse must be read entirely so the digitial portion knows what the D value is of the A signal, and that's where the delay comes from.

I am going to measure an analog system (72MHz) in the next day or so, but I would bet the delay is so small I would not notice it on my scope until I got the time/div on the scope down to 100us or so, or even lower.

[JimDrew]

Since data is digital, you have to know how long a pulse is before you can send it to the receiver. Unlike analog, you can't just wait in realtime due to the processing overhead of the radio packets. This lag does have a byproduct of allowing the data to be encrypted and checksum'd (which we do with our system).

If anyone whines, they should look at a PCM frame. PCM frames for Futaba and JR are 28.75ms, resulting in your controls updating less than 35 times a second. A normal PPM frame is 20ms, which updates 50 times per second. The Spektrum's frames are 22.5ms, which updates 44.4 times per second. Our frame rate is actually 10ms, which updates 100 times per second, doubling the data to provide even better protection against dropped packets.

There is definitely a "lag" between PCM and PPM.

[Mr.RC-CAM]

Isn't this delay insignificant compared to the total delay of a 72Mhz PPM radio?It is insignificant to the R/C user. It is of interest only in a technical discussion about the timing of the encoded signal. Hilgert had noticed that the PPM translator PIC delayed the PPM by 4uS (and had a 2uS symmetry offset). I merely commented here that these microsecond values are much smaller than the delay in the rest of the DX6 timing chain.

In the background, Hilgert had emailed me some of his findings before posting here. I was merely trying to lead him into realizing that what he sees as timing anomalies in the PIC have no impact to the system. The reported microsecond delays are of no concern in this R/C application, especially in light that there are more significant delays elsewhere (including the servos and control surfaces themselves). The goal is to ensure that the overall delays in the electronic and mechanical system do not get to the breaking point where a user will notice. Frankly, in the electronic domain, the DX6 conversion has room before that occurs. So, there is no need for anyone to be concerned.

[hilgert]

(which we do with our system).
Our frame rate is actually 10ms
Jim, that's great. Unfortunately your website does not work very well. I went to find your system but there is nothing on the products page, and many of the links just don't work (it's been this way for several months).

Do you actually HAVE a product for sale? As of now I only know of one 2.4GHz production RC system for aircraft, and that's the Spektrum system (the TX sucks, but the system is awesome). So, a 44.4 frame per minute update on a production system beats a 100 frame per second update on a system that is not yet for sale.

Or, have I missed something here?

-Hilgert

[hilgert]

It is insignificant to the R/C user. It is of interest only in a technical discussion about the timing of the encoded signal. Hilgert had noticed that the PPM translator PIC delayed the PPM by 4uS (and had a 2uS symmetry offset). I merely commented here that these microsecond values are much smaller than the delay in the rest of the DX6 timing chain........So, there is no need for anyone to be concerned.Exactly.

I was merely trying to lead him into realizing that what he sees as timing anomalies in the PIC have no impact to the system.
Got that part from the get-go. This is just interesting technical stuff with no practical negative implications. Also, I just got my new DSO and started playing with *all* of it's features, which is when I noticed this. If one did not posses the tools to measure this at the "atomic" level, then nobody would have noticed it in practical use.


There are two things that I pointed out. First, there is a 2us (that's 2 millionths of a second) delay on the front end of the PIC pulse, and a 4us delay on the end, so there is a net 2us "shift" plus a 2us "addition" to the pulse which introduces some barely measurable inaccuracy. BUT, it's at the "who the heck is going to possibly notice" level, and I only saw it on a digital scope "zoomed" way in. For our purposes in RC, this is at the "atomic" level and we don't really care (and it's a CONSISTENT 2us, by the way, not a random one). There is more slop than that in even the most expesive TX systems (one click on my 9303 trims is several times that). I doubt our 72MHz systems are any more accurate than that - most of the TX's probably do a worse job than the PIC and DX6 RF deck do at signal detection on the *exact* edge of the PPM pulse, and the analog RX's are probably in the same boat as well. Oh, and let's not forget about servo slop and such...

Second, there is an average 2ms (that's 2 thousandths of a second) delay (give or take) between the TX PPM pulse start and the start of the pulse out the corresponding RX channel. Most of this delay HAS to exist since the A part of the A/D conversion has to be complete before the D part can be determined and subsequently sent to the RX, etc. However, as JimDrew points out, the FRAME rate is 22.5ms anyway (and can be worse on PCM apparently, but I have never looked at that), so there is a whole 22.5ms before the frame rolls back around anyway. NASA may care about 2ms, but I don't think any of us could ever tell in practical use when flying our planes through the air 200 feet away.

Mr.RC-CAM is correct, this is really a technical "issue" that presents no practical problems. To me it is interesting to discuss, here in the DIY Electronics forum, but there is NO FIRE to be concerned about.

-Hilgert

[Lakc]

So whats the realtime delay for something like hydraulic airelon actuators. You would think it would take longer to impart inertia and flow in several feet of hydraulic lines? Just for grins, has anyone ever figgured out how much latency is found on real aircraft control systems?

[Nicetie]

So whats the realtime delay for something like hydraulic airelon actuators. You would think it would take longer to impart inertia and flow in several feet of hydraulic lines? Just for grins, has anyone ever figgured out how much latency is found on real aircraft control systems?

If the fluid had no air in the system and the actuator at the other end
was a piston there should be NO delay in any number of feet of hydraulic
line since the fluid isn't compressable.

A one inch diameter line driven by a one inch diameter piston in
New York running to Mexico City should have a liquid movement
at the Mexico City end equal to the piston movement simultaniously
applied at New York. The fluid doesn't flow any further than the piston movement, just displaces at the same speed as the piston.

Ken K5MBV

[Cas123]

Don't forget to take into consideration the stretching of the tubing, friction and inertia of the fluid. they can all add up.

Ron...

[Mr.RC-CAM]

Control surface latency is a real concern in full size aircraft. The delays come from the electronic control system, valves, actuators, and so forth. I went looking for some hard numbers and came up dry. It would be interesting to see some typical numbers from a jumbo jet as well as the faster fighter.

I should have saved the link, but one crash analysis report I came across concluded that the pilot had attempted to operate a control surface too fast in his particular aircraft, and caused a control system lockup. Yikes, what a silly design.

[TeamTEOR]

I am not sure if there would be much of a difference between the two if they are hydrolic. The difference I can see though is getting the mass of the jumbo jet to rotate, yaw, or pitch as opposed to the smaller, lighter & faster fighter jet.

[Mr.RC-CAM]

I am not sure if there would be much of a difference between the two if they are hydrolic.I'd expect them to be different because of difference in the intended application. My gut feeling is that the component choices (electronic controls, pump pressures, actuator size, etc.) to be carefully matched to the end use. I also expect that there are deliberate limits placed on the control movement speeds of some aircraft to prevent the pilot from getting into trouble.

This is getting a bit OT, so it probably would be best to start up something on the Modeling Science forum. Perhaps there are some full size aircraft designers that mingle there.

[JimDrew]

Hilgert,

Our system is not yet for sale. It has been in testing for many months. We just finished the plastic enclosure design for the 8 and 10 channel receivers, Futaba/Hitec transmitter module, JR transmitter module, and the telemetry system. I will have the first samples Friday morning. I expect everything to fit just fine. If there are no glitches, I should be able to make an official announcement of the system next week. I was originally expecting product to be available about mid October, but if we can get plastic as quickly as I am told we can, then the systems could very well be available early September. We have FCC, IC, and ETSI approvals already, so there is no certification hold up. The AMA is also fully aware of the system as well. We have several patents pending, and do not violate any other's patents. I believe that we will have a very successful product line.

As far as the website working well... it does work well, but the product database is not yet linked. We have a LOT of products that have already been created and we have been sitting on since April, waiting to make a big splash all at once. There is also a forum that is setup similar to the RCGroups forum.

[TeamTEOR]

Hey Jim, I look forward to seeing that system of your as well. It might make me dust off a couple of old nitro planes. I picked up a Futaba 9C Super, and I love it so far. Talk about taking things to the next step!

[JimDrew]

Congrats on picking up the 9C. You told me a few weeks ago about you looking for one - now you have something to use with the XtremeLink(tm). The 9C is my radio of choice, followed by the JR9303.

[Nicetie]

Don't forget to take into consideration the stretching of the tubing, friction and inertia of the fluid. they can all add up.

Ron...

Just for the example, perfect tubing with no stretch or friction is assumed.

Inertia of the fluid is not a factor. It would only limit the piston rate of
acceleration which would change with any change of piston pressure.

Ken K5MBV

[hilgert]

Finally got my PIC programmer yesterday. Also got a batch of the 12F683 chips for programming. This weekend gwh and we will build a module for his collection of TX's. We'll post some pix when done.

[Cas123]

Ahh, perfect world scenario :cool: If that was the case you would be right.

Getting back to the DX6 signal delay. how much would one notice this in practice? I would think it would be unnoticable.

Ron...

[TeamTEOR]

I may not be the most advanced pilot by any means what so ever, but I did notice the lag. It was not terrible enough to hinder my flying, but just enough to make me think an extra quarter of a second ahead with input. Not a big deal even more so if the DX-6 is your first radio, once you are used to it you will not really pay attention to it.

[hilgert]

I may not be the most advanced pilot by any means what so ever, but I did notice the lag. It was not terrible enough to hinder my flying, but just enough to make me think an extra quarter of a second ahead with input. Not a big deal even more so if the DX-6 is your first radio, once you are used to it you will not really pay attention to it.
The "lag" is only 2 THOUSANDTHS of a second (only 2 MILLIONTHS of which is introduced by the PIC). Are you using a DX6 stock? If so, the resolution on the sticks is not up to snuff. But if you are using a good TX I cannot believe there is a noticeable delay.

Again, that's a 2 THOUSDANDTHS of a second (2/1000, or 1/500, or .002 seconds). There must be some other delay (you weren't drinking beer or anything were you? :D ).

EDIT: The human brain cannot distinguish pulses or delays with a frequency above 45Hz or so, and that's almost 20ms - way longer than the 2ms delay here. I'm putting my stock in the beer theory...or perhaps the heat in Arizona got to you? Or maybe heat AND beer? :D

[JimDrew]

Who says that the Spektrum is not one full frame (22.5ms) behind the transmitter?

[hilgert]

Who says that the Spektrum is not one full frame (22.5ms) behind the transmitter?
That's a good question - I have not checked that - do you know otherwise?

[hilgert]

I have had some backgroud discussions with JimDrew - there is some neat stuff coming out of his operation very soon. I can't say any more, but I can say I'll be moving my existing RX's around planes for the next few months rather than getting additional RX's.

Hold onto your seats...

-Hilgert

[JimDrew]

People can test the Spektrum themselves. I have tested individual channel out and one frame out conversions, so the receiver was either 20ms behind or 2ms behind. It doesn't matter unless you need the retract channel to respond within a certain period of time. Look how long it takes to move the stick from full left to full right. How many milliseconds is that? I would guess a least one full frame, and I believe it to be more like 3 or 4 full frames. Paintball marker triggers don't have to move nearly as far and the finger/lever actuation is more natural than moving a gimbal, and the fastest players in the world can't exceed 50ms per movement. Resolution is the only thing that you might notice a difference with, I doubt the frame rate is ever going to be noticable. If it really was, people would have been complaining about PCM a long time ago. I have had a few people fly with this system, including Darcy Wingo (Composite ARF fame) and he was very surprised at how smooth it is compared to the stock RF setup.

[hilgert]

I think it's 2ms behind, not 20ms. But, again, as JimDrew states, who could notice? As I stated above a human can only perceive visual "changes" below 45Hz or so (actually, it's probably much lower - I remember this from somewhere). So, the real "lag" is how long it takes to notice you need to make a change, plus the time to make the change, plus the time to send the change. The later one is probably a very tiny component of the whole process.

[JimDrew]

I usually realize I need to make a change right after the wing tip hits on the harrier roll.. doh! :)

I just got an email from REDEYE RPM. I won't be getting the plastic enclosure samples until Tuesday... but they will be in black plastic instead of that dingy clear/yellow color, so I won't have to paint them for pictures!

[tungym]

RC-CAM, You are genius!! How come I miss this post for a month!
I just back from the Dayton Airshow and my 2 months query is solved by you!

[chewytm]

Hilgert,

Our system is not yet for sale. It has been in testing for many months. We just finished the plastic enclosure design for the 8 and 10 channel receivers, Futaba/Hitec transmitter module, JR transmitter module, and the telemetry system. I will have the first samples Friday morning. I expect everything to fit just fine. If there are no glitches, I should be able to make an official announcement of the system next week. I was originally expecting product to be available about mid October, but if we can get plastic as quickly as I am told we can, then the systems could very well be available early September. We have FCC, IC, and ETSI approvals already, so there is no certification hold up. The AMA is also fully aware of the system as well. We have several patents pending, and do not violate any other's patents. I believe that we will have a very successful product line.

As far as the website working well... it does work well, but the product database is not yet linked. We have a LOT of products that have already been created and we have been sitting on since April, waiting to make a big splash all at once. There is also a forum that is setup similar to the RCGroups forum.


Hi Drew,

I just won a bid for a Hitec Eclipse today in ebay. I was going to order a new Spektrum DX6 to cannibalize :eek: tomorrow! :p Am I glad I just happened to check into this thread today! Guess whether I will still be ordering the DX6 tomorrow...? :D

Will you be announcing the products here also? At least give us the website to check out and order the goodies.

Regards,

chewy

[tazdevil]

Hi,

Is anybody try this mods on a futaba 9zap or else TX ?

Mr rc-cam ?

thanks

[hilgert]

I have - it works on an 8C, and will be testing on a 9C this afternoon. The only issue is that Futaba does not use Ch1 for throttle, etc., so the failsafe will not work on throttle. Apparently the 8C/9C uses an open collector on the PPM output (which assumes the other end will have a pullup resistor), so that was a mystery to me at first until Mr.RC-CAM pointed that out. Also, if you want the "RX Ready" light on the 9C (a line on the LCD on the 8C) to come on you have to use a resistor to short back to pin 3 (I think - I'm as work right now) to let it know that the RF is working. I'll post results once this testing has been done.

-Hilgert