Início / coding / Perguntas / 79133700
Accepted
Mairlot Geoffrey
Asked: 2024-10-28 21:55:05 +0800 CST

BLE CPS - Recursos de ordenação de bits

  • 772

Estou tentando escrever um servidor BLE para o serviço CPS (Cycling Power Service). Os dados de potência são capturados corretamente pelo cliente (relógio polar), mas não consigo fazer o relógio capturar pares de rotação da roda e rotação da manivela. Pelo menos nenhum dado é mostrado no relógio para velocidade e cadência. A cadência deve definitivamente estar funcionando, pois funciona com outro sensor stagePower usando o mesmo serviço.

Tentei capturar a chamada de Pontos de Controle caso essa fosse a causa raiz da falta de suporte, mas nada ocorre...

Então pensei que o problema pode estar nos bits de recursos. E ainda não está claro para mim como esses bits devem ser enviados. Dados tipo byte little-endian? Ou LSbit -> MSbit?

Pelos exemplos que consegui encontrar para referência, ele é enviado em ordem regular, mas duvido que seja o caso. O que estou enviando agora é:

uint8_t fBuffer[4];
fBuffer[0] = 0x00;
fBuffer[1] = 0x00;
fBuffer[2] = 0x00;
fBuffer[3] = 0x0C;
         
CyclePowerFeature.writeValue(fBuffer, 4);

Apenas para completar, aqui estão alguns quadros de dados característicos que são enviados (capturados pelo nRF Connect):

30002A001500000070190800E3F9
30002A001A00000004300A0067FF
30002A001C00000053380B002A02
30002A0020000000B4480C00EC04
30002A002600000065610E00700A
30002A0028000000B4690F00320D
30002C002C00000063771000F80F
30002B002F0000005A8812005F15
30002A0033000000F89813001818
30002A003700000059A915009C1D
30002B003D0000000AC217001923
30002B003F00000059CA1800D325
30002B00420000009DD819008E28
30002A00460000001FE91B00062E

Bandeiras: 0030 (bits 4 e 5 ativados) para ativar pares de dados de roda e manivela Potência de saída: 42-43 Watts (2A00 - 2C00) Velocidade calculada deste conjunto (tamanho da roda: 2,35 m): 11,9-16,4 km/h Cadência calculada deste conjunto: 87-89 RPM

Detalhes da roda: Contador de revoluções: 15000000 -> 46000000 (ou seja, 15->46 em hexadecimal B-endian / ou seja: 21->70 em decimal) Carimbos de tempo de revolução: 7090 -> 1FE9 (ou seja, 1970->E91F em hexadecimal B-endian / ou seja: 6512->59679 em decimal - 1/2048 de s)

Detalhes da cadência: Contador de manivela: 0800 -> 1B00 (ou seja, 08->1B em hexadecimal B-endian / ou seja: 8->27 em deciaml) Carimbo de data/hora da manivela: EFF9 -> 062E (ou seja, F9E3->2E06 em hexadecimal B-endian / ou seja: 63971->11782 em decimal - 1/1024 de s)

Os valores decodificados para cada quadro parecem OK para mim seguindo a lógica :g

  • calcular e converter time_diff com o quadro anterior (para manivela e roda)
  • calcular #revoluções (para manivela e roda) com o quadro anterior
  • calcular RPM: frame_crank_revolutions x 60 x 1000 / crank_time_diff
  • calcular velocidade: frame_wheel_revolutions¨x 2,35 x 1000 / wheel_time_diff

Tentei entrar em contato com a Polar (que assinou as especificações do CPS...) para obter algumas informações, mas eles apenas responderam "somos compatíveis com os sensores X e Y"

bluetooth-lowenergy

1 respostas

  1. Best Answer

    No seu caso, a especificação indica endianess.

    De acordo com o Cycling Speed ​​and Cadence Service, Cap. 1.7 Byte Transmission Order , todas as características usadas com este serviço devem ser transmitidas com o octeto menos significativo primeiro (ou seja, little endian).

    A outra parte da especificação Perfil de velocidade e cadência do ciclismo também pode ser interessante.

    • 0

relate perguntas