ardechelibre[.org]

Bonjour,
Concernant le microphone FG23629, j'ai modélisé la réponse spectrale.
L'équation : 1 / (1+2*m*j*W/Wc+(j*W/Wc)^2) avec
- Wc = 2*pi*15kHz
- m = 0,5
Le modèle est un passe bas du 2eme ordre valable de 1kHz à 120kHz.
Attention, en dessous d'1kHz, un passe haut dont la fréquence de coupure est inférieure à 100Hz.
     Emmanuel

Dernière modification par Emmanuel COLLET (2015-12-28 22:36:41)

Bonjour à tous,

En attendant de publier la 1ère version du logiciel (début janvier promis) vous trouverez sur les liens ci-dessous un schéma de la pieuvre I2C pour relier la carte audio aux clavier, écran et horloge. Comme aucun de ces éléments n'a un connecteur identique, je préconise une pieuvre réalisée avec des morceaux de nappe et des connecteurs à souder sur de petits morceaux de plaque à trous. Sur la plaque utilisée pour le connecteur J2 de la carte audio, 3 connecteurs supplémentaires permettent de connecter l'horloge, et les alimentations des pré-ampli et ampli. Ensuite 4 fils de la nappe partent vers le connecteur de l'écran puis vers le connecteur du clavier.
Le fichier Calc énumère les éléments pour commencer la réalisation des prototypes hors pré-amplis, micro, ampli, prise USB externe et alimentation dans un 1er temps.
Malheureusement, il n'est pas possible de commander la carter Pi Zero, elle est en rupture de stock chez Kubii. J'espère que la situation va se débloquer en janvier... Dès que ce sera possible, je commande de mon coté le nécessaire pour un proto de la version "manual" et un autre pour la version "fixed". Clavier, écran et horloge sont déjà commandés chez AliExpress.

Les fichiers en téléchargement :
- Schéma de la pieuvre I2C
- Liste des éléments pour monter des prototypes avec prix et exemple de fournisseur

Bon réveillon...

Jean-Do.

Bonjour Jean-Do,

Pourras-tu nous transmettre une photo du montage (organisation générale du circuit et surtout le montage du MEMS) ? Je galère beaucoup pour les soudures de ce type de micros, je suis preneur de toute bonne idée.

Sinon, je viens de commander le matos nécessaire à un (même 2) protos avec la batterie et le circuit d'alimentation évoquée dans le volet "alimentation". Reste à attendre les livraisons (j'espère d'ici fin janvier).

Pour le boitier, j'ai trouvé celui-ci qui devrait répondre à la demande si mes estimations sont bonnes.

Merci,

Fred.

Bonjour à tous et meilleurs voeux pour cette nouvelle année !
Jean-Do, je serais intéressé par deux hauts parleurs, peux tu les ajouter à ta commande ?
Fred, il me reste des 2 pcbs , une fois le micro soudé dessus il te permettent d'avoir accès simplement aux Vin/Gnd/Vout (les 3 "gros" pads rectangulaires) . Je peux te les préparer s'il te reste des mems. S'il en faut plus je peux adapter le desing et mutualiser une nouvelle impression.
j'avance sur la carte d'alim, une première version est routée mais le résultat me semble trop encombrant... j'essaie de faire mieux
.
A+
Hub

pour l'instant je suis à 85x95 mm en intégrant l'arduino et la RTC. Il n'y a pas le preampli , je pense plutôt l'intégrer sur le pcb du micro histoire de limiter les parasitages alim/signal. J'essaie de passer des composants dip de l'autre coté (comme la CR2032) et d'optimiser le routage pour faire plus petit. Comme le BOM n'est pas encore fixé, je n'ai pas le chiffrage. Je vous tiens au courant rapidement.

Pour le PCB du micro, je dois être autour de 100 € tout compris pour 30 pièces. (20 € de frais de port x-( ). je t'envoie mon adresse pour les mems.
A+

Bonjour,

OK pour les deux HP Ultrason pour toi Hubert. Fred, tu n'en voulais pas 1 ?

Pas mal pour la carte alim avec Arduino et RTC ! Mais ce n'est pas un peut rapide de lancer le routage et le circuit sans test ?
Je pensais que tu lançais seulement une carte d'alimentation qui ne pose pas trop de problème de schéma.
Avec la RTC et l'Arduino, c'est un autre problème. J'aimerais bien examiner le schéma histoire de vérifier le dialogue entre l'Arduino et la Raspberry. Les deux doivent communiquer : Au minimum, Raspberry Pi doit envoyer l'heure de coupure et de redémarrage à l'Arduino. A priori, il est possible de communiquer via l'I2C en passant l'Arduino en esclave mais ce dernier doit aussi fonctionner en maitre pour lire l'heure sur la RTC. Il faut que je vérifie si un fonctionnement Maitre/Esclave est possible sur l'Arduino.

Et qui fait le programme de l'Arduino ??? Je pourrai le faire mais il n'est pas dans mon intention de réaliser un modèle "Automatic" hors, ce modèle est le seul à utiliser le montage avec l'Arduino.

Pour le circuit des MEMS, oui, soit il est indépendant comme ta photo, soit il est sur le circuit du pré-ampli mais il faut bien vérifier ou tombe le trou d'entrée des sons pour que ce dernier coïncide avec un emplacement correct sur les boitiers.
Et oui, je suis d'accord avec Fred, il faut réaliser des essais avant de se lancer dans la réalisation d'un circuit. Emmanuel travaille sur ce point et il faut attendre ses résultats.
Et ensuite, vérifier les contraintes mécaniques pour la position du pré-ampli et du micro dans les différentes versions.

Jean-Do.

Bonjour,

J'ai examiné le schéma de l'alimentation et j'ai d'abord plusieurs questions car j'ai du mal à interconnecter les différents éléments du schéma :
- Une sortie USB connectée à l'Arduino est indispensable pour le programmer (c'est le rôle de P5 header 4 ? et c'est ce connecteur qu'on voit sur le dessin du PCB ou il s'agit de P2 ?).
- U6 sert à protéger la batterie des décharges profondes ?
- U4 sert pour la charge de la batterie à partir d'une alimentation secteur au travers de U1 ou d'un panneau solaire ?
- U7 sert à booster la tension de la batterie pour réaliser du 5V pour l'Arduino et le PI ? Il manque la référence de U7
- Quel est le modèle du processeur ATmega (U3) utilisé histoire de vérifier sa consommation annoncé ?

Et ensuite des problèmes, essentiellement sur le dialogue PI/Arduino :
- La sortie analogique ADC1 commande le relais de coupure d'alimentation du PI. Perso, je préfère une broche logique et avec un transistor pour protéger la sortie, les broches analogiques sont trop peu nombreuses pour les utiliser de cette façon.
- Avec un Arduino 5V, la liaison I2C n'est pas possible avec le Raspberry qui est en 3V3.
- Idem pour la liaison série du Raspberry, impossible de la connecter avec l'Arduino sans adaptation.
Un convertisseur de tension est indispensable pour rendre la liaison compatible (de ce genre par exemple).

Quel est le rôle de l'Arduino ? Selon moi, il sert essentiellement à couper et remettre l'alimentation de l'ensemble PI/Carte audio/Pré-ampli pour gagner en consommation. C'est effectivement possible via la sortie ADC1 qui commande le relais REL1. Accessoirement, des capteurs sont connectés aux broches de l'Arduino (température, humidité...) pour mémoriser des valeurs pendant que le PI est coupé. REL1 est de type bistable ? Il ne faudrait pas perdre dans l'alimentation de REL1 ce que l'on gagne à couper l'alimentation.
Il faudra probablement mettre un interrupteur sur une entrée logique de l'Arduino pour forcer la mise sous tension du PI pour qu'un opérateur puisse modifier les paramètres de fonctionnement pendant les périodes de coupure de tension (si le PI est hors tension, un clic le met sous tension. Après démarrage, l'opérateur peut modifier les paramètres et sortir proprement en faisant un halt. Un second clic coupe alors l'alimentation du PI).
Les deux processeurs, celui de l'Arduino et celui du PI ont besoin de connaitre l'heure en permanence. C'est le rôle de U2 (DS1307) pour l'Arduino mais, en l'état, cet élément ne peut pas servir pour le PI puisque le bus I2C ne sort pas et est de toute façon incompatible en tension avec le PI.
Pour couper l'alimentation à une date/heure précise et la remettre à une autre date/heure, l'Arduino a besoin de connaitre ces deux date/heures connues uniquement du PI via la programmation imposée par l'opérateur.
De même, l'Arduino n'ayant pas de mémoire de masse, les mesures qu'il effectue doivent être communiquées vers le PI qui pourra les stocker dans une clé USB ou sa carte SD (attention, lorsque le PI est hors tension, il faudra stocker les mesures sur l'Arduino qui a une mémoire très limitée).

Une communication entre ces deux processeurs est donc indispensable et nous avons le choix entre deux possibilités :
- Utilisation de la liaison série : dans ce cas, il faudra imaginer un protocole entre les deux composants pour a) mettre l'Arduino à l'heure, b) récupérer l'heure de l'Arduino, c) initialiser sur l'Arduino les dates d'extinction et d'allumage du PI et d) récupérer les éventuelles mesures faites par l'Arduino. Je ne suis pas partisan de cette solution, surtout pour des problèmes de synchro des heures. De plus, cette solution monopolise la sortie série du PI qui est aussi utilisable par un GPS.

- Utilisation du bus I2C : on se retrouve alors avec deux maîtres, la carte PI et la carte Arduino et plusieurs esclaves, le clavier, l'écran et l'horloge. Les caractéristiques du bus I2C autorisent parfaitement cette configuration et dans ce cas, nous avons une seule horloge partagée par le PI et l'Arduino. Elle est mise à l'heure par l'opérateur à partir du PI et les deux l'utilisent pour la gestion de l'heure. Toutefois, un maitre ne peut pas parler à un autre maitre. Pour une communication possible entre les deux par ce biais, il faut passer l'Arduino en esclave le temps d'échanger avec le PI. C'est à priori possible (cf. cet article) à condition de bien séquencer cette partie (par exemple, avant démarrage du PI, l'Arduino passe en mode esclave, le PI dialogue avec lui pour échanger des informations puis lui indique qu'il peut repasser en maître. Comme il y a au moins un redémarrage par jour, nous aurons un échange Pi/Arduino par jour ce qui semble suffisant. Avec cette solution, ce sont les drivers respectifs des cartes qui dialoguent avec l'horloge et permettent la gestion de l'heure.
Cette solution n'est possible qu'avec un Arduino 3V3 ou une adaptation de niveau entre le monde Pi et le monde Arduino.

Et pour finir, il serait intéressant d'avoir une idée du prix de l'ensemble car, si j'assemble un arduino pro mini (1€50), une horloge (1€20) et une carte alimentation comme proposée par Fred (16€30), on a les mêmes fonctionnalités pour moins de 20€...

C'est tout pour l'instant !

Jean-Do.

Bonjour et meilleurs voeux à toutes et à tous.
Jean-Do est-ce qu'il est encore possible d'ajouter un HP ultrason à ta commande?
Magnifique boulot!
Si tu as besoin d'un beta testeur n'ayant jamais approché le PI, je suis partant mais je risque de te solliciter plus que d'autres. Peut-être vaut-il mieux attendre que le projet soit plus abouti? à toi de dire.
Et, si vraiment tu t'ennuyais, je veux bien de l'aide pour essayer de mettre en oeuvre l'application SDR embarquée sur PI (dernier Hackable page 88) car cette application peut vraiment être utile lors de tracking critique et j'ai déjà la clé USB SDR que j'utilise sur PC comme analyseur de spectre HF... Tu penses quoi de cet article? On en reparle en mail car je suis un peu hors sujet? (même si ça pourrait intéresser pas mal de monde ici!).
A bientôt.
Bruno

Bonjour à tous,
j'ai basculé les autres  éléments de réponse sur l'alimentation dans la rubrique alimentation.
A+
Hub

Merci beaucoup emmanuel pour ce travail!

J'ai hate de voir ce que donneront les circuits!!!

Fred

Bonjour à tous,

Après une interruption momentanée de l'image et du son, PiBatRecorder repart...
Désolé, j'étais fort occupé sur un nouveau projet que je vais évoquer ici.

Début 2015, j'ai développé un RhinoLogger, système chargé de mémoriser les activités d'un site occupé par des Grand Rhinolophe.
Il est composé d'un détecteur hétérodyne (D200) réglé sur 80kHz, d'une carte processeur Arduino et un petit peu d'électronique
chargés de détecter sur la sortie audio de l'hétérodyne les "tidadilou..." des GR et d'oublier les "tac, tac, tac.." des inévitables MOE.
Les activités sont mémorisées dans des fichiers CSV sur une carte SD.
Après un test satisfaisant d'un mois sur une colonie de repro, le système est installé fin aout 2015 sur un site de swarming et d'hivernage en sud Vendée.
Les résultats sont assez intéressants mais le système présente quelques inconvénients :
- Il consomme trop (~130mA) et, pour diminuer la consommation, le système est coupé en journée.
- Alimenté par une batterie 12V 40Ah, il faut la changer tout les 15 jours et, à l'automne, ce délai n'étant pas bien maitrisé, nous avons loupé quelques semaines.
- A la fin de l'hiver, le micro du D200 nous a lâché sans pouvoir s'en rendre compte (la baisse d'activité constatée à été mise sur le compte de la baisse des températures mais, après remonté de ces dernières, l'absence d'activité est devenue suspecte).
Nous n'avons donc pas une série de mesures complète sur l'ensemble de la saison.
- Avec le D200, le prix du système est de 300 à 500€.

Face à ces problèmes, au printemps 2016, j'ai commencé à réfléchir à une nouvelle version.
Déjà, j'ai trouvé une carte processeur plus puissante, compatible Arduino et très sobre coté consommation : Adafruit Feather M0 Adalogger.
Équipée d'un convertisseur analogique/digital, j'ai d'abord vérifié à quelle cadence il était possible de réaliser des acquisitions pour ensuite décider du système à mettre en place (division de fréquence ou spectre complet). Avec une fréquence d'acquisition maximale de 250kHz, le spectre complet était possible, Petit Rhinolophe y compris.
Restait à adapter le pré-ampli développé pour PiBatRecorder au niveau nécessaire au convertisseur (3V3 maximum). De 2 étages, il fallait passer à 4 pour obtenir un niveau de sortie acceptable. Sur cette base, j'ai monté une maquette sur une plaque de montage rapide, équipée d'un écran, une horloge sauvegardée, un clavier 5 touches et une sonde de température.

Après développement d'un logiciel minimal pour les tests, j'ai effectué quelques essais avec un émetteur US à 41kHz puis sur des sites à GR avec différents micros. Malgré quelques soucis avec le pré-ampli en juillet, les résultats étaient conformes à l'attendu et j'ai finalisé un logiciel.
Le traitement effectué est relativement sommaire. Avec le processeur, impossible de réaliser des acquisitions en continue et d'analyser les échantillons en parallèle. Les acquisitions sont effectuées sur 256 ou 512 échantillons et ont lieux respectivement toutes les 5ms ou 10ms. Les échantillons sont analysés (FFT) et le niveau maximum est recherché sur 5 bandes (FM-40-60kHz, bande GR, bande spécifique RE, bande commune RE/PR et bande spécifique PR avec des marges compte-tenu de la précision fréquentielle de l'analyse). Si le niveau dépasse le seuil sélectionné (seuil relatif au-dessus du bruit), une détection est déclarée. Une seule détection suffit pour la bande FM. Pour les bandes des Rhino, il faut que le nombre de détections dépassent un seuil sur une durée de 200ms pour décréter une détection de type fréquence constante (typiquement 18 à 20 détections pour 256 échantillons chaque 5ms, soit la moitié des détections possibles). Ensuite, 3 fichiers CSV sont créés: un fichier mémorisant le nombre de secondes et minutes positives par jour (une ligne par minute, un fichier par jour), un fichier mémorisant le nombre de minutes positives par heures (une ligne par heure, un fichier par jour) et un fichier mémorisant le nombre de minutes positives par jour (une ligne par jour, un fichier par année). Pour chacun de ces fichiers, sont aussi mémorisés la température, l'humidité et la tension batterie. Ils sont stockés sur une carte micro SD.
Après résolution des problèmes du pré-ampli fin juillet, j'ai réalisé deux prototypes. Le 1er est installé depuis le 31 aout 2016 sur le même site que l'année dernière en parallèle du modèle 2015 pour vérifier les résultats et pallier aux éventuels problèmes sur le nouveau modèle. Le second sera installé bientôt sur un autre site avec, nous l'espérons, des enregistrements SM2 en parallèle pour vérifier les résultats. Sur ce site, les trois espèces de Rhino sont présentes.

Coté consommation, les résultats sont très bons puisque le système consomme moins de 15mA. Une batterie 12V 40Ah permet une autonomie de 3 à 6 mois. Difficile d'être plus précis, une batterie au plomb qui a déjà quelques cycles à une auto-décharge voisine de la consommation du système ! Avec une autonomie aussi longue, j'ai ajouté un module GSM qui permet d'envoyer vers 3 numéros des SMS de synthèse journaliers pour surveiller à distance l'état du système. Bien entendu, il faut un accès au réseau sur le site. Une rallonge de 10m permet de placer l'antenne GSM à l'extérieur.

Coté résultats, il faut attendre encore quelques jours mais ils sont étonnants puisque nous avons de 900 à 1100 minutes positives par 24h pour les GR (550 à 600 pour le PR) soit 16h d'activités ! Attention, les GR ne tournent pas pendant 16h mais, pendant cette période, il y a ou moins un GR qui passe par minute. Placé à l'entrée, il semble que cette pièce soit occupée en priorité par les bêtes en cette saison. Le système 2015, avec un fonctionnement de 20h à 7h, ne permettait pas de détecter une activité aussi importante. Nous allons bientôt récupérer les 1er fichiers et, via les secondes positives, vérifier si les passages sont épisodiques ou s'il y a la fête dès que nous avons le dos tourné .

Coté prix, il est très bas puisqu'on est à moins de 250€ avec l'ensemble des options (batterie LiPo interne, batterie externe et SMS avec rallonge antenne de 10m) en sélectionnant les fournisseurs les moins chers.

La comparaison avec des enregistrements SM2 en continue reste à réaliser pour confirmer le bon fonctionnement du système...
Sur confirmation de ce test, je publierai le schéma, le logiciel et un dossier de fabrication.

A+

Jean-Do.

Quelques nouvelles du RhinoLogger. Les deux prototypes sont en fonction, l'un dans une cavité en sud Vendée qui transmet des SMS journaliers et l'autre dans une cavité à l'ouest de l'Indre-et-Loire.
Les courbes ci-dessous montrent l'activité journalière du site Vendéen. Après une forte activité des GR, ce sont les PR qui deviennent actifs. Aucune détection des RE, normal, cette espèce est absente du site. Mais justement, les PR sont aussi absent mais pourtant bien actifs !

En Indre-et-Loire, les activités sont moins importantes et Étienne S. a déposé un SM2 au même endroit pendant deux nuits et a dépouillé les résultats pour les comparer à ceux du RhinoLogger. A noter que le SM2 n'avait pas de trigger pour éviter de louper des cris.

Grand Rhinolophe :

Pour cette espèce, qui est la cible prioritaire du RhinoLogger, les courbes sont quasi identique, ce qui est très rassurant pour le système.

Petit Rhinolophe :

Pour cette espèce, l’activité reste très basse et, si les courbes sont globalement identique, il est évident que le RhinoLogger manque de sensibilité et aussi probablement qu’une partie des détections de Petit Rhinolophe se retrouvent dans la bande commune Euryale / Petit Rhino.
Malgré le filtre du préamplificateur favorisant les hautes fréquences, le micro MEMS manque de sensibilité à ces fréquences. Toutefois, les résultats du RhinoLogger pour cette espèce restent exploitables.
Il existe un autre biais : en présence d’une activité GR, ce dernier pouvant émettre fort et générer des harmoniques, les autres bandes ne sont pas traitées. Toutefois, du fait de la très faible activité des GR sur le site, ce phénomène doit être très marginal.

Il reste à expliquer le problème du sud Vendée. Si les courbes ci-dessus démontrent que RhinoLogger détecte le PR avec moins de sensibilité qu'un SM2, comment expliquer la forte activité détectée alors que l'espèce n'est, à priori, pas présente ? Seuls des enregistrements sur le site peuvent l'expliquer. C'est fait mais il faut attendre les dépouillements...

Rhinolophe Euryale

Pour cette espèce, RhinoLogger ne rapporte aucune détection dans la bande spécifique du Rhinolophe Euryale malgré la présence de l'espèce sur le site ! Les résultats présentés sur les courbes sont issus de la bande commune RE/PR. Il n’y a pas vraiment de corrélation des courbes et, après réflexion, il est assez difficile de détecter les activités des RE avec la méthode proposée par le RhinoLogger.
Le principe est le suivant, nous avons une acquisition à 250kHz de fréquence d'échantillonnage de 512 échantillons en 2ms toutes les 10ms. Le calcul FFT transforme les échantillons en un tableau de niveau pour 256 canaux de 500Hz. Pour les 5 bandes analysées, le système vérifie si un canal dépasse le seuil de détection et, si oui, on mémorise cette détection dans la bande considérée. Toutes les 200ms, si le nombre de détections dans la bande dépasse le seuil FC (9 détections minimums pour 20 détections possibles dans 200ms), on décrète que nous sommes en présence d’une fréquence constante dans la bande considérée et la minute est déclarée positive pour cette bande.
Ce calcul est vrai pour le GR. Mais, pour les RE et les PR, la proximité des bandes, l’étroitesse de la bande RE (100-102,4kHz soit 6 canaux de 500Hz) et la présence de la bande commune fait qu’il y a un traitement supplémentaire.
Pour les PR, on cumule les détections de la bande commune et la bande spécifique PR et, si le nombre de détections dépasse le seuil et que la fréquence maximum détectée est dans la bande PR, c’est cette dernière qui est détectée, sinon, c’est la bande commune.
Pour les RE, on cumule les détections de la bande commune et la bande spécifique RE et, si le nombre de détections dépasse le seuil et que la fréquence maximum détectée est dans la bande commune, c’est cette dernière qui est détectée, sinon, c’est la bande RE. En fait, dans l’idéal, il faudrait prendre la fréquence minimum pour prioriser la bande RE mais, avec les FM montantes et descendantes, ce n’est pas possible, la probabilité de détecter ces FM n’est pas nulle et dans ce cas, la fréquence minimale n’est pas significative pour la fréquence de la FC.
De plus, dans les exemples fournis par Étienne, les RE dépassent toujours 102,4kHz, ce qui explique que les détections ne soient jamais dans la bande spécifique.
Il faut revoir l’algorithme est je propose la solution suivantes :
RE, compter les détections dans les bandes 100-102,4 (bande spécifique RE) et 102,4-104 (partie de la bande commune avec RE le plus probable), si le total des détections dans 200ms dépassent le seuil, sélectionner la bande qui possède le plus de détections (RE ou bande commune).
PR, compter les détections dans les bandes 104-106,4 (partie de la bande commune avec PR le plus probable) et 106,4-120 (bande spécifique PR), si le total des détections dans 200ms dépassent le seuil, sélectionner la bande de la fréquence maximum (bande commune ou PR).

Je vais coder cette méthode et, si on a le temps, nous allons recommencer le test...
Et vivement les résultats de SM2 du sud Vendée pour vérifier le système avec beaucoup plus d'activités...