Question re testing / debugging macPPM to work...

[matthewjcockerill]

It was great to come across macPPM as it looks like exactly what I've been looking for to help my son use his RC controller with X-plane - way better than our crappy joystick

I'm not sure how to confirm that the various aspects are working as they should, though...

When I run your macPPM binary (on Mac OS 10.12.5) with the -t option (test mode), it says "Initializing..." but no text output beyond that.

With the -t option it also outputs a steady buzzing sound.
This buzzing seems to be independent of audio input - e.g. it sounds just the same whether line or microphone in is selected, and if line is selected, it sounds the same whether or not the RC transmitter buddy cable is plugged in.

When plugging the buddy cable in there is definitely activity from the transmitter being picked up- this can clearly be seen in the audio control panel .

So I am wondering if you have any ideas for identifying what is or isn't working?

One thing that I am not clear about is - if I am running it from the binary (as I'm not really experienced at compiling from source) how do I provide the libportaudio dependency? There is a directory called libportaudioBinary in the download, but this appears to contain only source code. I found a binary called libportaudio.dylib elsewhere but it is not quite clear where this should go...

Finally, sometimes but not always, I see the following error:
"Unable to create HID device - hope that it exists already. "

If you've got any ideas for how I might diagnose, that would be great!

Thanks for any tips
Matt
PS
Incidentally, the transmitter I am using is a Saturn 2.4 GHz FHSS transmitter very similar to this one. http://airtekhobbies.com/downloads/esale6.pdf
I'm anticipating that the coding of its buddy system may or may not be Futaba-compatible, but at before delving into that just want to confirm that macPPM is correctly installed, and can pick up anything on the line-in...

[albhm]

Hi Matt,

what happens if you try the -t and -c options together? Depending on how your cable is wired the signal is either on the left or right channel and the -c option switches between them. What you are looking for is a clearly audible change in the buzzing sound while moving the controls on your transmitter. libportaudio.a is statically linked into the binary, so it is only needed for compilation.

[matthewjcockerill]

Hi there. Amazing! Thanks for this. I was sure I'd tried the -tc option, but I just tried it now and it worked perfectly - all performing as expected in terms of returning numbers that vary as I move the controls. I have also now compiled from source myself, which worked but only once I found and downloaded pa_mac_core.h from another source as it complained that was missing initially. I think maybe that also needs to be in your portaudio binary zip file? Now that I have it compiling, should be easy enough to tweak joystick mappings if need be. I guess you can add Saturn to the list of controllers which are known to work! Thanks again for rapid response, and for sharing this! Matt

…

On 20 July 2017 at 21:28, albhm ***@***.***> wrote: Hi Matt, what happens if you try the -t and -c options together? Depending on how your cable is wired the signal is either on the left or right channel and the -c option switches between them. What you are looking for is a clearly audible change in the buzzing sound while moving the controls on your transmitter. libportaudio.a is statically linked into the binary, so it is only needed for compilation. — You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub <#1 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AHjjBgLCs4eDXZ-oEHD1TA3haUoiM2QGks5sP7hWgaJpZM4OeKQZ> .

[albhm]

Nice to hear it's working so far!
I updated the portaudio zip file to include pa_mac_core.h - thanks for the hint!

Regarding the mapping: the columns of numbers seen while using -t are in order.
So if the value in the third column changes while you move the x-axis of the left stick, change
joy.x = (getBuddyBoxThreadInputChannelValue(&pasBB, 0)-0.5) * 255;
to
joy.x = (getBuddyBoxThreadInputChannelValue(&pasBB, 2)-0.5) * 255;
in main.c - and so on. Maybe I'll add some sort of option or config file to accomplish that without having to recompile.

[matthewjcockerill]

The nice thing about X-Plane is that it provides a full GUI for mapping/calibrating inverting axes, so all can be sorted within the app. No code change needed - though I did tweak to flip the default audio channel (perhaps code could automatically try one then the other as part of calibration?) Anyway, it works just great. Thanks again!

…

On 21 Jul 2017, at 08:43, albhm ***@***.***> wrote: Nice to hear it's working so far! I updated the portaudio zip file to include pa_mac_core.h - thanks for the hint! Regarding the mapping: the columns of numbers seen while using -t are in order. So if the value in the third column changes while you move the x-axis of the left stick, change joy.x = (getBuddyBoxThreadInputChannelValue(&pasBB, 0)-0.5) * 255; to joy.x = (getBuddyBoxThreadInputChannelValue(&pasBB, 2)-0.5) * 255; in main.c - and so on. Maybe I'll add some sort of option or config file to accomplish that without having to recompile. — You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub, or mute the thread.