next topic »

[Reply #75 on:]

encore un test à faire
verifier si les 2emes/3emes ... trames successives "apres init" sont identiques, même pour des appuis décalés dans le temps

Les trames commencent toujours de la même manière âpres mise sous tension :

FE 79 5F 78 19 87 D (A)
FE 79 5F 78 0D A2 F (B)
FE 79 5F 78 11 E9 9 (C)
FE 79 5F 78 0E 66 3 (D)

Que donnent plusieurs ON successifs suffisement espacés dans le temps et sans OFF intermédiaires ?

Avec l'interrupteur c'est impossible d'avoir plusieurs ON successif sans OFF intermédiaires vu que c'est un interrupteur "va et vient".
Et comme je ne peut pas piquer le signal de la télécommande ...

Bon sinon j'ai mis en place un systéme de boutons, côte émetteur j'ai un inter ON /OFF, et côté récepteur j'ai un inter DUMP / RUN ce qui me permet de faire des dump de l'eeprom après chaque basculement de l'inter ON / OFF.

Je peut donc affirmer sans me tromper que les 8 bits tournants et les 8 bits inconnu NE SONT PAS stocké dans l'eeprom.
Les seuls modifications apporté lors d'un appui sur le BP sont au niveau de l'octet 0x00 / 0xFF qui stocke l'état du relai du récepteur.

[Reply #76 on:]

Si tu génère 8 bits aléatoires en emission, est-ce que l'objet télécommandé réagit ou pas ?
Peut être n'y a t'il aucune corrélation entre les bits, il faut juste qu'ils soient différents

[Reply #77 on:]

Oui, barbudor la piste du timer est intéressante
j'ai repris ton fichier pour faciliter l'analyse de l'évolution du dernier octet.
c'est peu être fortuit (je ne sais pas comment ont été rythmées les emissions successives) mais je crois voir des répétitions sur le quartet fort de ce qui pourrait être une valeur de timer pris au vol et  envoyée en fin de trame ! (F271 ou 5DD...) cf texte colorié joint.
J'ai trop envie que ce soit ça !!

Je peut donc affirmer sans me tromper que les 8 bits tournants et les 8 bits inconnu NE SONT PAS stocké dans l'eeprom.
Les seuls modifications apporté lors d'un appui sur le BP sont au niveau de l'octet 0x00 / 0xFF qui stocke l'état du relai du récepteur.

skywodd je crois qu'on peut éliminer (ouf !) le rolling code qui nécessiterait un minimum de mémorisation supplémentaire en eeprom récepteur.

[Reply #78 on:]

Si tu génère 8 bits aléatoires en emission, est-ce que l'objet télécommandé réagit ou pas ?

Héhé ! JACKPOT ! Avec des chiffres complétement aléatoire ça marche !
Bon parfois ça rate mais sinon dans le principe ça fonctionne !

[Reply #79 on:]

Pour l'anecdote
meme si je ne ressortirais mes "jouets" que plus tard   , je ne vais pas me priver déjà de sortir un connecteur kivabien
 

[Reply #80 on:]

Héhé ! JACKPOT ! Avec des chiffres complétement aléatoire ça marche !
Bon parfois ça rate mais sinon dans le principe ça fonctionne !

timer++ !!  le récepteur écarterait les trames dont les octets de fin seraient trop proches.

en complémentant l'octet de fin à chaque envoi ,au lieu d'envoyer de l'aléatoire,ça suffit peut être à maintenir un delta suffisant pour le récepteur entre deux messages successifs ?

[Reply #81 on:]

Si tu génère 8 bits aléatoires en emission, est-ce que l'objet télécommandé réagit ou pas ?

Héhé ! JACKPOT ! Avec des chiffres complétement aléatoire ça marche !
Bon parfois ça rate mais sinon dans le principe ça fonctionne !

alors continue l'analyse  
quels codes ratent, quels codes fonctionnent, si ça se trouve ça se reduit simplement  

Héhé ! JACKPOT ! Avec des chiffres complétement aléatoire ça marche !
Bon parfois ça rate mais sinon dans le principe ça fonctionne !

timer++ !!  le récepteur écarterait les trames dont les octets de fin seraient trop proches

Bonne suggestion
faire un test avec des des valeurs moyennement eloignées  
0 63 127 255

[Reply #82 on:]

alors continue l'analyse  
quels codes ratent, quels codes fonctionnent, si ça se trouve ça se reduit simplement  

En faite je crois que les ratés sont du à ma méthode basé sur random() d'arduino qui est pas si random que ça  
Je suis en train de regarder comment ça ce comporte avec une bête addition à chaque fois.

Ps: Quand il va falloir que je reprenne tout le topic depuis le début pour faire le compte rendu ... ça va être plus long que le hack en lui même

[Reply #83 on:]

Les valeurs des 8 derniers bits sont effectivement pompé d'un timer 8bits (à incrémentation positive) !

-> voir fichier calc joint

[Reply #84 on:]

écart mini constaté  = 5  = 0xD5 -0xD0 FAUX il faut faire (n) par rapport à (n-1) !
(cf 65 trames de barbudor) ...  sauf erreur de lecture

Sans doute içi : delta de 3 seulement

Code:

> FE 4A 23 D8 0 9 8 5 3
> FE 4A 23 D8 0 D A D 5
> FE 4A 23 D8 0 1 E D 0
> FE 4A 23 D8 0 E 6 D E <<
> FE 4A 23 D8 0 6 7 E 1 <<

> FE 4A 23 D8 0 9 8 F A

[Reply #85 on:]

Les valeurs des 8 derniers bits sont effectivement pompé d'un timer 8bits (à incrémentation positive) !

-> voir fichier calc joint

comme ce ne doit pas etre verifié temporellement par le recepteur
fais qq test successifs avec 0 et 127 en finale

[Reply #86 on:]

Nan, pas un timer.
Quelque soit le temps entre 2 pressions de boutons, la séquence ne change pas.
Nouvelle séquence avec 285 captures
Aucune répétition

je ne sais plus si on l'a déjà dit mais la séquence inconnue ne dépend pas du flag ON/OFF

Séquence que de ON :

> FE 4A 23 D8 0E A3 1
> FE 4A 23 D8 0E F9 D
> FE 4A 23 D8 0B 96 B
> FE 4A 23 D8 07 C0 9
> FE 4A 23 D8 06 24 0
> FE 4A 23 D8 0E EB 9
> FE 4A 23 D8 05 7A F
> FE 4A 23 D8 07 89 8
> FE 4A 23 D8 09 A6 5
> FE 4A 23 D8 09 EF 3
> FE 4A 23 D8 0E 61 9
> FE 4A 23 D8 06 76 2
> FE 4A 23 D8 09 8F 9
> FE 4A 23 D8 0D A2 6
> FE 4A 23 D8 01 E7 9

Séquence ON et OFF

> FE 4A 23 D8 0E A3 1
> FE 4A 23 D8 0E F9 D
> FE 4A 23 D8 0B 96 B
> FE 4A 23 D8 07 C0 9
> FE 4A 23 D8 06 24 0
> FE 4A 23 D8 0E EB 9
> FE 4A 23 D8 05 7A F
> FE 4A 23 D8 17 89 8
> FE 4A 23 D8 19 A6 5
> FE 4A 23 D8 19 EF 3
> FE 4A 23 D8 1E 61 9
> FE 4A 23 D8 06 76 2
> FE 4A 23 D8 09 8F 9
> FE 4A 23 D8 0D A2 6
> FE 4A 23 D8 01 E7 9

[Reply #87 on:]

Et Skywodd, tu as un noyau multi-tâche
Simultanément il continue à répondre aux différents sujets, a publier sur son blog et a décortiquer les Blyss

[Reply #88 on:]

en complémentant l'octet de fin à chaque envoi ,au lieu d'envoyer de l'aléatoire,ça suffit peut être à maintenir un delta suffisant pour le récepteur entre deux messages successifs ?

J'ai pris un delta de 50 entre chaque trame, ça marche nikel comme sur des roulettes, je testerai avec juste +1

--> Voir .ino en pièce jointe

écart mini constaté  = 5  = 0xD5 -0xD0 FAUX il faut faire (n) par rapport à (n-1) !
(cf 65 trames de barbudor) ...  sauf erreur de lecture

Ou tu as vu min = 5 ? Dans mon fichier calc j'ai bien min = 3.

comme ce ne doit pas etre verifié temporellement par le recepteur
fais qq test successifs avec 0 et 127 en finale

Raaa encore des tests

Et Skywodd, tu as un noyau multi-tâche
Simultanément il continue à répondre aux différents sujets, a publier sur son blog et a décortiquer les Blyss

Tout en répondant à mes mail et à mes @mention twitter, le tout en discutant sur skype  
Certain appellerons ça de la dispersion ... d'autre du multi-taches

[Reply #89 on:]

s'il n'y a pas de bug au niveau de ton systeme de capture, barbudor,  on doit faire un pas en arrière dans l'analyse car on voit apparaitre des valeurs nouvelles (par exemple 78, 9A ou 9E dans l'avant dernier octet., valeurs qui ne sont pas toutes dans le cycle 98 > DA > 1E > E6 -> 67 > DA .. qu'ont pensait identifié  

> FE 4A 23 D8 05 7A F
> FE 4A 23 D8 1  78*   9 8......78, pas 98 ?
> FE 4A 23 D8 1  9A*   6 5......9A ,pas DA ?
> FE 4A 23 D8 1  9E*   F 3......9E, pas 1E ?
> FE 4A 23 D8 1  E6    1 9
> FE 4A 23 D8 0  67    6 2
> FE 4A 23 D8 0  98    F 9
> FE 4A 23 D8 0  DA   2 6
> FE 4A 23 D8 0  1 E   7 9

@skywodd

Ou tu as vu min = 5 ? Dans mon fichier calc j'ai bien min = 3.

le min de 5 a été constaté "à vue de nez"  dans l'enregistrement de barbudor '65 trames...' avant ton analyse !!