Unable to build

[Radrik5]

Build fails with the following errors: 8>------ Build started: Project: SppProcess, Configuration: Release x64 ------ 8> Starting CreateVersion 8>LINK : fatal error LNK1104: cannot open file '..\x64\Release\vJoyInterface.lib' 9>------ Build started: Project: SppConsole, Configuration: Release x64 ------ 9> Starting CreateVersion 9>LINK : fatal error LNK1181: cannot open input file 'SppUI.res'

Trying to build vJoy ...

[Radrik5]

I managed to build SPP by building vJoy and copying .lib and .dll files to the output folder.

Maybe reference vJoy as git submodule and include it into SPP solution?

[shauleiz]

Both SPP and vJoy are not maintained anymore. I still try to answer users questions but I feel these projects are mature and do not need anymore of my time.

On Tue, 26 Sep 2017 at 19:35 Dmitry Oksenchuk notifications@github.com wrote:

I managed to build SPP by building vJoy and copying .lib and .dll files to the output folder.

Maybe reference vJoy as git submodule and include it into SPP solution?

— You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub https://github.com/shauleiz/SmartPropoPlus/issues/2#issuecomment-332258579, or mute the thread https://github.com/notifications/unsubscribe-auth/AMx8JATmIMRwYfZrldNrHxOEhsl4l9uhks5smSfhgaJpZM4Pkhpk .

[Radrik5]

SPP doesn't work very well with my RadioLink AT9.

There are three problems:

1. Walkera PPM seems to have more jitter in channel output than Positive PPM (I will double check this). But Positive PPM doesn't work when all 10 channels have low values (long pulses). It cannot sync because PPM_TRIG=870 is too high (I have sync pulses with 660-670 width). Here is the fix but it can break other setups: https://github.com/Radrik5/SmartPropoPlus/commit/8776fd35e045a240ae075fe40a413d09d64bba88
2. Quad-copter in simulators often has yaw or roll drift when sticks are in the center position. This is caused by the way SPP works with jitter: it remembers the first value that is near the center and ignores other values that is around PPM_JITTER=5. Adding average for last 4 values solves the problem. I haven't pushed the fix to my fork yet.
3. Tiny stick movements near the center are not detected. This is also caused by jitter cancellation algorithm and fixed with averaging.

When I want to publish my changes, should I create a pull request to this repository or make a release from my fork?

[shauleiz]

Thank you Dmitry for your work. If you want to create your own branch it is fine with me but I warn you it might take a lot of your time (maintaining it and giving support). If you want to create a pull request it is also fine but it may take me some time to test, pack and release. SPP is no longer in my focal point. You can of course do both.

On Wed, 27 Sep 2017 at 11:14 Dmitry Oksenchuk notifications@github.com wrote:

SPP doesn't work very well with my RadioLink AT9.

There are three problems:

1. Walkera PPM seems to have more jitter in channel output than Positive PPM (I will double check this). But Positive PPM doesn't work when all 10 channels have low values (long pulses). It cannot sync because PPM_TRIG=870 is too high (I have sync pulses with 660-670 width). Here is the fix but it can break other setups: Radrik5/SmartPropoPlus@8776fd3 https://github.com/Radrik5/SmartPropoPlus/commit/8776fd35e045a240ae075fe40a413d09d64bba88
2. Quad-copter in simulators often has yaw or roll drift when sticks are in the center position. This is caused by the way SPP works with jitter: it remembers the first value that is near the center and ignores other values that is around PPM_JITTER=5. Adding average for last 4 values solves the problem. I haven't pushed the fix to my fork yet.
3. Tiny stick movements near the center are not detected. This is also caused by jitter cancellation algorithm and fixed with averaging.

When I want to publish my changes, should I create a pull request to this repository or make a release from my fork?

— You are receiving this because you commented.

Reply to this email directly, view it on GitHub https://github.com/shauleiz/SmartPropoPlus/issues/2#issuecomment-332445149, or mute the thread https://github.com/notifications/unsubscribe-auth/AMx8JBfqdNiAYF2VMn_D_aGgHXHou071ks5smgPtgaJpZM4Pkhpk .

[Radrik5]

Then I'll do both. Thanks!

[wdcossey]

Hey @Radrik5,

If you are interested, I started porting SmartPropoPlus to C#, using WPF and some open source audio libraries.

It has a plug-in architecture, so you can easily extend the app to support different Radios or just simply do something another way without affecting/rebuilding the main application.

I have done all of the current supported PWM & PPM integration offered by SmartPropoPlus (as it's essentially a 1-to-1 port).

If you're interested have a look https://github.com/wdcossey/SharpPropoPlus, see the CSCore branch for the latest changes.

[shauleiz]

Sounds like a very promising approach. If you allow me giving you a small advice I will add that you may introduce a user defined PPM option. Some vendors invent their own version of PPM which is slightly different and then you get people needing yet a new version of PPM decoder. Good luck with your project. On Wed, 27 Sep 2017 at 23:47 William David Cossey notifications@github.com wrote:

Hey @Radrik5 https://github.com/radrik5,

If you are interested, I started porting SmartPropoPlus to C#, using WPF and some open source audio libraries.

It has a plug-in architecture, so you can easily extend the app to support different Radios or just simply do something another way without affecting/rebuilding the main application.

I have done all of the current supported PWM & PPM integration offered by SmartPropoPlus (as it's essentially a 1-to-1 port).

If you're interested have a look https://github.com/wdcossey/SharpPropoPlus, see the CSCore branch for the latest changes.

— You are receiving this because you commented.

Reply to this email directly, view it on GitHub https://github.com/shauleiz/SmartPropoPlus/issues/2#issuecomment-332650328, or mute the thread https://github.com/notifications/unsubscribe-auth/AMx8JOPO7VLbysaGttoRRN6Qwgiodisrks5smrRigaJpZM4Pkhpk .

[Radrik5]

Hi @wdcossey,

That's an interesting project, I'll try it. I'm not good at C# but I will try porting my jitter cancellation changes to it.

[wdcossey]

@shauleiz ,

I'll definitely look into introducing a feature like the one you suggested, would make things a lot simpler, rather than having to compile a different assembly for each PPM implementation.

I haven't finished the project yet, there's still some work to be done, you will get credit for your outstanding work.

@Radrik5, I'm not good at writing C++ but I can read it, if you push your fixes for your jitter cancellation implementation, I can put it into the project. FYI: I noticed the same bug in the simulator, the drifting is a pain and there's definitely a dead zone with the sticks.

[Radrik5]

I have pushed my jitter cancellation fix to my fork: https://github.com/Radrik5/SmartPropoPlus/commit/09e85f77c081baa7ab8565cba91c0df13ec2ca93

It's something like Moving Average but only inside PPM_JITTER range. I tried regular Moving Average and Exponential Moving Average (like here: https://github.com/opentx/opentx/pull/3240/files#diff-127c5d5fc347542bca86a4b6b0dfff58R1516) but they worked worse.

Sometimes I still get drifts in the center but they are less often and less strong than before. I'm going to test this for some time and maybe try other filtering algorithms. Or maybe try to somehow force it to stick to "correct" center value. I don't have such drifts when flying a real quad.

[Radrik5]

They've revisited jitter filter in OpenTX 2.2: https://github.com/opentx/opentx/commit/9a40830f8a40e6f8f0ca83384e899a058645f135#diff-127c5d5fc347542bca86a4b6b0dfff58R1583

I'll try this as well.

[wdcossey]

@Radrik5 I will implement your solution shortly as well as have a look at the filtering by OpenTX 2.2, perhaps have a mix of yours and the OpenTX implementation with regards to the small movements .

Configuration of decoder settings is read-only at the moment (and looks a clunky), will implement it within a few days.

[Radrik5]

@wdcossey, the settings look great!

I made a mistake in MA implementation that turned out the whole thing into a simple formula: <out> = (3 * <out> + <in>) / 4

or in general case: <out> = ((ALPHA-1) * <out> + <in>) / ALPHA

This formula with different factors is used in many filter algorithms including OpenTX. It worked quite well for me too but there was still some drift when sticks return to the center. I usually have jitter [-1; +1] and sometimes [-2; +2], so it was easy to stick to 187 or 189 values in the center (instead of 188).

Adding more precision (error accumulation) caused more jitter because my real center value is 188.5, and average was often slightly below (rounded to 188) or slightly above (rounded to 189) it.

I end up splitting averaging and rounding. If the average value is inside [-0.75, +0.75] range from the previous integer value, I stick to the previous integer. That removes both jitter and drift. However, the ALPHA=4 became too low with high precision averaging (without rounding on each step), so I increased it to 10 to remove jitter, but with 10 I lost responsiveness and smoothness of stick movement (until the new value was less than PPM_JITTER=5, filtered value slowly moved to new value, but as stick moved and new value become more than PPM_JITTER, filtered value jumped to new value). Now I use lower ALPHA for bigger stick movements and don't use PPM_JITTER.

Here is how ALPHA depends on difference between new value and previous value:

abs(<out> - <in>)	ALPHA
0, 1	16
2	12
3	6
4	3
5 and more	2

These values work very well for me but if someone has more jitter, they'll need to tune it. I think this set of values should be in the jitter filter settings.

My algorithm uses floating point value (double) for averaging and integer values for input and output. I don't have performance issues with floating point arithmetic on my PC but if you think it's worth it to implement with integer values (using a multiplier like OpenTX), I'll try to do so.

[Radrik5]

I pushed new implementation: https://github.com/Radrik5/SmartPropoPlus/commit/99ea0e6fbc5065c710b926094001cd5eacde2fe6

I'm almost happy with it although it still has rare small jitter and rare drifts. I came to a conclusion that it's a matter of compromise: the more you reduce jitter the more dead zones and drifts you get, the more you reduce dead zones and drifts the more jitter you get.

[wdcossey]

Hey @Radrik5,

I don't want to keep spamming @shauleiz issues page, perhaps create one for your fork?

I implemented your jitter filter into on of my decoders for testing and had mixed results, channels seemed to bounce all over the place, could be I botched it up.

I forgot to mention I had vastly (almost zero) less jitter after messing around with my soundcard software, disabling the mic filters (which are meant for voice) for your sound card software should give you much greater accuracy of channel decoding.

I have a Sound Blaster Z, disabling ClearVoice (it sees the pulses as noise and not audio) made a massive difference, same thing was noticed with the internal Realtek High Definition audio card.

[Radrik5]

I think it will be easier for others to find this thread when they have the same issues with jitter as I did. So, if @shauleiz don't mind, I'd prefer not moving to my fork.

@wdcossey, do you mean that after disabling ClearVoice you have no jitter (almost) and additional filtering is not required? But before that you had so strong jitter that my filter didn't work well?

While debugging the filter I wrote channel values into a text file in <raw value>,<filtered value>\n format and then analyzed it in Excel. Without that it was hard to understand what's wrong with current filter. It's worth saying that writing values into debug output (using a breakpoint) gives incorrect values, maybe it's just not fast enough.

[wdcossey]

@Radrik5 I have updated my project with a number of changes and additions. If you want me to make you a build (since I currently have AppVeyor disabled) I'd be more than happy.

I have absolutely zero (I can't see any) jitter using the default "de-jitter" and configuring my audio card. One would suspect that on-board devices would have some noise coming from other internal components.

That all said, there would still be some minor dead spots with the default jitter implementation (as anything under the defined jitter value would be ignored).

[Radrik5]

@wdcossey, I have similar jitter on the Receiver tab in Betaflight, so it may come from my sticks.

Did you add some filtering of input pulses? If so, I'd like to try the new build.

[magyarl89]

Hello guys! Is this topic still alive?

I have a FlySky i6S transmitter and I looking for the best solution for Sim. The methods I've already tried:

1. Use the transmitter's USB (digital): It works very precisely, but with very bad refresh rate (I feel like 10Hz).

2. Cheap USB dongle (PPM): Nice refresh rate, but horrible jitter.

3. Jack for the audio input (PPM): a. Default 48kHz sample rate: not so precise, lot of jitter b. 192kHz sample rate: precise and fast. But only one annoying problem: can't get center precisely, after some stick movement, sometimes it has a remaining offset. Sticks are perfect (USB method can proove it) and the higher sampling rate is also should be enough.

Did you wrote some new version, where you can play with filtering values? Can you build it for me? (I don't know how to build for myself :) )

[wdcossey]

Hi magyarl89,

Sorry, I have been busy with work for a while, I only started working again on my project (SharpPropoPlus) again a few days ago.

Rather than spamming this project, head over to mine and open an issue and I'll be more than happy to help you out.

Here's the link to the project: https://github.com/wdcossey/SharpPropoPlus

I'll build a release for you, and if you are interested and want to test things you can do that too!