Problema de cálculo de paridad

Últimamente he estado haciendo bastante domótica (RF; 433MHz) en muchos dispositivos diferentes, lo que funcionó bien para todos excepto uno. Básicamente es un robot de piscina con un control remoto realmente horrible.

Recopilé algunos datos usando un BladeRF SDR y GNU Radio. La columna "otros 3" es básicamente la acción, mientras que "otro 1" parece ser una serie y "otro 2" define el robot si tiene varios en uso, supongo (algún amigo mío que tiene el mismo tiene un valor diferente allí). No estoy seguro de para qué sirve el conteo, pero supongo que es para que el robot sepa cuándo el rango se amplía demasiado (¿falta información?). He reducido los bytes y sus significados, sin embargo, no puedo calcular el CRC (suma de verificación) correcto para los datos.

ANTIGUO - ¡POR FAVOR VEA LA ACTUALIZACIÓN A CONTINUACIÓN!

Aquí hay algunos datos de muestra:

<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

Hay un recuento para cada solicitud que se debe cambiar y algunos comandos para enviar, por ejemplo, la columna "otros 3" podría leer 00000010 en lugar de 00000001.

Sería muy útil si alguien pudiera darme algunas pistas sobre dónde mirar. He probado diferentes técnicas como XOR a través de los bytes o el módulo de cálculo, etc. Incluso probé diferentes herramientas de fuerza bruta del algoritmo CRC, desafortunadamente aún no he tenido éxito.

EDITAR: Puse los datos en Excel y agregué algunas funciones (básicamente compara cada 4 bits con los de arriba, la última transmisión). Lo hice cuando reconocí que el CRC permaneció igual una vez. Este fue el caso cuando tanto la acción como el recuento aumentaron en 1. Por favor, eche un vistazo:

ACTUALIZAR:

He encontrado alguna otra especificación más detallada. del mismo proveedor en la red después de buscar durante horas y salió el CRC tan pensado, de hecho, es una paridad. También ajusté mi diagrama de flujo de captura de radio gnu y recopilé algunos datos nuevos. Haga caso omiso de los datos anteriores y eche un vistazo aquí:

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

Y aquí está de nuevo como un lujo excelente:

¿Alguien sabe cómo calcular esa paridad? Intenté dividir los datos, etc. y usar los cálculos de paridad habituales, pero desafortunadamente aún no he tenido éxito.

smart-home data-transfer interfacing

— Omegavirus
fuente

No tiene suficiente información aquí, ya que lo único que muestra que cambia además del valor de verificación es el último byte, el conteo. Por lo tanto, no puede distinguir el impacto de los bytes anteriores frente a algún valor inicial estático del algoritmo. Puede hacer algunas suposiciones y tal vez probarlas, o incluso tal vez encontrar una teoría demasiado hermosa para que no sea probable, pero todo lo que realmente puede revertir solo con los datos proporcionados es el papel del último byte en la creación del valor de verificación.

— Chris Stratton

@ChrisStratton Tienes razón. He agregado algunos datos cambiando otros valores. ¿Es útil?

— Omegavirus

Agradable. Me sorprendería, pero es posible que haya un código variable. ¿Confirmó si la reproducción simple de capturas antiguas es efectiva? Piensa que tendrá que responder esta, pero será una referencia útil.

— Sean Houlihane

@SeanHoulihane Yo también lo pensé al principio. Pero después de algunos intentos fallidos, logré reenviar los datos y los acepté, así que concluí que no hay un código móvil o algo así. Quiero decir, de esa manera sería posible capturar 'bocetos' completos de acciones y reproducirlos, pero eso no funciona, ya que ese recuento debe aumentarse adecuadamente todo el tiempo (todavía hay una diferencia de cierta cantidad que se acepta) como dije supongo porque los datos se pierden por problemas de alcance, etc.) porque si no, el robot pierde 'sincronización' y necesita ser devuelto y enchufado a su estación de acoplamiento.

— Omegavirus

@MikaelFalkvidd Esa es una buena idea y generalmente mi punto de partida cuando está disponible. Desafortunadamente, como es un dispositivo europeo, no hay identificación de FFC o similar disponible.

— Omegavirus

Oh hombre, no me preguntes cómo, pero creo que lo descubrí.

Echemos un vistazo:

Básicamente, divide los datos en paquetes de 4 bits cada uno. Luego concatena cada primera, segunda, tercera y cuarta letra juntas por separado. Esto se puede ver en las columnas 1, 2, 3 y 4. Luego, cuenta los 1 en cada uno de ellos (el número de unos se escribe al lado de cada uno de ellos). Si son pares es un 0 para el bit de paridad, si son impares es uno. Entonces, antes de terminar, ahora tiene que agregar binario 1 al resultado anterior (!). Eso coincidía cada vez y pude generar con éxito mis propios marcos de esa manera. Problema resuelto parece. Perfecto. Muchas gracias a todos por contribuir.

— Omegavirus
fuente

En otras palabras, el mordisco de verificación es un XOR de todos los anteriores.

— Chris Stratton

@ChrisStratton Disculpe esta pregunta, pero ¿qué necesita exactamente ser XOR? He intentado cada bloque de paridad de las categorías, pero eso no funcionó.

— Omegavirus

XOR cada uno de los mordiscos en un acumulador que inicialmente es cero y tendrá su respuesta. Esto te deja con uno en cada posición de bit si el número de unidades en esa posición es impar.

— Chris Stratton

Mera optimización: descubriste el requisito tú mismo :-)

— Chris Stratton

@ChrisStratton Right, sin embargo, el enfoque XOR es obviamente el correcto y lo implementé fácilmente de esa manera en Python. De todos modos, el +1 al final todavía era necesario. ¿Sabes por qué?

— Omegavirus