I just purchased an ardupilot mega and soldered input and output pins, but I am having trouble reading receiver inputs. I uploaded the sample program from Sparkfun found here ( Example Firmware ). Currently only input0 is being read correctly. 

With nothing plugged in:
All inputs read 1500

After plugging a receiver output to input0:
input0 is read correctly and some of the other inputs change to 1000

When receiver outputs are plugged into inputs 0-7:
No change and nothing appears to be read.

Any ideas? Is this a soldering mistake or a bug on the board? Also, at one point, only input4 was working and all others stopped working. I'm not sure why that could have happened.

Any help would be greatly appreciated!

- rusty

Views: 799

Reply to This

Replies to This Discussion

I suspect the problem lies in the source of the Atmega328 chips (which are used in the PPM encoder). There's been a global shortage of them and everyone (including us) has been forced to get them from any source they can. I'm guessing that some of the Atmega328s that Sparkfun got are funky. Hopefully that batch has been cleared out now...
Well I ordered the oil-pan some connectors and RX leads. Maybe they will come by the time Sparkfun sends me a new APMega.
I made some test with my APM, when are connected signals from input 0 to 5 and power on the APM, if i disconnect any input (0 to 5) and connect it in the other two free inputs, i can't see any response in the terminal, but if a make a reset in the APM, the new inputs begin to show the correct values and work fine.

Maybe the PPM code (I couldn't saw it yet) in the first start up determine how may channels are conected, and if you make any change without a reset, may seem that something is going wrong.

P.D. Sorry for my poor english.
I have been experiencing some odd problems as well. With a JR receiver all channels work correctly. With a FrSky receiver the higher channels (4 upwards) sometimes lock for up to several seconds. They appear to hold their last value and ignore the input. After some time they suddenly start following the inputs again. I have confirmed it is the PWM->PPM conversion and not my code by monitoring the PPM output of the 328. You can clearly see the values sticking occasionally. Maybe the failsafe is too sensitive?

Looking at the PWM outputs of the FrSky rx the outputs appear normal though the frame rate is slightly high at around 55 - 60 Hz. I haven't yet checked if the pulses are output in sequence or together.
Possibly built with counterfeits? See below:
I just tried the version of code in the Google code repository and it doesn't exhibit the freezing. I had to tweak it slightly to run at 20MHz as it was set up for 8MHz. I also found a link on the Wiki to some other source but it takes me to a Google docs page that says 'Select an account to use with Google Docs'. It shows my Google account but won't let me use it. Has anyone else had the same problem? Does anyone know what is the most recent code?
171 is the latest APM version in the repository.
Umm, can you clarify. Do you mean here?
When you grab the code via SVN checkout, you use this URL.


Today the rev. is 173
That is the APM main code. I am talking about the 328 PWM->PPM converter code. I am not using the APM code at all. I am using FlightOS.

The version of the PPM converter in the Google code repository does not appear to be the same as the version that comes pre-programmed into the 328.

Reply to Discussion



Season Two of the Trust Time Trial (T3) Contest 
A list of all T3 contests is here. The current round, the Vertical Horizontal one, is here

© 2019   Created by Chris Anderson.   Powered by

Badges  |  Report an Issue  |  Terms of Service