DIY GnuVario : variomètre opensource - openhardware Arduino

[jpg63]

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

[prunkdump]

Salut !

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

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

[jpg63]

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

[olitask]

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

Code:

#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

[jpg63]

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

[ptitkiki]

puisqu'il faut se compter :  
total : 1  

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

[Van Hurlu]

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

[Xiboard]

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

[jpg63]

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

[Pascoq]

"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      

[ptitkiki]

@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?

[jpg63]

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

[josecarbon]

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.

[Jérémie LeCouvert]

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.

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

[dgtall]

Chaud pour un kit également.
Pour un "essential" ou un "full kit"

[jpg63]

Je me rajoute pour 1 kit "essential" ou "full" mais cela semble évident  pour pouvoir développer sur le gnuvario 

 

On commence a avoir pas mal de monde même avec un prix plus élevé c'est super

On pourrait procéder par étapes

1/ Une version proto sans pcb pour valider le schema
                     - Pour bien faire, il faudrait 1 ou 2 personnes autre que moi pour détecter les problème et améliorer le schema
2/ Réalisation d'un pcb non optimisé
                     - Tout les beta tester qui le voudront - moins de travail - réalisation plus rapide
2/ Le choix du boitier en fonction des contraintes de place des nouveaux composants
                      - Toutes les propositions seront les bienvenues dès que l'on aura une idée de la taille du pcb
3/ Conception d'un PCB pour le boitier
                      - Gros boulot
4/ Mise à dispo de kit "essential+" - tout les composants, le PCB et le boitier sans usinage ni découpe
                      - Commande groupée avec avance de l'argent
5/ Réalisation d'un "full kit"   
                      - encore un gros travail

[FluffyClouds]

Hello, A l'époque de la révolution du kobo mini et de xcsoar, j'avais réalisé le pcb d'un vario basé sur l'arduino nano qui se contentait de sortir des trames nmea et openVario pour interprétation par xcsoar.
Lors de la sortie de l'arduino zero, je l'avais modifié en clone basé sur le samd21 mais je ne l'avais malheureusement jamais terminé.

La sortie des drivers pour ecrans e-ink m'a remotivé à finalement faire une petite série de 10 pcb qui est en cours de test et qui je pense pourrait vous interesser.

Je ne sais pas dans quelle mesure ma pcb est compatible avec le code du gnuvario mais ca doit pouvoir s'adapter. C'est un clone en tout point du mkrZero et qui comprend carte sd/gps/m5611/mpu9250/chargeur de lipo/buzzer, sortie I2C, nappe pour ecran waveshare et module HC-05.

Voir photo en attache. Tout fonctionne correctement pour le moment à part l'écran/bluetooth que je n'ai pas encore eu le temps de coder.

Suite au prochain épisode

[jpg63]

Hello, A l'époque de la révolution du kobo mini et de xcsoar, j'avais réalisé le pcb d'un vario basé sur l'arduino nano qui se contentait de sortir des trames nmea et openVario pour interprétation par xcsoar.
Lors de la sortie de l'arduino zero, je l'avais modifié en clone basé sur le samd21 mais je ne l'avais malheureusement jamais terminé.

La sortie des drivers pour ecrans e-ink m'a remotivé à finalement faire une petite série de 10 pcb qui est en cours de test et qui je pense pourrait vous interesser.

Je ne sais pas dans quelle mesure ma pcb est compatible avec le code du gnuvario mais ca doit pouvoir s'adapter. C'est un clone en tout point du mkrZero et qui comprend carte sd/gps/m5611/mpu9250/chargeur de lipo/buzzer, sortie I2C, nappe pour ecran waveshare et module HC-05.

Voir photo en attache. Tout fonctionne correctement pour le moment à part l'écran/bluetooth que je n'ai pas encore eu le temps de coder.

Suite au prochain épisode

Super travail, très jolie

Très très intéressant, on peut toujours adapter le code du gnuvario 

Tu pourrais nous donner la taille du pcb - est-il possible de récupérer des entrées/sorties, pour ajouter 3 boutons ?

[FluffyClouds]

Il y a déjà 3 boutons, j’avais prévu à l’image du Flymaster de pouvoir naviguer dans un menu avec haut, bas et enter. Il y a quelques autres sorties aussi dispo comme visible sur l’image en haut à droite. Pour le moment j’en suis à 65 par 49mm, on peut réduire un peu en serrant un peu les composants ou beaucoup en passant en double face mais ca deviendra compliqué pour la soudure !

[jpg63]

Il y a déjà 3 boutons, j’avais prévu à l’image du Flymaster de pouvoir naviguer dans un menu avec haut, bas et enter. Il y a quelques autres sorties aussi dispo comme visible sur l’image en haut à droite. Pour le moment j’en suis à 65 par 49mm, on peut réduire un peu en serrant un peu les composants ou beaucoup en passant en double face mais ca deviendra compliqué pour la soudure !

La taille est très raisonnable, on reste dans un espace compatible avec un vario monté sur les élévateurs

Pour le BT et l'écran, le code du GnuVario fonctionne
Perso je suis très intéressé et j'aimerai beaucoup essayer de faire fonctionner le code du Gnuvario sur ton PCB, par contre je ne me vois pas souder du CMS.

[FluffyClouds]

Il me reste encore à vérifier quelques points avant d'envisager d'en distribuer, notamment dêtre sur que je ne fais pas exploser la lipo ou le port USB . Mais pour ca, j'attends les lipos  ! Aliexpress c'est bien mais faut pas être pressé!

Pour le smd, je fais pour le moment tout à la main, c'est beaucoup de boulot! Je compte tenter la méthode renommée du Professeur tournessol très bientot: la casserole.

[jpg63]

Il me reste encore à vérifier quelques points avant d'envisager d'en distribuer, notamment dêtre sur que je ne fais pas exploser la lipo ou le port USB . Mais pour ca, j'attends les lipos  ! Aliexpress c'est bien mais faut pas être pressé!

Pour le smd, je fais pour le moment tout à la main, c'est beaucoup de boulot! Je compte tenter la méthode renommée du Professeur tournessol très bientot: la casserole.

On attends tes retours avec impatience 

[ptitkiki]

Wow amazing.

Superbe boulot félicitation.

Si tu es ouvert à l'open source / open HW, je pense qu'il y a clairement une convergence à opérer avec le GNUVario !

[vmath54]

Arff ! Impressionné par les compétences dans ce groupe !

Je suis partant également pour un kit ... J'en salive d'avance.

[air]

Intéressé également, mais également impressionné par la réalisation de Fluffy Coulds, si on pouvait avoir un kit sur cette base