Tridge,
I was using serial 2 as that was what was working before.I also tried it on serial 5 as someone said they were having issues with serial 2 in another thread. before the beta 3 update like I said it would output the data for right about a minute then stop after the update it doesnt seem to send anything.
Here is a link to my parameter file
Matek 765 4.0.2 Beta 3 Dump for tridge.param (20.3 KB)
Thanks for looking into this
This is caused by enabling BLHeli/DShot output on those channels and is actually deliberate. The PWM range on a DShot output is not meaningful. By forcing channels that use digital output control (such as DShot) to be 1000 to 2000 we prevent issues with scaling from other places in the code.
We should make this clear in the documentation on DShot. I’ll ping @hwurzburg
I had a look, and first thing to note is your param file has NMEA output going to 3 serial ports. That is a lot of NMEA ! I’m not sure if you intended this.
It does work for me, but I did find that a bug fix from @peterbarker was needed to stop is corrupting the line endings on NMEA. With that fix applied I get nice clean output and it continues for as long as the board is up.
One thing to note is that it only outputs NMEA if it knows the time. That usually means it needs to have had GPS lock at least once, although there are other ways to get the time.
I’ve put a 4.0.2beta3 with the line ending fix for you to test here:
http://uav.tridgell.net/tmp/matekf765-nmea-fix1.apj
The other thing to watch out for on this board is the flow control pins. SERIAL1 has hardware flow control, so if you use that port then you may need to set BRD_SER1_RTSCTS=0 to disable the flow control.
I also note that you have a quite low baudrate on SERIAL6 of 9600 for the NMEA. Not sure if that is deliberate.
Flashing the apj from that link flashes Arducopter 4.0.0rc4
As far as the multiple Nmea outputs that was just me being sloppy and not zeroing out those serial options when I iwas testing on different uarts.This is definitey something I should pay more attention to.
sorry about that, try this:
http://uav.tridgell.net/tmp/matekf765-nmea-fix2.apj
no worries, it is valid to have 3 NMEA outputs, just unusual
Ok flashed that one and turned off the extra nmea outputs and used serial 2 only. It started out good reporting 6 satellites on the nmea output and held for 5 minutes or so.Once I armed the throttle it dropped to three satelites and stayed there.Upon disarming it would return to 6 sattelites.I repeated this process several times with the same results each time.
The NMEA output is setup to show 6 satellites when ArduPilot has a good position. It shows 3 satellites when it doesn’t have a good position.
Are you testing indoors? Or perhaps you are getting interference when you start the motors which causes the EKF to get bad data from the GPS or compass?
If you set LOG_DISARMED=1 then we would get a log which would tell us what is happening.
I was testing indoors but had 10-12 satellites so thought it would be ok as I was right near a window. I will test outside tomorrow to see if that changes it and if not will change the logging to get a log file. Thanks for working with this with me.
Well It looks like that worked.I was still getting the drop to 3 satellites but your message about the ekf issue made me think about it so I ran with the plane to simulate takeoff and get the yaw alignment set seems to have fixed it.
Thanks
1 Like
Heureka @tridge 
It works with a better parameter setting!
I systematically tried out settings for BLELI:
SERVO_BLH_AUTO set 1 causes the unwanted behavior at motor output 7 (used for yaw servo in case of non-vectored tri’s). Instead of SERVO_BLH_AUTO (set it to 0) use SERVO_BLH_MASK with the bitmask of actually to BLHELI-ESCs connected outputs. On the bench, yaw servo works.
Rolf
I’ve just release plane 4.0.2 stable. This is a minor release with a few bug fixes and enhancements. Changes are:
- fixed voltage scaling on CUAVv5Nano
- fixed 10Hz NMEA output
- fixed range check on RC channel selection
- scale UART RX size with baudrate
- default fast sampling enabled on first IMU for all capable boards
- fixed bootloader flash alignment bug
- fixed PWM 5 and 6 for MatekF765-Wing
- support RM3100 compass on I2C
- fixed error on AHRS level trim in preflight calibration
- fixed handling of SB without BUSY on I2Cv1 devices
- update bootloaders to be more robust to unexpected data
- added new COMPASS_SCALE parameters and estimator to fix issue with compass in Here2 GPS
- fixed issue with millis wrap on boards with 16 bit system timer
(MatekF405, MatekF765, speedybeef4 and KakuteF4) - fixed i2c internal masks for several boards
- fixed scaling of Blheli32 RPM conversion
- changed to WFQ FrSky telemetry scheduler
- enable LED pin on MatekF765
- added params for Durandal battery monitor pins to param docs
- updated bootloaders to reduce change of line noise stopping boot
- fixed DMA error causing memory corruption in ChibiOS I2C driver
- fixed param conversion from plane 3.9.x to plane 4.0.x for rangefinders
- cope with UAVCAN GPS that doesn’t provide AUX messages (Here2 GPS)
- send temperatures for IMUs on mavlink
- fixed I2C clock speed error on STM32H7
- fixed CR/LF output error for NMEA output
Happy flying!
3 Likes
@yak-54 I just wanted to let you know I haven’t forgotten about your issue. I am going to try and replicate here if I can find my minimosd. I didn’t want to hold up the 4.0.2 release though, so I’m afraid it will probably have the same issue for you
don’t worry about it its new build the other plane that i fly has only one screen
thank you so…much I plan to test with the FX-61 ; flying wing …
I just have updated my quadplane to 4.0.2. I have recalibrated the HERE2 compass but the COMPASS_SCALE remains at zero >>> It should change automatically to 1.17
I have changed it manually to 1.17.
I think it is the right thing but it is not what was expected
what calibration method did you use? Do you have the tlog of the calibration process?
yes, it should work out the calibration. It is unlikely to come out at exactly 1.17, but should be close
I have used onboard calibration with 1.3.68 MP version. I’ll post the tlog. I will try again with latest version of MP, Could it be the problem?
1 Like
I have updated MP to the latest version 1.3.70
I have recalibrated HERE2 primary compass only
I have used live calibration
I have used onboar calibration
But COMPASS_SCALE still maintains the value zero.
If I change it manually to 1.17 >> Do we get the same result?
1 Like
The most likely cause is that you are calibrating without GPS lock. If you don’t have GPS lock then the calibrator doesn’t know what the correct magnetic field strength should be, so it leaves COMPASS_SCALE=0.
It will help, but it would be better to get the right scale by calibrating with GPS lock.
Perhaps you are calibrating indoors? If so then that is a bad idea.
I have understood. Indeed I was trying to calibrate without GPS lock. >> Tomorrow I will calibrate it with GPS Fix.
Thanks Tridge