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.

[markusgritsch]

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.

Maybe it's some detail in the bidirectional Dshot implementation of SilF4ware. Maybe it's already fixed since your fork. I think I made some minor changes quite some time ago. And the issues are only with this single ESC, right? It would be a good time now to look at the signal traces with a scope, to see what's actually going on. Maybe some edge case timing issue with this ESC, maybe the hardware is a bit different and causes problems.

Since I do not exeperience any issues, it's hard to help with your problem.

[mathiasvr]

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

It should only "work" on L type ESCs but I haven't been able to test it as I don't have any. It would be great if you could do a betaflight motor test or similar for me. :)

I didn't realize your startup issues were only happening with bidirectional dshot. This seems like a bug, but as markus said it's difficult to say whether it's bluejay, the fc firmware or a combination causing it?

[sakitume]

@markusgritsch I think you bring up some good points. I think it would be worth the effort to try and update the SilF4ware core that I forked particularly the latest DSHOT code you have.

I wish I had the equipment to examine signals at the level you're describing but unfortunately I do not. However it looks like in today's world this is actually quite affordable now. It has been many years since I worked at that low level with hardware so I continue to be amazed at how affordable and available technology has evolved.

@mathiasvr I will try and test the DSHOT150 implementation for you with L type ESCs. The CrazybeeF3 boards I have already work fine with "normal" DSHOT300, so those would be good boards for me to test this with.

And yes, the issue with the O_H_5 firmware testing/evaluation only occurs when using bidirectional DSHOT300. I hope to retry after updating my fork with latest from Markus' SilF4ware repo.

[markusgritsch]

Tested F_H_40_24_v0.7 and F_H_40_24_v0.8 (no difference) with bidirectional Dshot 600 (necessary for 8k mainloop) with Betaflight. Betaflight Configurator Motor testing tab shows quite some Telementry Error percentage (red above 3%, sometimes 4%). For comparison: F_H_40_REV16_73 shows 0.1% maximum error rate with Dshot 600.

[mathiasvr]

Thanks @markusgritsch, I have mostly been using DShot300 so will try to examine DShot600 in more detail.

To avoid interfering with commutation Bluejay should be skipping more telemetry packets with DShot600, but I don't think it should show up as errors in the motor test.

[sakitume]

@mathiasvr I was able to merge in many of the relevant changes Markus made in SilF4ware into my fork and now bidirectional DSHOT300 seems to be working with Bluejay v0.8 O_H_5 firmware. I need to perform more testing but wanted to provide this update for now.

@markusgritsch the changes that seemed to be the most important were the GCR decoding. I think your earlier suggestions (you gave for v0.6) might have solved the issues I saw with v0.7...meaning we needed the fixes in v0.7 before those suggestions had a chance of being effective.

I hope to do some more testing of v0.8 (such as DSHOT150 on L type ESCs, and more bidirectional DSHOT300 on the O_H_5 hardware I have). Once I do that I hope I can close out this ticket.

Thanks again everyone.

[mathiasvr]

@markusgritsch I also got some errors with dshot600, thanks for reporting it. I measured the normal dshot signal from betaflight with my analyzer and it was spot on so I think it should be precise enough? Anyway, now I have tuned the telemetry timings to minimize the errors in betaflight motor tab, even though the timings are now below spec. Not sure why that is needed but I guess betaflight communication is more important. It will be updated in next release.

[mathiasvr]

I'm closing this for now, feel free to reopen if there are still problems. Thanks for all the info provided here!

[Stampede10343]

I am also having issues with Bidirectional DShot on a Mobilte 7 with O_H_5 firmware. Tried multiple versions, when I enable Bidirectional DShot the quad does not arm, CPU load goes up from ~30% to ~60% and the OSD lags.

[swilkens]

@Stampede10343 Moblite 7 has an F4 chip right?

There are currently some possibly related changes happening in BETAFLIGHT 4.3.0-RC releases, specifically for F4 processors. Do you use those releases by chance? If so, does it also happen on 4.2.11?

https://github.com/betaflight/betaflight/pull/11278

[Stampede10343]

@swilkens ahh interesting it is F4, yeah I'm on 4.3 RC2. I'll have to try 4.2.11.

[Stampede10343]

Yeah 4.2.11 seems to work fine!