[trust]

Arg. I know what the problem is, not sure how to fix it.
JDL has hard coded channel 7 is OSD display toggle - which I now use as my arming switch!
How can I disable that?
Must be somewhere in the OSD code...

[jdl]

Unless you have changed existing UAVO IDs, nothing should be updated in OSD code.

I guess the FC firmware switches/commands the OSD to display Panel3 - the empty one, only warnings are displayed there. This will happen when Output Channel 7 is set to some high value... OSD monitors Cannel 7 to switch between OSD Panels.

[jdl]

Arg. I know what the problem is, not sure how to fix it.
JDL has hard coded channel 7 is OSD display toggle - which I now use as my arming switch!
How can I disable that?
Must be somewhere in the OSD code...

Look at line 505 in UavTalk.ino:

Code: [Select]

osd_chan7_raw = uavtalk_get_int16(&msg, MANUALCONTROLCOMMAND_OBJ_CHANNEL_7);

Also in OSD_Panels.ino:

Code: [Select]

void switchPanels()

[trust]

Yeh, I found that, and modified the code such that swithPanels ignores the code there for checking switch 7, and instead
sets panel=0 (which I assume is the main panel) and setup_menu_active = false; - which I assume if true enables the setup panel.

Now it ignores the channel 7, but it still seems to jump to panel 1 after 10 seconds.
There must be a timer somewhere that is doing this but where?

[trust]

As a temporary "workaround", I set up everything in panel 1 the same as panel 0 - but then discovered that any attempt to enable the Horizon, gets a -1 index value and crashes the setup tool. It works fine on the first panel, but not the second panel.
So there is no artificial horizon (which is very useful), but everything else.

[trust]

Aiiieee..
I discovered the Arduino compiler-
1) Does not check the files to see if they have been changed from another editor -so I have to exit and restart every time I make a change
2) Generates a new build directory EVERY time I make a change & recompile. I was using what I THOUGHT was the current version of the code when it was a previous build.

Now the code I modified- setting panel=0 - works fine - I can see panel 0 with the horizon.
"FIXED" LMFAO

[TheOtherCliff]

Besides creating your new XML UAVO file, did you change any other XML / UAVO files (anything that changes the checksum / md5sum, even a space or blank line or comment) that the OSD accesses?  If so, you will need to put the new structs and new md5sum into the OSD code.

[trust]

The only changed modules were actuator, sanitycheck, and adding mixersettings2, bimodefun, and bimodestatus - none of these last 3 are accessed by OSD.
It seems to be accessing parameters fine now, though I haven't done a flight test yet. Windy last few days.

I've upgraded 2 more of our Hellaplanes to use the bimode code - it's been a tricky getting the systems to add a 3rd switch and the camber adjust function - I need all 8 channels of input, and 8 channels of output for my Hellaplanes, and Chris needs 11 channels of output. I wanted a switch for arming - as I discovered several times when doing power off glide tests, holding the yaw stick can disarm in flight - not a fun thing to deal with. Fortunately was able to land successfully.
  I realized I can use the Throttle 2 curve input selector to select an Accessory adjustment knob input, and can scale it + or -, then add it to appropriate axis functions for each mode to get the front elevon functions needed using bimode.
  One minor code change I made as a consequence is the code that scales Accessory input functions on throttle2 curve was set to absolute value - I changed it to proportional, so the knob would go + or -.
  I ended up using a not-completely-functioning-properly Atom FC for 6 of the servos on Chris' plane in bimode - I worked around the Ch1 problem. I though his Orangerx 920 receiver would work in PPM mode, but it turns out the V1 receivers are s.bus output - I didn't discover this till yesterday. So I can fix his to run ALL control functions from the one Revo FC. It seems the V2 are PPM output, which I have on most of my planes. The v3 versions do not support DSM2, which is what I have on my transmitter (dang) - I've ordered a DSM2/DSMX xmtr module I hope to adapt to my Futaba 9.

[jdl]

As a temporary "workaround", I set up everything in panel 1 the same as panel 0 - but then discovered that any attempt to enable the Horizon, gets a -1 index value and crashes the setup tool. It works fine on the first panel, but not the second panel.
So there is no artificial horizon (which is very useful), but everything else.

This issue (Horizon cannot be enabled in Config tool in Panel 2) was fixed few days ago, please download the current version of Config tool if you need Horizon in Panel2.

[trust]

JDL - thanks, I'll try that.

I ordered 5 older versions of the Orangerx 8 & 9 channel receivers - they were supposed to be v2 with PPM but instead they are V1 with s.bus output. I currently have a DSM2 xmtr module on my Futaba 9.
I can make them work with the s.bus input on the main port.
But I need 8 channels of PWM output, and want to be able to run the GPS/mag module, the OPOSD module, & the OPLINK on my mini REVOs.
If I plug the GPS in the flex port, then I still need a telemetry port. I can allocate that on the rcvr in port, which can have multiple functions - but I don't see an option for BOTH telemetry and using the remainder of the pins as output pins.
  If there are enough UARTs to run all these devices, is there a way to make a special allocation code for telemetry+output?
I've been looking at the code, and found the place in pios_board.c where they set this up:
    case HWSETTINGS_RM_RCVRPORT_PPM:
    case HWSETTINGS_RM_RCVRPORT_PPMOUTPUTS:
    case HWSETTINGS_RM_RCVRPORT_PPMPWM:
    case HWSETTINGS_RM_RCVRPORT_PPMTELEMETRY:
    case HWSETTINGS_RM_RCVRPORT_PPMDEBUGCONSOLE:
    case HWSETTINGS_RM_RCVRPORT_PPMCOMBRIDGE:
    case HWSETTINGS_RM_RCVRPORT_PPMMSP:
    case HWSETTINGS_RM_RCVRPORT_PPMMAVLINK:
    case HWSETTINGS_RM_RCVRPORT_PPMGPS:
    case HWSETTINGS_RM_RCVRPORT_PPMHOTTTELEMETRY:
#if defined(PIOS_INCLUDE_PPM)
        PIOS_BOARD_IO_Configure_PPM_RCVR(&pios_ppm_cfg);

        if (hwsettings_rcvrport == HWSETTINGS_RM_RCVRPORT_PPMOUTPUTS) {
            // configure servo outputs and the remaining 5 inputs as outputs
            pios_servo_cfg = &pios_servo_cfg_out_in_ppm;
        }

        // enable pwm on the remaining channels
        if (hwsettings_rcvrport == HWSETTINGS_RM_RCVRPORT_PPMPWM) {
            PIOS_BOARD_IO_Configure_PWM_RCVR(&pios_pwm_ppm_cfg);
        }

        break;
#endif /* PIOS_INCLUDE_PPM */
    case HWSETTINGS_RM_RCVRPORT_OUTPUTS:
        // configure only the servo outputs
        pios_servo_cfg = &pios_servo_cfg_out_in;
        break;

I imagine I need to enable ONLY the output pins that are NOT telemetry pins, AND enable the telemetry pins (where is this done?).

[TheOtherCliff]

This is starting to get into the complicated stuff.    There is a data only .c file in that same area where most of the hardware configuration is stored in structures (e.g. probably pios_ppm_cfg, pios_servo_cfg_out_in_ppm, pios_pwm_ppm_cfg, pios_servo_cfg_out_in).  Then there is either jumping in and trying what looks like it will work or researching the PIOS layer and finally the functions and limitations of the processor in question as it is wired in the FC in question.

I don't use OSD on many aircraft and don't really have any "running out of ports" issues.

Would running a PPM/Sbus to PWM converter connected in parallel to "receiver out" help you at all by reducing the number of outputs you need?  Would running a parallel FC (even one of your spare Atoms) this way do what you need?

[trust]

The simplest solution would be to just get some 8 or 9 ch PPM Orangerx DSM2 compatible receivers - and I'm looking into that - vendor says he has some, is checking stock.
  Another vendor sent me 5 sbus receivers instead of the PPM ones - I either have to decide to keep them or return/exchange them.  DSM2 compatible receivers are getting hard to find, so I'm tempted to keep them.

I tested the GPS port - as expected it works fine.

But when I selected the receiver port as telemetry, I get no data comm to the OPOSD board. I checked with scope - no data coming out of the Tx port of the Revo. Checked all pins - nothing.

[trust]

Well, I found the Tx telemetry output pin - it was on pin 5, the white wire pin that is normally the PPM input (or is an output).
The OSD now works (I guess it doesnt need Rx to work).
So my guess is there are enough USARTs to work everything needed (although I dont have the OPLINK connected yet).

Now to figure out the output mapping.

[trust]

Somewhat of a hack, but I got it working.
My notes:
add item Telemetry+Outputs hwsettings.xml RM_RcvrPort
add     [HWSETTINGS_RM_RCVRPORT_TELEMETRYOUTPUTS]        = PIOS_BOARD_IO_UART_TELEMETRY,
to pios_board_c flexiio_function_map

in  switch (hwsettings_rcvrport) {
    case HWSETTINGS_RM_RCVRPORT_TELEMETRYOUTPUTS:
        // enable pwm on the remaining 5 channels
            pios_servo_cfg = &pios_servo_cfg_out_in_ppm;

        break;

Compiled firmware & GCS.
The last case statement uses the config for ppm+outputs, which i figured since the PPM pin was now the telemetry pin would be safe to use.

It seems like the code is allocating 2 pins for the telemetry plus the ppm pin - I only get 3 PWM output pins active (I need only two)
It also seems like the original code does not route the telemetry Tx to the correct pin - as I mentioned, it's on the white pin 5.
Not sure why that is!
But at any rate it appears to work - at least in so far as doing what I need it to do!
Now I can use these Orangerx sbus receivers.

[trust]

So far we have now flight tested two of the four Hellaplanes we've implemented the Bimode code on.
In both cases most of the flight after vertical takeoff was executed in horizontal wing mode (uses the alternate mix table).
The most recent test was in a more challenging aircraft configuration with more of a canard style airframe - wider wingspan in rear wing than front, and further aft CG.
Despite a rather harrowing transition, flight was successful and fairly smooth. Review of the tailcam footage & telemetry data couldn't find an aircraft cause for the extreme left roll after transition. It was pretty thermally and somewhat gusty day, winds about 5+mph on the ground, probably 10+ aloft. The aircraft correctly then applied a hard right roll - which it did - a bit too strongly, as it banked almost vertically to the right, then rolled back level - all at about 10 feet off the deck (wingspan is 5'). I can't be certain exactly when the bimode switch was flipped, but it was ASAP after the wing transitioned. I'm considering adding some OPOSD display of the actual control inputs - it would be very helpful to know exactly what was applied vs what the plane did.
Here's a V1 video:

And the above mentioned V3 front cam video: