s3c / pwmix Goto Github PK

The pwmix project is a small hardware device that can alter PWM/PPM signals generated by common hobby remote controls. This allows enabling mixing for cheap RC transmitters, or where the receiver applies some mechanism that isn't desired. It is based on the Attiny85 but smaller micro controllers like the Attiny25 can be used, you'll need a pretty steady hand to make it fit on the edge of the larger footprint though.

The unit supports two inputs and two outputs, although these are identical and can potentially be used otherwise. With the micro controller facing upwards, the top left channel is input channel one, the bottom left channel is input two, the bottom right channel is output one, and the top right channel is output two. By convention, input one is considered the main input, and input two is considered the modulating input.

Since the Attiny85 has an inaccurate internal timer, rather than adding a crystal the unit does a clock sync to sync with the receiver. This is done by adjusting the internal clock using a binary search at startup, to match the expected pulse length with what is received. This is done on input channel one, and the expected value differs between code features.

The project was created with the following in mind:

• (DONE) Differential drive mixing - the main input takes a motor drive, while the second takes a servo turning signal. These are mixed together to output two motor drive signals mixed to provide differential drive. This allows the use of two motors to drive and steer, as opposed to a motor and a servo. Initial sync should be at mid stick (1.5mS PWM pulse)
• Servo limiting (planned) - the main input takes a servo input, while the optional second input takes a calibration servo signal. If the second signal is present, the minimum and maximum values are stored and saved in EEPROM. The output signals are mirrored and will never exeed the stored limits. To set the limits plug in both signals and vary the second signal between min/max. The input signal is scaled so full input deflection gives full limited output deflection. Initial sync should be at low stick (1mS PWM pulse)
• Fake Nitrous oxide (planned) - the main input takes a motor drive, while the second takes a enable signal. If the enable signal is greater than 3/4 full deflection, the mirrored outputs (following the motor drive signal) are allowed to swing to greater than 50%, if not, the output signals are limited to 50%. When this enable trigger is active, a timer decrements a 30 second limit, which limits the motor to 50% when depleted. This creates a fake boost mechanism, which gives a more dynamic nature to racing. Initial sync should be at mid stick (1.5mS PWM pulse)
• (DONE) PPM to PWM converter - Each board strips off the first two PPM channels and outputs them as PWM, then passes the remaining PPM signal along. This allows daisy chaining the PPM signal along the body of the plane so you only need to run one wire from the receiver and still be able to control all servos/motors, etc.

Known issues (Differential drive mixing):

• There seems to be a dead band/jitter of around 50uS for small values on input two in one direction, this also seems to reflect more on output one than output two for some reason. I don't really know why this is happening, I've confirmed that there is a tiny dead band/jitter on the input channel, but insignificant compared to the output. The inputs/outputs aren't handled differently in any way so some weird race condition is in play here. The most likely scenario is that the edge trigger interrupt fires just before the compare match timer, so the timer interrupt only fires after the edge has been processed, creating a dead band region. The ideal fix for this would be to use the compare match module to automatically turn off the output pins, but the hardware doesn't allow this, as the output pins aren't assigned to the compare match pins. I'll fix this if there's ever another revision. Update: Ok, I managed to confirm that this was the problem, and I fixed the issue by making the pin change ISR non-blocking and adding a flag to avoid re-entry if another pin change occured. We still have some jitter but that's to be expected considering all the overhead and no crystal. The above fix would still be better though