A new PPM encoder firmware has been released. This applies to APM2.x, APM1.x and the standalone PPM encoder.
Basically, a PPM encoder converts the 8 incoming PWM signals to one PPM signal that is then fed to the main processor. While doing so it detects if a cable from the receiver the the APM gets disconnected or if the receiver stops working.
Changes:
- New interrupt system that handles certain Futaba receivers better (simultaneous changes on groups of R/C channels in fast intervals) (this was already present in v2.3.13)
- Adapted behaviour in case of channel loss: If one channel is lost, it will be set according to the following table. The other channels will continue working.
Channel 1 Roll Set to center (1500 μs) Channel 2 Pitch Set to center (1500 μs) Channel 3 Throttle Set to low (900 μs) Channel 4 Yaw Set to center (1500 μs) Channel 5 ... Remain at last value Channel 6 ... Remain at last value Channel 7 ... Remain at last value Channel 8 ... Remain at last value
In ArduCopter and ArduPlane a fail-safe action can be triggered by the throttle low signal.
This should be carefully configured as explained in the wiki for ArduCopter and ArduPlane.
Also note that this has nothing to do with loosing radio connection between the transmitter and the receiver. The receiver's behaviour when it gets out of range depends on the transmitter/receiver hardware and setup. So make sure to go through all the scenarios before flying
Functionality
APM 2.x LED Status:
- RX - OFF = No input signal detected
- RX - SLOW TOGGLE = Input signal OK
- RX - FAST TOGGLE = Invalid input signal(s) detected
- RX - ON = Input signal(s) lost during flight and fail-safe activated
- TX - OFF= PPM output disabled
- TX - FAST TOGGLE = PPM output enabled
- TX - SLOW TOGGLE = PPM pass-trough mode
APM 1.x LED Status:
Normal mode:
- Error condition (All channels lost or throttle channel lost): blue LED blinks very fast
- Normal behaviour: blue LED blinks according to throttle position
Radio Passthrough mode (for ArduPlane only, using firmware with channel 8 override):
- If throttle position < 1200 μs, status LED is off
- If throttle position > 1200 μs, status LED is on
Normal servo Input (PWM) mode:
- PPM output will not be enabled unless a input signal has been detected and verified
- Verified inputs are lost during operation (lose servo wire or receiver malfunction):
- The last known value of the lost input channel is kept for ~1 second
- If the lost input channel is not restored within ~1 second, it will be set to the default fail-safe value (for channel 1-4) or kept at the last value (for channel 5-8)
- Lost channel signal is restored: Normal channel operation is restored using the valid input signal
PPM pass-through mode mode (signal pin 2&3 shorted):
- PPM output will not be enabled unless a input signal has been detected
- Active signal on input channel 1 has been detected:
- Any input level changes will be passed directly to the PPM output (PPM pass-trough)
- If no input level changes are detected withing 250ms:
- PPM output is enabled and default fail-safe values for all eight channels transmitted
- Input level change detected again, PPM fail-safe output is terminated and normal PPM pass-through operation is restored
Download
The hex file files are located in the downloads section:
- APM2.x
- APM1.x (or standalone PPM encoder)
- APM1.x (or standalone PPM encoder) (with channel 8 override)
Flashing/Updating
The instructions on how to flash the the PPM encoder firmware can be found in the wiki:
Comments
The flip 3.4.7 says "can not open ArduPPM_v2.3.13_ATMega32U2.hex" .WHY?
Hello,
lets see if someone still listen to this discussion?
I have tried to compile the project (under Windows7) and it worked so far but I have a difference at two bytes in the hex file (somewhere in the libgcc). Because I think it should end up in exactly the same output I wanted to ask what compiler / toolchain you have used to compile the project.
The reason to change it is that the mode 4 does not fit to my setup I am used to.
And a second thing is that I think it would be even better to set the failsafe values from the receiver if the transmitter / receiver connection is lost. So I can setup the values in the receiver by my own.
But this seems to be a problem too. Because if the receiver should set the failsafe values (after 250ms) to the ppm signal the encoder should go out of the failsafe mode. This is not the case for my Graupner MX20?
Does the transmitter ppm output not care about the failsafe values?
Bernd
I'm going to take a shot at updating the firmware. I can remove the APM case without dissembling my Quad or removing all of the motor/RX connections. Is it okay to leave everything connected to the APM while I do the update or does the APM need to be 'stripped down"? I'll remove the props for safety.
Does this make it possible to connect the new FrSKY X8R receiver directly to the APM using the SBUS port or does it still need the SBUS to CPPM converter?
Also the APM 2.5 seems to reset (red and blue flashing lights) when I try to connect via Mission Planner, but then MP just times out.
When I try to load a v3.0.1 sketch via the Arduino IDE it gives the following error:
avrdude: stk500v2_ReceiveMessage(): timeout
avrdude: stk500v2_ReceiveMessage(): timeout
avrdude: stk500v2_ReceiveMessage(): timeout
avrdude: stk500v2_ReceiveMessage(): timeout
avrdude: stk500v2_ReceiveMessage(): timeout
avrdude: stk500v2_ReceiveMessage(): timeout
avrdude: stk500v2_getsync(): timeout communicating with programmer
Again, the Arduino Mega 2560 shows up fine in the device manager (as COM6) and the newest drivers have been loaded.
So I decided to do a complete reload of the latest mission planner (I think 1.2.60 at the time) which re-installed the drivers. It worked and I was able to update with the new software as well as connect. It flies, and everything was fine.
BUT
Fast forward to today, and I'm trying to connect to the APM again to adjust some settings. I can't get it to connect (it times out when I try to connect via mavlink, and it gives me a "communication error - no connection" when I try to upload firmware). Again, it shows up fine in the device manager and in the list of com ports in mission planner. The APM code is loaded correctly and it actually files fine, I just can't access it via the USB (or the telem). I've even tried updating the drivers via the device manager (which uses a slightly newer version than the one that comes with mission planner). All with no luck.
I've tried reinstalling the latest version of mission planner several times on different computers to no avail. My other APM 2.5 (with v2.9 and the old PPM firmware) connects perfectly. I have not tried to upgrade that yet as I am having so many problems with this one.
The only other thing I can think of is that maybe the board got to hot when I was desoldering the SPI connector for the 32u2 (didn't end up using it and it doesn't fit the case).
>>>2. I've gone back through the instructions in detail several times. Everything works exactly as expected (as it did the very first time) except I cannot access the Atmeg 2560 (though it does show up correctly in the device manager and in the com list for mission planner).
That means you have the 32u2 programmed correctly with a functioning program.
>>>3. I've already tried reinstalling the bootloader by connecting the Atmega 2560 ISP header (not the Atmega 32u2 ISP header) to a USBasp and the arduino IDE. It just hangs. I've tried this on multiple computers, multiple OSes. I've used the USBasp to reinstall bootloaders before on different boards, but it is possible there is something wrong with the USBasp.
You had a functioning bootloader when you previously described that the blue light was flashing. If you still have a functioning bootloader on the 2560 and the 2560 is showing up in Mission Planner (that means that you have working code on the 32u2) then load the flight code.
When I say it hangs, it just takes a long time (expected), and then displays an error (I forget exactly what it was, but I can try again and post the results).
When I use avrdude (via the USBasp) from the command line it correctly identifies the device as a Atmega 2560 as evidenced by the identifier bits.
Thanks Craig,
1. Yes, they're both real. Straight from 3dr.
2. I've gone back through the instructions in detail several times. Everything works exactly as expected (as it did the very first time) except I cannot access the Atmeg 2560 (though it does show up correctly in the device manager and in the com list for mission planner).
3. I've already tried reinstalling the bootloader by connecting the Atmega 2560 ISP header (not the Atmega 32u2 ISP header) to a USBasp and the arduino IDE. It just hangs. I've tried this on multiple computers, multiple OSes. I've used the USBasp to reinstall bootloaders before on different boards, but it is possible there is something wrong with the USBasp.
Do you have a suggestion or more detailed instructions on how I should be reloading the bootloader? I have been using the arduino IDE, but this tutorial (http://www.rcgroups.com/forums/showthread.php?t=1254724) uses an AVR Studio 4 with the AVRISP MKII.