mageshms / arducopter

Automatically exported from code.google.com/p/arducopter
0 stars 0 forks source link

Loosing CH3 input after rebooting APM 2560 #157

Closed GoogleCodeExporter closed 8 years ago

GoogleCodeExporter commented 8 years ago
Arducoper ACM 2 
What steps will reproduce the problem ?

Simply reboot the APM board.

What is the expected output? What do you see instead?

Expected output is normal radio input on all channels after reboot.

Instead i loose CH3 input, sometimes but rarely i loose CH4 input.

Very often after reboot i loose throttle (radio CH3). Inside Radio or PWM test, 
throtle stay at the value it was before reboot.

APM Board resetting does not solve the problem.

Only a power off solve the problem. 

What version of the product are you using? On what operating system?

I have an APM 2560 board with IMU shield.

Please provide any additional information below.

To be sure that my receiver was not faulty, i've connected a servo on receiver 
output 3, just after i get the problem.

The servo is working perfectly so i'm sure it's not a receiver problem.

I can't see any radio input problem during normal run. Problem exhibit only at 
reboot.

Could it be a PPM encoder firmware problem or a bug in the AVR chip himself ?

Original issue reported on code.google.com by olivier....@helidream.fr on 23 May 2011 at 8:44

GoogleCodeExporter commented 8 years ago
So odd. I can't reproduce it. Contact 3Drobotics for potential investigation as 
I think this is a hardware issue.
Let me know.
Jason

Original comment by jasonshort on 23 May 2011 at 4:25

GoogleCodeExporter commented 8 years ago

Sometimes, powering of the radio transmitter and powering on again, i get Ch3 
to life. But not always.

This mean that the ppm encoder seems sensitive to the loss of radio signal 
because this event can restore normal CH3 output.

Very strange. I will watch the PPM encoder output with a digital scope to see 
what's exactly in the encoded signal when i loose CH3.

Original comment by olivier....@helidream.fr on 23 May 2011 at 4:55

GoogleCodeExporter commented 8 years ago
You are using an analog radio that ceases PWM output at radio loss? Otherwise 
how would it know the radio went out?

Original comment by jasonshort on 23 May 2011 at 5:03

GoogleCodeExporter commented 8 years ago

Yes, first stage is normal programmed failsafe, and after 25 secondes PWM 
outputs are disabled if link is not restored. This is to avoid servo 
destruction on planes when crashing.

72 Mhz Hitec Aurora 9 transmitter and Fusion 9 receiver.

I will add that the problem is not linked to the radio failsafe. It is linked 
to APM board reboot. When the problem occur there is no loss of signal. I just 
reboot the APM board.

Original comment by olivier....@helidream.fr on 23 May 2011 at 5:49

GoogleCodeExporter commented 8 years ago

What is the AVR fuse setting for start time ?

Perhaps it is too short, causing loss of some inputs.

Original comment by olivier....@helidream.fr on 24 May 2011 at 10:51

GoogleCodeExporter commented 8 years ago
Hardware issues are just not my forte and I'm the only one monitoring this 
thread. Could you repost to DIYDrones.com or contact 3dRobotics?

Original comment by jasonshort on 24 May 2011 at 10:58

GoogleCodeExporter commented 8 years ago

I contacted 3dRobotics and proposed to make tests if needed to isolate the 
problem.

Original comment by olivier....@helidream.fr on 25 May 2011 at 7:45

GoogleCodeExporter commented 8 years ago

Making normal tests yeasterday, i loosed CH3 input during normal run a couple 
minutes after boot.

So the fuse setting is not the problem.

I suspect an hardware problem on my board or a defectuous AVR. I need to find 
time to analyse this more deeply.

Original comment by olivier....@helidream.fr on 31 May 2011 at 12:04

GoogleCodeExporter commented 8 years ago

I made some more tests.

What i suspect now is that when the APM board is resetted (hardware reset or 
warm reboot), the main AVR send crap signals to the PPM encoder through MUX and 
PPM lines.

Then the PPM encoder is crashed perhaps because of shorts on the MUX and PPM 
outputs.

I need to put a scope on the PPM and MUX outputs to see the real cause. I need 
to know if the CH3 is missing from the PPM output, or if it is not decoded 
inside the main AVR.
I miss room here to do this but i'll try tomorrow.

Anyway something is wrong, and i think that my board is not the cause.

Original comment by olivier....@helidream.fr on 4 Jun 2011 at 10:25

GoogleCodeExporter commented 8 years ago

Those PPM encoder crashes could eventualy explain the strange things some users 
have reported with yaw, rudder or unexpected crashes.

I think that this problem is very important and needs to be fully understood.

Original comment by olivier....@helidream.fr on 4 Jun 2011 at 10:34

GoogleCodeExporter commented 8 years ago

Here is a capture of the PPM encoder output.

Transmitter stick was up right. Ch3 and Ch4 should have same max width. 
Instead, Ch3 is smaller.

A check at the same time on the receiver PWM output show that PWM Ch3 output is 
ok.

Resetting the PPM encoder through the ISP port solve the problem.

Original comment by olivier....@helidream.fr on 5 Jun 2011 at 9:26

Attachments:

GoogleCodeExporter commented 8 years ago

I think that there is definitely a PPM encoder problem.

Chris sent me a replacement board, this time a 1280 board. After connecting it, 
loading the last firmware, radio setup, i did again some tests.

After playing with the throttle stick, all was ok. suddenly after a couple 
minutes, i loose CH3 input again.

I loose it when i was pushing the transmitter stick quite fast to the max.

After checking, my receiver output 3 was perfectly normal. But going to CLI 
radio test, i had no more Ch3 input.

Conclusion :

I think that there is definitely a problem with the PPM encoder. Certainly a 
software problem.

For those tests, i've used an USB isolator to be sure that there was no ground 
loop between the computer and the board.

Original comment by olivier....@helidream.fr on 22 Jun 2011 at 9:52