Merci, oui je veux bien car effectivement j'ai essayé plusieurs fois d'aller sur Sigrok sans succès.
ici pour Linux : pulseview-NIGHTLY-x86_64-debug.AppImage , téléchargeable pendant 30 jours (48 Mo)
https://transfert.free.fr/iJXGKdm
Impeccable, ça fonctionne, encore merci !
Il est tard et j'ai du faire une bêtise avec mes transistors, ça ne fonctionne pas, à demain !
J'avais oublié de faire des ponts entre collecteurs et résistances au +5V!
Maintenant c'est bon pour Pulseview, pour les valeurs c'est faux bien sûr 15.55 mm alors que ça devrait être 0.00 mm
500 kHz ne me parait pas suffisant , les impulsions d'horloge ne sont pas assez finement saisies pour que le décodeur donne un résultat fiable. N'ayant pas un nombre suffisant de points pour chaque état logique de l'hotloge ,Pulseview ne peur respecter leurs durées
Le décodeurs table sur un timing précis des états logiques reçus
mets en ligne le fichier Pulseview, c'est plus pratique à étudier qu'une image
Bonjour, ok. L'image c'était pour ceux qui veulent voir ce que ça donne.
Comparateur_0mm_1Mhz_15-04-2025.zip (829 Bytes)
Pour donner une image à tous de ce que je considère comme "instable", c'est au début avant le trait blanc c'est différent à chaque fois,
et après c'est "stable" à priori toujours identique quand le comparateur affiche 0.00 mm.
Et évidemment la valeur de 15.36 mm ne correspond pas à l’affichage du comparateur 0.00 mm
J'ai fait à 1.00 mm au comparateur
Comparateur_1mm_1Mhz_15-04-2025.zip (828 Bytes)
et 2.00 mm
Comparateur_2mm_1Mhz_15-04-2025.zip (810 Bytes)
et 3.00 mm
Comparateur_3mm_1Mhz_15-04-2025.zip (838 Bytes)
Tant que je ne vois pas le décodeur fonctionner correctement je ne peux pas conclure + je laisse totalement de côté 'linstabilité' (bruit) qui est un détail tant qu'on n'a pas compris l'essentiel.
Avec tes derniers enregistrements le décodeur foire , il ne détecte pas les bonnes frontières pour les deux mots de 24bits -> les résultats numériques n'ont aucun intérêt
Remarque : si on reprend l'image du message #78 mais que l'on inverse DATA par rapport à ce que l'on voit le second mot de la trame serait quasi nul ce qui serait sympa pour la valeur relative au dernier Zéro mémorisé.
(seuls les 4 bits de poids faibles seraient à 1, tous les autres à 0, soit le nombre binaire de 23 bits suivant
soit le nombre
MSB....................................LSB
00000000000000000001111
il me semble qu'en l'état Pulseview permet déjà de répérer sur les chronogrammes un candidat intéressant pour la valeur de la mesure : le second mot de la trame. ça vaudrait peut être le coup de tenter un code Arduino en te replaçant dans les mêmes conditions que pour l'image ci dessus, le code capturerait le complément de l'état de DATA à chaque front montant de CLOCK une fois terminé l'intervalle entre les deux mots de 24 bits de la trame de 48 bits
Le bits capturés seraient rangés en commençant par les poids faibles
le nombre de 23 bits (laisser tomber le 24e,) serait considéré comme résultat brut de mesure à convertir ensuite dans l'unité désirée
Le codage n'est pas mon fort
N'ayant de plus pas le matériel pour tester une proposition , je laisse ça aux pros.
Le décodeur est peut-être fait essentiellement pour les pieds à coulisse classiques, ce que l'on trouve le plus souvent.
Il faudrait que j'essaye avec le PAC pour voir, mais j'ai du recâblage à faire !
d'après ce qui est écrit dans le code source en Python du décodeur , il est pour ce (Chinese Scale Protocole de cette page (2x24bits) qui ressemble fortement t aux chronogrammes relevés
https://www.shumatech.com/support/chinese_scales.htm#Chinese%20Scale%20Protocol
perso : comme écrit ci dessus j'ai maintenant l'impression que les chronogrames de Pulseview (pas la valeur numérique du décodeur) montrent , dans le second mot de la trame un nombre de 23 bits à exploiter , il vaut zéro quand l'affichage vaut zéro aux 4 bits de poids faibles près (le bruit)
Oui rapidement c'est bien pour le PAC le décodeur est fait pour ce protocole
pardon il faut que je m'absente...
OK donc , caliper n'était donc pas la bonne piste en matière de décodeur
On s'en tient à l'analyse des chronogrames de Pulseview faute de décodeur adapté à ton comparateur, 'on 'décode' nous mêmes
Si j'avais cet appareil je me lancerai dans un code Arduino pour récupérer et 'faire parler' les 23 premiers bits ou 24 bits du second mot de la trame de 2 fois 24bits
= récupérer sur 'DATA' 23 bits , série synchrone, sur front montant de 'CLK' en commençant par les LSB
(front montant ou descendant de CLK, DATA inversé ou pas leslon le câblage entre le comparateur eu la carte aRduino)
Le plus simple est peut être de détecter le début de la trame (tempo) puis récupérer ses deux mots de 24 bits
structure d'une trame de 2 mots série synchrone de 24 bits
intervalle entre deux trames : 128ms
Bonsoir,
Je suis un peu perdu, je me demande si c'est raisonnable de continuer avec ce comparateur qui me semble bien difficile à décoder.
Je n'ai rien trouvé sur ce protocole : Data Sylvac Protocol (48 bit 2X24 Type A)
https://www.caliper2pc.de
je devrais peut-être voir ce que donne ce logiciel Caliper2PC, ceci dit ce n'est pas pour Ubuntu Linux ça risque d'être un peu difficile, enfin pour moi !
J'ai reçu l'autre comparateur avec sortie mini USB, je vais peut-être me concentrer sur celui là, j'espère que ça sera plus facile, mais déjà il faut que je commande de la prise mini USB pour se connecter.
Sinon j'ai refait 4 enregistrements (copies d'écran), et dans ces enregistrements c'est juste le tout début qui est différent, jusqu'au 2 ème bit clock j'ai l'impression
non en fait c'est au 6 ème que c'est identique
J'ai testé le nouveau comparateur et j'ai fait une ................. !
Donc il a une prise micro USB et j'ai utilisé un petit câble de récupération dont j'ai utilisé les 4 fils présents.
J'ai cru que le noir c'était la masse, le rouge le +3V, et les deux autres vert et blanc, peut-être clock et data.
Au début je n'avais pas mis de +3V et j'ai réussi à voir des signaux, mais j'ai eu la très mauvaise idée de mettre le +3V (avec une résistance pour limiter le courant) et j'ai cramé une sortie,
en fait le rouge c'est la masse et le blanc c'est le +3V,
le noir ça devait être data mais je n'ai plus rien maintenant,
et le vert c'est à priori clock qui fonctionne.
En démontant le comparateur pour être certain du câblage (j'aurais dû le faire avant bien sûr, mais j'avais un peu peur de l’abîmer, ce qui est le cas maintenant !), j'ai vu qu'il y a un autre fil utilisé, mais je ne l'ai pas dans mon câble.
Heureusement il fonctionne toujours en comparateur, mais pour mon utilisation je peux reprendre le premier comparateur, retour à la case départ !
Comparateur_SHAHE_0mm_22-04-2025.zip (851 Bytes)
J'ai peut-être encore une possibilité avec le comparateur SHAHE, d'après une vidéo le connecteur USB n'est pas "classique" et data ne serait pas sur le fil que j'ai utilisé.
Il faudrait que je trouve un autre cable mini USB complet ou que je commande une prise mini USB pour avoir les bonnes connexions.
ESP32 REMOTE INDICATOR | SHAHE REMOTE DEVICE | #43
Le schéma
Je reviens donc sur le premier comparateur et je suis très perplexe avec des nouveaux enregistrements, on dirait vraiment que ce n'est presque jamais 2 fois la même chose.
Il me faudrait un enregistrement plus long, j'ai commandé un autre petit "Scanalogic" plus performant que celui que j'ai et qui date.
A noter que pour récupérer Pulseview c'est ici
https://www.sigrok.org/download/binary/pulseview/
en attendant je suppose que le site soit de nouveau opérationnel.
Bonjour @michelm
Merci pour le lien de téléchargement à nouveau valide
Les développeurs de PulseView et Sigrok ont eu de gros soucis avec l'hébergeur de leur site
Beaucoup de pertes 'infos semble-t-il . Reste à voir ce qui pourra être récupéré et remis en ligne
(Je pense entre autres au Wiki qui contenait des infos techniques détaillées sur les appareils de mesure supportés.)
la 'mailing list' suivante permet d'avoir quelques infos sur ce qui se passe :
Bonjour al1fch,
Oui c'est très utile PulseView et Sigrok je ne connais pas toutes les possibilités, en particulier le décodage, mais c'est vraiment appréciable.
J'espère qu'ils pourront remettre en ligne le Wiki etc.
Merci pour la 'mailing list'.