vmath54
Rampant
Hors ligne
Aile: planeur
pratique principale: autre (?)
vols: 100 vols
Messages: 1
|
|
« Répondre #2325 le: 28 Juin 2020 - 12:26:01 » |
|
Bonjour à tous, Après un long moment d'absence, je viens de me relancer dans la construction d'un vario tout neuf, avec écran 2.9 Merci à Ratamuse pour le pcb et le boitier ... J'ai eu des déboires avec 2 précédents varios ; pas logiciel, mais hardware. J'ai à nouveau des soucis avec mon nouveau vario. Je l'ai assemblé hier ; aucun problème pour cete opération, le tuto sur le site est très clair, c'est au top. Hier soir, après avoir fermé le boitier, j'ai installé le dernier firmware (0-8-beta3), via l'IDe Arduino ; install sans problème, mais au démarrage, c'est resté sur la page d'accueil du vario (logo du vario, et info 'Version Beta 3 00.08.J JUN 27 2020'). Il était tard, j'ai décidé de creuser le lendemain. Ce matin, je mets l'inter sur On, et rien ne se passe ; comme si je n'avais rien fait. J'appuie sur le bouton de reset, rien. Quand je relie le vario au PC via la prise USB, le PC ne détecte rien. J'ai soupconné la batterie qui se serait peut-être déchargée dans la nuit, ou un fil coupé ; j'ai démonté le boitier, et testé la tension sur les 'test points' Gnd et Vcc. C'est bien 0V si bouton Off, et 4.15V si bouton On. Aucune led de s'allume à la mise sous tension. Ca laisse à penser que le TTGO est HS ; Il y a d'autres tests à faire ? J'ai bien sur controlé les soudures, et vérifié qu'il n'y a pas de fil blessé ; tout est OK. Je suis vraiment mauvais, ou j'ai la 'scoumoune'
|
|
|
|
jpg63
Rampant
Hors ligne
Aile: Mac-Para ELAN
pratique principale: vol / site
vols: 500 vols
Messages: 0
|
|
« Répondre #2326 le: 28 Juin 2020 - 12:30:55 » |
|
vmath54 si le vario reste sur la page d'accueil c'est qu'il n'arrive pas à trouver l'altitude. Refait toutes tes soudures
Pour le fait que maintenant il ne démarre plus vérifie si le connecteur de l'antenne GPS ne touche pas la pile sinon pareil c'est peut être une soudure sur le VCC ou la masse
|
|
|
|
vmath54
Rampant
Hors ligne
Aile: planeur
pratique principale: autre (?)
vols: 100 vols
Messages: 1
|
|
« Répondre #2327 le: 28 Juin 2020 - 15:46:12 » |
|
merci pour la réponse, et bien vu : il y avait 2 problèmes : 1) le vario reste sur la page d'accueil 2) ensuite, il est resté figé Pour le 2, c'est réglé : un problème lié au flash du firm. Ce que j'ai fait hier soir : - Installation du logiciel via l'IDe Arduino ; le vario est resté figé sur la page d'accueil. - J'ai ensuite généré un binaire (croquis - exporter les binaires compilés), et tenté d'installer ce binaire via le 'flash download tool' ; ca n'a pas fonctionné. - Ensuite, j'ai utilisé 'NodeMCU-PyFlasher-4.0-x86.exe' pour flasher (je l'utilise pour un autre projet). Le flash a fonctionné, mais c'est après que ca s'est gaché. En fait, le 'NodeMCU-PyFlasher-4.0-x86.exe' flashe le binaire à l'adresse 0x00000 au lieu de 0x10000 ; c'est probablement ce qui explique le blocage du vario. Je suppose que ca a écrasé le bootloader ? suite à différentes manips ce matin, en particulier, des essais avec un autre TTGO vierge que j'ai sous le coude, mon vario est maintenant reconnu de mon PC en port COM, alors que ce n'était pas le cas auparavant. Je ne sais pas vraiment pourquoi. J'ai réinstallé le dernier code du vario directement depuis l'IDE Arduino ; il bloque toujours sur la page d'accueil, mais est en vie : la page s'efface puis se réaffiche. J'avais mis le debug au minimum (DebugConfig.h) : il n'y a que '#define PROG_DEBUG'. Ca donne ceci dans la console, après un reset : rst:0x1 (POWERON_RESET),boot:0x13 (SPI_FAST_FLASH_BOOT) configsip: 0, SPIWP:0xee clk_drv:0x00,q_drv:0x00,d_drv:0x00,cs0_drv:0x00,hd_drv:0x00,wp_drv:0x00 mode:DIO, clock div:1 load:0x3fff0018,len:4 load:0x3fff001c,len:1216 ho 0 tail 12 room 4 load:0x40078000,len:9720 ho 0 tail 12 room 4 load:0x40080400,len:6352 entry 0x400806b8 GNUVARIO compiled on Jun 28 2020 VERSION 0.8 - ⸮⸮⸮? Beta 3 Failed to read file TITRE_TIME : Heure No update file. Je vais creuser la chose ; je vous tiens au courant. Le moral remonte. Au fait, j'ai repris toutes mes soudures ; elles étaient correctes. Je n'avais pas de doute dessus, j'avais fait très attention et vérifié après.
|
|
|
|
vmath54
Rampant
Hors ligne
Aile: planeur
pratique principale: autre (?)
vols: 100 vols
Messages: 1
|
|
« Répondre #2328 le: 28 Juin 2020 - 15:54:38 » |
|
Et avec la sdcard insérée, ca donne ceci : GNUVARIO compiled on Jun 28 2020 VERSION 0.8 - ⸮⸮⸮? Beta 3 Chargement des parametres depuis le fichier params.jso deserialisation Paramètres : ****** Systeme ******* Json Recup - BT_ENABLE : 0 Json Recup - NO_RECORD : 0 Json Recup - ALARM_SDCARD : 1 Json Recup - BEEP_GPSFIX : 1 Json Recup - BEEP_FLYBEGIN : 0 Json Recup - BEEP_VARIOBEGIN : 0 Json Recup - COMPENSATION_TEMP : -6.00 Json Recup - COMPENSATION_GPSALTI : -30 Json Recup - SLEEP_TIMEOUT_MINUTES : 20 Json Recup - SLEEP_THRESHOLD_CPS : 0.50 Json Recup - MULTIDISPLAY_DURATION : 2000 Json Recup - DISPLAY_STAT_DURATION : 6 Json Recup - URL_UPDATE : http://gnuvario-e.yj.fr/webupdate/checkversion Json Recup - LANGUAGE : 0 ****** General ******* Json Recup - Pilot Name : Magali Json Recup - Time Zone : 0 Json Recup - Glider Name 1 : MAC-PARA Muse 3 Json Recup - Glider Name 2 : Json Recup - Glider Name 3 : Json Recup - Glider Name 4 : Glider Name : MAC-PARA Muse 3 Json Recup - Time Zone : 1 ****** Vario ******* Json Recup - VARIOMETER_SINKING_THRESHOLD : -2.00 Json Recup - VARIOMETER_CLIMBING_THRESHOLD : 0.20 Json Recup - NEAR_CLIMBING_SENSITIVITY : 0.50 Json Recup - ENABLE_NEAR_CLIMBING_ALARM : 0 Json Recup - ENABLE_NEAR_CLIMBING_BEEP : 0 Json Recup - DISPLAY_INTEGRATED_CLIMB_RATE : 0 Json Recup - RATIO_CLIMB_RATE : 2 Json Recup - CLIMB_PERIOD_COUNT : 10 Json Recup - SETTINGS_GLIDE_RATIO_PERIOD_COUNT : 20 Json Recup - RATIO_MAX_VALUE : 30.00 Json Recup - RATIO_MIN_SPEED : 10.00 Json Recup - VARIOMETER_ENABLE_AGL : 1 Defaut Recup - SENT_LXNAV_SENTENCE : 1 Json Recup - ACCELERATION_MEASURE_STANDARD_DEVIATION : 0.35 Json Recup - VARIOMETER_INTEGRATED_CLIMB_RATE : 0 Json Recup - SETTINGS_VARIO_PERIOD_COUNT : 5 Json Recup - BLUETOOTH_SEND_CALIBRATED_ALTITUDE : 0 ****** Flight start ******* Json Recup - FLIGHT_START_MIN_TIMESTAMP : 15000 Json Recup - FLIGHT_START_VARIO_LOW_THRESHOLD : -0.50 Json Recup - FLIGHT_START_VARIO_HIGH_THRESHOLD : 0.50 Json Recup - FLIGHT_START_MIN_SPEED : 8.00 Json Recup - RECORD_WHEN_FLIGHT_START : 1 Sauvegarde de nouveaux paramètres ****** SAUVEGARDE params.jso ******* ****** GnuvarioE ******* ****** Systeme ******* ****** General ******* ****** Vario ******* ****** Flight start ******* Pilot Name = Magali __dataPilotName = Magali - 6 / Magali - 6 __dataGliderName = MAC-PARA Muse 3 - 15 / MAC-PARA Muse 3 - 15
Lecture du fichier wifi.cfg Wifi SSID 1 : xxxxx Wifi Password 1 : xxxxx Wifi SSID 2 : your_SSID2 Wifi Password 2 : your_PASSWORD_for SSID2 Wifi SSID 3 : your_SSID3 Wifi Password 3 : your_PASSWORD_for SSID3 Wifi SSID 4 : your_SSID4 Wifi Password 4 : your_PASSWORD_for SSID4 TITRE_TIME : Heure
Lecture du fichier log.cfg log : Activé log Serial : Activé log SdCard : Activé log Debug : Activé VarioLog.cpp:283: tmpMessage = INFO - FirmWare : 0.8b3 VarioLog.cpp:241: msg = DEBUG - VarioData.cpp:329 - bool VarioData::initLog() No update file.
|
|
|
|
vmath54
Rampant
Hors ligne
Aile: planeur
pratique principale: autre (?)
vols: 100 vols
Messages: 1
|
|
« Répondre #2329 le: 28 Juin 2020 - 16:33:16 » |
|
Petite question qui n'a rien à voir avec mes soucis actuels : Le fichier params.jso proposé dans la sdcard par défaut contient entre autres, ceci : "COMPENSATION_TEMP": -6, "COMPENSATION_GPSALTI": -30, Est-ce volontaire d'avoir mis par défaut une valeur différente de zéro ?
Concernant l'utilité de ces paramètres : . je comprends qu'un capteur de température ait besoin d'être calibré. . pour le GPS : dans quel cas peut-il être nécessaire de compenser l'altitude GPS, de manière permanente ?
Je sais que le calcul d'altitude par GPS n'est pas précise ; mais est-ce qu'un capteur GPS peut faire une erreur systématique, permanente et de même valeur du calcul d'altitude ?
|
|
|
|
jpg63
Rampant
Hors ligne
Aile: Mac-Para ELAN
pratique principale: vol / site
vols: 500 vols
Messages: 0
|
|
« Répondre #2330 le: 28 Juin 2020 - 17:47:40 » |
|
Petite question qui n'a rien à voir avec mes soucis actuels : Le fichier params.jso proposé dans la sdcard par défaut contient entre autres, ceci : "COMPENSATION_TEMP": -6, "COMPENSATION_GPSALTI": -30, Est-ce volontaire d'avoir mis par défaut une valeur différente de zéro ?
Concernant l'utilité de ces paramètres : . je comprends qu'un capteur de température ait besoin d'être calibré. . pour le GPS : dans quel cas peut-il être nécessaire de compenser l'altitude GPS, de manière permanente ?
Je sais que le calcul d'altitude par GPS n'est pas précise ; mais est-ce qu'un capteur GPS peut faire une erreur systématique, permanente et de même valeur du calcul d'altitude ?
Les valeurs sont celles que j'avais dans mes fichiers, aucun problème pour les remettre à zero, les champs sont accessibles dans les paramètres wifi. Pour le GPS, cette compensation est la valeur corrigé via l'AGL, en appuyant 2sec sur le bouton gauche à partir du moment ou le GPS est fixé. Pour éviter d'avoir à refaire la calibration plusieurs fois dans la journée, la valeur est stockée dans les paramètres. Il est possible de la remettre à zero ou recalibrer le GPS via l'AGL (autant de fois que l'on le souhaite). Le GPS peut dans certain cas avoir plusieurs dizaines de mètres d'écart avec l'altitude réelle. L'erreur varie mais reste néanmoins constante sur une ou plusieurs journées et du lieu. Le GPS a une précision assez mauvaise en altitude par contre elle bonne en position (utilisée pour connaitre l'altitude sol - AGL)
|
|
|
|
vmath54
Rampant
Hors ligne
Aile: planeur
pratique principale: autre (?)
vols: 100 vols
Messages: 1
|
|
« Répondre #2331 le: 28 Juin 2020 - 19:33:05 » |
|
Merci jpg63 pour ces précisions.
Je n'avance pas dans la recherche de mon problème, et je vais être obligé de lacher pour une semaine. Je vous tiendrais informés dès que j'ai un peu de dispo
|
|
|
|
parazard
Rampant
Hors ligne
Aile: MCC Compact
pratique principale: autre (?)
vols: 120 vols
Messages: 0
|
|
« Répondre #2332 le: 29 Juin 2020 - 22:15:30 » |
|
Bonsoir ! Je suis un parapentiste qui n'a plus volé depuis de longues années (et j'hésite sérieusement à m'y remettre... ), avec une vie de famille bien remplie. Le reste du temps, je développe des appareils électroniques avec des radios et des GPS dedans. Je suis tombé sur ce joli projet, et je voulais apporter modestement ma contribution. Je peux peut-être partager quelques éclaircissements par rapport à la question posée sur l'altitude du GPS. Il y a deux types d'erreurs d'altitude. La première erreur est simplement le fait que le système est moins précis en altitude qu'en position (comme déjà mentionné plus haut) pour des raisons purement géométriques: les satellites sont essentiellement au-dessus du récepteur, et pour améliorer la précision il en faudrait aussi au-dessous... pas très réaliste. D'après cet article ( https://www.junipersys.com/support/article/6614 ), si la documentation du récepteur mentionne une précision en position de 5m (par exemple), la précision en altitude est souvent 1.7x plus grande (env 8.5m). Pour améliorer cette valeur, les seules possibilités sont de passer sur des récepteurs plus complexes. La deuxième erreur est liée au système de référence. Concrètement, un système de référence peut être imaginé comme une sorte d'ellipse en 3D qui représente le niveau de la mer tout autour du globe. WGS84 est un de ces systèmes, très utilisé par les GPS. Malheureusement, la terre n'est pas une ellipse parfaite, et il y a donc un décalage entre le 0m AMSL d'un endroit donné et le 0m donné par le WGS84 pour ce même endroit. Pour la ville de Grenoble par exemple, il y a une différence d'env. 51m. La bonne nouvelle est que ce décalage change très peu avec le temps (ok, c'est relatif...), change assez peu sur une distance de quelques centaines de km, et il peut se calculer. La page https://geographiclib.sourceforge.io/cgi-bin/GeoidEval permet de le faire. Une possibilité pourrait être d'intégrer dans le vario une librairie pour faire cette compensation, par exemple https://geographiclib.sourceforge.io/html/geoid.html . Le set de données le plus petit (600ko) permet de faire le calcul avec moins de 30cm d'erreur. Si je peux encore me permettre une petite info concernant les antennes: il est important qu'elles soient le plus éloignées possible de tout objet, et encore plus s'il est métallique, sous peine d'avoir des problèmes de portée (bluetooth/wifi) ou réception (GPS). Il est possible que l'antenne GPS fonctionne mieux si elle est au-dessus de l'écran que sur le côté. Encore bravo pour ce magnifique projet
|
|
|
|
Theduck38
Rampant
Hors ligne
Aile: BGD - Base
pratique principale: vol / site
vols: 970 vols
Messages: 0
|
|
« Répondre #2333 le: 01 Juillet 2020 - 17:22:58 » |
|
Hello,
Serait-il possible de compiler et de mettre à disposition de la MàJ OTA la dernière version du Firmware (0.8b3 si j'ai bien suivi...) ? Je suis en 0.8b2 et je n'ai aucune proposition de mise à jour via le Wifi.
Étant donné que la MàJ OTa à l'air de marcher pour moi, je n'ai pas forcément envie de reconfigurer / recompiler le code... j'avais eu quelques déboires la première fois.
@vmath54 : lorsque j'ai monté mon gnuvario, j'ai eu un pb de flash : l'utilitaire me disait Ok alors qu'il ne flashait pas. La solution : couper l'appareil pendant la compilation, et remettre sur ON juste au moment où on a les tentatives de connexion dans la fenêtre DOS.
|
TD38 Vole depuis 1993 Biplace - Initiateur
|
|
|
jpg63
Rampant
Hors ligne
Aile: Mac-Para ELAN
pratique principale: vol / site
vols: 500 vols
Messages: 0
|
|
« Répondre #2334 le: 01 Juillet 2020 - 18:08:49 » |
|
Hello,
Serait-il possible de compiler et de mettre à disposition de la MàJ OTA la dernière version du Firmware (0.8b3 si j'ai bien suivi...) ? Je suis en 0.8b2 et je n'ai aucune proposition de mise à jour via le Wifi.
Étant donné que la MàJ OTa à l'air de marcher pour moi, je n'ai pas forcément envie de reconfigurer / recompiler le code... j'avais eu quelques déboires la première fois.
Pas de soucis, je mettrai la version compilée sur le serveur "ressource" , dès que j'aurai un moment 1sec
|
|
|
|
Gali
Rampant
Hors ligne
Aile: orbea
pratique principale: apprends à voler
vols: 10 vols
Messages: 0
|
|
« Répondre #2335 le: 02 Juillet 2020 - 06:36:24 » |
|
Hello Idem pour moi, malgré l'assistance de Ratamuse pas moyen d'injecter la 0.8B3 vive l'OTA et encore bravo à la team gali
|
|
|
|
Philgab
Rampant
Hors ligne
Aile: ITV Jedi2
pratique principale: cross
vols: 500 vols
Messages: 0
|
|
« Répondre #2336 le: 02 Juillet 2020 - 10:52:55 » |
|
Après une dizaine de jours de vols et avoir croisé d'autre GNUvario-E j'ai repris mes tentatives de passage en version 8b3. Voler doit porter conseil car j'ai pu charger cette version en incluant BT et Wifi avec l'IDE Arduino qui indique 90% de remplissage mémoire En attendant de la tester en vol j'ai pu apprécier les pages de configuration et de gestion des vols J'ai un pb avec le BT : le GNUvario est bien identifié comme périphérique BT et appairé avec les tel que j'ai testés mais je n'arrive pas à l'associer avec Flyme ou XcSoar. Quel type de vario externe faut-il choisir et faut-il rester en trames LK8000 ? Quand je sors du menu Wifi le vario ne reconnait pas la carte SD et bippe comme si elle était absente, un on-off et ça repart normalement. Je crois qu'à partir de la 8b2 le vario ne reconnait plus le format des anciennes SD de moins de 2Go, celles qu'on utilise avec le GNUvario V1 ...
|
|
|
|
jpg63
Rampant
Hors ligne
Aile: Mac-Para ELAN
pratique principale: vol / site
vols: 500 vols
Messages: 0
|
|
« Répondre #2337 le: 03 Juillet 2020 - 21:40:14 » |
|
La mise à jour v0.8b3 en binaire est disponible
Bon vols
|
|
|
|
blinde
Rampant
Hors ligne
Aile: P25
pratique principale: vol / site
Messages: 0
|
|
« Répondre #2338 le: 04 Juillet 2020 - 16:30:03 » |
|
Hello
Merci pour la MAJ. Par contre je pense qu'il y a toujours le problème d'offset GPS qui n'est pas mis dans la trace. Le GPS affiche bien l'altitude corrigée, mais qd on recup la trace, on a l'altitude non corrigée. Ca peut poser un problème si on veut par ex déclarer un vol, avec une TMA a 2000, le GPS va afficher 2000m mais sur la trace on aura par ex 2050 alors qu'on a, a priori, respecté la TMA...
|
|
|
|
vmath54
Rampant
Hors ligne
Aile: planeur
pratique principale: autre (?)
vols: 100 vols
Messages: 1
|
|
« Répondre #2339 le: 04 Juillet 2020 - 17:24:51 » |
|
... @vmath54 : lorsque j'ai monté mon gnuvario, j'ai eu un pb de flash : l'utilitaire me disait Ok alors qu'il ne flashait pas. La solution : couper l'appareil pendant la compilation, et remettre sur ON juste au moment où on a les tentatives de connexion dans la fenêtre DOS.
Merci, je prends note vmath54 si le vario reste sur la page d'accueil c'est qu'il n'arrive pas à trouver l'altitude. Refait toutes tes soudures ...
Je confirme ton diagnostic : en activant du debug, la log au démarrage donne ceci : GNUVARIO compiled on Jul 4 2020 VERSION 0.8 Beta 3 Failed to read file TITRE_TIME : Heure No update file. Attente premiere mesure alti Et ca reste bloqué la-dessus. Ca correspond à une boucle infinie dans VarioImu.cpp, en attente de cette première mesure. Je ne suis pas entièrement novice en soudure, j'ai fait très attention, je suis quasi certain de ma manip. Mes soudures sont bonnes ; est-ce qu'on peut en déduire à 100% que le CJMCU est mort ? Il était neuf, mais je l'avais dans un tirroir depuis un bon moment (en fait, depuis le vario V1). Y a-t-il d'autres essais à faire avant de tenter de dessouder et ressouder un nouveau CJMCU ? Ca m'emm. bien, car c'est le 2eme vario qui déconne de la même manière. C'est un composant fragile ?
|
|
|
|
Theduck38
Rampant
Hors ligne
Aile: BGD - Base
pratique principale: vol / site
vols: 970 vols
Messages: 0
|
|
« Répondre #2340 le: 04 Juillet 2020 - 22:43:03 » |
|
La mise à jour v0.8b3 en binaire est disponible
Bon vols
Merci beaucoup, la MàJ est faite. En essayant brièvement, j'ai remarqué que le vario était capable d'afficher un cap à 388...
|
TD38 Vole depuis 1993 Biplace - Initiateur
|
|
|
Ratamuse
passager biplace
Hors ligne
Aile: HOOK 5
pratique principale: vol / site
vols: 170 vols
Messages: 0
|
|
« Répondre #2341 le: 05 Juillet 2020 - 10:07:31 » |
|
Bonjour à tous, Je viens de mettre à jour le site internet. Au programme, quelques améliorations concernant l'explication de l'organisation des écrans et des combinaisons de touches, l'ajout d'un onglet pour aller sur la page de téléchargement et un onglet pour accéder au site en anglais, également mis en ligne. Site Fr: https://prunkdump.github.io/GNUVario-TTGO-T5-website/Site En: https://prunkdump.github.io/GNUVario-TTGO-T5-website-EN/Bons vols
|
|
|
|
SaturdayWind
Rampant
Hors ligne
Aile: alpha6
pratique principale: vol / site
vols: 16 vols
Messages: 0
|
|
« Répondre #2342 le: 08 Juillet 2020 - 15:32:17 » |
|
J'ai fait une 15zaines de vols avec le vario pour 4-5 heures de vol. Je vais essayer de me faire la version plus compacte. Problèmes rencontrés: - il s'est bloqué 2-3 fois. A fait le R2D2 puis freezé. Apres redemarrage ça va - a du mal à s'arreter d'enregistrer après l'attero, donc il faut le couper - les G indiqués sont farfelus C'est mon apprentissage des thermiques, ça m'aide bien. Il est plus lisible qu'un Syride sinon
|
|
|
|
parazard
Rampant
Hors ligne
Aile: MCC Compact
pratique principale: autre (?)
vols: 120 vols
Messages: 0
|
|
« Répondre #2343 le: 11 Juillet 2020 - 19:37:27 » |
|
Je ne suis pas entièrement novice en soudure, j'ai fait très attention, je suis quasi certain de ma manip. Mes soudures sont bonnes ; est-ce qu'on peut en déduire à 100% que le CJMCU est mort ? Il était neuf, mais je l'avais dans un tirroir depuis un bon moment (en fait, depuis le vario V1). Y a-t-il d'autres essais à faire avant de tenter de dessouder et ressouder un nouveau CJMCU ? Ca m'emm. bien, car c'est le 2eme vario qui déconne de la même manière.
C'est un composant fragile ?
Je ne pense pas qu'il soit plus fragile qu'un autre. L'électronique est sensible à l'électricité statique, il faut faire attention à ça. Difficile de conclure que le CJMCU est mort. Est-ce qu'il a fonctionné un moment ? Et celui de l'autre vario? C'est difficile de dépanner sans un minimum d'équippement... et idéalement un oscilloscope. As-tu quelque chose du genre ? Ou peut-être un multimètre déjà?
|
|
|
|
vmath54
Rampant
Hors ligne
Aile: planeur
pratique principale: autre (?)
vols: 100 vols
Messages: 1
|
|
« Répondre #2344 le: 11 Juillet 2020 - 22:03:17 » |
|
Je ne pense pas qu'il soit plus fragile qu'un autre. L'électronique est sensible à l'électricité statique, il faut faire attention à ça.
Difficile de conclure que le CJMCU est mort. Est-ce qu'il a fonctionné un moment ? Et celui de l'autre vario?
C'est difficile de dépanner sans un minimum d'équippement... et idéalement un oscilloscope. As-tu quelque chose du genre ? Ou peut-être un multimètre déjà?
Bonjour, Merci de ta réponse. En fait, j'avais un peu laissé tomber, en attendant les 2 CJMCU commandés chez aliexpress. Et depuis 2 jours, j'avais un peu de temps, et je me suis dit que ca pourait être intéressant de voir ce qui vit encore dans mes 2 varios. J'ai commencé par un 'i2c_scanner'. On en a un exemple dans le test-code du github, et pas mal d'autres exemples sur le web ; mais rien de directement opérationnel pour le GNUVario. J'en ai modifié un pour l'adapter au GNUVario-E ; je le joins à ce post. L'adaptation consiste à configurer les pins adéquats pour la communication i2c (ce ne sont pas ceux par défaut), et, par programmation, alimenter électriquement le CJMCU et le module GPS : le 'design' du PCB du GNUVario fait que l'alimentation de ces 2 modules est pilotée par programmation, pour permettre un mode veille efficace. Premier résultat, qui date de ce soir : - pour mon dernier vario, celui de mon dernier post : i2c_scanner ne trouve aucun device. Si je mesure au multimètre, le module MCU est bien alimenté en 4.8V entre GND et VCC lorsque le squetch fonctionne. Par ailleurs, la led du module GPS s'allume, ce qui signifie que ce module est bien alimenté électriquement. - pour le vario précédent, qui avait des faiblesses également coté MCU mais fonctionnait 'à peu près', c'est mieux. i2c_scanne sort ceci : I2C scanner. Scanning ... I2C device found at address: 104 (0x68) I2C device found at address: 119 (0x77) Found 2 device(s).
Pour répondre plus précisément à tes interrogations : - le CJMCU que j'ai soudé sur le vario a été acheté il y a environ 2 ans, au moment du vario version 1. Je l'avais conservé dans une petite caisse, dans son emballage électro-statique. Mais je n'ai pas prise de précautions particulières lors de la manipulation ou de la soudure. Et il n'a jamais fonctionné - celui de l'autre vario a toujours fonctionné, ... à peu près. Il donne, avec le code du GNUVario, des indications pas toujours fiables. En débug, fréquemment, il y avait un bnlocage sur le message 'first altitude' J'ai un multimètre et je sais m'en servir. J'ai deux équipements de genre oscilloscope à brancher sur PC via USB ; j'ai juste fais qqs essais après acquisition, jamais en utilisation réelle : - un oscillo owon VDS1022I - un analyseur logique comme celui-ci : https://fr.aliexpress.com/item/32613420798.html fonctionne avec le logiciel salaea Pour mon dernier vario : - comme indiqué précédemment, il est bien alimenté électriquement. - j'ai également vérifié à l'ohmmetre qu'il y a continuité entre les broches SDA et SCL du TTGO et du MCU. Bref, le MCU semble bien mort Pour le vario précédent, j'ai l'intention de faire des vérifications de fonctionnement basiques de chaque module, avec des libraries simples. Je m'attends à ce que tout fonctionne. Je soupconne depuis le début que certains composants soient un petit peu 'hors norme' relativement au GNUvario.
|
|
|
|
parazard
Rampant
Hors ligne
Aile: MCC Compact
pratique principale: autre (?)
vols: 120 vols
Messages: 0
|
|
« Répondre #2345 le: 11 Juillet 2020 - 22:40:45 » |
|
J'ai un multimètre et je sais m'en servir. J'ai deux équipements de genre oscilloscope à brancher sur PC via USB ; j'ai juste fais qqs essais après acquisition, jamais en utilisation réelle : - un oscillo owon VDS1022I - un analyseur logique comme celui-ci : https://fr.aliexpress.com/item/32613420798.html fonctionne avec le logiciel salaea Tu es bien équipé! C'est une bonne idée d'avoir un i2c_scanner adapté au gnuvario. Pourrais-tu faire une acquisition des deux signaux SDA et SCL du CJMU pendant que le logiciel du GNUvario fonctionne (pas le i2c_scanner cette fois) ? Le but est de voir déjà si ces signaux bougent, ensuite de voir si leur niveaux haut et bas ont la bonne tension, et enfin de voir s'ils sont assez rapides. Une autre mesure qui pourrait être utile c'est de configurer les pins en mode i2c, mais sans les faire bouger (pas de communication) et de mesurer leur tension avec un multimètre (plus précis qu'un oscilloscope). Elles devraient se trouver aux alentours de 3.3V.
|
|
|
|
Franck63
Rampant
Hors ligne
Aile: Delta3
pratique principale: vol / site
vols: 300 vols
Messages: 0
|
|
« Répondre #2346 le: 15 Juillet 2020 - 15:00:06 » |
|
Bonjour à tous, je suis en train de tester ce gnu vario et j'ai un soucis lors de la calibration : lorsque je lance le calibration.py il recherche un fichier "numpy" que biensur je n'ai pas ... est ce que cela parle a qqun? Merci d'avance de votre aide Sportivement Franck
|
|
|
|
vmath54
Rampant
Hors ligne
Aile: planeur
pratique principale: autre (?)
vols: 100 vols
Messages: 1
|
|
« Répondre #2347 le: 15 Juillet 2020 - 15:23:26 » |
|
... Pourrais-tu faire une acquisition des deux signaux SDA et SCL du CJMU pendant que le logiciel du GNUvario fonctionne (pas le i2c_scanner cette fois) ? Le but est de voir déjà si ces signaux bougent, ensuite de voir si leur niveaux haut et bas ont la bonne tension, et enfin de voir s'ils sont assez rapides. Une autre mesure qui pourrait être utile c'est de configurer les pins en mode i2c, mais sans les faire bouger (pas de communication) et de mesurer leur tension avec un multimètre (plus précis qu'un oscilloscope). Elles devraient se trouver aux alentours de 3.3V.
D'abord, merci à @Ratamuse d'avoir prévu des 'test points' pour débugger le bus I2C ; ca simplifie l'opération/ Pour le plus facile : la mesure de tension sur SDA et SCL : C'est OK. 3.36V si je prends le GND directement sur le TTGO, 3.33V si je prends sur le CJMCU (donc via le transistor). Pour la partie I2C : j'ai un peu tardé, car je voulais auparavant prendre en main l'analyseur logique (l'oscillo n'est pas très adapté pour ce type de mesures), et tester sur un matérie lqui fonctionne. Je dispose dans un petit coin d'un weemos D1, et d'un capteur de pression ms5611 ; je me suis fait la main dessus. Et j'ai développé un petit sketch qui récupère toutes les 2 secondes la température et la pression de ce capteur (inclus également dans le CJMCU), en utilisant les librairies proposée de base dans l'IDe Arduino. Conclusion : comme je m'y attendais, le TTGO envoie bien une première requete I2C au CJMCU à l'adresse 0x77 (MS5611), tout à fait conforme, mais celui-ci n'accuse jamais réception. Le résultat du sketch donne ceci : Error in read: 2. received NACK on transmit of address Error in read: 2. received NACK on transmit of address ... au lieu de : T: 25.64 P: 989.22 T: 25.66 P: 989.26 ... Donc, je suis quasiment certain que le CJMCU est mort. Mon autre vario, un peu 'bancal', retourne de bonnes valeurs. Je joins le sketch utilisé pour ces tests, et des copies d'écran de l'analyseur logique : i2c_OK.png : une analyse qui se passe bien i2c_NOK.png : l'analyse avec ce vario HS J'ai l'intention de me faire quelques sketchs basiques, avec le minimum de librairies, pour tester les éléments du vario de manière individuelle. Merci de m'avoir titillé, ca m'a permis de mettre un peu les mains dans le cambouis
|
|
|
|
vmath54
Rampant
Hors ligne
Aile: planeur
pratique principale: autre (?)
vols: 100 vols
Messages: 1
|
|
« Répondre #2348 le: 15 Juillet 2020 - 15:24:41 » |
|
les autres copies d'écran (quand ca va bien)
|
|
|
|
vmath54
Rampant
Hors ligne
Aile: planeur
pratique principale: autre (?)
vols: 100 vols
Messages: 1
|
|
« Répondre #2349 le: 15 Juillet 2020 - 15:56:49 » |
|
Bonjour à tous, je suis en train de tester ce gnu vario et j'ai un soucis lors de la calibration : lorsque je lance le calibration.py il recherche un fichier "numpy" que biensur je n'ai pas ... est ce que cela parle a qqun? Merci d'avance de votre aide Sportivement Franck
Il faudrait que tu installes la librairie python numpy Normalement, ca se fait avec la commande :
|
|
|
|
|