Detecteur de Foudre

Voici un petit bricolage autour d'un Arduino UNO pour détecter la foudre (et autres parasites électromagnétique). D'autres cartes du même type feraient l'affaire du moment qu'il y a un convertisseur Analogique/Digital. L'idée est de relier une antenne directement à l'entrée analogique et de voir ce que ça donne. C'est le tout premier pas vers ce que l'on appelle la Radio logicielle ou encore SDR: Sofware Define Radio. 

Rappels: 

• Le convertisseur A/D du UNO permet de mesurer sur 10 bits  une tension comprise entre 0 et 5 volts.  Donc 0 Volts = 0 ... 2.5 Volts = 512 ... 5 Volts = 1023.
  
  
• Une éclair émet un rayonnement électromagnétique dans le bande de fréquence 1 Hz - 300 Mhz et aussi dans la bande de fréquence du visible.  Si l’éclair atteint le sol, on parle de foudre, et une impulsion supplémentaire dan la bande VLF est émise au environ de 10 kHz. C'est elle que l'on cherche à détecter.
  
  
• Afin d'analyser l'onde captée avec le plus de fidélité possible il faut échantillonner le plus souvent possible. Si la fréquence d'échantillonnage est Fech la fréquence maximum mesurable sera Fech/2 (théorème de Nyquist-Shannon). Donc moins on passera de temps entre deux mesures successives plus la fréquence maximale mesurable sera élevée. 
  

La première chose que l'on constate est la nécessité de créer un offset de tension sur l'entrée A/D afin de pouvoir mesurer des variations de tension positives et négatives. C'est le rôle du potentiomètre POT1 de 20 Ko. Le but est de régler POT1 pour que la valeur mesurée 'au repos' soit proche de 512. Ainsi une variation positive de tension donnera une valeur entre 512 et 1024 et une variation négative donnera une valeur entre 512 et 0. Le potentiomètre POT2 de 3 Mo permet de régler l’atténuation du signal capté (il ne faut pas saturer l'entré du convertisseur).

Le buzzer sert à faire savoir quand le logiciel qui s’exécute sur le UNO détecte un événement. On peut réaliser de nombreuses expériences au niveaux du logiciel pour essayer de trouver la meilleure solution pour détecter les anomalies. Plus les calculs sont complexes moins on échantillonne souvent et plus basse est la fréquence maximale mesurable. On constate rapidement que la proximité d'appareils électronique induit une onde de 50 Hertz. Si nécessaire, on peut alimenter le UNO avec une batterie et se mettre à l’écart des sources de perturbation, mais on perd alors la liaison USB avec le PC ce qui réduit fortement la capacité d'analyse.

En absence d'orage il est possible de simuler les éclairs en utilisant un allume gaz piézoélectrique à proximité de l’antenne. L'antenne à elle seule est une vaste zone d'exploration. Un simple fils de cuivre de quelque mètres, un fil en forme de boucle, un dipôle ect...

 

Le code DetectionFoudre.ino a les caractéristiques suivantes:

• Au démarrage, pendant 20 secondes, il mesure la valeur moyenne que la broche du convertisseur A/D et l'envoi sur le port USB. De plus si la valeur est < 512 il éteint la led du UNO et si la valeur est > 512 il allume la led. Ces 20 secondes sont l’occasion d'ajuster POT1 pour recevoir sur le port USB une valeur proche de 512 et avoir la led du UNO qui frétille. L’idéal est d'avoir l'antenne débranché pendant cette étape. Voir fonction calibrate().
  
  
• En envoyant beaucoup de données pendant la boucle principale loop() j'ai eu des problèmes de perte de données. Avant Serial.print() j'utilise donc systématiquement la fonction ws() pour m'assurer qu'il y a suffisamment de place dans le buffer de transmission.
  
  
• Les valeurs lues sur le convertisseur A/D sont stockées dans une file circulaire de N éléments. Les nouvelles valeurs remplaçant les plus anciennes. Quand une événement est détecté (valeur dépassant la moyenne de plus ou moins 30%) on garde les N/3 échantillons précédant cet événement et on capture les 2N/3 échantillons suivants puis on envoi les N échantillons via le port USB et on fait sonner le buzzer. Ainsi on n’envoie sur le port USB une série de N valeurs contenant à coup sur un événement.
  
  
• Pour maximiser la vitesse d'échantillonnage le boucle principale n'utilise pas analogRead() car cette fonction est bloquante. Pour gagner quelques cycles le démarrage et la détection de fin de conversion sont gérés à la main. Ce code permet de faire environ 7400 échantillonnages par secondes : 7.4 kHz soit 135µs entre deux conversions.
  

 Exemples :

Les valeurs envoyées sur le port USB du UNO sont 

• capturées avec PuTTY (qui a la possibilité de sauver une session),
• nettoyées du superflus et sauvées avec l’extension .csv
• importées dans un tableur pour générer un graphe.

Note:  L'IDE Arduino est capable de faire des graphiques à partir des valeurs reçues sur le port usb mais on ne peut pas sauver ces valeurs ni faire varier l’échelle du temps ni revenir en arrière dans la visualisation. D’où l'utilisation d'un tableur.

Remarques:

• La ligne rouge (660) est le seuil de détection des événements (foudre).
• A,B,C,E,F sont des événements réels capturés, en D le doigt était posé sur l'antenne.
• Comme rien n'est transmis quand il n'y a pas de pics au dessus de 660 il peut s’être écoulé plusieurs minutes en les événements A,B,C,E,F présentés ici.
• Dans la zone 'F' la 'porteuse' de 50 Hz était mieux captée et dépassait systématiquement la valeur 660 sans que pour autant il y ai de véritables événements. Il faudrait perfectionner le code pour détecter les pics non pas par leur valeurs mais par leur fréquence (vitesse de variation du signal).

Autre exemple avec dépassements supérieurs et inférieurs :

Réseaux de détection de foudre

Ces réseaux utilisent bien sur un système de détection bien plus sophistiqué que celui présenté ici.

• Blitzortung réseau communautaire de détection. Récepteur en kit.
  
• Meteorage (Filiale de Météo France)
• Le 'World Wide Lightning Location Network' de l’université de Washington

Autre technique

Les fréquences radio que l'on cherche à échantillonner pour détecter la foudre sont très faibles. Au point que des cartes prévues pour échantillonner des signaux sonores peuvent être utilisées; Les cartes d'acquisition son échantillonnent à 44 kHz ou 48 kHz et fournissent un flux numérique en USB. Il faut utiliser un adaptateur entre l'antenne et l'entrée micro et un logiciel pour analyser le flux numérique : SAQrx. est l’outil parfait pour cela. Voir ce cas pratique par F6ACU.

git: renommer master en main

Il est à la mode dans le monde git de renommer la branche historique 'master' en 'main'. D’ailleurs tous les services d'hébergement de git (BitBucket, GitHub, GitLab ...) nomment la branche par défaut des nouveaux repos 'main'. Voici comment effectuer cette migration techniquement inutile.

NB: Pour ceux et celles qui ont un MASTER (diplôme) je ne sais pas comment on fait, ni pour ceux qui roulent en Renault Master...

A) Celui (ou celle ...) qui a la responsabilité de faire la conversion des anciens repos devra exécuter les commandes suivantes pour chaque repo :

# S'il/elle n'a pas déjà une copie du repo à migrer il devra le cloner :
  $ git clone git@gitmachin.org:<user>/<repo>.git
  $ cd <repo>

# S'il/elle a déjà une copie :
  $ cd <repo>
  $ git checkout master

# Vérifier que l'on est bien par sur 'master'
  $ git status
  On branch master
  Your branch is up to date with 'origin/master'.

# Renommer localement 'master' en 'main' (ou tout autre nom qui ne choque la sensibilité de personne ...)
  $ git branch -m master main
  $ git status
  On branch main
  Your branch is up to date with 'origin/master'

# Pusher cette nouvelle branche sur 'origin' et la lier a origin/main(--set-upstream ou -u )
  $ git push --set-upstream origin main

Aller sur l’interface web de gitmachin et déclarer que 'main' est la nouvelle branche par défaut.
Sans cela l’étape suivante échouera.

# Supprimer de 'origin' la branche 'master'
  $ git push origin --delete master
      
# Vérifier
  $ git status
  On branch main
  Your branch is up to date with 'origin/main'.

 

NOTE: L'interface web des principaux hébergeurs de git propose de 

• créer une nouvelle branche
• modifier la branche par défaut
• supprimer une branche (qui n'est pas celle par défaut)
  

Il est donc possible d'effectuer l’étape (A) uniquement avec la souris.

B) Tous les autres utilisateurs de ce repo devront exécuter ceci :

# S'assurer d’être sur la branche locale 'master'
  $ git checkout master

# Renommer localement de 'master' en 'main' (ou tout autre nom choisi à l’étape précédente)
  $ git branch -m master main

# Récupérer l'état actuel d'origin (ce qui inclue la nouvelle branche 'main')
  $ git fetch

# Supprimer le tracking de la branche distante 'master' qui n'existe plus.
  $ git branch --unset-upstream

# Lier la branche locale actuelle a origin/main
  $ git branch --set-upstream-to=origin/main

 

NOTE: Dans ce contexte, si vous utilisez Git 2.38 (Juillet 2020) une bonne pratique pour les repo créés localement est d’exécuter ceci :

$ git config --global init.defaultBranch main

Plusieurs comptes sur GitHub

Avant de répondre à la question de Comment gérer plusieurs comptes sur GitHub ? regardons comment GitHub effectue l'authentification.

Note: GitHub propose plusieur reponses à ce problème, mais la solution presenté ci-dessous n'y figure pas.

1) Un seul utilisateur pour tout !

Vous l’avez très certainement remarqué quand vous interagissez avec GitHub vous utilisez toujours le user git. Par exemple :

git clone git@github.com:example/test

 

Pour accéder à des repositories publics ça ne parait pas surprenant, mais c’est aussi le cas quand on clone un repo privé. Comment github fait-il pour savoir si celui qui lance la commande a le droit d’accéder à ce repository ? Comme le user est toujours le même et qu’il n’y a pas de mot de passe, c’est forcément la clé ssh qui sert à la fois pour l’identification et l’authentification.

 

Cela implique qu’une même clé ssh ne peut être associée qu’à un seul profil. Si vous tentez de réutiliser une clé déjà associé à un profil vous aurez ce type d’erreur :

Verify public key failed for Example key is already in use.

 

Il n'est pas possible d'utiliser le même email pour ouvrir plusieurs compte sur GitHub.
Si vous essayer vous obtiendrez:  Email is invalid or already taken

 

Donc:
- Une adresse email ne peut étre liée qu'a un seul compte identifié par un username, ce qui donne une url unique github.com/<username>.
- Ce username peut etre utilisé avec plusieurs clés ssh. Par contre, une clé ssh ne peut etre utilisée que par un seul username.

2) A qui est cette clé ?

Bien sûr il est impossible que quelqu’un d’autre que vous ait la même clé. Si vous avez ce message d'erreur c'est que vous avez un (vieux...) profil qui utilise déjà cette clé. Pour savoir lequel, il suffit d’initier une connexion ssh en ligne de commande en explicitant la clé à utiliser :

ssh -T -ai ~/.ssh/id_rsa git@github.com

Si la clé est connue, la réponse de GitHub sera:

> Hi XXXXXX! You've successfully authenticated,
but GitHub does not provide shell access.

 Où XXXXX est le nom du profil utilisant cette clé.

3) Jongler avec les clés

Il faut donc avoir autant de clés ssh que de profils sur GitHub. Le problème est comment indiquer quand on fait une opération avec git quelle clé doit être utilisée ? Une fois de plus c’est le fichier ~/.ssh/config qui va nous sauver. 

Il faut créer un host fictif pour chaque profil en spécifiant au moins le véritable hostname et la clé à utiliser pour ce host fictif.

cat ~/.ssh/config

Host Expl
    HostName github.com
    User git
    IdentityFile ~/.ssh/example_id_ed25519

Host Demo
    HostName github.com
    User git
    IdentityFile ~/.ssh/demo_id_rsa

 Grace à cela nous pourrons utiliser ces hosts fictifs ainsi :

git clone Expl:example/test
git clone Demo:demonstration/projet-demo

Le host fictif (Expl ou Demo) définit à la fois : le host réel (github.com), le user (git) et la clé à utiliser. Il n’est donc plus nécessaire de spécifier le user (git@Demo ou git@Expl). Il suffira donc de remplacer le classique « git@github.com » par « Expl » ou « Demo » suivant le profil que l’on veut utiliser.

    .ssh/config : Ref-1 , Ref-2

4) Confiez vos clés à un Agent-ssh

Une autre méthode consiste à charger toutes vos clés privées dans un agent ssh et laisser le protocole SSH essayer chaque clé jusqu’à ce que le serveur en accepte une. L'avantage d'un agent ssh est qu'il s'occupe de demander, si nécessaire, les pass-phrases des clés cryptées. Suivant l'agent il peut faire ça au démarrage, ou bien à la première utilisation de la clé.

- Un premier problème est que certains serveurs limitent le nombre de tentatives de connexion. Si vous avez beaucoup de clés chargées par l’agent-ssh vous risquez d’obtenir « too many authentication errors ».
- Le deuxièmes problème est quand vous avez plusieurs profils (donc plusieurs clés) sur GitHub . Comment savoir si la clé acceptée correspond au bon profil ?

Important: Pour que ssh interroge l'agent ssh il ne faut pas utiliser l'option  IdentitiesOnly dans .ssh/config

    Windows PuTTY/Pageant : Ref-1 , Ref-2 , Ref-3 
    Linux ssh-add et ssh-agent : Ref-4 , Ref-5

Résumons

Il y a trois sources possibles pour une clé privée:

a)     La clé par défaut id_rsa (ou id_ecdsa ou id_ed25519 etc…) venant du répertoire .ssh/
(méthode utilisable si on a une seule clé pour tout)

Dans les logs de  « ssh –T –v git@github.com » on trouvera cette paire de lignes Offering/Accepted :

Offering public key: C:\\Users\\bibi\\.ssh\\id_rsa RSA SHA256:GwKTTsGLCTlq…Ug
Server accepts  key: C:\\Users\\bibi\\.ssh\\id_rsa RSA SHA256:GwKTTsGLCTlq…Ug

b)     La clé associée explicitement au host fictif dans le fichier  .ssh/config
(méthode utilisable quand on doit associer une clé spécifique à certains host ou user@host)

Dans les logs de  « ssh –T –v example » on trouvera cette paire de lignes :
(rappel: example est une host fictif définit dans .ssh/config)

Offering public key: C:\\path\\to\\file RSA SHA256:GwKTTsGLCTlq…Ug explicit
Server accepts  key: C:\\path\\to\\file RSA SHA256:GwKTTsGLCTlq…Ug explicit

Notez le ‘explicit’ en fin de ligne.

c)     La clé proposée (parmi d’autres) par l’agent ssh :

Dans les logs de « ssh –T –v git@github.com » on trouvera cette paire de lignes :

Offering public key: nom_clé RSA SHA256:GwKTTsGLCTlq…Ug agent
Server accepts  key: nom_clé RSA SHA256:GwKTTsGLCTlq…Ug agent

Notez le ‘agent’ en fin de ligne.

SOLUTION

Il est évident qu’il faut de la méthode pour ne pas se mélanger les clés… 

- Le comportement par défaut de ssh n'est acceptable que si on a une une seule clé pour tout. Ce qui ne marche pas si vous avez plusieurs comptes GitHub.

- L'agent ssh est obligatoire quand les clés privées sont cryptées avec une pass-phrase. Dans ce cas il est fortement recommandé de le combiner avec la méthode suivante pour rendre le choix des clés prévisible.

- La méthode des hosts fictifs définis dans .ssh/config demande de la configuration et de modifier les url git pour éviter les ambiguités, mais c’est la seule méthode multi-clés dont le comportement est prévisible et sans risque de provoquer des « too many authentication errors ».

Donc ==>   .ssh/config  + (ssh-agent si pass-phrase)

L'utilisation du fichier .ssh/config donne accès à de très nombreuses options qui vont bien au delà du problème des profils multiples avec GiyHub.

https://www.openssh.com/

Perl 5 Search Engine

 

The Perl 5 search engine

Note: StackOverflow is excluded from the list of sites.

 

See also:  Download  Core modules  PerlDoc 

 MetaCpan  GrepCpan  CpanTesters  CpanAuthors

GitHub  DockerHub

 The index  r/perl