Filtro RPM do Betaflight: configure e comprove que funciona no log

O filtro RPM é o filtro mais preciso do Betaflight: a controladora de voo recebe a velocidade de cada motor e elimina o ruído exatamente nessas frequências. A seguir, veja do que ele precisa, como ativá-lo, o que fazem as configurações e como comprovar em um log real que está funcionando.

O que o filtro RPM faz e por que é melhor que um passa-baixa

O motor e a hélice fazem a estrutura vibrar na frequência de rotação (1×) e em seus múltiplos; a frequência de passagem das pás é 2× em uma hélice de duas pás e 3× em uma hélice de três pás. Todas aumentam com o acelerador, por isso aparecem como linhas diagonais em um mapa de calor de acelerador versus frequência.

Sem dados de RPM, o Betaflight tem duas ferramentas. Um passa-baixa corta tudo acima da frequência de corte, mas acrescenta bastante atraso e não consegue reduzir muito uma linha de 200 Hz. O notch dinâmico procura picos no espectro, fica atrás das mudanças do acelerador e tem apenas 3 notches por padrão, no máximo 5. O filtro RPM lê a velocidade de cada motor pelo DShot bidirecional em cada ciclo e aplica um notch estreito a cada harmônico de cada motor. São 4 motores × 3 harmônicos = 12 notches que acompanham o RPM com quase nenhum atraso.

Mas ele tem um custo: um notch com fator de qualidade Q na frequência f atrasa o movimento lento do quad em aproximadamente 1/(2π·Q·f). Em um loop PID de 4 kHz, 12 notches com Q = 5 e motores a 200 Hz (1×) acrescentam cerca de 1,15 ms. Um único PT1 a 150 Hz acrescenta quase o mesmo (1,06 ms). Mas esse PT1 reduz uma linha de 200 Hz em apenas 4–5 dB, enquanto os notches a reduzem em dezenas de dB. Assim, com o mesmo atraso, você remove quase todo o ruído dos motores e pode usar passa-baixa mais suaves. Os notches de baixa frequência custam mais: a 100 Hz, os mesmos 12 custam 2,3 ms; é para isso que servem min_hz e a faixa de transição.

O que você precisa

• Betaflight 4.1 ou mais recente. A versão 4.1 introduziu o DShot bidirecional e o filtro RPM.
• Um protocolo DShot (DSHOT150/300/600): com PWM, OneShot, Multishot ou ProShot, não há retorno de RPM.
• Firmware de ESC compatível com DShot bidirecional (veja a tabela abaixo). O Bluejay é instalado pelo esc-configurator.com.
• O valor correto de motor_poles: a quantidade de ímãs no sino. O Betaflight divide o RPM elétrico (eRPM) por motor_poles/2 para obter o RPM mecânico.

Configuração passo a passo

1. Retire as hélices. Faça um backup da configuração com diff all.
2. Confira o firmware do ESC: esc-configurator.com lê BLHeli_S, Bluejay e AM32; BLHeliSuite32 lê BLHeli_32. Se for BLHeli_S original, instale o Bluejay.
3. Conte os ímãs no sino de um motor.
4. Na CLI (use seu protocolo e a quantidade de polos):

   set motor_pwm_protocol = DSHOT300
   set dshot_bidir = ON
   set motor_poles = 14
   save

5. Após reiniciar, abra a aba Motors. Cada motor deve mostrar o RPM e uma porcentagem de erros. Aumente a rotação com o controle deslizante: o RPM deve subir suavemente e os erros ficar perto de zero. Na CLI, dshot_telemetry_info mostra o RPM e os pacotes inválidos de cada motor. Com o filtro RPM ativo, se até mesmo um ESC não enviar RPM, o Betaflight impede a habilitação dos motores e mostra RPMFILTER no OSD.
6. Confira se o próprio filtro está ativado: por padrão, sim (3 harmônicos), mas configurações copiadas às vezes têm valor 0.
7. No Betaflight 4.5 ou mais recente, confira se o registro de RPM no blackbox não está desativado (vem ativado por padrão), senão o log não permite comprovar nada:

   set blackbox_disable_rpm = OFF
   save

O campo eRPM no log só existe a partir da versão 4.5 (o código de blackbox da 4.4 não o inclui): nosso log 4.4.1 com DShot bidirecional não tem RPM, enquanto todos os logs 4.5.x têm eRPM[0]…eRPM[3]. E um log 2025.12.5 estava com o filtro ativo, mas o registro de RPM desativado, então não permite comprovar nada.

Configurações, com valores de logs reais

O Betaflight 4.3 renomeou os parâmetros e a versão 4.5 adicionou pesos por harmônico; a tabela mostra os padrões e valores de logs reais.

rpm_filter_q. Um notch estreito causa menos atraso, mas exige RPM preciso. Para um notch de 200 Hz, uma diferença de 10 Hz do centro reduz quase 7 dB em Q = 5, mas apenas 3,6 dB em Q = 8,5. Em compensação, 12 notches em Q = 8,5 acrescentam cerca de 0,7 ms em vez de 1,15. O VX3.5 usa 850 com telemetria limpa (menos de 0,02 saltos por segundo), mas a wiki do Betaflight recomenda não passar de 750; aumentar q em um quad com erros de eRPM é uma má ideia.

rpm_filter_min_hz e faixa de transição. Um notch nunca fica abaixo de min_hz e, de min_hz + fade até min_hz, sua intensidade diminui até zero. Isso afeta principalmente o 1× dos motores lentos ao cortar o acelerador e durante o propwash; com RPM muito baixo, também afeta o 2×. No quad de 7 polegadas com 4.6.0 (min 70, fade 50), o motor mais lento ficou abaixo de 120 Hz, dentro da faixa de transição, durante um quarto do voo (24%) e abaixo de 70 Hz em 4,4% do tempo. A menos de 5% de acelerador, a mediana da velocidade do motor foi 58 Hz. Quads de 5 polegadas giram mais rápido e funcionam bem com os valores padrão. Reduza min_hz apenas em hélices grandes e só se o log mostrar ruído em 1× com pouco acelerador: notches baixos custam bastante atraso.

rpm_filter_weights (4.5 ou mais recente) define a profundidade do notch de cada harmônico: 100 é um notch completo; 50, metade. O mesmo quad de 7 polegadas usa 100,60,100, e o log confirma: o 2× representou apenas 4–6% do ruído bruto acima de 80 Hz, enquanto o 3× representou 68% no eixo de rolagem. Altere os pesos somente com base no seu próprio log: outra quantidade de pás muda a distribuição de energia entre 2× e 3×.

Valores padrão do Betaflight 4.3 ou mais recente, para restaurar tudo:

set rpm_filter_harmonics = 3
set rpm_filter_q = 500
set rpm_filter_min_hz = 100
set rpm_filter_fade_range_hz = 50
set rpm_filter_lpf_hz = 150
set rpm_filter_weights = 100,100,100
save

Ignore a linha rpm_filter_weights no Betaflight 4.3–4.4, versões em que ela não existe.

O que ajustar depois de ativar

Notch dinâmico: reduza, não desligue. As linhas dos motores agora são tratadas pelo filtro RPM; o notch dinâmico fica responsável pelas ressonâncias da estrutura e do stack, que permanecem na mesma frequência em qualquer posição do acelerador e podem ser cobertas com um ou dois notches. Para a versão 4.2 ou mais recente, a wiki do Betaflight sugere dyn_notch_count = 1 e dyn_notch_q = 500; quase todos os nossos logs 4.5.x usam 1, e um usa 2. Com o filtro RPM ativado, a verificação de configuração não avisa se o notch estiver desligado, mas as ressonâncias da estrutura seguem diretamente para os PIDs.

O Dynamic Idle fica disponível. Ele também precisa de RPM: sem DShot bidirecional, dyn_idle_min_rpm não faz nada, e a verificação de configuração do bbdoctor informa isso. O valor representa centenas de RPM; o bbdoctor sugere 30 para 5", 40–50 para 3" e 20–25 para 7". Ele mantém os motores girando ao cortar o acelerador e é uma das primeiras soluções para propwash. Na versão 4.2, o nome é idle_min_rpm. A configuração fica no perfil PID, então ajuste-a em cada perfil que você usa.

set dyn_notch_count = 1
set dyn_notch_q = 500
set dyn_idle_min_rpm = 30
save

Filtros passa-baixa: sem pressa. Uma recomendação comum é aumentar o passa-baixa logo de início. O bbdoctor sugere aumentar os cortes do giroscópio em 15% (e depois verificar a temperatura dos motores) somente quando todos estes critérios forem atendidos: ruído filtrado abaixo de 1 deg/s, atraso do filtro acima de 1,5 ms, log de 500 Hz ou mais, giroscópio bruto silencioso (abaixo de 4 deg/s) e nenhuma ressonância na estrutura. O quad de 7 polegadas mostra por quê: 0,66 deg/s após a filtragem e 2,1 ms de atraso parecem indicar margem. Mas o ruído bruto no eixo de arfagem é 7,9 deg/s, então a conclusão é: “há margem, mas ainda é cedo para suavizar os filtros”; primeiro, resolva a parte mecânica. Os valores de ruído são explicados no guia de filtros.

Comprove no log

Você precisa de um log com o campo eRPM e o giroscópio sem filtragem a 1 kHz ou mais, idealmente 2 kHz (veja o guia de configuração do blackbox). Envie-o para o bbdoctor e confira três coisas.

1. As linhas dos motores desaparecem depois da filtragem. O mapa de calor bruto mostra as diagonais; o filtrado não deve mostrá-las. Se persistirem, os notches estão mal posicionados: confira motor_poles e os erros de eRPM.

2. Os motores têm valores próximos entre si. O bbdoctor compara o RPM de cada motor com o dos demais sob o mesmo comando. Neste quad de 7 polegadas, a variação fica entre −0,7% e +0,8%. Uma diferença de 6% gera um aviso; um motor 10% ou mais lento que os outros é marcado como problema sério. Para investigar um motor que arrasta ou vibra, veja o guia de vibração.

3. Erros de telemetria eRPM. O filtro RPM confia em cada pacote, então um pacote inválido desloca brevemente o notch do alvo. O bbdoctor conta, por motor e apenas enquanto ele está girando (comando acima de 12%):

• saltos: mudança de RPM acima de 35% entre quadros, acima de 30 Hz. Um motor com hélice não consegue mudar de velocidade tão rápido; é um erro de leitura;
• zeros: RPM abaixo de 5 Hz em um motor que está girando.

Mais de 1 salto por segundo ou mais de 1% de zeros gera o aviso “erros de telemetria eRPM”, com a recomendação de conferir a solda do fio de sinal do ESC, a interferência dos cabos de alimentação e o firmware do ESC. Para comparar, quatro logs do VX3.5 mostram de 0 a 0,02 saltos por segundo.

Neste quad, M4 ultrapassa o limite nos 11 voos do arquivo, com 1,6 a 6,1 saltos por segundo. M1 ultrapassa em três voos, M3 em dois e M2 nunca (seu pior resultado é 0,61). Não há zeros. Erros que persistem em um mesmo motor de um voo para outro não são interferência aleatória; apontam para aquele canal: solda do fio de sinal, passagem junto aos cabos de alimentação ou o próprio ESC. No voo mais longo (98 s), o bbdoctor avisou sobre dois motores: M3 com 1,35 e M4 com 1,61 saltos por segundo.

O RPM no log também ajuda depois de uma queda: o bbdoctor procura uma dessincronização antes do impacto, quando um motor comandado a 40% ou mais gira abaixo de 35% do RPM dos outros por mais de 30 ms. Se esse motor apresentou zeros de eRPM antes no voo, o caso é contado como falha de telemetria, não como dessincronização.

Solução de problemas: sintoma, causa e solução

Sobre a quantidade de polos: um motor de 12 ímãs configurado como 14 mostra 6/7 do RPM real; com o RPM real a 200 Hz, o notch fica em 171 Hz. Um notch Q = 5 reduz uma frequência a 29 Hz do centro em apenas 1,5 dB, então o filtro quase não funciona. Em 3×, o desvio é maior: 514 Hz em vez de 600. A verificação de configuração pede que você reconte os polos quando motor_kv é 6000 ou mais e motor_poles = 14. Isso só é acionado se você informou o KV: todos os nossos logs que registram motor_kv têm o valor padrão 1960. O bbdoctor também converte eRPM usando motor_poles do cabeçalho, então polos incorretos deslocam as linhas de harmônicos exibidas.

Erros comuns: informar o 12 de 12N14P em motor_poles (esse número representa os dentes do estator), aumentar o passa-baixa sem consultar um log, desligar o notch dinâmico ou aumentar rpm_filter_q apesar de haver erros de eRPM. Uma dessincronização ao cortar o acelerador é um problema no ESC e no motor, não no filtro RPM.

INAV, ArduPilot e PX4

INAV não usa DShot bidirecional neste caso. Ele recebe o RPM pela telemetria do ESC em um fio separado, conectado ao pino RX de uma UART livre, com a telemetria do ESC ativada nessa porta na aba Ports. ESCs BLHeli_32 e AM32 com um pad de telemetria fornecem esses dados; Bluejay não. A quantidade de polos vem de motor_poles. As configurações do filtro são rpm_gyro_harmonics (padrão 1, máximo 3), rpm_gyro_min_hz (100; a documentação do INAV permite 60–70 em um quad de 7") e rpm_gyro_q (500). Ative assim:

set rpm_gyro_filter_enabled = ON
save

Se o filtro estiver ativado, mas nenhuma porta tiver telemetria do ESC, a verificação de configuração do bbdoctor informa que o filtro não está funcionando. O blackbox do INAV registra apenas um valor escRPM nos quadros lentos, sem RPM por motor; por isso, as verificações de eRPM não estão disponíveis para logs do INAV.

ArduPilot usa seu notch harmônico acionado pela telemetria dos ESCs. SERVO_BLH_BDMASK é uma máscara de bits das saídas que usam DShot bidirecional (15 abrange as quatro primeiras); SERVO_BLH_POLES define a quantidade de polos. INS_HNTCH_MODE = 3 faz o notch acompanhar o RPM dos ESCs e INS_HNTCH_OPTS = 2 cria um notch para cada motor. Em placas IOMCU (Pixhawk, Cube), o DShot bidirecional só funciona nas saídas AUX, então a máscara AUX1–4 é 3840; algumas placas precisam de uma compilação do firmware com “-bdshot” no nome. Defina INS_HNTCH_FREQ abaixo da frequência de voo pairado; INS_HNTCH_BW geralmente começa com metade de FREQ, mas para notches por motor a documentação sugere um quarto. Nossos logs do ArduPilot com essa configuração usavam MOT_PWM_TYPE 6 (DShot600), INS_HNTCH_FREQ 50, INS_HNTCH_BW 25 e INS_HNTCH_HMNCS 1 (somente 1×).

MOT_PWM_TYPE = 6
SERVO_BLH_BDMASK = 15
SERVO_BLH_POLES = 14
INS_HNTCH_ENABLE = 1
INS_HNTCH_MODE = 3
INS_HNTCH_OPTS = 2
INS_HNTCH_REF = 1

PX4 usa o notch dinâmico IMU_GYRO_DNF_EN: o bit 0 acompanha o RPM do ESC, o bit 1 acompanha a FFT (que também exige IMU_GYRO_FFT_EN) e o valor 3 ativa ambos. IMU_GYRO_DNF_HMC define a quantidade de harmônicos. O RPM vem de DShot bidirecional, telemetria DShot por fio (DSHOT_TEL_CFG) ou ESCs DroneCAN. Nos nossos logs 1.16–1.17, DSHOT_BIDIR_EN = 1 ativa o DShot bidirecional e MOT_POLE_COUNT define os polos; nossos logs 1.15 ainda não têm DSHOT_BIDIR_EN. A documentação atual do PX4 seleciona BDShot como protocolo na configuração dos atuadores e define os polos de cada motor (DSHOT_MOT_POL1…12), então confira sua versão. Um log 1.16.2 tinha IMU_GYRO_DNF_EN = 3, mas DSHOT_BIDIR_EN = 0, DSHOT_TEL_CFG = 0 e DroneCAN apenas para os sensores: a parte de RPM não tinha dados para acompanhar, e o log não tem nenhum parâmetro IMU_GYRO_FFT_*.

DSHOT_BIDIR_EN = 1
MOT_POLE_COUNT = 14
IMU_GYRO_DNF_EN = 1
IMU_GYRO_DNF_HMC = 3

Saiba mais no guia de logs do ArduPilot e no guia de ULog do PX4.

Resumo

Ative o DShot bidirecional, confira a quantidade de ímãs e os erros na aba Motors, e mantenha os valores padrão do filtro. Depois, faça um voo com o registro de eRPM ativado e envie o log para o bbdoctor para ver se as linhas dos motores desapareceram e se o eRPM está limpo. A verificação de configuração funciona sem voo, e o relatório de exemplo mostra uma análise concluída.

Atualizado: 2026-10-22