Mode Zero

First I want to thank Phil for his 7 channel Arduino encoder documentation and sketch! Converting an old Heathkit GD-19 is proving to be a fun project!

After playing with the newest 7 channel "Dipswitch" encoder program, I wanted to make some changes to make it more practical for the GD-19 conversion. Note, this is still in the "Nano on a Breadboard" state, and not installed in the transmitter case yet.

1. The channel 7 servo slow routine was reassigned to the output of channel 5 (A4). This way a 6 channel receiver can be used and still take advantage of the switch controlled channel with the servo slow routine.

2. The aileron pot wiper is hardwired to both the aileron channel 1 input (A0) and also the channel 6 input (A5). This was done to simplify dual aileron servo setups with a 6 channel receiver and eliminate the need for a Y-harness.

3. Unfortunately, using the same input source, channel 1 and channel 6 travel in opposite directions, which doesn't really work for dual aileron servos. This was solved by changing the program to have channel 6 run in reverse of the original sketch. Now both the aileron channel and channel 6 travel the same direction.

4. Since the dual aileron setup uses channels 1 and 6, and the switched servo slow output uses channel 5, this leaves the thumbwheel control on the front transmitter case controlling channel 7. So on a 6 channel receiver, the thumbwheel is controlling a ghost channel 7. However the convenience of the dual aileron servo setup is well worth the sacrifice of losing the thumbwheel control.

5. For single servo ailerons, the thumbwheel channel 5 input (A4) is mapped to the output of channel 6 (A5). This lets the thumbwheel control on the front of the case operate the channel 6 (A5) output on a 6 channel receiver. Channel 7 (A6) now becomes the second aileron servo, but this channel is ignored on a 6 channel receiver. This routine is enabled by grounding pin D2. Otherwise the second dual aileron servo defaults to channel 6 (A5) output.

6. Holding the aileron stick to one side on startup now reverses both the aileron channel 1 (A0) and channel 6 (A5). Phil pulled a fast one on me here. For awhile this only reversed channel 6 one time after a calibration. Then it would only reverse the aileron channel 1 (A0) after that, until the next calibration routine was initiated. It took me awhile to find out where he disabled reversing of channel 6 and edit it out. Now the reversing sequence works on both channels every time, just like it's supposed to.

7. I'm still confused about why the default PPM Pulse Length (PPM_PulseLen) is set to 300. As a long time Taranis X9D+ user with DM9 module experience, I'm familiar with the need for the pulse length to be set to 400 for Spektrum instead of the default value of 300. I've tried both pulse lengths with the AnyLink2, and they both seem to work. I guess my question is why was the default pulse length chosen to be 300? Is 300 the default for FrSky ACCST? How do I determine which pulse length is the best choice for the AnyLink2?


So far I'm very pleased with the simplicity and capability of the Arduino encoder! It far surpasses the capabilities of the original GD-19, but will only require the addition of one or two new external switches, which won't spoil the original look of the transmitter (other than a 2.4 antenna).

The Arduino is a far better solution than my original idea of transplanting the guts of a Spektrum DX5e into the GD-19. It's been fun so far, and will no doubt only get better!

Hi Dave, thanks for the props, glad you're enjoying the conversion process! I love to see these old sets flying again, its so appropriate with older models, like silk and dope!

The 400uS thing is down to Spektrum mis-interpreting the long-standing convention that PPM analogue data is measured from edge-to-edge and therefore the pulse width is irrelevant. A value of around 250 to 300uS was common in the old AM and FM modulated sets - this convention precedes the Taranis and Spektrum by decades! Spektrum unfortunately chose to include the pulse width in their calculations, which is why theirs are the only modules on the market which are pulse-width-critical. I've discussed this with Andy Kunz, he explained that they used a new development team for the DM8 and 9. Its their mistake, not mine, but the encoder allows for it via the dipswitches - and channel 7 already moves to the channel 5 position if you choose 400uS 'Spektrum' option.

Like 99.9% of systems your Anylink should not be critical of PPM pulse length, use either Frsky/Orange/Flysky/Anylink/etc/etc dont have a 'default' PPM pulse width - its purely a Spektrum concept.

Just a point if I may, my reversing system doesnt lend itself to non-centering controls, thats why the aux channels dont reverse, though its trivial to change direction in the code, so when you say "Now the reversing sequence works on both channels every time, just like it's supposed to", theres an implication that you 'corrected' a code problem which isnt the case, it does act exactly as intended!

Cheers
Phil

Thank you for the explanation about the 400uS issue! That helped!

So if I'm understanding this correctly, the 400uS applies to any module that uses the DSM2 or DSMX protocol, which also includes the Orange DSM2/DSMX module. Maybe even the Multi-Protocol module when operating in DSM2/DSMX mode? The Spektrum protocol requires the 400uS, not just the genuine Spektrum hardware. Is this correct?

Phil_G wrote: 04 May 2020, 11:19 ...but the encoder allows for it via the dipswitches - and channel 7 already moves to the channel 5 position if you choose 400uS 'Spektrum' option.

You are correct. Grounding D5 moves channel 7 to channel 5. But channel 5 moves to channel 6, and channel 6 moves to channel 7. This ends up moving my second aileron servo to channel 7, where it's out of reach of a 6 channel receiver. The modification I made only swaps channel 5 and channel 7, leaving channel 6 alone.

Phil_G wrote: 04 May 2020, 11:19 Just a point if I may, my reversing system doesnt lend itself to non-centering controls, thats why the aux channels dont reverse, though its trivial to change direction in the code, so when you say "Now the reversing sequence works on both channels every time, just like it's supposed to", theres an implication that you 'corrected' a code problem which isnt the case, it does act exactly as intended!

I'm really sorry that you misinterpreted my comments, and I apologize for that. I should have chosen my words more carefully.

You were (and still are) exactly correct to exclude the non-centering controls from the reversing sequence in the programming logic. Otherwise they could easily be accidentally reversed each time the radio is turned on.

But in my case, the wiper of the aileron stick pot is hardwired to the channel 6 input (A5), and the same wiper is also hardwired to the channel 1 input (A0). Since channel 6 (A5) is now being fed by a self-centering control device, there is no chance of accidentally reversing channel 6 (A5) when the radio is turned on. So after modifying the programming to allow reversing on channel 6, I should have written "just like I wanted it to do" instead of writing "just like it's supposed to". I sincerely apologize for my poor choice of words.

Feeding the channel 1 (A0) and channel 6 (A5) inputs in parallel from the aileron stick pot wiper makes it easier to setup dual aileron servos. It also allows for flapperon mixing in the future. But this requires that both aileron channels get reversed at the same time in order to reverse the total aileron function, and not just one of the aileron channels.

Dave McDDD wrote: 04 May 2020, 22:54 Thank you for the explanation about the 400uS issue! That helped!
So if I'm understanding this correctly, the 400uS applies to any module that uses the DSM2 or DSMX protocol, which also includes the Orange DSM2/DSMX module. Maybe even the Multi-Protocol module when operating in DSM2/DSMX mode? The Spektrum protocol requires the 400uS, not just the genuine Spektrum hardware. Is this correct?

No thats not so Dave the PPM input is a separate thing entirely, specifically only two modules, the genuine Spektrum DM8 and DM9 need the 400uS pulse width, all other manufacturers modules behave properly, whether DSM/X or otherwise. Its not at all related to the Spektrum protocol. Any module will work to 400uS but only the DM8 and DM9 need 400 for correct servo timing. We could all use 400uS but it grates to adopt a known mistake, so we dont

Some PPM decoding software can under extreme conditions be confused by 400uS pulses.
Normally, from edge to matching edge, the channel spacing convention is 1000uS to 2000uS.
But some systems allow you to set travel volume as high as 120%, so channel spacing can be 800uS to 2200uS. The width of the PPM pulse itself varies from system to system, some are 250uS, most are 300uS, Spekky is 400uS. When a 120% PPM source also uses a 400uS PPM pulse, we can hit trouble.
In this case the gap between pulses, trailing edge to next leading edge, is 400 to 1800uS (ie channel spacing minus ppm pulse width). At 1800uS its fine, no problem. But at 400uS and with a 400uS PPM pulse width, the commonly used timing method method cannot distinguish between the PPM pulse and the gap between pulses as it relies on timing each high or low state from the moment it changes. It will of course re-sync perfectly when the stick is released and the timings return to normal bounds.
The whole 400uS thing is awkward and unnecessary, but unfortunately Spektrum are stuck with it!
Its one of many reasons I'm not a Spektrum fan, the other main reason being their early inability to design a low-dropout regulator thus spawning the whole unnecessary 5-cell thing, then theres 'satellites', the silly AC coupled trainer signal, their frequently-replaced RF boards... ...and.... and...
Re the other stuff I just wanted to point out that theres no problem with the original code
Cheers
Phil

I really appreciate the detailed explanation about the DM8/DM9 modules and the 400uS "mistake". Now it makes much more sense. It also more thoroughly explains the compatibility issues we went through with the Taranis and DM9 modules many years ago.

8+ years of Futaba FASST with a 12FG = zero unexplained problems
5+ years and counting of FrSky ACCST with a Taranis X9D and X9D+ = zero unexplained problems
My personal experience with Spektrum hasn't been that great. We will leave it at that.

Phil_G wrote: 04 May 2020, 23:55 Re the other stuff I just wanted to point out that theres no problem with the original code

I agree 100%!

Re: 300uS default pulse width.

As Phil correctly states, this has been a default since the earliest days of digital systems, and the answer to the the question why is quite interesting.

The very earliest single channel RC systems worked by detecting the presence or absence of a carrier wave - pure RF. Of course, during the "absence" of the carrier, the receiver was wide open to any other signal that happened to be around. This was not good for interference rejection!

The next step was to leave the carrier on all the time, but to modulate it with an audio "tone". Now the presence (or absence) of the tone was the operating signal. The carrier was on all the time and would (hopefully!) drown out any interference. The "tone" system carried on through reeds and analogue proportional, but when digital systems first appeared, we were back to using an interrupted carrier wave to carry the information.

The very first digital set - the Spreng / Mathes "Digicon", transmitted the pulses un-encoded. This resulted in the carrier being "off" for relatively long periods. This caused problems for the AGC (Automatic Gain Control) essential in AM receivers, and also left the receiver open to interference during the "off" periods.

I believe it was Frank Hoover, of F&M, who originally suggested the "spike-off" modulation that became the industry standard. Instead of transmitting individual pulses, the carrier was interrupted very briefly to mark the start and finish of the pulse. Now the carrier was on almost continuously, with a big improvement in interference rejection, AGC performance, and some other issues that plagued the original Digicon.

The 300 uS "off" period was the shortest that would allow 100% modulation (carrier completely off) necessary for the relatively crude receivers of the era, whilst at the same time fitting inside the FCC's (American regulator) mandated bandwidth requirements.

To fit inside the required bandwidth, the edges of the pulses needed to be shaped to a rise and fall time of around 100uS. Any sharper would splatter into the adjacent channel. So we had a 100uS fall time, 100uS "Off" period and another 100uS rise time for the carrier to turn back on again!

With the introduction of FM, there was no "off" time, so the pulses could - in theory - be made wider than 300uS, but not narrower, because of similar bandwidth requirements. The servo pulses vary between 1 - 2 mS (1000 - 2000 uS typically). To ensure reliable decoding, you don't want to have the "off" time more than half the minimum servo pulse time, ie: 500uS.

So we end up with a requirement of a minimum of 300uS and a maximum of 500uS. For AM, we need the shortest possible "off" time for the reasons mentioned above. For FM, you can go up to 500uS, maybe even a bit more, but not too much, but designers tended to stick with 300uS because "if it ain't broke, don't fix it!".

I'm guessing that the people who designed the Spektrum module in question were not model control specialists, and knew nothing of this history!

Of course, with spread spectrum you are no longer transmitting pulses anyway, just data from which the receiver can reconstruct a pulse train to keep existing servos happy. In theory (and some systems do this) you could just send the serial data direct to the servo and let the servo amp use the information directly without going through the PPM stage. But then you lose backward compatibility with the millions of servos out there in the wild!

This is all a bit of an over-simplification, but hopefully explains how we got where we are!

Here endeth the lesson!



--
Pete

Bravo! Bravo! Encore.

Pchristy,
Thank you very much for that detailed history lesson of how proportional RC started, and the steps it took to get where we are today. As somebody who started off in RC way back in 1969 at the age of 15 by building a Heathkit GD-19, your post is fascinating information to me!

If anyone wants to know more about how our systems came about, there are some fascinating stories to be found here:

http://www.rchalloffame.org/index.html

The first feedback (non-waggling!) system that I can find mention of is Al Doig's "Ulti-Multi" homebuilt set. The first commercially available (analogue) proportional was the Space Control.

Digital first appeared with the Spreng / Mathes "Digicon", which also pioneered the twin-stick arrangement generally used today. Previous sets tended to use single-stick "cuddle-box" arrangements. The first mass produced digital set appears to be the Bonner Digimite, of which I'm fortunate enough to own an example!

There are lots of pictures of all these sets, along with background history, at the above site. You can spend hours there learning about how all the famous names of the day came about!

Enjoy!

--
Pete

The conversion to Arduino of the first Heathkit GD-19 is a success! I just got done completing a short test flight of an electric PBF foamie in my yard, and it worked perfectly. The one on the left is a future conversion project, and the one on the right is my first conversion. The encoder is a Nano on a modified redboard shield. The RF section is an original Anylink. The software is Phil Green's 7 Channel Encoder sketch, with some modifications for dual aileron servos, flapperons, 100:100 elevons, and some other things. The stick pot wiring was scavenged from some dead 9 gram servos, which worked great to plug into the redboard. Extra spektrum bind plugs are used to enable/disable the elevon mixers, the calibration mode, and the channels 5 and 7 swap. The redboard, buzzer, and battery are held in place with velcro for now.......maybe permanently. The switch on the top right is the throttle safety/cutoff, and the one on the left is the flapperon enable/disable. I didn't install a channel 7 switch yet, since I doubt this transmitter will ever be used to fly something that needs 7 channels.

I haven't figured out how to make the original meter work with the 2S life battery yet. I've seen some photos of others with a digital display, which would be even better. Still need to do some more researching.

Thank you Phil for making the 7 channel encoder sketch available to everyone!