Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Unable to build #2

Open
Radrik5 opened this issue Sep 26, 2017 · 20 comments
Open

Unable to build #2

Radrik5 opened this issue Sep 26, 2017 · 20 comments

Comments

@Radrik5
Copy link

Radrik5 commented Sep 26, 2017

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
Copy link
Author

Radrik5 commented Sep 26, 2017

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
Copy link
Owner

shauleiz commented Sep 26, 2017 via email

@Radrik5
Copy link
Author

Radrik5 commented Sep 27, 2017

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
Copy link
Owner

shauleiz commented Sep 27, 2017 via email

@Radrik5
Copy link
Author

Radrik5 commented Sep 27, 2017

Then I'll do both. Thanks!

@wdcossey
Copy link

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
Copy link
Owner

shauleiz commented Sep 28, 2017 via email

@Radrik5
Copy link
Author

Radrik5 commented Sep 28, 2017

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
Copy link

@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
Copy link
Author

Radrik5 commented Sep 29, 2017

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
Copy link
Author

Radrik5 commented Sep 29, 2017

They've revisited jitter filter in OpenTX 2.2: opentx/opentx@9a40830#diff-127c5d5fc347542bca86a4b6b0dfff58R1583

I'll try this as well.

@wdcossey
Copy link

wdcossey commented Oct 3, 2017

@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.

image

@Radrik5
Copy link
Author

Radrik5 commented Oct 4, 2017

@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
Copy link
Author

Radrik5 commented Oct 4, 2017

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
Copy link

wdcossey commented Oct 6, 2017

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
Copy link
Author

Radrik5 commented Oct 6, 2017

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
Copy link

@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.

image

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
Copy link
Author

Radrik5 commented Oct 12, 2017

@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
Copy link

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
Copy link

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!

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

4 participants