Copter-4.3.0 released!

Right. Refresh parameters and then try again if you want to load the file. A long time ago before there were Main and sub-parameters this issue, if you want to call it that, didn’t exist :slight_smile:

I suppose the “load from file” routine would have to be revised to load it once, refresh parameters and load it again within one function. Perhaps there is a down side to that but not immediately seeing it.

2 Likes

We fixed a bug with the RSSI pin voltage scaleing, it’s voltage was reported 3 times too big. You will have to divide your set offsets by three and scale factor times by three for it to come good again. (if you have linear or inverted scaling type, hyperbola you would divide the scale by three)

This is the PR:

The pre-arm is a bug because we have a two pin 103’s. One it a analogue input (the one your using), the other is a digital output shared with main 3 that would be conflicting. We should have a fix for the next release.

So this is a bug in the prearm logic, not an actual hardware conflict? If so, is there a workaround, or should I just avoid using the pin 103 analog input for the time-being?

Thanks!

Regards,
-Luke

Correct, just a bug in the pre-arm. Fix here:

Unfortunately the only way to get past is to turn off arming checks, which is not a good idea. As you say you could swap to another pin, or wait for the fix to make it into the next release. Sorry.

No worries, I agree, arming checks stay on. I just picked up a little serial LIDAR, so this just is the nudge I needed to get that wired in, it’s all good!

Regards,
-Luke

@Bridgerman,

Sorry for taking so long to investigate this but I’ve confirmed that at a basic level at least the SBUS output on a CubeOrange is working. The way I tested was to:

  1. connected the CubeOrange’s SBUSo port to the RCIN port
  2. set BRD_SBUS_OUT = 1 (50hz)
  3. rebooted the autopilot
  4. re-connected with MP and check the Data screen’s Messages tab and saw “RCInput: decoding SBUS(1)”

This last message means that the autopilot is receiving a valid SBUS input which means that the SBUS output is also valid.

I then turned on MP’s live graphing of “ch10in” and used MP’s Servo/Relay tab to channel the Ch10 output (which is fed back in as ch10 input) and again it seems OK.

My guess is that the problem is the SERVOx_FUNCTION for the SBUS channels that you’re trying to feed into the Gremsy gimbal. I suspect if you use MP’s tuning screen and try to graph the servo output (e.g. “ch10out”) you’ll find that they’re also not moving with the RC input. So the issue is not actually the SBUS output but the way the servo output is configured.

Could you provide an onboard log?

Hello

After version AC4.3.0, my GPS device with NMEA output is no longer usable.
Is it no longer supported for GPS devices with standard NMEA output?

thanks

On small boards it might be disabled, but you can still enable it for your board:

3 Likes

OMG, thanks a lot, it works. !!!

1 Like