RPM Telemetry failure?

[sakitume]

Hello Mathias (tamashi). I mentioned this to you over RCGroups messaging but wanted to raise it as a github issue in case others might also be experiencing the same thing. The issue I'm having is that bluejay O_H_5_48_v0.4.0.hex does not seem to function with my Mobula6 flight controller board running my SilverFlight-FC firmware when I have RPM filtering enabled. The motors don't spin up.

This is not Betaflight that I'm running but a variant of Silverware based on SilF4ware.

RPM filtering definitely works on this board and firmware combination when using JazzMaverick. I believe I used JazzMaverick O_H_5_48_REV16_9_RC4.HEX, O_H_5_96_REV16_9_RC4.HEX and O_H_5_48_REV16_77.HEX successfully on this board and SilverLite-FC.

If I disable RPM filtering then the motors spin up as expected.

Let me know if there's anything I can do on my end to help diagnose/fix. Would be great to try out your firmware.

[mathiasvr]

Hi, yes thanks for testing this!

This issue is quite strange and I'm happy you have reported it this early. I have been testing some different motors and ESCs with betaflight and have not experienced this. I have not had the chance to try your firmware yet, but it is quite interesting that it only works without telemetry yet still works with telemetry in JazzMavericks version.

I'll continue to look into this, and hope we can soon find the cause of this.

[mathiasvr]

@sakitume I still haven't been able to figure out what's causing this, but since it only happens when using RPM telemetry I wonder if it is related to how RPM filter works in your SilverLite firmware.

I've looked into JazzMaverick's 16.77 and notice that it has a bit more delay between dshot packets and telemetry, and it also sends telemetry for every dshot packet.

Currently, Bluejay only sends a telemetry packet if a commutation has happened since last time. I think BLHeil_M 16.9 does something similar, but I cannot check it right now because I blew up my testing ESC :(

Anyway, it would be great if you could test some modifications to v0.4.0 of Bluejay to check if this could be related to these differences.

I have attached two hex files: one adds a little more delay between dshot packets and telemetry, the other sends telemetry for every dshot packet at the cost of more commutation interference at high rpm.

O_H_5_48_v0.4.0_testing.zip

Thanks!

[sakitume]

@mathiasvr I tried the two hex files you provided. The process I use is:

First reflashed the stock Betaflight 3.57 firmware so I could use the BLHeli passthrough it provides. Then I flashed both one of the hex files you provided using BLHeli configurator. I then power cycled the board and then used the "Motors" tab in Betaflight configurator to verify that the motors can all spin up. Everything looked good with Betaflight 3.57 (no RPM filtering enabled, DSHOT300).

Then I flashed my SilverLite firmware and armed the quad; this should cause the motors to idle. However there was no spinning.

I tried this with both of the hex files you provided.

There is some diagnostic code in the telemetry portion of the DSHOT implementation. https://github.com/sakitume/SilverLite-FC/blob/009bbeef1e925f58eb6af16de9f9ab6cc5166938/Core/Src/drv_dshot_bidir.c#L381

This was code developed by Markus (SilF4ware, which I forked) using the information/groundwork provided by Joe Lucid. https://github.com/betaflight/betaflight/pull/8554#issuecomment-512507625

I will try to find some time to enable this code and log it out over virtual com port every second and see if anything is noteworthy.

At the very least this debug code will tell me if rpm telemetry was detected and if so, how many errors occurred when trying to decode them.

What is still unclear to me is even if rpm telemetry failed to be decoded properly, why would the motors fail to spin? The firmware is still sending packets to each ESC instructing them what value to spin each motors.

Also, I have a switch that causes the motors to beep. This is achieved by sending each ESC a DSHOT command to beep. I thought to test this out to see if the ESCs are responding to the command packet and it seems like they're not!?!

Curious....

[mathiasvr]

@sakitume Thanks a lot for your quick testing. Your process sounds good.

Are you getting all the usual 5 beeps when powering up? First, 3 beeps when the ESC is powered, then one beep for detecting dshot protocol, and finally one beep for receiving "0" low throttle, which arms the ESC.

You should hear the same as when you disable telemetry. If you do, this really is just getting even more strange 😅

[sakitume]

Hey @mathiasvr. I reflashed Bluejay O_H_5_48_v0.4.0.hex onto my mobula6 board and then reflashed my SilverLite-FC firmware. I get the 3 beeps on powerup, but I do not get the additional 2 beeps after that.

Interestingly enough, I can get the ESC's to beep with a "motor beep switch" that I have hooked up that sends DSHOT command to beep (commands 1 thru 4 inclusive).

Also, after arming and then moving the quad around one of the motors eventually twitched and came to life. Normally all 4 motors would start spinning upon arming (air mode). Eventually I could keep pitching the quad until eventually all 4 motors started spinning, but they didn't seem to behave normally. So..something is weird for sure.

Also, I noticed your recent post on the RCGroups thread (yesterday):

"Turns out all the H versions cannot currently arm with bidir dshot because bluejay doesn't initially send telemetry"

Once you make a new release I'd love to give it a try to see if it resolves the issues I'm seeing. I'd really like to try Bluejay more than I have.

[mathiasvr]

Hi @sakitume, I was hoping the arming issue could be what you were experiencing as well but I'm not so sure.

Betaflight won't arm unless it receives telemetry data which I only enable after arming the ESC 🤦 I was testing mainly on the bench at the time so didn't notice it was quite useless with Betaflight's rpm filtering.

Anyway, your issue seems different since you don't get the 2 beeps that indicate dshot detection. However it should not be possible to send dshot commands or arm before the protocol has been detected, so this is really strange.

Actually, I can't really make sense of it at all, but I hope we can try debugging it further after the next release.

Edit: If you have time you can try this version of 0.4.0 with dshot level detection that is more similar to JazzMac's. Still, quite a longshot since it shouldn't really affect things this much.

O_H_5_48_v0.4.0_rcp_check_20.zip

[mathiasvr]

I think your twitching motor problems are related to the 48khz version needing more startup boost. I have also just noticed that startup boost is buggy with higher startup power than the default, so I'm working on some fixes I hope will fix this.

[sakitume]

Thanks for that other zip. I was able to flash that to see if anything changed. This time I flashed it onto a 75mm whoop. No beeps and no motor spin.

I'm not familiar with this "startup boost" feature of ESCs so am interested in helping you test out any newer versions to see if that might be related to the overall issue I'm seeing with my firmware

[mathiasvr]

No beeps at all?

Startup boost increases the throttle when starting the motors to get them spinning. JazzMac has already updated this, so maybe this could be why it works with his version? However, oddly enough it looks like it (v16.8) still has the startup power bug mentioned.

[mathiasvr]

Hi @sakitume, I have made some improvements and it seems to work more reliably now. However, I still don't have much knowledge about silverware or been able to test your firmware, so it would be great if you could try out version 0.6 at some point. Based on your issues it's hard to say if any of the changes will actually solve the problem so I'm very curious about the result.

[markusgritsch]

Hi @mathiasvr, I'm the developer of SilF4ware.

Just wanted to let you know, I flashed Bluejay J_H_15_24_v0.6.hex on a Racerstar REV35 35A Anniversary Edition ESC, and I can confirm, that it works fine with SilF4ware. I do not have any of the issues described above.

I'm going to upload a throttle/RPM curve to the RC Groups thread. Single issue I have is the huge startup boost, which I really don't like. I will describe it in detail there.

[mathiasvr]

@markusgritsch Thanks a lot that sounds great!

I changed the startup boost to accommodate some smaller stubborn motors but I definitely want to update it if it's now an issue for you. I'm hoping to avoid having a setting for it but that might end up being for the better.

Btw compared to _S, startup boost is now independent of startup power.

[markusgritsch]

Btw compared to _S, startup boost is now independent of startup power. So you are saying it's not even related to my increasted Startup Power setting, right? Well, as already written in the RC Groups posting, I would really like the old behavior back :)

Other than that, I like Bluejay very much. Thanks for your effort!

BTW, nice startup tone :)

[mathiasvr]

Actually, it looks like the stall count is 1 and not 0 during startup which I expected, making the initial startup boost even higher... Good thing I didn't chop your fingers off 😅

[sakitume]

@mathiasvr Thanks for reaching out. I haven't had a chance to test out v0.6 on the NOX or MATEKF411RX targets yet.

I have however tested it on a CRAZYBEEF3FS target and it works quite well. These are "L" type ESCs. However these F3 boards aren't as fast as the two F4 boards I just mentioned so I'm not using RPM telemetry (for RPM filtering). These F3 boards are often on sale for 20 USD and run very well for my 1S whoops and micros. I'm using the O_L_5_48_v0.6.hex on these boards and am getting longer flight times as expected. Very nice. Thank you again for this.

I hope to test the O_H_5_48_v0.6.hex firmware on my other F4 boards soon and will report back what I find.

[sakitume]

@mathiasvr Great news, S_H_50_48_v0.6.hex seems to be running well on the Play F4 (NOX target) board I just tested. This is with RPM telemetry (and thus RPM filtering enabled).

Next I will try and test on the MATEKF411RX board (O_H_5_48_v0.6.hex) and hope that works as well. Fingers crossed.

[sakitume]

Looks like O_H_5_48_v0.6.hex isn't working for me (using RPM telemetry) on this MATEKF411RX board. Also, I'm not getting the double-beep that occurs after the initial startup beeps (tune).

However this same hex file will work when not using RPM telemetry.

Again this is using my own firmware. And I've never tried to use Betaflight with RPM filtering on this board. I think it would be worthwhile attempting that to make sure this board is truly capable of supporting RPM telemetry+filtering.

[mathiasvr]

@sakitume Thanks for testing all these! Very nice to see an L type esc working! Strange about the O_H_5_48, seems it will be quite a difficult bug to track down, I'm also very interested to know if it works with Betaflight.

[sakitume]

@mathiasvr I seemed to have overlooked that I am already using RPM filtering/telemetry on these boards via JazzMaverick versions as I mentioned in my original issue posting. So it is already known that the hardware supports it.

So the open question is does Bluejay RPM telemetry work wtih Betaflight?

I was able to install Betaflight 4.1.7 (latest available 4.1 version for this board) and configure it for RPM telemetry. Unfortunately I could not get the built-in SPI receiver to work for some reason. So all motor testing was within Betaflight's "Motors" tab. Using that UI I could spin up each motor with their sliders and there were no reported errors displayed. Even though I can't actually fly this quad, I'm fairly confident that Bluejay v0.6 works fine with RPM telemetry and Betaflight.

So really the issue I'm facing is most likely due to my firmware and this hardware combination rather than Bluejay itself. I'm fine if you'd like to close out this issue.

[markusgritsch]

Try reducing 23 in line https://github.com/sakitume/SilverLite-FC/blob/9f1c9910bfc992a27e5e5953e4bc5fa116c8cf0b/Core/Src/drv_dshot_bidir.c#L391 to something smaller, and see, if it works then.

[mathiasvr]

@sakitume If it works with BLHeli_M I think it's reasonable to consider it as a potential issue with Bluejay. Maybe the cause has been masked by some of the problems with earlier bluejay versions? I hope we can get to the bottom of it.

[sakitume]

@markusgritsch I greatly appreciate the suggestion. I did try various values but unfortunately the system is still not operating as expected. The beauty of forking from your SilF4ware project is that so much just works "out of the box".

I went and re-tested with and without RPM telemetry and what I find is that without RPM telemetry, I get that double-beep a second or so after the initial startup beeps. But I do not get this double-beep at all when RPM telemetry mode is enabled.

This led me to looking at Bluejay source code, specifically here: https://github.com/mathiasvr/bluejay/blob/17efdd424bcb14d5a3d93ca98f73c2f6b7de3118/Bluejay.asm#L3676

If this region is where those double-beeps come from, and I'm never hearing those, then it looks like the DSHOT detection is failing and we're never jumping to arming_begin. Does that make sense? If that's the case then maybe I need to check the DSHOT implementation on both the FC firmware and in Bluejay to see where the discrepancy may lie. Maybe it is a very slight timing difference between what my system is providing versus what Bluejay is expecting and that maybe JazzMaverick is more tolerant.

FYI I'm using DSHOT300. I suppose I could try DSHOT 150 to see if there's any difference.

[markusgritsch]

Maybe it is a very slight timing difference between what my system is providing versus what Bluejay is expecting and that maybe JazzMaverick is more tolerant.

If that's the case, maybe try tweaking the value 1000 in DSHOT_BIT_TIME_THIRD, GCR_BIT_TIME_THIRD, and GCR_BUFFER_SIZE at the top of drv_dshot_bidir.c a bit up and down.

[mathiasvr]

FYI I'm using DSHOT300. I suppose I could try DSHOT 150 to see if there's any difference.

Bluejay does not support dshot 150 at the moment since I’ve been cutting some corners, sorry about that.

I will try to look into differences in dshot300 timing between bluejay and blheli_m as well.

[mathiasvr]

Okay, so I tried measuring some signals with a cheap logic analyzer. Not sure about the accuracy might need someone else to reproduce.

There definitely seems to be some problems when Bluejay is running in 24MHz mode (which it does when motors are not running).

Running DShot 300 with 48 kHz pwm.

Firmware	Delay between DShot and tlm	GCR 1	GCR 2	GCR 3
Bluejay (Idle 24MHz)	27.5 / 69.5 us (this is buggy)	2.5 - 2.68 us	5.25 - 5.3 us	8 us
Bluejay (Running 48MHz)	30.8 - 31 us	2.5 - 2.68 us	5.25 - 5.4 us	7.9 - 8 us
BLHeli_M 16.9 RC4	32.75 - 33 us	2.4 - 2.5 us	5.18 us	7.68 - 7.8 us

[mathiasvr]

I've updated the delay between dshot and telemetry for Bluejay v0.7 to be:

• 24MHz: 32.6 - 33 us
• 48MHz: 33 - 33.3 us

[sakitume]

@markusgritsch thanks again for the suggestion, I tried a few values but didn't see any changes. I'm still trying to wrap my head around how you implemented this as it seems like the duty cycle would be 66 and 33 percent for 1s and 0s. I had thought that perhaps that might be the difference. I think your DMA implementation is simple, clean and elegant and found it interesting to compare the difference between the bidirectional DSHOT via DMA versus "plain" DSHOT via DMA.

@mathiasvr I'm happy to report that v0.7 is mostly working. My FC board is now able to communicate with the ESCs via bidirectional DSHOT300 (RPM telemetry), I now get the ESC arming beeps (they are triple beeps now, wasn't expecting that) that occur after the startup beeps. I can arm the quad with my TX and apply throttle and have the motors spin up.

As expected, when the FC is disarmed it sends a DSHOT command of 0 which (of course) causes the motors to stop. When enabled it sends a value of 20 (+ the 48 offset DSHOT expects) so that the motors spin at a comfortable idle. The issue I notice is that spin-up to idle is inconsistent. Sometimes all motors spin-up to idle, sometimes they take a little while to spin up (maybe 100 to 300 ms). Sometimes 2 of the motors spin up fine but 2 others twitch a little bit before spinning up. On rare occasions one of the motors just twitches and never fully spins up (maybe it would if I let it continue but after 3 seconds of this I decide to disarm).

So I think this is great progress as it seems to confirm that the "Delay between DShot and tlm" you examined might be the central issue. Your v0.7 update certainly caused a positive change.

I'm going to flash this on a 75mm whoop and fly it around the house to see how it responds and report back how that goes. Hopefully the spin-up issue can be addressed as well.

Thanks again for all your work on this @mathiasvr

[markusgritsch]

@mathiasvr Great release, and the startup boost is also gone! Yay!

@sakitume The change, which makes me happy (no startup boost) causes your motor startup issue on these tiny motors. You should add the THROTTLE_STARTUP_KICK feature from SilF4ware to your fork which handles this: https://github.com/markusgritsch/SilF4ware/blob/f6b6c34cf404c731f4edac0b0eb6d3eaddeb27de/SilF4ware/config.h#L179

[mathiasvr]

@sakitume That's great news! Thanks to your issues and tests Bluejay telemetry is now much more reliable!

The startup boost is still higher than in BLHeli_S to try to accommodate smaller motors, but it seems the needed boost varies a lot with smaller motors. I think probably a configurable option is necessary to manage this. Startup boost is now dependent on idle speed, so you could try raising that as a temporary solution. Also, I recommend setting the timing to medium-high if you haven't already.

@markusgritsch I hadn't thought about handling startup boost from the FC - maybe this is the best solution? In that case, I think it would be nice to be able to turn it off completely in Bluejay. I will look into this once I begin tackling the configurator.

[markusgritsch]

Yes, I discovered that the reliability of motor reversing for 3D gets a lot better when using some boost or "kick" from the FC: https://www.rcgroups.com/forums/showthread.php?2645953-Mini-tubular-and-ultralight-LOS-Acro-FPV-Quads/page383#post41483891

So I figured, a similar kick could be helpful for startup with small motors, too. And changing the strength in the FC setting is IMO more convenient than configuring some parameter in the ESC.

Here is how fast successive reversing looks like in BB logs:

[Quick-Flash]

@sakitume The change, which makes me happy (no startup boost) causes your motor startup issue on these tiny motors. You should add the THROTTLE_STARTUP_KICK feature from SilF4ware to your fork which handles this: https://github.com/markusgritsch/SilF4ware/blob/f6b6c34cf404c731f4edac0b0eb6d3eaddeb27de/SilF4ware/config.h#L179

I've actually ported this code over to EmuFlight with much success. I've been following your silf4ware work for a good while and must say that you've done some great stuff with it!

[markusgritsch]

Thanks! Yes, I've spent quite some time improving it the last two years :) I think it has reached a point, where it flies just fine for me.

[Quick-Flash]

@markusgritsch you still working on silf4ware? I haven't seen anything going on there recently. I'd be sad if that project died.

[markusgritsch]

I'm flying it regularly. And it seems, I'm almost it's single user :) Not much going on in the SilF4ware RC Groups thread either. Last minor git commit was yesterday. It's just that for my needs and flying style the firmware is quite feature complete, and does what I expect it to do :)

[sakitume]

Thanks again, @markusgritsch for another great suggestion. I'll look into that THROTTLE_STARTUP_KICK feature you implemented and see if I can cherry-pick or merge the necessary changes into my fork.

Also, I feel similarly about the features, and functionality you've provided in SilF4ware. It "just works" and works quite well. I've not changed the core of it with my fork, only adding features that I personally want on top of it. Even though you built it for your needs, it works extremely well for the smaller quads that I fly.

@mathiasvr v0.7 seems to work well with the 75mm whoop I tested with. As long as I can get all 4 motors to spin up on arming, I can fly it with the performance I expect. I'm not experiencing any de-sync issues (where ESCs stop communicating and quad drops out of the air).

I'm hoping that Markus' suggestion is all I need to complete this puzzle. I will report back here when I have the opportunity to try that.

[Quick-Flash]

@sakitume sorry to derail, but I really love your wiki and would love a little help getting my own set up similarly.

[sakitume]

@Quick-Flash, sure thing. I'd be happy to help out. Reply back with your project's URL and I can contact you over an issue or whatnot on your project's github.

[sakitume]

@mathiasvr I'm not having much luck with the throttle startup kick that Markus suggested. Maybe I don't have the necessary code changes merged in, or I missed something.

I'm wondering if you might have any other suggestions with the motor spin-up on arming. I don't mind forking your project and doing my own experimental changes based on any suggestions. I'd need to figure out the build process (toolchain setup, etc) but I'm up for doing that if it would help further this along.

I should probably test v0.7 with Betaflight to see if it exhibits the same issue. I don't know if it has a feature such as what Markus developed in SilF4ware (that startup kick). If it doesn't it might mean the issue I'm seeing could manifest for Betaflight users as well.

[markusgritsch]

@sakitume The startup boost is still higher than in BLHeli_S to try to accommodate smaller motors How do your motors start up when using stock BLHeli_S 16.7? If, despite the above statement, they start up better with stock BLHeli_S, there might still be a bug lurking.

Startup boost is now dependent on idle speed, so you could try raising that Have you tried this? What's the outcome of it?

Also, I recommend setting the timing to medium-high if you haven't already. Is your timing already medium-high?

[markusgritsch]

@mathiasvr Startup boost is now dependent on idle speed Are you sure this is true? At startup, what does Bluejay interpret as 'idle speed'? If it's the first Dshot value it decodes which is different from 0 (or 48 or 1048), I cannot confirm this:

On the left side the motor traces at the red marker position line are 0%, then jump to 4% idle speed, when arming. On the right side the motor traces jump on arming from 0% to 25%, and then ramp down to 4% during 100 ms. No difference in motor startup is visible in the motor RPM debug traces.

On reversing everything is fine. The sawtooth kick is respected well, and really makes a huge difference in reversing performance.

[mathiasvr]

@mathiasvr Startup boost is now dependent on idle speed Are you sure this is true? At startup, what does Bluejay interpret as 'idle speed'? If it's the first Dshot value it decodes which is different from 0 (or 48 or 1048), I cannot confirm this:

Sorry, that was a very imprecise statement. When the motors are not running Bluejay will always increase "boost" the incoming DShot throttle value. BLHeli_S has a set minimum value as startup boost, so the throttle is only "increased" if below this value. So what I meant was that in BLHeli_S if the idle is below the startup boost value, increasing idle would not increase the boost. In Bluejay, increasing idle will always increase the boost as well. However, iirc BLHeli_S default startup boost is only 2.5% (1025) - so it only really matters for low idle.

TLDR: Throttle is slightly increased in the startup phase.

Now, every time the motors fail to spin up (stalls) the boost is increased further. @sakitume If your problems are due to too low startup boost, you should be able to see them spin up at some point after a number of consecutive stalls (motor twitching), or by simply increasing throttle on the transmitter.

[markusgritsch]

So, shouldn't then the motors start more powerful in the startup kick case depicted on the right hand side?

[mathiasvr]

So, shouldn't then the motors startup more powerful in the startup kick case depicted on the right hand side?

Maybe, I don't really know much about dc motors, but I guess the motors will not necessarily spin up much faster, but it's more a question of having enough power to begin spinning at all. Maybe startup (rampup) power is playing a part as well?

I could also be misunderstanding something since I'm not very familiar with blackbox.

I'm very happy about all the testing and experiments you or anyone else can provide to help improve the firmware. I'm currently not able to do any detailed testing myself and spend most time on code optimization and removing bugs.

If you think something is wrong we should keep looking into this, I'm open to any suggestions as well.

[mathiasvr]

I'm wondering if you might have any other suggestions with the motor spin-up on arming. I don't mind forking your project and doing my own experimental changes based on any suggestions. I'd need to figure out the build process (toolchain setup, etc) but I'm up for doing that if it would help further this along.

If it's a startup boost thing, I hope to have that configurable soon. I can also make a build with more startup boost for you if you like. If you prefer to make your own changes I'm happy to help you set it up as well.

[markusgritsch]

I was just thinking, if the startup behaviour of Bluejay 0.6 is able to get the tiny motors from @sakitume reliably running, Bluejay could decide, depending on the size of the first Dshot value (or first few values) different from 0 (48, 1048), how strong it should initially try to startup the motors.

This way, the startup behaviour could be changed by the FC without an additional Bluejay parameter.

[mathiasvr]

Yes, I think being able to change startup from the FC like that could be a good idea. Could maybe also be done with dshot commands.

[sakitume]

Hello all. Sorry for not replying sooner. High winds where I live in CA have caused lengthy power outages as well as internet connection issues for me.

@markusgritsch regarding some or your recent questions/suggestions:

The startup boost is still higher than in BLHeli_S to try to accommodate smaller motors
How do your motors start up when using stock BLHeli_S 16.7? If, despite the above statement, they start up better with stock BLHeli_S, there might still be a bug lurking.

I have not tried BLHeli_S 16.7 so cannot answer. But with BLHeli_M 16.9 and using bidir DSHOT300 the spin-up behavior is fine.

Startup boost is now dependent on idle speed, so you could try raising that
Have you tried this? What's the outcome of it?

Yes, my idle speed is 20 (1/100th of the 2000 value range). I bumped that up to 30 and also 40 but did not notice any change.

Also, I recommend setting the timing to medium-high if you haven't already.
Is your timing already medium-high?

It looks like the timing was currently set to "High", I tried changing it down to "Medium-High" and that did not improve anything unfortunately.

@mathiasvr I'd like to try a build of Bluejay that has more startup boost to see if that actually makes a difference. If the source changes for something like this are pushed to github (say as a fork) I'd be able to understand what changes you made should I want to make minor edits and experiment with fine tuning any behavior changes. I downloaded and installed the Keil C51 toolchain (hoping that's the right one) but am having issues with the makefile since I'm building under Windows 10 using "git-bash" shell and also using mingw32-make.exe. I've modified it (of course) since I don't need Wine to run the toolchain executables, but haven't got it working just yet.

[sakitume]

@mathiasvr I am now able to build locally. I was able to recreate the exact same .hex for v0.7 using the O_H_5_48 target. I can play around with the code and try different values for things should that be of any help to you.

[mathiasvr]

I have not tried BLHeli_S 16.7 so cannot answer. But with BLHeli_M 16.9 and using bidir DSHOT300 the spin-up behavior is fine.

BLHeli_M 16.8 does not really have more startup/stall boost. Maybe the commutation features are better for startup?

It looks like the timing was currently set to "High", I tried changing it down to "Medium-High" and that did not improve anything unfortunately.

Okay, you may want to stay at High then since it should only help if you were on default medium.

@mathiasvr I am now able to build locally. I was able to recreate the exact same .hex for v0.7 using the O_H_5_48 target. I can play around with the code and try different values for things should that be of any help to you.

That's great, I'm happy to merge your build changes so we can support Windows as well. Please let me know if I can help with anything you want to try. About the startup boost, I think it's unlikely that raising it will help if the motor doesn't start spinning after multiple stalls (which also raises it). But I guess there could be some difference to the initial kick.

[sakitume]

@mathiasvr I just tried v0.8 to see if there's any improvement with my issue, but I see no improvement.

What is bizarre is that I'm no longer able to reliably get all motors to spin up at all. When I first tried v0.7 I was able to get at least one test flight in. After several arm/disarm cycles I could get the motors to all spin up enough to test things out and verify that it seemed to work (once motors would spin).

But after trying many different things (motor timing, flash different versions of different ESC firmware, etc). I'm now no longer able to reflash v0.7 and get the motors to spin up reliably. I think my firmware code is the same as it was when I had some initial success, but cannot be certain of that.

Also, I did attempt bidirectional DSHOT150 but got no response at all. I noticed your changelists for v0.8 stated support for DSHOT150.

And just to be clear, the same ESC firmware (whether v0.7, v0.8, 48Khz, 24Khz) runs fine with "normal" DSHOT300 for me, it is only with bidirectional DSHOT300 where I'm experiencing motor startup issues.