DIY GnuVario : variomètre opensource - openhardware Arduino

[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

Il faudrait que tu installes la librairie python numpy

Normalement, ca se fait avec la commande :

Code:

pip install numpy

ok merci je regarde ca !!

[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

Il faudrait que tu installes la librairie python numpy

Normalement, ca se fait avec la commande :

Code:

pip install numpy

ok merci je regarde ca !!

Super ca a marché!! 
Merci !

[parazard]

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.

L'analyseur logique est l'instrument à utiliser pour décoder le contenu de la transmission (i2c ou autre), et effectivement l'un des CJMCU ne répond pas.

L'oscillo permet de vérifier les niveaux haut et bas. L'i2c est un bus en collecteur ouvert, donc le niveau "1" est fait par des résistances, et le niveau "0" est fait par les composants qui communiquent dessus. Parfois, quand le bus va trop vite ou le bus a trop de capacité, le signal "monte mou" et n'atteint pas le niveau requis pour un "1". Tu peux en voir un exemple ici: https://www.silabs.com/community/mcu/8-bit/knowledge-base.entry.html/2016/08/31/smbus_i2c_communicat-uMzm
Quand un composant fonctionne par intermittence (comme pour ton vario un peu bancal), on peut soupçonner ce genre de problèmes, qu'il est quasiment impossible à voir sans oscilloscope. Tu peux faire l'essai pour voir

[jpg63]

Je viens de mettre sur le github officiel les binaires des dernières version jusqu'à la v0.7b8. Ceci pourra permettre à certain de faire des essais avec des versions précédentes

J'ai aussi commencer à faire des mini codes pour tester chaque élément matériel. Vous pourrez trouver les tests du bis I2C, du baromètre (MS5611) et du MPU (Magnétomètres, accéléromètres et gyroscopes). Je rajouterai un code de test pour le GPS et la SD. Vous trouverai les codes et le binaire.

Nous travaillons sur plusieurs choses :

- une nouvelle librairie pour le site web embarqué
- la publication automatique des traces sur paragliding log book
- une nouvelle carte intégrant le GPS et le MS5611/MPU, il ne resterai qu'à souder la TTGO. Cette nouvelle carte rentrera dans un boitier plus petit
- l’amélioration du son et son paramétrage (xctracer simulateur)
- des mini codes de test pour le matériel

Nous allons bientôt pouvoir vous proposer les boîtiers avec un nouveau design des boutons 

[jpg63]

Je viens de mettre sur le github officiel et sur le site de ressources, l'ensemble des codes permettant de tester individuellement chaque composant.

Si vous avez un doute sur le fonctionnement de votre vario vous pourrez tester :

- l'écran
- la SDcard
- le GPS,
- le MS5611 (barometre)
- le MPU9250 (accel, gyro, mageto)
- et le son

Il ne sera pas nécessaire de compiler les codes, j'ai ajouter les binaires

[olitask]

Bonjour à tous

Pas de vacances pour le gnuVario !        

Je n'ai pas spécialement de problème avec mon e-vario, mais j'ai du mal à le "régler" . En effet, je le trouve trop sensible.
Lors de mes derniers vols,   je n'avais pas rechargé celui ci et j'ai repris mon ancien gnuvario sur lequel l’accéléromètre est désactivé dans le code( car en panne physique) et c’était plus agréable à l'oreille.

Ma question: Comment désactiver l'accéléromètre ( ou au moins minimiser sa sensibilité) dans la partie réglage du site embarqué ?   ( je n'ai pas trop envie de recompiler)

[vmath54]

Je viens de mettre sur le github officiel et sur le site de ressources, l'ensemble des codes permettant de tester individuellement chaque composant.
...

Super. Merci 

[Ratamuse]

Salut,

Pour la rentrée, j'espère pouvoir proposer une carte plus petite, intégrant le baro/gyro et le GPS. Elle est en cours de fabrication et si cela fonctionne bien, on la mettra sur le site. Le boitier en photo est pour un écran 2.9", il fait la taille du 1.54" mais sans les oreilles (115x53mm). Pour un écran 1.54" ça ferait un boitier de 85x53mm.

 Merci à tout ceux qui m'ont envoyé un complément paypal lorsque j'ai envoyé des PCB/boitiers, cela me permet de ne pas assumer seul les coûts. Coté tarif, au final, ça reviendra à peine plus cher que de mettre le module GPS et CJMCU117. On peux juste espérer plus de fiabilité (surtout pour le CJMCU117 car il y a de toute évidence pas mal de produits foireux).

L'étape suivante est une carte complète. Elle est pratiquement finalisée. Par contre, elle reviendra plus chère et tant que la TTGO T5 sera en vente, ce n'est pas forcément la bonne option pour les petits budgets (dans les 120€ la carte, écran compris).
Bons vols 

[vmath54]

Bravo !!! J'aime bien ce boitier tout simple.

Je confirme le manque de fiabilité du CJMCU : en attendant la livraison des 2 modules que j'ai commandé, j'en ai ressorti un de mes tiroirs, jamais utilisé, acheté au moment du vario V1 ; donc il y a environ 2 ans. En fait, il fait partie du même lot que celui qui s'est révélé défectueux dans mon vario précédent.

Avant de le souder sur le PCB du vario, je l'ai testé 'en volant', avec un weemos D1, puis un ESP32 de développement.
Verdict : un i2cscan révèle que le device 0x77 (MS5611) répond systématiquement ; par contre, le device Ox68 (MPU9250) répond de temps en temps.
J'ai bien mis les résistances de 4.7k de pullup sur SDA et SCL.
Ca se confirme avec des sketchs de test : le capteur de pression fonctionne très bien, les capteurs du MPU (accéléromètre, gyroscope, magnétomètre) ne fonctionnent pas.

Bref, lors de la réception des deux CJMCU commandés, je ferais des tests avant de souder sur le PCB du vario ...

[parazard]

Super, une version encore plus petite 

Attention: l'antenne du GPS est faite pour que la partie métallisée soit face au ciel, donc perpendiculaire au PCB. Comme elle est montée actuellement, tu risques d'avoir une dégradation de performances. Egalement, si tu peux, essaie de laisser au moins 5mm sans rien (surtout pas de cuivre!) tout autour de l'antenne wifi/bluetooth.

Si tu le souhaites, je jette volontiers un coup d'oeil au schéma avant de réaliser la carte.

Verdict : un i2cscan révèle que le device 0x77 (MS5611) répond systématiquement ; par contre, le device Ox68 (MPU9250) répond de temps en temps.
J'ai bien mis les résistances de 4.7k de pullup sur SDA et SCL.

C'est vraiment bizarre ça. Ca indique qu'un composant est très près de sa limite de fonctionnement. Est-ce qu'en baissant la fréquence du bus I2C tu vois une amélioration ? Et je reste très curieux de voir à quoi ressemblent les signaux à l'oscilloscope si jamais tu as un moment ...

[Ratamuse]

Super, une version encore plus petite 

Attention: l'antenne du GPS est faite pour que la partie métallisée soit face au ciel, donc perpendiculaire au PCB. Comme elle est montée actuellement, tu risques d'avoir une dégradation de performances. Egalement, si tu peux, essaie de laisser au moins 5mm sans rien (surtout pas de cuivre!) tout autour de l'antenne wifi/bluetooth.

Si tu le souhaites, je jette volontiers un coup d'oeil au schéma avant de réaliser la carte.

Verdict : un i2cscan révèle que le device 0x77 (MS5611) répond systématiquement ; par contre, le device Ox68 (MPU9250) répond de temps en temps.
J'ai bien mis les résistances de 4.7k de pullup sur SDA et SCL.

C'est vraiment bizarre ça. Ca indique qu'un composant est très près de sa limite de fonctionnement. Est-ce qu'en baissant la fréquence du bus I2C tu vois une amélioration ? Et je reste très curieux de voir à quoi ressemblent les signaux à l'oscilloscope si jamais tu as un moment ...

Je t ai envoyé un mail privé

[vmath54]

Verdict : un i2cscan révèle que le device 0x77 (MS5611) répond systématiquement ; par contre, le device Ox68 (MPU9250) répond de temps en temps.
J'ai bien mis les résistances de 4.7k de pullup sur SDA et SCL.

C'est vraiment bizarre ça. Ca indique qu'un composant est très près de sa limite de fonctionnement. Est-ce qu'en baissant la fréquence du bus I2C tu vois une amélioration ? Et je reste très curieux de voir à quoi ressemblent les signaux à l'oscilloscope si jamais tu as un moment ...

Pas possible pour le moment : 4 enfants à la maison pour les vacances, de 2 à 11ans, et mon labo de test est la table de la salle à manger....

[ArthurM]

Bonjour à tous,

Je viens de découvrir ce magnifique projet, je cherchais sans trop y croire un vario open source bien développé, le résultat est bien au delà de mes espérances! Bravo!

Pour la rentrée, j'espère pouvoir proposer une carte plus petite, intégrant le baro/gyro et le GPS. Elle est en cours de fabrication et si cela fonctionne bien, on la mettra sur le site. Le boitier en photo est pour un écran 2.9", il fait la taille du 1.54" mais sans les oreilles (115x53mm). Pour un écran 1.54" ça ferait un boitier de 85x53mm.

Du coup je serai bien intéressé par un kit PCB/boitier en 2.9" si jamais tu en lances en fabrication! Je ne sais pas comment vous vous organisez d'habitude?

En tout cas merci pour cette belle motivation!

Arthur

[parazard]

Pas possible pour le moment : 4 enfants à la maison pour les vacances, de 2 à 11ans, et mon labo de test est la table de la salle à manger....

En effet, bien occupé! Pas de souci

[Ratamuse]

Bonjour à tous,

Je viens de découvrir ce magnifique projet, je cherchais sans trop y croire un vario open source bien développé, le résultat est bien au delà de mes espérances! Bravo!

Pour la rentrée, j'espère pouvoir proposer une carte plus petite, intégrant le baro/gyro et le GPS. Elle est en cours de fabrication et si cela fonctionne bien, on la mettra sur le site. Le boitier en photo est pour un écran 2.9", il fait la taille du 1.54" mais sans les oreilles (115x53mm). Pour un écran 1.54" ça ferait un boitier de 85x53mm.

Du coup je serai bien intéressé par un kit PCB/boitier en 2.9" si jamais tu en lances en fabrication! Je ne sais pas comment vous vous organisez d'habitude?

En tout cas merci pour cette belle motivation!

Arthur

Salut,

Je ne pense pas... commander et envoyer une carte avec un transistor et 2 resistances est une chose. Envoyer des cartes un peu plus fournies en est une autre. Je ne veux pas en faire commerce, donc pas de benef hormis des donations pour ceux qui le souhaitent. Mais à une trentaine d'euros la carte, si il y a un problème de composant, il serait bien légitime de demander une "garantie". Et la, ce n'est pas gérable financièrement.
La meilleure solution et de se regrouper entre copains volants pour faire 5 cartes. (ou plus) Après, il est possible de faire 5 PCB et ne faire monter qu'une carte. Mais ça revient un peu plus cher par carte, 30€ au lieu de 6€.
Il y a peut être des solutions, je ne sais pas comment tournent d'autres projets, quelqu'un à peut être des idées.

A+

[vmath54]

Bonjour,

Une petite question concernant le schéma du PCB V2.1 : https://github.com/prunkdump/GNUVario-TTGO-T5/blob/master/PCB/Printing%20Impression%20Sch%C3%A9matique.pdf

Elle concerne le cablage du CJMCU-117, en particulier les pins NCS et PS qui sont juste reliées entre-elles ; dans d'autres projets utilisant ce composant, elles sont également reliées au +3.3V

Est-ce normal que ce ne soit pas le cas ici ? Je suppose que oui, mais je n'arrive pas à trouver le schéma de ce CJMCU-117.
La broche PS est certainement celle du MPU 9250 : Protocol Select ; par défaut à I2C.
Je n'ai pas trouvé le role de la broche NCS. Vu le nom, je verrais bien un 'Chip Select' SPI ; dans ce cas, je ne vois pas l'intéret de les boucler ...

[Ratamuse]

Bonjour,

Une petite question concernant le schéma du PCB V2.1 : https://github.com/prunkdump/GNUVario-TTGO-T5/blob/master/PCB/Printing%20Impression%20Sch%C3%A9matique.pdf

Elle concerne le cablage du CJMCU-117, en particulier les pins NCS et PS qui sont juste reliées entre-elles ; dans d'autres projets utilisant ce composant, elles sont également reliées au +3.3V

Est-ce normal que ce ne soit pas le cas ici ? Je suppose que oui, mais je n'arrive pas à trouver le schéma de ce CJMCU-117.
La broche PS est certainement celle du MPU 9250 : Protocol Select ; par défaut à I2C.
Je n'ai pas trouvé le role de la broche NCS. Vu le nom, je verrais bien un 'Chip Select' SPI ; dans ce cas, je ne vois pas l'intéret de les boucler ...

Bonsoir,

Sur la CJMCU, la pin PS permet de choisir entre le protocol I2C (VCC) ou SPI (Gnd) du MS5611. Par défaut elle est en niveau haut (sur VCC via une resistance) donc I2C.
La pin nCS est le chip select du MPU9250. En mode I2C, ils indiquent sur la datasheet de la mettre à VCC (VDDIO) en mode I2C. Donc en fait elle est mise à VCC par l'intermédiaire de la pin PS.
Donc elles sont bien reliées au 3.3V mais le 3.3V du module.

https://invensense.tdk.com/wp-content/uploads/2015/02/PS-MPU-9250A-01-v1.1.pdf
https://www.te.com/commerce/DocumentDelivery/DDEController?Action=showdoc&DocId=Data+Sheet%7FMS5611-01BA03%7FB3%7Fpdf%7FEnglish%7FENG_DS_MS5611-01BA03_B3.pdf%7FCAT-BLPS0036

A+

[vmath54]

Merci, @ratamuse, pour la réponse ; c'est clair.

Je comprends mieux la logique. Je suppose également que tout ceci a été fait pour permettre de pouvoir couper la consommation d'énergie du CJMCU lorsque le soft le commande (transistor T1 qui commande l'alimentation globale du CJMCU).

Je n'ai pas trouvé le schéma du CJMCU-117 ; si quelqu'un le trouve, je suis preneur.

A +

[jpg63]

bonsoir à tous,

avant de partir en vacances, je viens de publier une version v0.8b3 mineure sur mon github. Cette version corrige quelques petits bugs et ajoute la capacité de la batterie et la tension sur l'écran de démarrage

https://github.com/jpg63/Gnuvario_for_TTGO-T5/tree/master/Sources/Beta%20Code/v0.8b3

[ArthurM]

Bonjour à tous,

Je viens de découvrir ce magnifique projet, je cherchais sans trop y croire un vario open source bien développé, le résultat est bien au delà de mes espérances! Bravo!

Pour la rentrée, j'espère pouvoir proposer une carte plus petite, intégrant le baro/gyro et le GPS. Elle est en cours de fabrication et si cela fonctionne bien, on la mettra sur le site. Le boitier en photo est pour un écran 2.9", il fait la taille du 1.54" mais sans les oreilles (115x53mm). Pour un écran 1.54" ça ferait un boitier de 85x53mm.

Du coup je serai bien intéressé par un kit PCB/boitier en 2.9" si jamais tu en lances en fabrication! Je ne sais pas comment vous vous organisez d'habitude?

En tout cas merci pour cette belle motivation!

Arthur

Salut,

Je ne pense pas... commander et envoyer une carte avec un transistor et 2 resistances est une chose. Envoyer des cartes un peu plus fournies en est une autre. Je ne veux pas en faire commerce, donc pas de benef hormis des donations pour ceux qui le souhaitent. Mais à une trentaine d'euros la carte, si il y a un problème de composant, il serait bien légitime de demander une "garantie". Et la, ce n'est pas gérable financièrement.
La meilleure solution et de se regrouper entre copains volants pour faire 5 cartes. (ou plus) Après, il est possible de faire 5 PCB et ne faire monter qu'une carte. Mais ça revient un peu plus cher par carte, 30€ au lieu de 6€.
Il y a peut être des solutions, je ne sais pas comment tournent d'autres projets, quelqu'un à peut être des idées.

A+

Salut,

Je pensais plutôt à l'achat de PCB groupées et de boitiers imprimés 3D, n'ayant pas d'imprimantes... Je suis familier de l'électronique et de l'open source donc je connais le concept . Mais du coup j'ai commandé de mon côté de quoi faire un 2.9 en version actuelle, et on verra pour la prochaine mouture!

A+

[vmath54]

...

Verdict : un i2cscan révèle que le device 0x77 (MS5611) répond systématiquement ; par contre, le device Ox68 (MPU9250) répond de temps en temps.
J'ai bien mis les résistances de 4.7k de pullup sur SDA et SCL.

C'est vraiment bizarre ça. Ca indique qu'un composant est très près de sa limite de fonctionnement. Est-ce qu'en baissant la fréquence du bus I2C tu vois une amélioration ? Et je reste très curieux de voir à quoi ressemblent les signaux à l'oscilloscope si jamais tu as un moment ...

Bon, après quelques échanges en MP avec Ratamuse :
- je suis certain que le CJMCU que j'avais soudé sur le PCB du gnuvario était HS ; je l'ai remplacé.
- pour les essais sur une planche et un esp32 de dev : je n'avais pas ponté les pins PS et NCS, et je n'avais pas mis la pin ADO à la masse.
  une fois qu'on a fait cela, ca marche.
 
Je me suis quand même 'amusé' à tracer les signaux I2C sur le gnuvario avec mon oscillo USB OWON ; j'ai également été aidé par Ratamuse pour cela.
Je joins cette trace (CH1 rouge est SCL, CH2 jaune est SDA).
Quelques mesures :
  . VCC exactement à 3.3V
  . fréquence à 368 kHz
  . THigh à 1.280 µs
  . TLow à 1.280 µs
 
Ces traces sont similaires à celles que Ratamuse a faites chez lui, à l'exception des fronts descendants sur SDA qui génèrent un pic de -0.84V, ce qui n'apparait pas sur ses traces.

Pour le moment, je n'ai fait tourné mon gnuvario qu'avec le test MPU ; je vais enfin tester avec le code natif 

[Jo Seph]

Salut à tous,

Je découvre ce vario qui a l'aire bien sympas.

En attendant de commander un ESP32 avec un écran Noir et Blanc, Est ce que certain ont testés le vario avec un  TTGO-T5 3 couleurs (Noir/Blanc/Rouge)?

Comme j'en ai un sous la main, j'ai testé mais à l'initialisation le vario reste bloqué sur la commande "  ESP_LOGI(TAG, "Display Boot");" sans rien afficher à l'écran.
J'ai re-testé en modifiant  la librairie "GxEPD2_boards.h" pour avoir l'écran 3 couleurs "GxEPD2_3C<GxEPD2_290c" sans plus de résultats.

 Joseph

[Ratamuse]

Bonjour Joseph,

Le problème vient du temps de rafraichissement de l'écran. Avec un noir et blanc 2.9" le full refresh prend 2s et le partial 0.3s. L'écran est donc fluide. Par contre pour un écran 3 couleurs, le temps de rafraîchissement monte à 15s.Je n'ai pas vu la possibilité du partial refresh, il faudrait creuser la doc. Bref, un écran 3 couleurs n'est pas gagné.

A+

[Ratamuse]

Bonjour Joseph,

Le problème vient du temps de rafraichissement de l'écran. Avec un noir et blanc 2.9" le full refresh prend 2s et le partial 0.3s. L'écran est donc fluide. Par contre pour un écran 3 couleurs, le temps de rafraîchissement monte à 15s.Je n'ai pas vu la possibilité du partial refresh, il faudrait creuser la doc. Bref, un écran 3 couleurs n'est pas gagné.

A+

Salut,

J'ai également oublié de mentionner que selon le type d'écran, une résistance change sur le circuit de gestion de l'epaper. 3ohms ou 0,47ohms entre la pin RESE et la masse. Sur les plans de la TTGO T5 V2.4, cette résistance est à 0.47ohm. Sans possibilité de changer comme sur les petites cartes de demo. Je suppose que sur les TTGO vendues avec les ecrans couleurs ou souples, cette resistance est à 3ohms. Bref, entre Good display et Waveshare, il faut faire attention quand on achète un écran.
Et d'après les infos sur le site de waveshare, seul les écrans noir et blanc supportent le partial refresh, et encore pas tous.
Pour les resistances, ce site donne quelques exemples (en anglais) https://www.crystalfontz.com/blog/why-does-my-epaper-display-not-work-with-my-epaper-adapter-board/

A+

[Jo Seph]

Bonjour Ratamuse,

Merci pour toute ces infos,

Je vais me trouver une carte avec un écran noir et blanc en 2.9", ça me semble plus simple pour commencer à tester ce vario.
Je vais garder l'écran 3 couleur pour de futur projet.

joseph