Advanced Search

Thank you for reporting bugs to me.

f12e has same mount as d10. I can not confirm hall sensor will work but worth to try.

for the issues:
1. datalog: I will take a look on a real Tx.
2. ppmin: there is a bug. I will take a look.
3. usb gamepad: it is a known issue. I will submit a pr today. Hopefully, it will get fix in tomorrow's nightly.

That model file has PPMIn configured for Stick. I've attached a simple model made in the emulator just for testing channel one. Check with this model if the other tx PPM output on channel one shows up on CH1 in the 7e channel monitor.

The Stick and Channel PPMIn configurations are for the standard buddy box usage where the master tx is bound to the model. You'll need to select Extend so that the PPM inputs can be used as regular inputs in the mixers (PPM1-8 depending on how many you enable in the Extend options).

Set up the mixers to use Source as either the 7e inputs (THR, AIL, etc) or the corresponding PPM channels from the "master". Use the PPM input from the "master trainer switch" as the switch in the mixers to choose whether the 7e or PPM input is the controlling source.

What are the PPM channel assignments from the "master" tx? You need one PPM channel to act as the trainer switch (for this non-standard configuration).

The CHx inputs are the outputs of the channel mixers. Useful in other situations - not here.

Got interested in this and spent too much time on it. The summary is that I don't think a change would make a noticeable performance improvement. There is a change needed in the PPMOUT protocol, but it can't be made without versioned model files.

The code in the first post works fine to capture a single PWM signal. When you read ch.capture() it returns the width of the last pulse captured, but says nothing about how many captures may have been missed. For PPM the pulse length must be measured for each of a sequence of pulses, with additional logic to determine which pulse represents the first channel. (Note the code in the first post measures time the pulse is high whereas PPM is total pulse length. With PPM neither the signal polarity nor which edge is measured matters for measuring the pulses.)

The current ppmin.c code sets up an interrupt on the PPM input signal, reads a free-running counter value on interrupt, and subtracts from the previous counter value to determine the pulse length. A timer-based alternative would route the PPM input signal to the timer capture input, set up an interrupt on timer capture, and read the capture value on interrupt. All the other code in ppmin.c is still required - only a subtraction is saved. The precision improves by capturing the counter value automatically, removing any variablility caused by interrupt latency.

On the output side the code in pwm.c is mostly unused when BITBANG_PPM is defined, which it always is. The PPM output pin is controlled directly in protocol/ppmout.c which requires two clock timer interrupts (protocol callbacks) per channel. The commented-out timer code connects the PPM output pin to the timer compare ouput. The timer is configured for PWM with the notch length set in the compare register and the pulse length determined by the reload register. An interrupt is generated when reloading so the next channel value can be loaded, so this method requires half the interrupts of bit-banging (ignoring the callback interrupt). The precision improves by removing interrupt latency in the current bit-bang method.

The change needed in ppmout.c is at line 90, where the notch width should be subtracted from the desired pulse width. This line is the reason the Center and Notch PW default values of 1100 and 400 are needed to produce a pulse length of 1500 for a zero channel value. I consider this a bug because changing the notch width affects the center value. However fixing this would require adding the model files notch width to the center pw value in existing model files, so need model file versioning before a change can be made. Doubt many people change these options anyway.

Most of the interrupts could be eliminated by hooking the timer up to DMA. For output the pulse lengths would be updated in memory by the protocol and transferred to the timer by DMA on timer reloads. For PPM input the capture values would be transferred to a buffer, with a DMA interrupt triggering the channel processing. Some startup code would be needed to implement ppmSync and adjust the number of DMA transfers to the number of channels.

Sidenote: In ppmin.c, because all the variables involved are 16-bit, the line t =
(t1>=t0) ? (t1-t0) : (65536+t1-t0); is exactly the same as t = t1 - t0; . I was impressed that gcc generates the same code for both.

======================

Decided before posting the above I should follow through with some code and see if jitter is really improved by using the timer capture/compare. The PPM output was easiest to implement. Code for devos is here (except 12 - needs generalization).

The previously commented-out code in pwm.c had a couple issues with register defines and didn't set the master output enable. But spent most debugging time figuring out that if more than one peripheral shares an AF pin it's not enough to disable the peripherals not in use - their clock must also be turned off.

I tested the timer-based ppmout.c versus the bit-bang version, measuring jitter as the difference between mininum and maximum measured PPM values for fixed channel values. The timer-based version had jitter of 1-2 microseconds while the bit-bang version is about 4-5 microseconds.

I don't think that's a compelling case for change but don't mind cleaning up the code for a PR if there's a consensus.

The code above won't miss a pulse. But ppmin.c doesn't use the facilities I'm asking about. I'm not sure it's not using the edge-triggered capture, as I don't want to grovel through the libopencm3 docs to figure it out. It would just improve the accuracy a bit in any case.

It's clearly not using the auto-preload facility, though. Using that would mean you could skip saving the counter between interrupts and calculating the pulse width.

Then you probably mean src/target/common/devo/ppmin.c, not protocol/pwm.c you mentioned. I did not realized you're talking about input not output.

If you look at ppmin.c you'll see some timer logic, a bit more complicated than you presented because it needs to decode the whole PPM package, not just last pulse's width. So it uses interrupts not to miss a pulse.

mwm wrote: To use the Devo Tx as a master, you need to use PPMIn to either Stick or Channel mode to read PPM from the trainer port. To use it as a slave, you want to set the Protocol to PPM, to output PPM on the trainer port.

Section 10.1 of the Devo 10 manual covers the details.
So it works with deviation right? I'm not running the stock firmware. And does it need to be a certain nightly?
Deviation does not support the new wireless buddy box modes.

To use the Devo Tx as a master, you need to use PPMIn to either Stick or Channel mode to read PPM from the trainer port. To use it as a slave, you want to set the Protocol to PPM, to output PPM on the trainer port.

Section 10.1 of the Devo 10 manual covers the details.

Deviation does not support the new wireless buddy box modes.

Wene001 wrote: With an Orange R615X (CPPM-Sumsignal on bat port) wired to PPMin on your Devo you have a wireless variant

Smart! Now I have to try.

I`ve the DX6i in use with my deviated Devo12s.
Turn off the DX6i. It powers up on plugging the trainer cord.
No Problem

With an Orange R615X (CPPM-Sumsignal on bat port) wired to PPMin on your Devo you have a wireless variant

Played around with "Channel" PPMin settings
Switch none doesnt work for me.
Try to set a switch (and switch it on ) and assign PPM 5 to Ch9 and PPM 6 to Ch10
Then it should showe movement in Channel Monitor.
With this setup mixer for Ch9 and Ch10 is not used.

i would prefer to use "Extend" Setting for PPMin and use the mixer that you showed in the PDF above.

as shown here
www.deviationtx.com/forum/search?query=ppmin&childforums=1
i am using ppm signal on tip of the headphone jack, but i think deviation could handle both variants of signal

Wene001 wrote:
PPMIN set to extend

Thanks!
I did not try the extend option since I did not know what it did (it is not descibed in the manual)

For the rest, what you did is exactly what I had in mind. I want to correct the student, not I shit him off. I am testing now with a cable and the channel monitor now shows what I expected.
I have a 615X on my way for wireless buddybox as you did.

Thanks for the warning on 4.0.1. During my playing with buddybox settings on v401 I have experienced several crashes of the software.

Dont use the 4.01 for this
There is a bug
www.deviationtx.com/forum/3-feedback-que...-crash-on-my-devo12s
This is fixed in the actual nighlies
Example (for one Function):
Set Devo 7 Protokol PPM e.g. 6 Channels
Set Devo 8
Mixer GUI Advanced
PPMIN set to Extend
click on extend and set 6 Channels - OK
on the mixer page change to complex
set page to 3
on Page 1 set SRC to your preferred stick (e.g. AIL) - MUX:replace
on Page 2 set SRC to PPM input (e.g. PPM1) - MUX:add - assign a switch of your choice
on Page 3 set SRC to PPM input (e.g. PPM1) - MUX:replace - assign a switch of your choice

Hope this helps

i am using this with an Orange R615X (PPM SUM) wired to my 12s trainer port. (=Wireless Trainer

Recently I've been trying to get the PPM input working on the UTx board with Bluetooth & Smartphone integration. It has been mostly working, but the servos were jiggling like crazy. I finally root caused this to the PPM ISR not providing accurate timing. This has to do with interrupt priority. The PPM input is supposed to have highest priority so that it can accurately capture the time that an event happens. After screwing around with it for a couple days, I figured out that the libopencm3 set_nvic_priority doesn't actually work on the STM32F0. That means that the PPMIn timer is waiting until the SPI transmit completes which significantly impacts accuracy of the pulse-width. I think I have it all resolved now. This was the last major feature I needed to ensure theboard design is suffcient for all use-models.

Since the board seems to be working quite well in my Devo radio, I've moved on to PPM support. I have PPMIn working now, as well as bluetooth communication. So I'm working on the software to interface with my phone App. Once that is done I should be able to control any supported model from any transmitter.

I still need to spend some time understanding why the board doesn't boot reliably with the USB jumper installed. After that, I'll either spin a new board (if fixes are needed) or build a couple more from the pcbs I have. Then I need to start looking into manufacturing options.

hexfet wrote: Do you think the behavior described in the post (main screen channel values are not updated when PPM In is set to Channel) is worth fixing?

Yes it seems like the main page should show the value passed through PPMIn if enabled

MIXER_GetChannel appears to be used in the following locations:
timer code for enabling the timer based on channel value
safety-check on startup
datalog reporting and datalog enable trigger
main-page display


the timer code, main-page, and datalog should each use the PPMIn value for their triggers. I guess the safety should too since the entire point is tomake sure you aren't sending a dangerous value to the model on startup.

That implies that the PPMIn application could be moved to GetChannel, and the '//5th step: apply limits' code could then call MIXER_GetChannel() to avoid code duplication.

Works like a charm

One minor bug i`ve seen is:
If you use the PPMIn Mode "Channel" the "PPM Movement" is only seen in channel monitor , not on the channel bars on the homescreen.
PPM Sigals used in the Modes "Extend" and "Sticks" are showed up as they should in Channel Monitor and on the homescreens channel bars

I actually set out to do things they way you described, with the virtual channels following the output channels on that page. This causes problems on the touch screen controllers, where the page organization is totally different. The existing monitor pages (output, telemetry, and button input which isn't in the b&w controller firmware) are laid out radically differently and don't scroll. Changing that page would have required redesigning the page layout, then rewriting all the code for it. Adding them as separate pages there was much simpler, but meant that I really needed to do things that way on the b&w controllers as well, or it would have caused the code to diverge even further. Since I don't think the single-page UI design is a clear win, I went with the simpler, more maintainable code.

I've never actually used the PPMIN stuff before - I just added that page because it was easy to do while I was working on this, seemed useful and might prompt the people who were actually using it to make suggestions.

I'd expect that the output monitor to show the values you're asking for, because those are the outputs in those modes. If that's not the case, I think we need to create an issue for it as a bug. Adding the "(PPM)" notation to the output monitor would just be confusing, as the output channels in that case aren't going to the PPM output line, but to the RF module.

The input channels are a different case. While the monitor doesn't have special handling for the case of the inputs coming from the student, that might be happening in the input processing code. If so, then all you really want is a change in the labels and setting the input channel count to 0 in one case. That's easy enough.

If you're using these features, could you let me know if my conjecture about the output values is right, and how the input channel monitor currently behaves? If you're not using it (which doesn't mean suggestions aren't welcome!), I'd rather hold off on anything complicated until we can get input from someone who is using these features.

Set PPMin (Model setup) to Extend and configure as needed. Plug is the DSC plug. Protocol to be, of course, PPM.

PhracturedBlue wrote: 'PPM In' is a new feature that probably requires more than just a couple sentences.
It has 2 uses:
1) It can be used for additional inputs. For instance, it was primarily requested by the FPV folks, who wanted to be able to control their camera motors from their headset (as you look around, the camera looks around) or at least that is my undersatnding of their use.

2) It is used to enable the transmitter to act as a Master in a buddy-box setup. Here the student configures his student for PPMOut, and the Instructor for PPMIn with a control switch. When the instructor has the switch set, the channels from the student replace those on the Tx. When the switch is cleared, the Instructor(Master) Tx resumes control

The settings hidden behind the button enable Deviation to be compatible with any other slave radio, enabling full control of the PPM speed and structure

Just to add little to that.

1) 'head Tracker' or 'Camera Gimbal' or advanced option to add extra controls, switch's, potentiometer

2) Hope/should be able to also limit student control of craft. Meaning Full house plane Rud/Elv/Alr/Thro student can be limited to control everything but throttle.

Been very long time since done any but needed.