DIY GnuVario : variomètre opensource - openhardware Arduino

[vmath54]

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]

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]

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 :

Code:

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]

Et avec la sdcard insérée, ca donne ceci :

Code:

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]

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]

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]

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]

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]

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.

[jpg63]

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]

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]

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]

La mise à jour v0.8b3 en binaire est disponible

Bon vols

[blinde]

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]

...
@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]

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...

[Ratamuse]

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]

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]

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]

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 :

Code:

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]

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]

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]

...
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]

les autres copies d'écran (quand ca va bien)

[vmath54]

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 :

Code:

pip install numpy