DIY GnuVario : variomètre opensource - openhardware Arduino

Bonsoir à tous

J’ai ( enfin…) pensé à enregistrer le bruit parasite de mon vario. Il se déclenche quand on est en phase ascendante uniquement. Pour le reste, il fonctionne bien. ( voir pièce jointe )

Sinon, en dehors du vario, mais toujours dans l’électronique, que pensez vous de réaliser une balise météo ? De retour de l’AG de mon club, j’ai appris que les balises FFVL qui sont tombées en panne ( après 4 ans pour l’une et une semaine pour l’autre -foudre !) ne seraient pas remplacées ni réparées. La boite les ayant vendues n’existant plus ou refusant de donner les plans. Par ailleurs, on avait voté le budget pour deux pioupious , mais ça fait un plus d’un an que la livraison se fait attendre.

Est ce qu’un ensemble comme ci dessous serait envisageable ?

arduino, + module GPRS/GSM + abonnement free à 2€/mois + batterie rechargeable solaire + anémomètre https://fr.aliexpress.com/item/1PCS-X-Wind-speed-sensor-signal-4-20MA-0-5V-output-wind-speed-transmitter-anemometer/32668695668.html?spm=a2g0w.10010108.1000014.3.1eb75b1eTotSPM&traffic_analysisId=recommend_3035_null_null_null&scm=1007.13338.80878.000000000000000&pvid=a0d86500-974b-4ed5-abb2-fe62091010d1&tpp=1

Bonnes fêtes à tous Olivier

Bonsoir,

Même tac pour moi :lol:

Bin je suis bien embêté … :grat:

J’ai beau tester des configurations différentes je n’arrive pas à repoduire ce “Tac” :? Pourtant sur la bande son de Olitask on l’entend parfaitement. Merci pour avoir pris le temps de faire l’enregistrement :pouce: On entend bien que le Tac est en début de son sur à peu prêt toutes les fréquences.

Est-ce que vous pouvez m’envoyer vos VarioSetting.h ? Ou tester avec les firmwares en pièce jointe si le problème est toujours présent ? Il doit bien y avoir une explication puisque cela touche plusieurs personnes :shock:

L’idée d’Olivier pour les balises météo est excellente ! Il faut pas hésiter à se lancer. Je suis partant pour donner un coup de main :+1:

J’avais pensé aussi bosser sur un stabilisateur de caméra. Vu qu’on commence à maitriser le MPU et que c’est un gadget par mal utilisé en parapente.

@vmath54 j’ai vu que sur le projet OpenVario il ont fabriqué un module indépendant sur lequel il faut brancher les sondes du planeur :

https://www.openvario.org/doku.php?id=projects:series_00:mechanics

Après comment ils ajustent ça au cockpit :shock:

Fabriquer tout ça me semble quand même super technique.

https://www.openvario.org/lib/exe/fetch.php?media=projects:series_00:ov_asw24.jpg

A+

Ce type d’équipement est intéressant pour une personne propriétaire de son planeur.

Et oui, pour intégrer cet écran openvario dans un tableau de bord, ce n’est pas simple. En pratique, il faut refaire complètement ce tableau de bord, pour pouvoir y loger tous les instruments.
Au fait, le soft qui permet le rendu d’openvario est XCSoar

Bonjour à tous

J’ai flashé le firm.hex (v2) fourni dans le post précédent et le bruit parasite n’est plus présent. J’ai ensuite re-téléchargé le github de JPG63 et écrasé les anciens fichiers et les librairies, reflashé et la le bruit parasite est réapparu ! Mais comme j’aime bien la fonction mute …

Voilà pour les retours.

Salut,

comme mon code est basé sur celui de Punkdump, on va trouver pourquoi on a ce bruit parasite. Les différences de code sont principalement sur l’affichage.

Prunkdump tu pourrais m’envoyer le code et les bibliothèques de ton programme de test

Salut !

Bin j’ai utilisé le code de la branche master :?

Ça peut aussi être un problème de compilation …

je vais faire des tests plus attentif sur le miens, mais j’avoue que je n’ai pas attention à ce bruit

je vous tiens au courant

Bonsoir

Le fichier FIRM posté avant hier par Prunkdump ne présentait pas de problème, mais je viens de télécharger la branche master , je l’ai compilé et j’ai le bug qui est présent dans cette partie ci aussi !! . Compilé avec la 1.8.2

Je poste mon variosetting , des fois que…

#ifndef VARIO_SETTINGS_H
#define VARIO_SETTINGS_H

/*----------------------------*/
/*          SOFTWARE          */
/*      Vario parameters      */
/*        Version 1           */
/*----------------------------*/

/* Set your personnal info here and launch */
/* the SetVarioParameters Sketch to store  */
/* them in EEPROM.                         */
#define VARIOMETER_MODEL "GNUVario"
#define VARIOMETER_PILOT_NAME "Olitask"
#define VARIOMETER_GLIDER_NAME "Ozone Buzz Z5"

/* time zone relative to UTC */
#define VARIOMETER_TIME_ZONE (+1) 

/*********/
/* Beeps */
/*********/

/* The volume of the beeps, max = 10 */
#define VARIOMETER_BEEP_VOLUME 2

/* The variometer react like this according to vertical speed in m/s :        */
/* (near climbing beep is not enabled by default)                             */
/*                                                                            */
/* <--LOW-BEEP--|------SILENT------|--NEAR-CLIMBING-BEEP--|--CLIMBING-BEEP--> */
/*              |                  |                      |                   */
/*           SINKING         CLIMBING-SENSITIVITY      CLIMBING               */
#define VARIOMETER_SINKING_THRESHOLD -2.0
#define VARIOMETER_CLIMBING_THRESHOLD 0.5
#define VARIOMETER_NEAR_CLIMBING_SENSITIVITY 0.5

/* The near climbing alarm : signal that you enter or exit the near climbing zone */
/* The near climbing beep : beep when you are in near climbing zone               */
//#define VARIOMETER_ENABLE_NEAR_CLIMBING_ALARM
//#define VARIOMETER_ENABLE_NEAR_CLIMBING_BEEP


/*******************/
/* Screen behavior */
/*******************/

/* the duration of the two screen pages in milliseconds */
#define VARIOMETER_BASE_PAGE_DURATION 3000
#define VARIOMETER_ALTERNATE_PAGE_DURATION 3000


/********************/
/* Measure behavior */
/********************/

/* Flight start detection conditions :                      */
/* -> Minimum time after poweron in milliseconds            */
/* -> Minimum vertical velocity in m/s (low/high threshold) */
/* -> Minimum ground speed in km/h                          */
#define FLIGHT_START_MIN_TIMESTAMP 85000
#define FLIGHT_START_VARIO_LOW_THRESHOLD (-0.5)
#define FLIGHT_START_VARIO_HIGH_THRESHOLD 0.5
#define FLIGHT_START_MIN_SPEED 10.0

/* Speed filtering :                                               */
/* Greater values give smoother speed. The base unit is 2 seconds  */
/* so size = 5 use the last 10 seconds to average speed.           */
#define VARIOMETER_SPEED_FILTER_SIZE 5

/* Set the GPS precision needed to use the GPS altitude value  */
/* to calibrate the barometric altitude.                       */
/*      !!! the best possible precision is 100 !!!             */ 
#define VARIOMETER_GPS_ALTI_CALIBRATION_PRECISION_THRESHOLD 200


/*****************************/
/* SDCard/Bluetooth behavior */
/*****************************/

/* What type of barometric altitude is sent :           */
/* -> Based on international standard atmosphere        */
/* -> Calibrated with GPS altitude                      */
//#define VARIOMETER_SDCARD_SEND_CALIBRATED_ALTITUDE
//#define VARIOMETER_BLUETOOTH_SEND_CALIBRATED_ALTITUDE

/* GPS track recording on SD card starting condition :  */ 
/* -> As soon as possible (GPS fix)                     */
/* -> When flight start is detected                     */
#define VARIOMETER_RECORD_WHEN_FLIGHT_START

/* What type of vario NMEA sentence is sent by bluetooth. */
/* Possible values are :                                  */
/*  - VARIOMETER_SENT_LXNAV_SENTENCE                      */
/*  - VARIOMETER_SENT_LK8000_SENTENCE                     */
#define VARIOMETER_SENT_LK8000_SENTENCE

/* When there is no GPS to sync variometer bluetooth sentences */
/* set the delay between sendings in milliseconds.             */ 
#define VARIOMETER_SENTENCE_DELAY 2000


/*----------------------------*/
/*          HARDWARE          */
/*      Vario parameters      */
/*                            */
/*----------------------------*/

/* Comment or uncomment according to  */
/* what you embed in the variometer   */ 
#define HAVE_SPEAKER
#define HAVE_ACCELEROMETER
#define HAVE_SCREEN
#define HAVE_GPS
#define HAVE_SDCARD
#define HAVE_BLUETOOTH
#define HAVE_VOLTAGE_DIVISOR

#define HAVE_SCREEN_JPG63

/* If you embed an accelerometer set the model here. */
/* Possible values are :                             */
/*   MPU6050, MPU6500, MPU9150, MPU9250              */
#define MPU9250

/* Set the pins used for Screen and SD card modules */
#define VARIOSCREEN_DC_PIN 2
#define VARIOSCREEN_CS_PIN 3
#define VARIOSCREEN_RST_PIN 4
#define SDCARD_CS_PIN 14
#define VOLTAGE_DIVISOR_PIN 16

/* The screen contrast */
#define VARIOSCREEN_CONTRAST 60

/* The voltage divisor */
#define VOLTAGE_DIVISOR_VALUE 1.27
#define VOLTAGE_DIVISOR_REF_VOLTAGE 3.3

/* The bauds rate used by the GPS and Bluetooth modules. */
/* GPS and bluetooth need to have the same bauds rate.   */
#define GPS_BLUETOOTH_BAUDS 9600

/* I2C speed                                   */
/* You can try 800 on <8mhz microcontrollers   */ 
/* (Not always work)                           */
#define FASTWIRE_SPEED 400

/* Alarm */
/* Alarm SDCARD not insert */
#define ALARM_SDCARD
/* Alarm GPS Fix */
#define ALARM_GPSFIX
/* Alarm Fly begin */
#define ALARM_FLYBEGIN

/* Mute */
#define HAVE_MUTE

#endif

Salut

1/
concernant le bruit parasite, je constate effectivement bien le problème sur vario V2, je n’ai pas essayé sur le V1. On dirait que le buzzer claque comme si on lui envoyé une valeur qui le bloque ou qu’on l’alimente à l’envers

2/
Coté M0, nous sommes à un tournant, nous devons faire un prototype puis passer à des kits. Le travail est important et Prunkdump en manque. Avant d’aller plus loin, nous aurions besoin de savoir, combien d’entre vous sont intéressés par une version M0 avec écran E-Ink.

Pour rappel :

microcontrôleur M0+ 32bits 48Mhz - 32k de sdram, et 256k de flash
Ecran 1,54" E-Ink
3 boutons poussoir, possibilité de mise en veille
Micro SD
Transfert de données via USB

Pour le reste on garde la même chose que la version 2

  • Capteur de pression
  • accéléromètre
  • Gps
  • chargement via Usb + batterie

le son et lumière en version booster

Le M0 et l’écran valent chacun environ 20€ pièce, ce qui va amener notre kit sans boitier (pas encore choisi) au alentour des 80€ soit une version presque 2 fois plus chère que la précédente mais avec un potentiel logiciel quasi sans limite par rapport à la version 2

Si vous souhaitez tenter l’aventure M0, on attend vos retours

puisqu’il faut se compter : :+1:
total : 1 :smiley:

Cela dit, gérer les kits doit representer bcp de boulot, je ne suis pas certain que ça soit indispensable.
Publier le schéma, la liste des composants avec les sources d’achat, peut suffire à mon avis à ce que chacun gére son kit…

Il me semble plus profitable de conserver votre (précieux !) temps de cerveau sur le dev, le debuggage etc.

Ou alors, si vraiment vous voulez rester sur un kit, partager ces taches “operationnelles” avec des contributeurs moins experts dans le dev. (Je me propose d’ailleurs le cas échéant.)

puisqu’il faut se compter :
total : 1+1 = 2

:vol: : :+1:
total : 3

Un peu du même avis que ptitkiki : plusieurs approches :
1/ des kits : Tout le monde paye en avance. 1 personne commande tous les composants. Et s’occupera de faire les kits puis de les réexpédier. (à voir si ça inclu ou non du travail type perçage de boitier comme punk avait fait ou non)
Avantage baisse du cout car commande groupé. Désavantage une personne se tape un maxi de travail (à voir pour qu’il se prennent un pourcentage)

2/ des essential kit : Juste ce que l’on trouvera pas dans le commerce : le CI, le boitier, un composant dur à trouver ??!

3/ Juste la liste des composants mais bcp vont renoncer à faire le CI donc le montage

Le 1 peut-être intéressent si on trouve quelqu’un qui n’a pas de job et qui du coup se dédommage. Sinon ça va pas être facile de distribuer les taches car ça va multiplier les frais de ports pour tous.

Pour info vous avez sur le github branche M0 jpg63, le schema, la liste des composants et le code, il manque juste le PCB, mais avant d’arriver à un kit, le travail d’optimisation du PCB et la réalisation d’un circuit compatible avec le boitier choisi est un gros gros boulot.

pour le boitier je pensais à l’une de ces options

en version M sans compartiment à piles
https://www.okw.fr/fr/Boitiers-en-plastique/Soft-Case.htm

ou
http://www.hammondmfg.com/pdf/1553A.pdf

ou un boitier dessiné sur mesure et fait en 3D

Si quelqu’un peut se charger du PCB se serait autant de travail en moins pour Prunkdump - Comme pour le version 2, on fera faire les pcbs par un pro.

Niveau kit si chacun se charge de retailler son boitier, ce sera autant de travail de moins pour celui qui s’occupe de préparer les kits

“L’essential kit”, pourquoi pas, j’imagine que c’est un peu galère à gérer la totalité du kit, entre les commandes, ceux qui veulent, puis qui veulent plus, puis qui changent d’avis…
Pour les Ci je pense qu’on doit pouvoir avoir un prix intéressante en fonction du nombre, pour les composants, a moins d’en commander deux containers chez nos chinois, le gain doit rester sur l’épaisseur du trait, le seul avantage, si tant est que tous les composants viennent bien de chez le même fabricant, c’est d’identifier (peut être) un composant défectueux plus facilement, tous les composants du kit présentant le même problème…
Après, si quelqu’un veux bien faire le boulot de commande et de dispatching, feignant comme je suis, je suis prêt a lui confier la mission et même lui laisser une gratte dessus, si ça peut permettre à quelqu’un qui hésite à investir, de “s’offrir” un vario, je contribuerais avec plaisir…

Sinon + 1 pour moi

Je ne le répéterais jamais assez : Bravo à tous ceux qui investissent du temps et de la matière grise dans ce projet :+1: :+1: :+1:

@jpg63 :
Sur la version M0, y a t’il toujours besoin de changer le bootloader de l’arduino comme sur les version Nano?

Et au niveau de la partie Alimentation / gestion de batterie / allumage et mise en veille, tu pense que c’est suffisamment déverminé pour passer sur PCB? Ou ça serait utile qu’on monte des protos “en l’air” un peu plus utilisable que que sur breadboard pour pousser un peu les tests?

pas besoin de changer le bootloader - pour la mise à jour, elle est intégré au Mkzero, on place le fichier firmware sur la carte SD, au reboot la mise à jour s’effectue et le fichier est supprimé. On pourra aussi utiliser ide via l’usb

On est jamais à l’abris d’une erreur, faire un proto serait effectivement une très bonne chose avant de passer au pcb. J’ai fais des tests et prévu, une coupure totale par interrupteur en plus du système de mise en veille - pour assurer j’ai prévu un inter qui force l’enable du circuit contrôleur mais si tu veux bien te charger de tester et valider mon schema on aura pas de mauvaise surprise.

Bonjour,
Je reviens sur le bruit de claquement du buzzer. j’ai fait l’essai du firmv2 de prunkdump et j’ai toujours le bruit.

J’ai aussi un autre problème avec l’écran qui devient de plus en plus clair (il est presque illisible maintenant) et pourtant il a très peu servi.

Merci à tout ceux qui bossent pour ce projet.

Je suis intéressé mais partisan à 300% de la solution de “l’essential kit” ! C’est facile d’approvisionner des composants à bas coût sur AliExpress, ça l’est beaucoup moins pour le PCB et un boitier adapté…

Chaud pour un kit également.
Pour un “essential” ou un “full kit”