Hello! It possible to add non-damped mode as feature like it presents in Blheli_32 and blheli?
For airplane active damping not needed.
Thanks!

I'm hoping someone can help me figure out what's going on with my new whoop board. After confirming all motors spin in Betaflight configurator I tried flashing Bluejay .14 48k with esc-configurator.com.

Upon powercycling the board only motor 4 spins. The rest just make a stuttering sound without making any revolutions. Flashing .14 24k results in motors 1 and 4 spinning while 2 and 3 stutter.

I also tried flashing Bluejay .13 48K and only motors 1 and 4 consistently start while 2 and 3 stutter without spinning.

I tried to revert to Blheli_S 16.7 official using the same configurator and motors 1,2, and 4 spin while 3 still stutters. I'm fairly certain motor 3 ran without issues prior to my upgrade attempt with esc-configurator.com.

I'm using a pre-release build of Betaflight 4.3 from this thread betaflight/betaflight#10788 and I'm wondering if maybe the ESCs aren't flashing right since the results are all over the place. I'd love to get Bluejay working but at this point I can't even get back to my pre-flash state.

Any help would be greatly appreciated.

With blheli_s I was able to happily run an idle value of 3. With this code I need to run an idle of 5.5 in order to keep all the props spinning in the air. Also the startup kick is just to much, need a way to dial that down.

Describe the bug
After Enabling bidirectional Dshot-600, only motor 4 will spin, others show 100% error.
Occasionally I got all motors to spin, but could not fly, because of RMP filter warning flag.

When changed to version 0.14, worked as expected.

Expected behavior
All motors would show 0% error rate and no RPM filter flag preventing arm.

Configuration:

• Bluejay version: 0.15
• ESC variant: F-H-40
• PWM frequency: 48/96 ( tested both)
• DShot bitrate: 600
• Bidirectional DShot: On
• FC firmware: Betaflight 4.2.11

The accuracy of the reported e-period (for rpm telemetry) should be improved to provide better rpm filtering and use of more narrow notch filters.

Screen for controlling and testing motors not always findable? Sometimes it is there, and sometimes not.

Seems like a bug in the configurator, else there is no obvious way to pull up the panel using menu or button. If not a bug, this is a feature request.

Configuration:

MacOS and Chrome based configurator

• Bluejay version: [e.g. 0.6]
• ESC variant: [e.g. A_H_5_24]
• DShot bitrate: [150/300/600]
• Bidirectional DShot: [On/Off/Either]
• FC firmware: [e.g. Betaflight 4.2.6]

If your issue is related to flashing, please press Save Debug Log in the configurator and post the log.

Describe the bug

Seems like Z_H_30 ESC's doens't work on 48khz or higher. Only 24k works.
Tested on HappyModel X12 AIO, found simmilar issues online on betafpv aio with same esc's

Expected behavior

Spin motors :)

Configuration:

• Bluejay version: [e.g. 0.14-0.16]
• ESC variant: [e.g. Z_H_30]
• PWM frequency: [48/96]
• DShot bitrate: [300]
• Bidirectional DShot: [Either]
• FC firmware: [e.g. Betaflight 4.3 RC3]

We can now change the startup melody, but we also want to play melodies with the beacon signal.

Describe the bug
Start bidirectional dshrot can only recognize two motors(only motor 1,2），Turn off the normal recognition of 4 motors

Expected behavior
A description of what you expected to happen.

Configuration:

• Bluejay version:0.11-96k/48k 0.10-96k/48k
• ESC variant: G-h-30
• Bidirectional DShot: ON
• FC firmware: [e.g. Betaflight 4.3.0]

Now that we have a pipeline for building, I would highly suggest a build server creating daily/nightly builds. I can chip in space and the actual build pipeline. I would build the main branch and keep a 7 day backlog of those builds.

If it wasn't for the crappy licensing situation I think integration tests via travis would be pretty cool - we could run the docker build pipeline via travis and would know if a commit breaks our builds.

Please consider forking blheli-configurator like others have done (https://github.com/Asizon/blheli-configurator/releases and https://github.com/jflight-public/jesc-configurator) because this makes it really easy to quickly update ESCs and test new releases.

EDIT - I see you have forked configurator but not published a release yet, hope this is something which can be done! Your commits look very promising :-)

thanks

I think, i would be usefull to have a special version of the firmware for debugging purposes. At some point an ESC goes bad (from a crash or other reason) and it would be nice if you could debug the problem in-system.
That version when flashed to the ESC, should be able to help at least on these scenarios:

• test if the FETs corresponding to motor wire A,B or C are working. The firmware could apply different waveforms on a FET in order to check this with a oscilloscope, a lightbulb or other mechanical means (motor, speaker etc). For example a test could be "apply Vcc for 5 secs on motor-wire A" in order to check if the FET is working, with a lightbulb connected to the motorwire A and GND.
• test if the feedback (zero-crossing detection) from motorwires is working.

There could be other tests also and we could have the good ESCs (in a 4in1 ESC with one bad ESC) beeping to signal the test results.

Whats your opinion on this?

I would really like to see the new S2M protocol by FETTEC, which is a good bit faster and more efficient (comparable to dshot1200) and seems to handle telemetry in a very clean way. The protocol could be a firmware choice as PWM frequency currently is, as the flash is quite limited already.

This feature could lead FC firmware devs to finally look into this protocol, which i think would be a leap forward in comparison to DShot.

This is what FETTEC writes on their Discord server:

S2M is a new ESC protocol form FETtec, its made to send fast digital throttle signals to ESCs and receive the complete telemetry over the same line.
On the FC side it uses the same hardware resources as DShot, but in a different way to generate true inverted serial bytes at 2.000.000 baud, not PWM pulses like Dshot does. Because of this, the ESCs can read it much faster and does not need to read PWM pulses to get bits out of them. With S2M the ESCs read three 8-bit bytes using its hardware serial to receive a 12-bit throttle signal. After that the ESCs can simply replay the telemetry also with its hardware serial.

To secure the throttle signal against signal failures the actual 12-bit throttle value is send twice, once with normal bit configuration and a second time with inverted bit configuration. The ESC only accepts signals where both values are equal. Like that the chance to have a ESC read a wrong signal is close to zero.
The telemetry answer uses a 8 bit CRC for the 4 byte payload which is a very strong CRC to payload relation.

Because the fact that S2M uses the signal line to each ESC for throttle signal and telemetry, the FETtec FC FW can do Onewire in addition to have two digital, bidirectional ESC signals at the same time, making it redundant. Without any extra wiring.

Speed wise S2M with a baud rate of 2.000.000 can be compared to Dshot 1200. But as it takes much less time for the ESC to read the signal value, the absolute time between a sent and used signal might be even less then with Dshot 2400.

Here is a capture of S2M on the FETtec FC G4 running FETtec FC firmware and octo configuration:

Technical:

The FC sends three bytes (24-bit) to the ESC which contains the 12-bit throttle signal resulting in 11-bit (possible 2048 steps) positive and negative (inverted) throttle.
To decode the throttle signal simple bit operations are used. 
If we take the idle throttle signal of 1000us (2000 as it is 2000-4000 positive and 2000-0 negative). 
The serial bytes sent are: 125, 130, 15. As the signal is sent twice, once with not inverted bytes and once with inverted byte, the ESC first need to put this two signals together.
The non inverted signal = byte1<<4 | ((byte3>>4)&0xFF) with the values placed 125<<4 | ((15>>4)&0xFF) results in 2000.
The one with inverted bytes = (~(byte2<<4 | byte3&0xF)))&0xFFF with the values placed (~(130<<4 | 15&0xF)))&0xFFF results also in 2000.

The ESC answers each received signal with a 5 byte telemetry string which contains the motors RPM (in each frame), the type of one additional telemetry value and the additional telemetry value itself. Like that the FC gets all RPMs in every loop and the ESC can switch through 8 possible additional telemetry values like current, voltage, temperature, consumption and such. 
The first first two bytes contain the ERPM and the additional telemetry type, the third and fourth byte the additional telemetry value a the fifth the CRC for all four bytes.
Its done like:
ERPM = ((byte1&0x1F)<<8) | byte2;
Additional telemetry type =  (byte1>>5)&0x07;
Additional telemetry value = (byte3<<8) | byte4; 

the last byte is the CRC-8 generated with this function:
uint8_t CRC8(uint8_t crc, uint8_t crc_seed){
    uint8_t crc_u, i;
    crc_u = crc;
    crc_u ^= crc_seed;
    for ( i=0; i<8; i++) crc_u = ( crc_u & 0x80 ) ? 0x7 ^ ( crc_u << 1 ) : ( crc_u << 1 );
    return (crc_u);
}

The additional telemetry type numbers are:
0 : Temperature 
1  : Voltage 
2 : Current
3 : Consumption
4, 5, 6, and 7 are unused for now.

I flashed my Diatone Mamba f50 BLHeli_S esc tonight and now the quad won't arm. I initially used v15 then went to v14 thinking an older version wouldn't be buggy and just work.
.
Should I be looking at the minimum startup value?
Right now I'm using Dshot 600. Should I go down to 300?

Describe the issue

Hi!
I want to flash my ESC in bluejay but when i select "flash all", i can't find any bluejay ESC target.
Same problem with esc configurator and Bluejay configurator.
Can you help me?

i have the SpeedyBee F405 V3 BLS 50A 30x30 FC&ESC Stack

Bluejay version

0.16

ESC variant

J-H-50

PWM frequency

24

DShot bitrate

600

Bidirectional DShot

Off

FC firmware

Betaflight 4.3

Motor size

No response

Configurator debug log

No response

Hi, first of all, thx for your great work!

Just tested v0.10 and the reported RPM stops around 3700-4000, it is spinning to slow by the sound of it.

After I have noticed that, I checked with v0.9 and reported RPM is around 32000 (empty 5S 1750KV), sounds right again.

ESC Config is on defaults.

• Bluejay version: 0.10 (24 & 48 kHz)
• ESC variant: C-H-40 (Mamba F405 MK2 Stack)
• Bidirectional DShot: On
• FC firmware: BF 4.2

If you need me to test something, I am up for testing.

is it possible to implement a brake on stop at zero throttle on airplanes?

Describe the bug

The O_L_ layouts have a comparator bug that causes incorrect back-emf readings making it impossible to drive the motor.

Configuration:

• Bluejay version: 0.11+
• ESC variant: O_L_X_X

Hi there,
first and foremost: THANK YOU so much for providing this fantastic ESC firmware. It must be a great deal of work to program and maintain this. I don't know why there are only so few people using BlueJay thus far - it perfectly slides in the huge gap left between pay-to-use JESC and JazzMav (I don't have to say anything about that do I?). BlueJay ticks all the boxes: RPM telemetry, free to use and a maintainer that is able to communicate with and listen to their users :-)
I have installed V 0.10 this morning on a Mobula 6 whoop board. Everything works great out of the box (default settings, RPM enabled) and it just works.
There is just one thing I noticed: when I am using turtle mode, the motors do not respond immediately to stick inputs. There is a small delay that was not there with JESC/BLheli_s. Is that delay intentional? It makes it more difficult to time short motor pulses to turn the quad back upright and makes one feel less connected. If that is indeed intentional - what is the rationale behind it? I can hardly imagine that this is safer for the motors (I tend to overshoot) and it also feels less nice to use.
Best,
Fabian

Describe the bug

Flashed 0.15 48kHz onto a iFlight F7 Beast AIO and checked RPM telemetry in BF.
With BLheli_M all looks normal, with BlueJay Error shows 100% until motors start spinning.
When motors start spinning, error goes down to 0%.

Expected behavior

Even with motors not spinning, I would expect 0% telemetry errors.

Configuration:

• Bluejay version: 0.15
• ESC variant: G_H_30
• PWM frequency: 48
• DShot bitrate: 600
• Bidirectional DShot: On
• FC firmware: Betaflight 4.2.12

Describe the bug

Z-H-30 target does not work for Betafpv 1S 12A FC.
Tried 24khz and 48khz, motors dont spin.
Factory blheli_s 16.7 firmware works fine.

Configuration:

• Bluejay version: [0.14]
• ESC variant: [Z_H_30_48]
• DShot bitrate: [300]
• Bidirectional DShot: [Either]
• FC firmware: [Betaflight 4.2.9]

Hi，I update the speedy bee 50A ESC,when I update the first one ESC,it's interrupt, I wait for more than 10mins, and the progress bar do not work . So I power off the ESC and power on agian . It's only 3 ESC detect ,the first esc is gone ,so how can I do,and it would be work normal?
And the log like that:
2022-11-13 @ 20:19:56 -- Done reading ESCs
2022-11-13 @ 20:19:56 -- Read ESC 4: J-H-50 - Bluejay, 0.18, 48kHz
2022-11-13 @ 20:19:56 -- Read ESC 3: J-H-50 - Bluejay, 0.18, 48kHz
2022-11-13 @ 20:19:56 -- Read ESC 2: J-H-50 - Bluejay, 0.18, 48kHz
2022-11-13 @ 20:19:56 -- Failed reading ESC [1

Why i can not set the Min/Max/Center Throttle in ESC-Configurator?
When we use Blheli S,we can set Throttle in BlheliSuit and ESC-Configurator, but if we flash bluejay FW , the parameter set is disappear. So the Throttle set is 1847/2047 or 1900/2000?

Describe the bug

v0.16 Can not be configured using the following configurator tools:
ESC Configurator (PWA)
Bluejay Configurator (Standalone)

I flashed v0.16 into BLHeil_S C_H_40 successfully using Bluejay Configurator , but I can not configure it using ESC Configurator (PWA) or Bluejay Configurator。It says that version 0.16 is not supported.

Expected behavior

A description of what you expected to happen.

Configuration:

• Bluejay version:0.16
• ESC variant: C_H_40
• PWM frequency: 24
• DShot bitrate: 150 300 600
• Bidirectional DShot: Either
• FC firmware: Betaflight 4.2.11

Describe the bug
I lost one ESC after the upgrade from 0.11 to 0.13

Expected behavior
All 4 sec should be in the list

Configuration:

• Bluejay version: 1.3.6
• ESC variant: S-H-50
• Bidirectional DShot: 300
• FC firmware: Betaflight 4.3

while using the motor beeper functionality, i realized how fun it would be to have the motor beeper actually play music instead of just a single tone.

Hi, I have this issue when I use BL or BLS bidirectional mode.(Because BL/BLS is no longer being developed further)
As described in the linked video, When you move forward and release the trigger,it will stop slowly.But when you move back and release the trigger,it will stop quickly(suddenly).
I had turned off Damping and Brake. （The same is true when I test the bluejay v0.13_nobrake firmware）
How can I make the motor decelerate inertial in both directions？
I want to use BL ESC on my RC Boat.

https://www.youtube.com/watch?v=uPV5X-c9g2Y #

This repository is abandoned, development continues in the new repository.

It's not possible using Bluejay directly connected to a TBS receiver on my helicopter.

It would be great if bluejay could listen and talk CRSF developed by @tbs-fpv

It would be even better if bluejay could report back esc telemetry (RPM) to the receiver.

Hi, and thanks for working on improving BLHeli-S.

I'm sure you're aware of this, it's a 'feature' of BLHeli-S, but I was wondering if you can do anything to improve it a bit.

What I'm referring to is the way that at high DSHot signals - high throttle - the ESC doesn't respond smoothly, instead it generates a series of steps. At least that's what the RPM data shows.

Here I am steadily increasing the motor drive signal in Betaflight's motors tab, by holding my up arrow. The entire pass takes about 16 seconds.

This image shows the last 10 seconds. Motor drive signal from betaflight in the top panel, RPM as measured by DShot Telemetry and recorded in the DShot Telemetry debug, with the debug mode set to motor_test.

Bluejay was set to defaults with dithering active.

Note how there are 5 large, flat steps above about 80% throttle. This is a significant non-linearity that would markedly reduce the PID loop's ability to control the quad whenever a motor is driven above 80%.

I'm fairly sure this has always been the case with BLHeli-S but have always wondered why, and if anything can be done to improve it.

There are other brief steps at about 35 and 66% throttle.

Some sort of way to make the pwm dynamic. This has been implemented in am32 and is called variable pwm. Something worth looking into if it isn't to difficult, but I do understand how difficult a lot of this coding must be.

Describe the issue

When one commutation is finished,the timer2 counter is set with Wt_ZC_Tout_Start, in order to know whether zero cross check is timeout.
But when a new zero cross point checking start,Flag_Demag_Detected is set.
And if there is a wrong comparator output, in the function comp_read_wrong_extend_timeout,the timeout check counter timer2 is reset as followed:

comp_read_wrong:
    jb    Flag_Startup_Phase, comp_read_wrong_startup
    jb    Flag_Demag_Detected, comp_read_wrong_extend_timeout

    inc    Temp3                    ; Increment number of OK readings required
    clr    C
    mov    A, Temp3
    subb    A, Temp4
    jc    comp_check_timeout            ; If below initial requirement - take another reading
    sjmp    comp_start                ; Otherwise - go back and restart

comp_read_wrong_startup:
    inc    Temp3                    ; Increment number of OK readings required
    clr    C
    mov    A, Temp3
    subb    A, Temp4                    ; If above initial requirement - do not increment further
    jc    ($+3)
    dec    Temp3

    sjmp    comp_check_timeout            ; Continue to look for good ones

comp_read_wrong_extend_timeout:
    clr    Flag_Demag_Detected            ; Clear demag detected flag
    anl    EIE1, #7Fh                ; Disable Timer3 interrupts
    mov    TMR3CN0, #00h                ; Timer3 disabled and interrupt flag cleared
    jnb    Flag_High_Rpm, comp_read_wrong_low_rpm    ; Branch if not high rpm

    mov    TMR3L, #0                    ; Set timeout to ~1ms
    mov    TMR3H, #-(8 SHL MCU_48MHZ)

As above description, if a wrong comparator out is got when Flag_Demag_Detected is set,the timeout check time must be reset.So whether the timeout check time of Wt_ZC_Tout_Start is not need,it's can be directly set as the value of what comp_read_wrong_extend_timeout set.

Bluejay version

0.16

ESC variant

ah5

PWM frequency

24

DShot bitrate

150

Bidirectional DShot

Off

FC firmware

4.2.9

Motor size

0802

Configurator debug log

no

Motors stop when slider reaches 1500

Tried calibrating the esc's via betaflight, moved slider to max and plugged in battery to esc, esc didnt beep but beeps when slider moved to lowest position

Describe the issue

A bit of backstory first: I wanted to update my drone from BF 4.3 RC4 to the release 4.3 and while setting it up I wanted to test failsafe by arming and turning my radio off but it just dies right after arming, sometimes needs a bit of throttle to die. Dying means no reset, no startup beeps - from the ESCs or the FC, the video blanks and than shows roling white blobs on black.
Tried re-flashing 4.3 RC4, but it does the same thing, only sometimes it manages to properly reset instead of dying.
Also, my smokestopper doesn't trigger. It should be trigger around 3-4A I think.

I have HolybroKakute F7 AIO with 4 separate ESCs - two G-L-30 and two L-H-40 types. (I helped here with the telemetry timing a while back).
I am debugging the problem right now and I wanted to update the ESC as I was running old BETA firmware, what if it could solve my problem?
G-L-30 flashed fine, but the L-H-40 are reporting MCU mismatch, override not enabled - aborted and I want to ask here rather then forcing the flash. I do not remember having this problem before.

I'm pretty sure these are F-H-40s, I have flown this drone before, than it sit on the shelf for weeks, only thing I did was soldered antenna on VTX and now it is dying even with the VTX completely disconnected. I have no idea why lol.
So what's the way to get the proper MCU?

Bluejay version

0.14 BETA

ESC variant

F-H-40

PWM frequency

48

DShot bitrate

300

Bidirectional DShot

On

FC firmware

Betaflight 4.3

Motor size

2205

Configurator debug log

No response

Describe the bug
Whichever direction of the motors I choose, they remain the same. Tried 0.16 and 0.15.
However I was able to switch direction via betaflight, with disabled bidirectional DShot.

Similar issue in #24

Bluejay version: 0.16, 0.15
ESC variant: C-H-40
Bidirectional DShot: On
FC firmware: Betaflight 4.3.1
FC: Mamba basic f722 mini mk3
board_name: MAMBAF722_I2C

This one is apparently rather special. We'd like to use the following pinout:

• Ap: 1.1 (open drain active high)
• Ac: 1.0 (open drain active low)
• Bp: 1.2 (open drain active high)
• Bc: 1.3 (open drain active low)
• Cp: 1.5 (open drain active high)
• Cc: 1.4 (open drain active low)
• MA: 0.0
• MB: 0.2
• MC: 0.1
• CC: 0.3
• Tx: 0.4
• Rx: 0.5

We use NCP81253 gate drivers, which accept 3-state PWM input. This is generated with pull-ups and the mentioned open drain outputs:

When Ac is low, the PWM input is low. When Ac is high-Z, Ap can either pull PWM to 2V5 (Ap low) or leave it at 5V (Ap high-Z). This has sort of worked with a different pinout, but we were forced to re-route the ESC to this pinout because of space constraints.

Hi,
it would be nice to select PWM frequency in Configurator without reflashing the firmware.
Like in blheli_m configurator:

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.

I have measured the duty cycle of the different PWM frequencies (24, 48, 96) at offsets with no dithering, and it seems to get slightly lower as frequency goes up. This seems to confirm #2.

Describe the bug
The PWM duty cycle gets lower as PWM frequency is increased, for the same throttle input.

Expected behavior
The PWM duty cycle should be the same for different PWM frequencies when given same the throttle input.

Configuration:

• Bluejay version: 0.10
• Bidirectional DShot: On
• FC firmware: Betaflight 4.2.8

I think maybe it could be related to rounding (truncation). It could also be because of the resolution (without dithering) being lower with higher PWM frequencies, but in that case, I think it would be preferable to round up instead.

Describe the bug
I'm not able to set motor direction. Whatever I choose (normal or reverse) I have a normal direction. On version 0.11 everything works as expected.

Expected behavior
Been able to choose a motor direction.

Configuration:

• Bluejay version: 0.12.1
• ESC variant: O-H-5
• Bidirectional DShot: On
• FC firmware: Betaflight 4.2.8
• FC: Happy model Crazybee F4 Lite
• board_name: CRAZYBEEF4FS

Would brushed mode be possible in BlueJay like it works in AM32?
We could use AIO with one broken ESC to control small RC cars!
AlkaMotors/AM32-MultiRotor-ESC-firmware#71

Describe the bug
Non-zero (5-10%) DShot telemetry error rate in betaflight configurator, accompanied by occasional "clicking" noise coming from motor

Expected behavior
No telemetry errors, motor runs smoothly

Configuration:

• Bluejay version: 0.12.2
• ESC variant: G-L-30
• Bidirectional DShot: On
• FC firmware: Betaflight 4.2.9

When testing motors in the motors tab using bidirectional dshot, the error percent isn't 0%. It scales with the throttle reaching 1% around mid throttle.

I would expected 0% error.

Is this a bug, a limitation of the L type ESCs or is this safe to fly?

Configuration:

• Bluejay version: 0.14
• ESC variant: I have two G-L-30 and two F-H-40 , only the two G-L-30 do this.
• DShot bitrate: 300 as both L and H are supported
• Bidirectional DShot: On
• FC firmware: Betaflight 4.2.9

I've just flashed my ESC from 0.12.1 to 0.12.2 but the Configurator is still showing 0.12. How do I know if I have 0.12.1 or 0.12.2 installed?

Configuration:

• Bluejay version: 0.12.2
• ESC variant: A-H-25

Hey, I was wondering if it would be possible to get a short summary in the readme what the difference between bluejay and BLHELI_m are.

I mean, apart from this one being properly source controlled ;-)

Thanks for the work anyway, will keep an eye on this project.

I have been looking at the targets today and I have the feeling that some refactoring could be done here easily. I suggest the following things:

• Improve indentation and white spacing: check target/A.inc in my branch to see what I have in mind
• Improve comment indentation: So that they are all in one line - easier to parse with the eyes IMHO
• Code de-duplication: There is a lot of duplicate code in the targets - I would suggest moving this code in common includes as I did with the LED and RPM macros - you know because "Don't repeat yourself"

I am fully aware that coding style is totally subjective and I have no hard feelings if this gets rejected. But since we are not trying to put the source code on a diskette, I am all for improving readability - a couple of blank lines do help a lot ;-)

I would build all the hex files pre refactoring and binary compare them after re-factoring to make sure the styling changes did not break anything else.

https://github.com/stylesuxx/bluejay/tree/formatting

At the current time DSHOT telemetry is very limited. It can send back to FC eRPM value and nothing else. There are cases where it would be very advisable to send other telemetry values back to FC.

Proposal: Use eRPM 0x0FFF telemetry value as a escape frame.

When one escape frame is sent back to FC, ESC is signaling the FC that the next telemetry frame (extended telemetry frame) will contain extended telemetry data than eRPM data. If two escape frames, one after the other are sent back to FC, it means that 0 eRPM is being sent back to the FC. After receiving extended telemetry frame the FC will expect normal or escape telemetry frame next.

As a telemetry frame can be corrupted, if FC is not expecting an extended telemetry frame, but the corrupted frame could have been an escape one, the next frame shall be discarded. If FC is expecting an extended telemetry frame, and the new frame is corrupted the FC simply discards the frame and will expect a normal or escape telemetry frame next.

Extended telemetry frame format

The extended telemetry frame will be just like the normal telemetry frame as regards the crc. The first 4 bit contains extended telemetry data type, and the next 8 bit with contain the value.

Extended telemetry frame examples

Type 0 ---->>>> data will be temperature in format [0 = -53ºC ---- 254 = 200ºC]
....
....
....
Type 14 ---->>>> data will be debug value high
Type 15 ---->>>> data will be debug value low

Extended telemetry data scheduling

As DSHOT cannot trigger extended telemetry data, the proposal is to schedule it on the firmware side.

Extended telemetry data scheduling examples

1: Type 0, 800ms
2: Type 14, 100ms
3: Type 15, 100ms
So Type 0 will be sent 800ms after starting, type 14 100ms after type 0, type 15 100ms after type 14, and then the scheduling starts over again.

Hi. I'm using Bluejay for configuring the main and tail rotors (betaflight passthrough) on my helicopter running Heliflight-3D. I would like to be able to write a different setup to each motor and disable damped light mode for the main motor. Can these options be added please?

It has been suggested to extend ESC telemetry to provide information such as missed zero crossings and demag events.

Currently Bluejay only supports rpm (e-period) telemetry according to the specification of bidirectional dshot.
DShot also allows telemetry on a separate wire which is currently only supported by 32-bit ESC firmware.

It needs to be decided whether Bluejay should add support for dshot (separate wire) telemetry and/or if bidirectional dshot (single wire) telemetry should be extended to somehow support different types of information than RPM.