la 2ème capture c'est : sur cava.png
je l'ai reprise en recopiant en dessous le 1er byte sous les 2èmes et 3èmes bytes, pour montrer le rythme
on voit clairement qu'on a bien affaire à un format série !
il n'y a donc plus qu'à déterminer le bitrate en fonction de la largeur des bits ; je pense alors qu'à ce stade tapi n'a plus besoin de nous (ni d'avoir à nous fournir d'autres éléments) pour faire son rétro protocole
(et que d'ailleurs c'est peut-être pour cela qu'il ne donne plus signe de vie)
Bonsoir
le dernier message de tapi se terminait sur ces mots
Si vous êtes fatigués de me répondre, je comprends complètement, je pense que je ne vais pas tarder à laisser tomber, c'est trop compliqué pour moi
d'où la proposition de communication du fichier .sr de l'enregistrement mais qui sait il a peut être , depuis, abouti (sans le dire) avec ta proposition @trimarco232 ?
oui, restons optimistes, ça protège
AAAhhhh,
j'avais pas mal de travail cette semaine et je n'étais pas repassé sur le forum, quel bonheur de voir toute cette effervescence !!! Vous êtes magnifiques 
Alors je vais reprendre sérieusement les tests, ce soir, je reconnecte tous mes petits câbles et j'enregistre en 1Mhz sur plusieurs secondes au format .sr.
Je vous poste ça dans la soirée
Bon dimanche à tous
Bonsoir,
Encore désolé de ne pas être repassé avant,
voilà j'ai refait une analyse en 1Mhz et en sample de 5M.
Artouste, pour te répondre, j'ai pris une photo de mon installation (probablement douteuse pour bon nombre d'entre vous sur l'analyseur, j'ai la masse de connectée (fil gris ) en GND et les deux fils de données en channel 1 et channel 2.
Pour le test, j'ai utilisé les différentes commandes de l'accordeon, changement de son, appuis sur les notes et déclenchement de séquences musicales.
La piste "commandes midi in "doit correspondre aux informations d'affichage de l'écran de l'accordéon lorsque l'on change de son. Pour preuve, Si je déconnecte le fil que je nomme "commande midi in", lorsque je change de son sur l'accordéon, le son en sortie du module change mais l'écran de l'accordéon affiche "pas de communication".
Trimarco22, tu dis que la 2ème capture ressemble fort à un paquet série de 3 x 8bits (avec S et T),S et T c'est quoi : start stop ,?
J'ai observé les signaux de la ligne "notes out"et on dirait qu'il y a toujours trois séries entrecoupées d'une série qui dure toujours le même temps et qui est toujours 0.
Pour la première série, je n'ai relevé que trois commandes différentes (en midi ou uart) : cc, cb ou dc mais majoritairement cb. En tout cas, il a beau être insistant, je ne lui donnerais pas ma carte bancaire !!!
Bon je pense que vous analyserez ça 100 fois mieux que moi.
En tout cas cette semaine, je vais pouvoir m'y remettre.
Bonne semaine à tous et merci
Outch, j'ai parlé trop vite, la deuxième série peut être différente, elle n'est pas toujours sur 0. Désolé
tapi:
(...)
Trimarco22, tu dis que la 2ème capture ressemble fort à un paquet série de 3 x 8bits (avec S et T),S et T c'est quoi : start stop ,?
(...)
oui, en abrégé (comme sur la 3ème capture, je n'ai rien inventé)
-> mesures la durée d'un bit : en inversant la valeur tu auras le baudrate (bps) qui te permettra d'observer et de décoder tes trames
Effectivement en mesurant avec le zoom au maximum, j'ai 8µ tout pile. Sur les tableaux que je trouve, pour 115200 ils disent 8.681µ. C'est normal que ça varie un peu ? peut-être l'analyseur qui n'est pas assez précis ? ou alors on peut affiner le reglagle du baudrate ?
Autre question, est ce que le frame error que j'ai sur une majorité de message au même niveau que les stop vient du fait que je n'ai pas bien règler mon decodeur uart ? ou alors que ça n'est pas de l'uart ?
bonsoir,
tapi:
... j'ai 8µ tout pile. ... pour 115200 ils disent 8.681µ. C'est normal que ça varie un peu ? peut-être l'analyseur qui n'est pas assez précis ?
l'analyseur travaille à sa propre vitesse : il te donne les temps qu'il a relevés.
si tu prends un autre bit, il sera peut-être mesuré à 9µs, ou 12, suivant l'horloge d'acquisition de l'appareil.
si tu veux avoir "une vraie mesure", il faut prendre une "longue" plage et diviser par le nombre de bits reçus.
exemple : si 100 bits durent 868µs, 1 seul vaudra bien 8.68, même si la résolution de l'analyseur n'est que de 4µs.
tapi:
Autre question, est ce que le frame error que j'ai sur une majorité de message au même niveau que les stop vient du fait que je n'ai pas bien règler mon decodeur uart ?
C'est fort possible.
Si tu indiques au décodeur qu'il y a un bit de parité alors qu'en fait il n'y en a pas tu auras une "frame error" ou inversement s'il y a une parité et que tu ne l'as pas indiquée au décodeur.
Alors du coup, j'ai testé en changeant les valeurs de parity (odd, even, none, ignore etc) et en 8 bits, j'ai toujours le frame error à la fin.
J'ai même testé en changeant toutes les autres valeurs (delimiter -1 etc) stop bits etc et ça ne change rien.
La seule façon de le faire disparaitre c'est de passer en 7 bits et parity none.
Je ne sais pas si ça fait avancer le schmilblic...;
La seule façon de le faire disparaitre c'est de passer en 7 bits et parity none.
Je ne sais pas si ça fait avancer le schmilblic...;
peut être mais il n'est pas exclu que cela ne soit qu'un 'faux semblant' sur la base d'un décalage de débit
je propose de lancer une acquisition à 5 ou 10MHz puis d'appliquer le décodeur "Guess Bitrate" sur le signal reçu pour régler le pb de la valeur effective du débit... avant d'appliquer et paramétrer un décodeur UART
... et ma proposition d'examen d'un fichier .sr non décodé tient toujours.....
Il est important d'avoir une bonne résolution pour des mesures de temps, débit faibles, pour cela la cadence d'échantillonnage dit être très élevée par rapport au débit
ci dessous une acquisition à 1MHz d'un start bit à 115200 bauds, on voit les points d'échantillonnage en nombre insuffisant pour être exploités correctement à coup sür par un décodeur, les fronts montants et descendants représentés (reconstitués) peuvent être décalés par rapport aux instants des fronts réels.
Ces décalages pevent empếcher le décodeur de bien interpréter les signaux.
En fait, le fichier .sr je l'ai posté sur la page deux, avec la photo de mon instal, c'est en zip car ça ne passait pas dans le format d'origine sur le forum. Mais c'était en 1Mhz.
Du coup, j'en reposte deux autres en zip plus précis, un en 6Mhz et l'autre en 24Mhz (allons-y gaiment !)
Effectivement, on peut lire que le bit fait 8.0416666. Après j'ai appliqué le décodeur Guess Bitrate mais il n'apparait pas dans la liste lorsque je viens appliquer l'uart, du coup, je ne sais pas si je fais bien car je suis donc obligé de remettre mon d1, je ne suis pas sur que l'uart prenne le guess bitrate et les résultats sont donc les mêmes (toujours le frame error en 8bits).
100M à 24Mhz et 6Mhz.zip (10.8 KB)
Coup d'oeil rapide à l'enregistrement à 6MHz et première impression
-> pas de signal UART en D1 ou D0
EDIT : la première impression n'etait pas la bonne , voir plus bas en #36!!
je laisse quand même tel quel le message initial même s'il part dans une mauvaise direction et contient des affirmations fausses
Prenons le motif le plus courte : D1
admettons que les premières 8µs environ (125 000 bauds) soient le bit de départ,
La trame est basée sur des intervalles de 8µs , elle ressemble à certaines trames rencontrées avec les télécommandes IR ou radio
Prenons le motif plus compliqué : D0
Début de la trame en D0
C'est une trame qui parait suivre la même logique que celle de D1 (rythmée à 8µs) mais avec un plus grand nombre de bits transmis.
Merci beaucoup pour cette avancée et effectivement, ça semblerait assez logique que le protocole soit directement du sans fil. Maintenant, est ce que c'est propriétaire ou pas ?!?
Est ce que deux arduinos peuvent s'échanger ce type de protocole ?
NON, cette avancée n'en était pas une , basée sur une mauvaise première impression !!
Nouvelle tentative de décodage ce soir de décodage type UART sur le signal D0 pour vérifier...
GuessBitRate donne les valeurs 122448 bauds , puis 12759 bauds (en tout début du signal D0 acquis)
Essai de décodage UART à 125000 bauds en 8 bits, sans parité et avec un bit de stop.
Le décodage en mode ASCII laisse voir dans la trame :
'.....PLEIN JEU MUSETTE..." !!!
et un peu plus loin dans D0 "...BASSON...."
UART OK !... En avant la musique !!
Avec une version récente de PulseView/Sigrok , avec 'Tabular View', on peut faire apparaître 'en clair' toute la trame
signal D0 :
Pour le signal D1 le même décodate UART donne des groupes de 3 octets valides commençant par souvent par 9B
Vue du début de la trame D1 décodée :
Les jeux sur D0, les notes sur D1 ?
NANNNN !!!!! Tu es un ouf de détective !!!!
C'est trop bien !!!! MERCI !!!!!
Génial !!! Du coup, je viens de tester sur le d1, et quit à ce que ça soit de l'uart pourquoi pas du midi avec les mêmes caractéristiques ? et ben bingo !!! Toutes les notes 0 avec les différentes vélocités, ça doit correspondre à l'état du soufflet. Puis avec le tabular output, on voit bien des notes (21,39,41,42,23 etc)qui sont d'abord "on" puis "off".
C'est super, franchement chapeau !!!!
Alors le 9b doit correspondre au cannal midi, après il y a un numéro qui correspond à la note et le dernier numéro correspond à la vélocité.
J'en reviens pas !!!