I’m beginning to think this is the H7 issue I see on the BeastH7 - I’ll attach some motors and do some tests this evening hopefully
I had to correct the last results, I did it another way and I obtained the following:
Not perfect but much better.
Ah interesting - that is good news. I will continue pushing on this theme as it seems to be paying off. Interesting about dshot 150
This is the difference between the two test:
-
I merged your PR on my local master (from yesterday) with:
git pull https://github.com/andyp1per/ardupilot pr-matekh743-bdshot
and then built target MatekH743-bdshot -
I cloned your ardupilot repo and checked out the branch:
git checkout pr-matekh743-bdshot
and then built target MatekH743-bdshot
Where do the two case differ?
No idea, sorry. It may just be random - I too see some variablilty related to how I power up the flight controller. For instance on the trace sometimes I get no signal from one timer - which I believe is the problem you are seeing.
Anyway I don’t like so much this Matek H743 Mini even for thermal problems, it become very hot:
What version of BLHeli do you have? also I have the MatekH743 Slim rather than mini - dunno whether that makes a difference
BlHeli32 version 32.7
Definitely won’t try fly it until it’s stable on the bench, not to worry there.
I don’t have access to the craft right now, but if setting the ESC protocol to DSHOT 300 in the ESC tab in MP accomplishes setting MOT_PWM_TYPE to dshot, then yes. Initially I was getting conformation in the messages that I had DSHOT on outputs 1-4 and PWM on 5-8, it wasn’t until after setting BDMASK that the motors became “unallocated” in the messages tab per my above post.
Ok maybe difficult to diagnose without the hardware. I could do a debug build for you which might tell us more.
I’ll try it if your willing to whip it up.
Without BDMASK = 15 it’s been stable, but given that’s a param required for bdir it’s something worth looking into. How would the debug build work to show us the error?
It just means I can get an accurate line number for the watch-dog fault
Sounds good. I’ll have some time this evening to test, let me know when you have something to test and I will happily flash and report back.
Ok, so my results are entirely consistent now on my branch. I have four ECS and four motors, two with BLHeli32 and two with BLHeli_S
DSHOT150: nothing works
DSHOT300: everything works at all dshot and loop rates
DSHOT600: everything works at all dshot and loop rates
DSHOT1200: only BLHeli32 ESCs work
Thanks for info. Now I start to think that my ESC is crap and I have to buy a better one.
Which value for SERVO_DSHOT_RATE in your test?
Ah … OK you said all “dshot and loop rates”
I tried, 0,1 and 2 - but I’m beginning to think this is more of a random effect
I also verified that motors not turning is when we don’t get telemetry - so its quite a good check on a logic analyzer for works vs not-works
Ok, I have spent some time playing with this and its as good as I can get it I think. I get BLHeli32 working for me on all dshot bitrates. BLHeli_S only works on 300/600 - but I think that’s true for betaflight as well. Let me know if this works for you.
It turns out bi-dir dshot in the ESCs is incredibly sensitive to the bitrate. I guess that makes some sense but was unexpected.
Here’s a link to a debug build. Please load it up and send me the watchdog message you get.
I just loaded the provided debug build, and was able to set SERVO_BLH_BDMASK=15 without error. Checked back in the messages tab and found no watchdog errors. Ensured outputs were set to ds600, and attempted to send motor test command to motor A, which sent the board into bootloop. Flashed official, reset params to default, repeated the process with ds300, same results, except this time I got sent to bootloop directly upon writing SERVO_BLH_BDMASK=15
Ran test again with LOG_DISARMED=1 checked the messages of the log and again found no watchdog errors. Would it help if I was able to get a FC sent your way?