Rien n'y fait. J'en ai plusieurs sous la main, je ne suis pas expert mais pas débutant non plus.
Auparavant j'utilisais le JQ6500 qui lui accueille les fichiers son en ram contrairement au DFPlayer qui utilise une carte SD. Avec ce dernier J'ai beau essayer toutes les configurations et avec ou sans microcontrôleur... du silence rien que du silence !
Le HP semble lâcher néanmoins un léger bruit blanc de fond donc j'en ai déduis que c'est peut-être un problème de nommage des fichiers (0001.mp3 ou 001.mp3 selon les tuto sur internet) qui ne se déclenchent pas, mais que des essais infructueux.
Peut-être aussi une mauvaise version du chip, je sais plus quoi penser.
Bref, désolé pour le bla bla J'envisage du coup l'acquisition d'un appareil pour monitorer les signaux.
Ce sera une première pour moi j'en ai jamais vraiment tripoté un (j'ai pas dis que j'étais ignare en signal, au moins pour la base).
Auriez-vous des conseils pour un budget raisonnable pour un bricoleur et surtout une première approche, sans tomber dans le mauvais produit. Quelles fonctions à ne pas râter lors de l'acquisition d'un tel appareil ?
Et si vous êtes arrivé jusque là et que vous avez aussi une suggestion pour le DFPlayer, je prend tout.
Merci de votre lecture !
Ça paraît une bonne excuse pour acheter un scope mais il faut en avoir le besoin … et mettre un budget correct (au moins 2 entrées, une fréquence d’analyse élevée, possibilités de déclencher sur fronts, enregistrement des échantillons, calibration etc)
Sinon on trouve des clones de Salae pour pas trop cher et c’est votre ordinateur qui fait l’affichage
Pour votre souci - Il y a aussi des copies de DFPlayer qui sont vendues et qui ne sont pas 100% compatibles avec la bibliothèque - une histoire de timing de la communication sur le port série et de réactivité du composant
Un oscillo n’est pas un objet miracle.
C’est assez cher et il faut le maitriser.
Rien que l’utilisation et la connexion des sondes, si ces opérations ne sont pas maîtrisées, peuvent masquer le défaut recherché ou faire apparaître un defaut qui n’existe pas.
Il faut de bonnes notions de bande passante pour savoir si l’oscillo que l’on possède est adapté à la recherche du défaut que l’on soupçonne.
Le clone de Saleae à moins de 10 € est simple d’emploi et rend de grands services.
Le logiciel qui l’accompagne est prévu pour analyser les principaux protocoles de transmission ( uart, i2c, spi, etc....).
je partage à 100% les remarques et réserves ci-dessus de @68tjs et @J-M-L
Si un investissement 'oscilloscope' est décidé en connaissance de cause, pour moi la barre pour un oscilloscope polyvalent est en 2023 vers 300€ avec, ,par exemple, un DS1102Z-E de Rigol ou équivalent sur le plan des caractéristiques chez Siglent ......
N.B le DS1102Z-E me donne entière satisfaction après plusieurs décennies d'utilisation quotidienne de scopes analogiques, rien dans mes besoins ne m'incitant à monter en bande passante ou en nombre de traces.
Un budget raisonnable est vraiment une notion très personnel, pour un oscilloscope moi je dirais 500€.
Pour ce prix il y a pas mal de choix.
Mais cela correspond t-il à définition de raisonnable?
Mon alimentation délivre 30A en 5 volts avec plusieurs sorties pas de problème de ce côté-là.
L'encodage en .mp3 peut avoir de nombreuses options, on a pas de détails sur ce point.
Pour l'oscilloscope, j'en emploie 2, celui de "première intervention" DSO150:
qui suffit pour voire les signaux de l'Arduino (mono canal) et l'autre, le PicoScope 2204A,
le programme de ce dernier, décode quelques protocoles:
Merci pour les conseils sur l'oscillo, en effet une telle acquisition demande d'en avoir le besoin, est-ce mon cas ... pas certain, surtout au prix évoqué par @ terwal mais je m'y attendais.
Et surtout pour juste monitorer des pins. J'ai découvert l'option de plotting dans les dernières version de l'IDE Arduino, je suis un peu confus sur l'utilité : puis-je afficher ce qui sort des pins par ce biais ?
Avez vous un « vrai » DFPlayer ?
Je crois que c'est une excellente question : DFPlayer Mini HW-247A
et des notices qui se contredisent sur le net concernant le nommage des sons.
J'ai tout tenté sur ce point.
Il y a aussi des copies de DFPlayer qui sont vendues et qui ne sont pas 100% compatibles avec la bibliothèque - une histoire de timing de la communication sur le port série et de réactivité du composant
Oui cela doit être possible, mais cela nécessite de faire des lectures sur les broches que tu utilises pour la communication avec ton module.
Ton module ne communique pas par une liaison série ?
Il me semble que @J-M-L ou @al1fch ta conseiller un analyser logique aussi, ce qui a l'avantage d'être très abordable, car à moins de 100€.
Ce que propose @jpbbricole doit être aussi abordable.
Un très grand + 10 000
C’est totalement independant de l’IDE. C’est donc beaucoup plus souple.
C’est très simple d’emploi, beaucoup plus qu’un oscillo.
Conseil :
Si avec @al1fch nous avons réussi a te convaincre, recherche des câbles en silicone terminés par des grippe-fils.
C’est a peine plus cher et c’est sacrement plus pratique.
Bien vu, le chip est un GD3200B
J'ai donc repris avec la lib de enjoyneering
Et avec un ESP 01S
Comme j'avais auparavant modifié les pin 1 et 3 (TX et RX par défaut) en GPIO classiques pour un autre projet j' ai introduit les lignes suivantes dans le setup:
Malheureusement c'est coriace : pas de résultats.
Le moniteur m'indique bien qu'il y a un problème de communication avec le code 4
Serial.println("status:");
Serial.println(mp3.getStatus()); //0=stop, 1=playing, 2=pause, 3=sleep or standby, 4=communication error, 5=unknown state
Je ne suis pas clair sur le baud, mon esp semble fonctionner en 74880, selon la config Serial.begin() et dans le moniteur j'ai au choix des "???" ou des petits carrés, et parfois le numéro du code d'erreur.
En règle générale les cartes avec des ESP8266 ont un débit à 74880 bauds avant le démarrage du code téléversé , il s'agit ici des messages de démarrage ('boot') du soc, ensuite c'est Serial.begin() qui définit le débit, debit ici qui doit être compatible avec le DFPlayer mini
Pour une raison que j'ignore (meilleure stabilité de fonctionnement ?) alors ques les ESP8266 sont conçus pour émettre le message de boot à 115200 bauds avec un quartz de 40MHz, les fabricants de modules ou cartes mettent un quartz de 26MHz, d'où le 74880 bauds
Quelle est la 'valeur ajoutée' de ce choix très particulier de débit ?
S'agissant des messages émis par le programme , pourquoi ne pas choisir une valeur comme 115200bauds ?
Est-il impératif de visualiser en clair les quelques lignes de boot' avec leur débit très particulier ?
Redéfinition de fonctions spéciales de GPIO : j'ai abandonné les ESP-01S depuis trop longtemps pour me rappeler d'éventuels problèmes ..... Avec our les cartes 'évoluées' avec des ESP8266 ces redéfinitions ne semblent pas utiles , du moins pour mes usages
