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 ***@***.***> 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 <#2 (comment)>, 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: Radrik5@8776fd3
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 ***@***.***> 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@8776fd3> 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 <#2 (comment)>, 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 ***@***.***> 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 <#2 (comment)>, 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: Radrik5@09e85f7

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: opentx/opentx@9a40830#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: Radrik5@99ea0e6

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.