New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

ArduPPM: Added Spektrum satellite support #520

wants to merge 3 commits into
base: master


None yet
6 participants

Kwarf commented Aug 28, 2013

This adds the ability to directly attach a Spektrum satellite to the APM.

Since there's no free timer available I used an overflow interrupt on the timer that is used for the PPM encoder to time the sampling of the data bits.

This is only tested on the APM2.5 (ATmega32U2). I have tested with 2 different satellites bound in 2 different modes, 7 channels at 22ms frame interval and 9 channels at 11ms frame interval. See for more info about the protocol.

The jumper should be connected between channel 3 and 4 to enable this mode.

Known issues

  • When the USB cable is connected it has a hard time to keep up with the sampling, so it will cause some packets to be dropped, it may also read the channel position incorrectly causing a servo glitch. I don't really see this as a problem since you don't use the USB in flight, I have measured without it attached and it did not drop a single frame in 5 minutes.
  • 11 bit frames are not supported, I only have a DM8 module so I can't configure it to output 11 bits, and I didn't feel confident implementing something I cannot test.

This will obviously need much testing before being merged, but I know that this feature has been requested on the forums multiple times.


This comment has been minimized.


JohnArneBirkeland commented Sep 2, 2013

Great work, and creative use of AVR hardware.

I don't have Spektrum satellites to test with, but the code looks solid.
As I see it the main obstacles to making this official would be.

  • Testing, testing and more testing..
  • Unpredictable behavior when USB is connected, this would most likely generate a lot of user support.
  • Since we a at edge of what is possible to bit-bang with AVR, what is the margin for error with regard to varying clock crystal frequency stability etc.
  • External electronics needed for 3.3v conversion. Simple for some, but complicated for others.

This comment has been minimized.

Kwarf commented Sep 3, 2013

I played around a bit with HIL and X-Plane this evening, it works surprisingly well over USB. However I found a critical bug and would strongly advice against anyone testing it in real flight yet.

When I was testing the failsafe by turning off my transmitter and turning it back on again I was unable to resume control of the plane, and the PPM RX LED still indicated failsafe (solid on). So back on with the logic analyzer to see that the frame header had changed. It seems it does this to inform the main receiver of signal dropouts when you have a regular setup.

I saw both 0x00 0x57 and 0x00 0x2C so it isn't consistent either. I will look more into this problem tomorrow, taking more measurements and searching online.

Kwarf added some commits Sep 4, 2013

ArduPPM: Fixed deadlock after radio outage
The frame header can't be used to reliably sync frames since it has
been seen to change after short radio outages. We now check the time
between bytes instead.

This comment has been minimized.

Kwarf commented Sep 4, 2013

I decided that checking the frame header wasn't a reliable way to sync since it may change during flight and we don't have access to protocol specifications.

I have changed the code so that it measures time between bytes instead. It checks that the line has been silent for >8ms when accepting the first byte, and then checks that the time between each byte in the frame does not exceed 100us. This allows me to ignore the header completely.

It would be nice if any interested people could test this using HIL or just the MissionPlanner and report back here, to see if it works with different transmitter/satellite combinations.


This comment has been minimized.

wolkesson commented Oct 22, 2013

I'm very keen on testing this patch! I've tested it with the HIL, but are having troubles keeping the required frame rate (update rate from FG->AMP->FG) because of the USB implications of the patch. I'm simulating a Quad, but consider switch to a plane since I guess that won't require the same frame rate to be kept stable. Question is if one could prioritize USB when connected? Also I guess any code that could be moved out of the interrupt would help.

I haven't dared using it in flight yet. I willing to help increase performance in USB mode for the HIL to work. Where do you think it's best to start? Prioritizing USB when connected maybe?


This comment has been minimized.

Kwarf commented Oct 22, 2013

I suspect that the USB performance will be hard to improve (I haven't looked at the code at all). The only "trick" I have is that you can remove the jumper when downloading flight logs and similar stuff that's USB-heavy.

I think the best solution for you would be to run the telemetry data over the regular serial port instead of the USB when in HIL, either by wireless telemetry link or a serial port adapter cable. I'm currently waiting for the new Pixhawk to ship so I'm afraid I won't do any more development/testing on this patch.


This comment has been minimized.


Olivier-ADLER commented Nov 9, 2013

Great work Kwarf !

I'm actually merging the actual ArduPPM code with my working version of ArduPPM v3, adding PPM redundancy mode and a few minor failsafe modifications to switch to the new 800us (or preferably 700 us) missing channels failsafe reporting.

I did not know the existence of this Spektrum mode pull request before i did start the merge. Because ArduPPM v3 merge is quite a lot of work and ArduPPM is a critical piece of code, we'll see if we'll merge Spektrum mode later when the PPM redundancy mode merge will be fully tested. Or we could perhaps compile s separate bin if the code cannot enter the official release.

John i will do a pull request with the v3 RC1 version in a couple days so that developer testing can start.


@gmorph gmorph added the APM label Jan 23, 2015


This comment has been minimized.


tridge commented Aug 23, 2015

We've stopped adding new features for AVR boards now, but if someone wants to volunteer to be the AVR maintainer then we could add new HAL_AVR features to point releases for plane/rover.
I'll close this now, but if you want to volunteer to be a maintainer then please raise it on drones-discuss

@tridge tridge closed this Aug 23, 2015

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment