Problema de cálculo de paridade

Ultimamente, tenho feito bastante automação residencial DIY (RF; 433MHz) em muitos dispositivos diferentes - que funcionaram bem para todos, exceto um. É basicamente um robô de piscina com um controle remoto realmente ruim.

Eu coletei alguns dados usando um BladeRF SDR e GNU Radio. A coluna "outros 3" é basicamente a ação, enquanto "outro 1" parece ser serial e "outro 2" define o robô se você tiver vários em uso, eu acho (algum amigo meu que tem o mesmo valor diferente) há). Não sei ao certo qual o objetivo da contagem, mas acho que é para que o robô saiba quando o intervalo fica muito amplo eventualmente (faltando alguma informação?). Eu reduzi os bytes e seus significados, mas falho no cálculo do CRC (soma de verificação) correto para os dados.

VELHO - VEJA ATUALIZAÇÃO ABAIXO !!

Aqui estão alguns dados de amostra:

<other1                  > <other2> <other3> <count > <crc   >      
10110100 00111110 10001111 11001000 00000001 11110111 01011110
10110100 00111110 10001111 11001000 00000001 11111000 01010011
10110100 00111110 10001111 11001000 00000001 11111001 01010100
10110100 00111110 10001111 11001000 00000001 11111010 01010001
10110100 00111110 10001111 11001000 00000001 11111011 01010010
10110100 00111110 10001111 11001000 00000001 11111100 01010111
10110100 00111110 10001111 11001000 00000001 11111101 01011000
10110100 00111110 10001111 11001000 00000001 11111110 01010101
10110100 00111110 10001111 11001000 00000001 11111111 01010110
10110100 00111110 10001111 11001000 00000001 00000000 01100111
10110100 00111110 10001111 11001000 00000001 00000001 01101000
10110100 00111110 10001111 11001000 00000001 00000010 01100101
10110100 00111110 10001111 11001000 00000001 00000011 01100110
10110100 00111110 10001111 11001000 00000001 00000101 01100100
10110100 00111110 10001111 11001000 00000001 00000111 01100010
added data:
10110100 00111110 10001111 11001000 00000010 00000110 01100100
10110100 00111110 10001111 11101010 00000010 01100101 10011010
10110100 00111110 10001111 11101010 00000001 01100100 10011100
10110100 00111110 10001111 11101010 00000001 01100011 10011101
10110100 00111110 10001111 11101010 00000001 01100110 10011010

Há uma contagem para cada solicitação que deve ser alterada e alguns comandos a serem enviados, por exemplo, a coluna "outros 3" pode ler 00000010 em vez de 00000001.

Seria muito útil se alguém pudesse me dar algumas dicas sobre onde procurar. Eu tentei técnicas diferentes como o XOR nos bytes ou o módulo de cálculo, etc. - Eu até tentei diferentes ferramentas de força bruta do algoritmo CRC - infelizmente sem sucesso ainda.

EDIT: Coloquei os dados no Excel e adicionei alguma função (basicamente compara cada 4 bits com os de cima - a última transmissão). Eu fiz isso quando reconheci que o CRC permaneceu o mesmo uma vez. Esse foi o caso em que a ação e a contagem foram aumentadas em 1. Dê uma olhada:

ATUALIZAR:

Encontrei outras especificações mais detalhadas. do mesmo fornecedor na rede, depois de pesquisar por horas e saiu o tão pensado CRC é de fato uma paridade. Também ajustei meu fluxograma de captura de rádio gnu e coletei alguns dados novos. Desconsidere os dados acima e dê uma olhada aqui:

other 1> other 2                > other 3> other 4    > parity
10110100 001111101000111111101010 00000001 011110101001 0101
10110100 001111101000111111101010 00000001 011110111001 0110
10110100 001111101000111111101010 00000001 011111001001 0011
10110100 001111101000111111101010 00000001 011111011001 0100
10110100 001111101000111111101010 00000010 011111101001 0100
10110100 001111101000111111101010 00000010 011111111001 0011
10110100 001111101000111111101010 00000010 100000001001 0011
10110100 001111101000111111101010 00000010 100000011001 0100
10110100 001111101000111111101010 00000001 100000101001 0100
10110100 001111101000111111101010 00000001 100000111001 0011
10110100 001111101000111111101010 00000001 100001001001 0110
10110100 001111101000111111101010 00000001 100001011001 0101
10110100 001111101000111111101010 00000010 100001101001 0101
10110100 001111101000111111101010 00000010 100001111001 0110
10110100 001111101000111111101010 00000010 100010001001 1011
10110100 001111101000111111101010 00000010 100010011001 1100
10110100 001111101000111111101010 00000001 100010101001 1100
10110100 001111101000111111101010 00000001 100010111001 1011
10110100 001111101000111111101010 00000001 100011001001 1110
10110100 001111101000111111101010 00000001 100011011001 1101

E aqui está novamente como o excel chique:

Alguém sabe como calcular essa paridade? Tentei dividir os dados, etc., e usar cálculos de paridade comuns, mas infelizmente sem sucesso ainda.

smart-home data-transfer interfacing

— Omegavirus
fonte

Você não tem informações suficientes aqui, pois a única coisa que você mostra alterando além do valor de verificação é o último byte, a contagem. Portanto, você não pode distinguir o impacto dos bytes anteriores vs. algum valor inicial estático do algoritmo. Você pode fazer algumas suposições e talvez testá-las, ou até mesmo achar uma teoria bonita demais para não ser provável, mas tudo o que você pode realmente reverter a partir dos dados fornecidos é o papel do último byte na criação do valor de verificação.

— Chris Stratton

@ ChrisStratton Você está certo. Eu adicionei alguns dados alterando outros valores. Isso é útil?

— Omegavirus

Agradável. Eu ficaria surpreso, mas é possível que exista algum código contínuo. Você confirmou se a repetição simples de capturas antigas é eficaz? Pense que você precisará responder automaticamente a este, mas será uma referência útil.

— Sean Houlihane

@SeanHoulihane Eu também pensava assim no começo. Mas, depois de algumas tentativas fracassadas, consegui reenviar os dados e eles foram aceitos. Concluí que não há código rolante ou algo assim. Quero dizer, dessa maneira seria possível capturar 'esboços' inteiros de ações e reproduzi-lo, mas isso não funciona, pois essa contagem deve ser aumentada adequadamente o tempo todo (há uma diferença de alguma quantia que ainda é aceita - como dito, presumo que os dados sejam perdidos por problemas de alcance etc.) porque, caso contrário, o robô perde a 'sincronização' e precisa ser trazido de volta e conectado à sua estação de acoplamento.

— Omegavirus

@MikaelFalkvidd Essa é uma boa ideia e geralmente meu ponto de partida quando disponível. Infelizmente, como é um dispositivo europeu, não há ID do FFC ou similar disponível.

— Omegavirus

Oh cara, não me pergunte como, mas acho que descobri.

Vamos dar uma olhada:

Basicamente, você divide os dados em pacotes de 4 bits cada. Você concata cada primeira, segunda, terceira e quarta letra juntas separadamente. Isso pode ser visto nas colunas 1, 2, 3 e 4. Depois, você conta os 1s em cada um deles (o número de unidades é escrito ao lado de cada um deles). Se eles são pares, é um 0 para o bit de paridade; se eles são ímpares, é um. Portanto, antes de terminar, agora você deve adicionar 1 ao binário de antes (!). Isso correspondia todas as vezes e eu consegui gerar meus próprios quadros dessa maneira. Problema resolvido, parece. Perfeito. Muito obrigado a todos por contribuírem.

— Omegavirus
fonte

Em outras palavras, a mordidela de verificação é um XOR de todos os anteriores.

— Chris Stratton

@ChrisStratton Perdoe esta pergunta, mas o que exatamente precisa ser corrigido? Eu tentei cada bloco de paridade das categorias, mas isso não funcionou.

— Omegavirus

Transforme X em cada um dos petiscos em um acumulador que seja inicialmente zero e você terá sua resposta. Isso deixa você com um um em cada posição de bit se o número de pessoas nessa posição for ímpar.

— Chris Stratton

Mere otimização - você descobriu a exigência a si mesmo :-)

— Chris Stratton

@ ChrisStratton Certo, no entanto, a abordagem XOR é obviamente a correta e eu a implementei facilmente dessa maneira em python. De qualquer forma, o +1 no final ainda era necessário. Você sabe por quê?

— Omegavirus