loguer des données (faible puissance)

[invite527cb2ce]

Bonjour,
Je cherche à réaliser un système pour enregistrer des données fournies par un capteur (environ 2 ko/s, communication soit par I2C, soit par SPI), pour ensuite les transférer vers l’ordinateur.
Le but est de pouvoir enregistrer ces données pendant au moins 2 jours (360 Mo de données au total) puis quelles soient conservées pendant au moins une semaine (pour laisser le temps d’aller récupérer le système et de le décharger).

Mes contraintes/souhaits sont les suivants*:
- possibilité d’écriture à au moins 2ko/s en moyenne (en temps réel ou par bloc)
- faible consommation d’énergie*: le capteur consommera environ 4mA en 3V, ça m’arrangerait si la consommation pouvait être faible en comparaison
- les données doivent pouvoir être conservées plusieurs jours après la fin de l’enregistrement*: il faut donc soit une mémoire non volatile, soit nécessitant très peu de courant.
- le système doit être le plus compact possible (idéalement pas plus de 2-3 cm²)
- le système ne doit pas être trop cher (idéalement pas plus de 20€/pièce pour une centaine de pièces)
- le système peut être à usage unique (la partie mécanique imposera probablement un usage unique de toute façon)
- alimentation en 3V probablement (sauf si vous avez une idée de pile très compacte pour une tension plus basse ou un système de conversion DC-DC qui tienne sur 1cm²)
- je n’ai pas vraiment de contraintes sur le système pour lire les données (100-200€ sont OK, pas de limitation de consommation électrique, peut nécessiter de petites manips)

A noter que toutes les contraintes peuvent être un peu relâchées si besoin.

Sans contraintes de taille et de consommation, j’aurais penché pour un microcontrôleur et une carte (micro-)SD. Mais je me demande s’il n’y a pas mieux à faire, surtout que le microcontrôleur ne fera rien d’autre que lire les données via l’I2C pour les écrire en mémoire*?

Est-ce que vous avez des idées*?

En vous remerciant par avance,
Cordialement
Sandro
-----

[invitee05a3fcc]

pour enregistrer des données fournies par un capteur

C'est quoi comme capteur ? Un lien WEB sur sa datasheet ?

[Murayama]

Bonjour!

Si vous avez des soucis de consommation, le MSP430 peut être une solution.
Ce n'est pas la seule, mais c'est efficace. Avant de vous lancer dans un circuit, il
est préférable d'utiliser une carte toute faite, par exemple celle ci.

Du point de vue taille de données, je crois que vous n'avez pas d'autre choix
que de prendre une carte SD, effectivement. Ou alors, il y a des chips flash série
(SPI aussi), et les derniers en date sont à 2Gb (MT29F2G01). Ce qui fait qu'avec
2 chips, vous pouvez stocker vos 360 MO. Mais vous aurez le problème de la récupération
des données. Par exemple utiliser un chip avec USB, ce qui n'est pas le cas du chip
ci-dessus.
Une carte SD consomme beaucoup, ou du moins consommait beaucoup quand j'ai
fait le prototype ci-dessous, donc l'idée est de partitionner la FRAM en une partition
de programme et une partition de données (attention à ne pas écraser les adresses
des routines d'interruption, classique avec le MSP 430 utilisé de cette façon).
Bref, vous faites 2 plages de plusieurs dizaines de kbytes, et vous écrivez vos données
temps réel pendant que vous recopiez l'autre partie de la mémoire dans la carte SD.
Consommation quasi nulle du MSP430 comparé à vos 4 mA. De mémoire, c'est dans
les 60µA/MHz (mais il faut vérifier(1)), et pour tourner à 2kbytes par seconde, 1MHz est
plus que suffisant. Et consommation de la carte SD uniquement quand vous écrivez
dedans.

(1) Les anciens MSP430 (qui datent de 15 ans et qui avaient des tailles de flash et de RAM
ridiculement petites) tournaient à 250 µA/MHz.

À tout hasard, j'avais fait cette carte dès la sortie des premiers processeurs équipés
d'USB. À l'époque, pas de FRAM, mais uniquement de la flash. J'avais mis 2 petites flash
de 32kB qui servaient à l'enregistrement parce qu'elles ne consommaient que 5 mA
contre 50 pour la carte SD (de mémoire, mais ça fait 8 ans).



C'est un logger à 8 canaux / 12 bits. La carte analogique se place dessous et communique
par le connecteur 50 broches à gauche. C'est trop gros pour vos specs, mais il y a plein de choses
dont vous n'avez pas besoin (chargeur LI-PO, USB, bouton de navigation, quartz "haute fréquence",
etc...). D'ailleurs, avec MSP430, on peut toujours se passer du quartz HF et utiliser le quartz
32k à partir duquel l'horloge est générée par FLL.

C'est quoi comme capteur ? Un lien WEB sur sa datasheet ?

Ça serait bien pour l'anecdote, mais par contre comme nous savons que le capteur
fonctionne en SPI et consomme 4mA en 3V, c'est une donnée qu'il n'est pas absolument
nécessaire.

(idéalement pas plus de 2-3 cm²)

Vous rêvez tout debout! 2cm², ça fait 1.4cm de côté, c'est la taille du chip.
À moins qu'il ne s'agisse de 2~3cm, le tout au carré, ce qui
nous amène environ à 10. En mettant les composants d'un côté et la carte SD de l'autre,
ça pourrait aller si vous prenez tous les chips en BGA et des résistances 1005 qui ne sont
pas très faciles à souder à la main. La carte ci-dessus est en 1608, ce qui n'est pas trop
difficile après avoir soudé quelques composants. J'imagine que vu le prix vous excluez aussi
la technologie COB (chip on board, soit le semiconducteur directement posé sur la carte,
sans boîtier, et relié au PCB en wire bonding avant d'être recouvert de pâte de réglisse).

Pascal

[invitee05a3fcc]

Ça serait bien pour l'anecdote, mais par contre comme nous savons que le capteur fonctionne en SPI et consomme 4mA en 3V, c'est une donnée qu'il n'est pas absolument nécessaire.

Peut être pour toi, pas pour moi.

[A voir en vidéo sur Futura]

[invite936c567e]

Peut être pour toi, pas pour moi.

En effet, la nature des données enregistrées et les informations utiles qu'elles contiennent pourraient notamment remettre en question le volume de 360 Mo a priori nécessaire.

[invitee05a3fcc]

En effet, la nature des données enregistrées et les informations utiles qu'elles contiennent pourraient notamment remettre en question le volume de 360 Mo a priori nécessaire.

Entre autres ....
Mais aussi de justifier

............... des données fournies par un capteur (environ 2 ko/s,)

Si c'est un capteur de température, ça me semble beaucoup !
De plus, il faut peut être rajouter des timings codes

[invite527cb2ce]

Bonjour,
et merci pour vos réponses.

Tout d'abord pour ce qui est du capteur, il s'agit d'un IMU+magnétomètre : j'ai pas encore regardé assez de modèles pour arrêter un choix, mais pour l'instant celui qui me semble le mieux est celui-ci : http://www.st.com/content/ccc/resour...DM00103319.pdf (dimension : 3*3mm, courant environ 4mA, communication I2C et SPI).

Pour la quantité exacte de données, ça peut varier un peu : d'un coté on peut compresser un peu les données, d'un autre, je ne sais pas encore exactement quel IMU j'utiliserais ni à quelle fréquence je lirais les données. Pour l'utilisation des données, le but est de pouvoir avoir le déplacement du capteur pendant si possible 48h, aussi précisément que possible (ou plutôt aussi peu imprécisément que possible) : plus j'enregistre de données, mieux je pourrais reconstruire la trajectoire.


Pour la question de la consommation électrique, c'est une contrainte indirecte : je veux que mon système entre dans une sphère de diamètre aussi petit que possible, mais les batteries étant assez volumineuses, il vaut mieux réduire la consommation pour éviter de trop grosses batteries. Je pensais m’orienter vers des piles bouton de diamètre 20mm, à la limite 23 ou 24.5mm. Ça m'arrangerait donc d'avoir un PCB de la même dimensions (après réflexion, il doit être possible d'utiliser les deux faces du PCB et de mettre le support de la batterie par dessus des composants).
En gros, je cherche un compromis entre une taille aussi réduite que possible (30 mm de diamètre maximum, moins étant mieux) et une autonomie aussi grande que possible (au moins 24 heures, plus étant mieux). Deux autres critères sont la qualité de la mesure de l'IMU et le prix, mais ces deux critères sont moins importants tant que ça reste raisonnable (pour le prix, 100€/pièce grand max assemblage compris pour une série de 100 ou 1000 pièces).

Pour la fabrication, je ne compte pas faire l'assemblage moi même (sauf peut-être un premier proto avec des développement bord), donc pas de problème pour utiliser de petits composants en montage de surface ou du ball array.
Pour le COB, je connaissais pas (sauf justement pour réaliser le boitier des composants) : j'ai rapidement regardé, mais je n'ai pas trouvé pour l'instant d'indications ni sur le coût pour un prototype/de petites séries, ni où commander les composants sans le boîtier.

Pour le MSP430, ça me semble un bon choix (environ 200µA si on utilise la FRAM avec 20% de cache-miss). En plus il est disponible en format 6*6mm, ce qui est pas mal.


L'idée de bufferiser les données avant de les écrire en mémoire non volatile est très bonne.
Pour la mémoire, la carte micro-SD est une solution, mais elle prend tout un coté (après, c'est bien pratique pour récupérer les données). Comme je crains que le magnétomètre ne marche pas très bien s'il est coincé entre la pile et la carte SD, il faudra donc mettre la carte SD sous la pile, mais je pense que c'est faisable. Par contre je n'ai pas encore trouvé de datasheet de carte micro-SD qui donne la consommation.
Pour la flash, en série on est vite limité, mais est-ce un problème d'être en 8bits parallèle? (il y a bien assez de pins sur le microcontrôleur). Pour ce qui est de récupérer les données ensuite, je pense pas que ce soit un vrai problème : il suffit de prévoir un connecteur à 3 fils pour connecter le microcontrôleur par I2C ou SPI à un Arduino qui pourra lui les transmettre à l'ordinateur par USB.

En vous remerciant par avance
Cordialement
Sandro

[invitef86a6203]

Un Arduino et une carte SD
https://www.arduino.cc/en/Reference/SD

Il faudra faire des flush régulièrement pour ne pas perdre de données ou faire plusieurs fichiers si besoin.
La taille de la SD dépendra des besoins, il suffira d'échanger la carte pour récupérer les données.

Il faudrait surtout faire le calcul de la consommation , car si c'est des piles ,il faudra les changer souvent.

[invitee05a3fcc]

plus j'enregistre de données, mieux je pourrais reconstruire la trajectoire.

Avant de penser mettre ton truc dans un dé à coudre, il faudrait vérifier que ta trajectoire peut être reconstituée à partir des données stockées en faisant abstraction de la taille de l'électronique.

Le gros problème, c'est le calcul de la trajectoire à partir accéléromètres. En effet, il faut intégrer accélération pour avoir la vitesse , il faut intégrer la vitesse pour avoir la distance .
Or, un intégrateur, ça dérive ......
En général, on couple ce genre de produit avec un GPS (qui ne dérive pas) et qui permet de recaler les erreurs de calcul des intégrateurs

C'est pour ça que la spec signale un usage Indoor (où le GPS est très mauvais)

Utiliser ton LSM9DS1 sur 48 heures ..... je demande à voir la restitution de la trajectoire avant de discuter de la taille de la pile !

[invite527cb2ce]

@freepicbasic : merci pour ta réponse : un arduino fera probablement bien l'affaire pour le tout début du prototypage, mais il est beaucoup trop grand et consomme trop (18mA au repos pour un Nano).

@Daudet78 : j'ai bien conscience que dans l'idéal il faudrait des coordonnées absolues type GPS, mais pour mon application il n'y aura malheureusement pas de signal GPS disponible. Je dispose des coordonnées GPS du départ et de l'arrivée, éventuellement de quelques points intermédiaires, mais c'est tout. Après, mes exigences en termes de précision sont très faibles, déjà rien que la forme globale de la trajectoire (fréquence de changement de trajectoire, trajectoire "locale", valeur des accélérations, ...) est une information intéressante.
Pour ce qui est de la qualité de la reconstruction, je comptais faire des simulations numériques pour tester différents algos. Par contre je pense qu'il est plus facile de m'assurer que du point de vue électrique j'arrive à tenir mon cahier des charges que de me plonger dans l'état de l'art de la reconstruction de trajectoires par données inertielles. Sans compter que je suis encore en l'attente de trajectoires types qu'un ami doit m'envoyer (il m'a prévenu que ça risquait de prendre un peu de temps avant qu'il n'ait le temps de chercher ces données et de les convertir en un format exploitable.

, mais premièrement j'attends encore qu'un ami m'envoie les trajectoires types (ce qui risque de prendre un peu de temps), et je pense qu'il est plus rapide de m'assurer au moins de la faisabilité au niveau électronique

[invitee05a3fcc]

Par contre je pense qu'il est plus facile de m'assurer que du point de vue électrique j'arrive à tenir mon cahier des charges que de me plonger dans l'état de l'art de la reconstruction de trajectoires par données inertielles.

C'est sûr que si tu fais tenir dans un dé à coudre un truc qui ne marche pas .... tu auras gagné le cocotier. Moi, j'appelle ça mettre la charrue avant les boeufs !

[invitef86a6203]

mais il est beaucoup trop grand et consomme trop (18mA au repos pour un Nano).

Arduino c'est juste un µc ATMEGA328 pour un nano, avec quelques bricoles autour qui consomme en plus et qui font surtout que la programmation est facilité.
Si on enlève tout ce qui n'est pas indispensable , il suffit de se référer au datasheet voir ci-joint pour la conso.

De plus un chiffre absolu trouver sur le net ne signifie rien !
La consommation dépend de la vitesse de l'horloge et de ce qu'il fait et des charges sur ses pins.
Avec une horloge à 32khz, évidemment ça consomme moins sur n'importe quelle µc, mais alors on a une brouette à la place d'un mustang...
Faire du SPI à cette vitesse ça va pas être triste, bon courage pour le développement.

Peut être faut il plutôt jouer avec le mode sleep ?

[invitef86a6203]

DAUDET78 a raison si le but est mettre "un sac à dos électronique" LOL à un pigeon avec un simple accéléromètre, ça demande une étude sérieuse...

Déjà, en se promenant avec le proto et en essayant de reconstituer le trajet connu.
ça va forcément dériver !

L'initialisation pour savoir la position des 3 axes de départ, sur le dos d'un animal risque de ne pas être simple non plus.

[invite527cb2ce]

C'est sûr que si tu fais tenir dans un dé à coudre un truc qui ne marche pas .... tu auras gagné le cocotier. Moi, j'appelle ça mettre la charrue avant les boeufs !

Ne t'en fait pas, j'ai pas l'intention de commander de composants, ni même de faire le circuit électronique détaillé avant d'avoir fait mes simulations. Mais vue que de toute façon je dois attendre les données des trajectoires avant de pouvoir commencer à faire des simulations, autant commencer à m'intéresser à la partie électronique. Sans compter que si je n'ai pas au moins une vague idée de la précision des capteurs et de l'autonomie (donc de la durée sur laquelle simuler), alors je voie mal comment je peux faire une simulation.

@freepicbasic : désolé, je pensais que tu suggérais d'utiliser un Arduino tel quel. Uttiliser un atmega est tout à fait possible. Et l’Arduino est une excellente "development board", certainement la plus conviviale que j'ai utilisée jusqu'à présent (d'ailleurs, pour bien des projets l'Arduino "tel quel" fait parfaitement l'affaire jusqu'au bout, mais malheureusement pas dans mon cas).

Pour la consommation, que j'ai donnée pour l'arduino nano, c'est celle à vide (pins en output, à LOW, sans charge) avec une boucle "loop" vide, d'après le test suivant : https://www.carnetdumaker.net/articl...et-compatible/ . Après, on peut toujours bidouiller avec des sleep, essayer de changer la fréquence d'horloge, ..., mais ça donne une idée de la consommation à vide pour une utilisation standard.

Avec une horloge à 32k, évidemment ça consomme moins sur n'importe quelle µc, mais alors on a une brouette à la place d'un mustang...

Car tu utilise un mustang pour aller chercher tes légumes au jardin?
Les 32kHz, ça pourrait peut-être même suffire si je ne fais pas de compression (ça laisse 16 instructions pour lire un octet et l'écrire dans la flash), mais c'est vrai qu'il vaut peut-être mieux jouer avec du sleep et/ou des interruptions : à creuser

[invite527cb2ce]

DAUDET78 a raison si le but est mettre "un sac à dos électronique" LOL à un pigeon avec un simple accéléromètre, ça demande une étude sérieuse...

Non, les pigeon, je les laisse tranquille, promis. Par contre j'ai bien l'intention de passer plusieurs jours à faire des simulations et tester différents algorithmes (je ne pense pas qu'une bête intégration soit la meilleur solution, je pensais par exemple à essayer v(t)=exp(-dt/tau)*v(t-1)+a(t)*dt pour prendre en compte le fait qu'on ne vas jamais très loin sans changer de direction ou s'arrêter). Mais comme s'assurer que le projet est électriquement faisable est bien plus rapide que de m'assurer de la qualité du résultat, je commence par la faisabilité de la partie électrique.

Déjà, en se promenant avec le proto et en essayant de reconstituer le trajet connu.
ça va forcément dériver !

C'est au programme (pour cette étape j'utiliserais probablement un arduino, un shield SD et un IMU monté sur une carte de développement). Puis j'irais me promener en ville pendant quelques heures en notant bien mon trajet sur une car

L'initialisation pour savoir la position des 3 axes de départ, sur le dos d'un animal risque de ne pas être simple non plus.

L'initialisation ne devrait pas trop être un problème :
- l'accélération moyenne donne le vecteur gravité
- comme indiqué, je prends un IMU avec magnétomètre, donc j'ai le vecteur champ magnétique (qui est connu pour une position géographique donnée)

J'ai donc deux vecteurs non colinéaires, qui suffisent à me définir un repère (je peux prendre le 3ième vecteur comme étant leur produit vectoriel). Comme je connais les vecteurs champ magnétique et gravité dans le référentiel terrestre, j'en déduis l'orientation de mes 3 axes. Mieux encore, je peux appliqué le même procédé sur toute fenêtre de temps suffisamment longue et ainsi avoir en permanence une mesure absolue de l'orientation.

[invitee05a3fcc]

Mais comme s'assurer que le projet est électriquement faisable est bien plus rapide que de m'assurer de la qualité du résultat, je commence par la faisabilité de la partie électrique.

C'est beau l'enthousiasme/inconscience de la jeunesse..... Mais j’espère pour toi que tu as fait des progrès depuis cette discussion .

[invite936c567e]

Si l'on part sur un ATmega328P "standalone" avec une interface USB-série séparée de l'appareil, sous une tension d'alimentation d'environ 3V, la consommation en fonctionnement peut être limitée à moins de 0,6 mA en utilisant l'horloge RC interne à 1MHz, et à moins de 60 µA avec l'horloge RC interne à 128 kHz.


Concernant la consommation des cartes SD, elle est assez variable et dépend de la capacité de mémoire et de la marque. SanDisk annonce par exemple un courant maximum de 100mA, mais on constate généralement une consommation plus réduite, de 5mA à plusieurs dizaines de milliampères en fonctionnement. Le courant chute au-dessous du milliampère lorsque la carte est mise en sommeil.

Pour rendre le projet viable, il faudra trouver un modèle de carte consommant le moins possible, et mettre en place un système de cache afin d'y écrire les données rapidement entre deux plus longues phases de mise en sommeil.


Pour les piles, une CR2450 (lithium 3V, diamètre 24mm) est capable de délivrer un courant discontinu de 10 mA pour une capacité effective d'un peu plus de 200 mAh (à 25°C).

Une CR2032 (diamètre 20mm), plus classique, présente une capacité moindre et supporte un courant plus faible, du fait de sa résistance interne plus importante qui fait chuter la tension. Compter environ 100 mAh sous 3 mA.

Une batterie rechargeable LIR2450 (3,6V, diamètre 24mm) présente une capacité effective à peu près deux fois moindre qu'une pile CR2450, mais en contrepartie supporte un courant 5 à 10 fois plus élevé.

[bobflux]

Avant de penser à l'implémentation du produit fini, il faut faire un proto gros et moche qui te permettra de valider que les données fournies par ton IMU te conviennent. Donc un microcontroleur quelconque, une grosse pile, une carte SD...

[invite527cb2ce]

@Pa5cal : merci beaucoup pour toutes ces informations.

Concernant la consommation des cartes SD, elle est assez variable et dépend de la capacité de mémoire et de la marque. SanDisk annonce par exemple un courant maximum de 100mA, mais on constate généralement une consommation plus réduite, de 5mA à plusieurs dizaines de milliampères en fonctionnement. Le courant chute au-dessous du milliampère lorsque la carte est mise en sommeil.

Pour rendre le projet viable, il faudra trouver un modèle de carte consommant le moins possible, et mettre en place un système de cache afin d'y écrire les données rapidement entre deux plus longues phases de mise en sommeil.

Tu penses que j'ai des chances d'obtenir des informations détaillées sur internet et/ou en envoyant un mail aux fabricants? Ou faut-il acheter des cartes "au hasard" et tester?

Pour les piles, une CR2450 (lithium 3V, diamètre 24mm) est capable de délivrer un courant discontinu de 10 mA pour une capacité effective d'un peu plus de 200 mAh (à 25°C).

Une CR2032 (diamètre 20mm), plus classique, présente une capacité moindre et supporte un courant plus faible, du fait de sa résistance interne plus importante qui fait chuter la tension. Compter environ 100 mAh sous 3 mA.

Une batterie rechargeable LIR2450 (3,6V, diamètre 24mm) présente une capacité effective à peu près deux fois moindre qu'une pile CR2450, mais en contrepartie supporte un courant 5 à 10 fois plus élevé.

Merci beaucoup pou ces valeurs. Je pense qu'il vas donc falloir que je me résigne à un diamètre de 24mm (un peu plus avec le support de la pile), surtout que je vais surtout travailler en environnement plutôt froid (0-12°C) ce qui vas encore diminuer un peu la capacité de la pile d'après ce que j'ai compris.

@bobflux : le prototype gros et moche est prévus, mais en tant qu'étudiant fauché en vacances, je préfère réfléchir un peu plus avant

[invite936c567e]

Tu penses que j'ai des chances d'obtenir des informations détaillées sur internet et/ou en envoyant un mail aux fabricants? Ou faut-il acheter des cartes "au hasard" et tester?

En fait, toute la difficulté est de faire la relation entre une référence à propos de laquelle on peut obtenir des informations précises et un produit qu'on peut acheter à bas prix. Dans les cas où cette mise en correspondance est garantie (magasins spécialisés), le prix d'achat de la carte risque de dépasser à lui seul le budget alloué.

je vais surtout travailler en environnement plutôt froid (0-12°C) ce qui vas encore diminuer un peu la capacité de la pile d'après ce que j'ai compris.

Un peu ... ou un peu plus.

Le froid dégrade notablement les performances des piles. Non seulement la capacité effective chute, mais pour un courant donné, la tension produite s'effondre. Si le courant est important, alors il n'est pas sûr que le fonctionnement prévu reste possible.

Pour fixer les idées, voici l'impact de la température sur la courbe de décharge d'une pile CR2032, pour un courant de seulement 1 mA :

[invitef86a6203]

2 remarques;

1)
Le champ magnétique n'est pas une référence absolu et il varie localement, sans parler des nombreuse masses métalliques d'origine humaine disséminées un peu partout.

2)
Il ne faut pas oublier que dans la vrai vie on est en 3D, et qu'un simple marcheur engendre des accélérations haut/bas et des chocs qui ne vont pas être négligeables du tout, et difficiles à prendre en compte.

A la rigueur un planeur sans trop de perturbations, mais même là, la dérive, va vite de faire sentir.

[invite527cb2ce]

Merci beaucoup pour ces remarques.
Il faut donc compter 30-40% de puissance disponible en moins.

A priori, je n'aurais pas de masses métalliques à proximité. Pour les variations locales, il faut que je me renseigne, mais il me semble que c'est assez faible pour être négligé dans un milieu sans roches ferromagnétiques et en l’absence de perturbations humaines.

Je compte étudier des écoulements d'eau, donc à priori il n'y aura pas de grosses accélérations haut-bas (par contre il y aura des rotations sur soit même et des remous)

[invite936c567e]

Il faut donc compter 30-40% de puissance disponible en moins.

C'est un peu plus compliqué que ça.

Par exemple, si le circuit exige un minimum de 2,5V pour fonctionner et si le fort courant consommé fait immédiatement chuter la tension de la pile à 2,4V, alors on peut dire que le froid a fait disparaître 100% de la puissance utile.

[invite527cb2ce]

D'accord avec toi.
Pour l'IMU, il fonctionne jusqu'à 1.71V, donc pas de problème.
Pour le microcontrôleur, je pensais m’orienter vers du 1.8V nominal.
Pour la carte SD, il me semble que certaines nécessitent du 3.3V mais que d'autres fonctionnent en 1.8V.

Après je dois vérifier si les composants résistent à du 3V. Sinon il faut ajouter un petit convertisseur (ça augmente l'autonomie mais ça fait des composants en plus)

[invitef86a6203]

Je compte étudier des écoulements d'eau, donc à priori il n'y aura pas de grosses accélérations haut-bas (par contre il y aura des rotations sur soit même et des remous)

Un (des) siphon ou une (des) cascade genre machine à laver.
Bon courage !

[invitee05a3fcc]

Un (des) siphon ou une (des) cascade genre machine à laver.

je verrais plutôt un écoulement d'eau souterrain

surtout que je vais surtout travailler en environnement plutôt froid (0-12°C) ce qui vas encore diminuer un peu la capacité de la pile d'après ce que j'ai compris.

Vu la gamme de température

[invitef86a6203]

plutôt froid (0-12°C)

Fonte des glaces; Groenland , glaciers ,pôles ...
Donc siphons et cascades !

J'imagine le bidule tournicotant en se cognant , pour reconstituer la trajectoire par le calcul...

[invite527cb2ce]

je verrais plutôt un écoulement d'eau souterrain Vu la gamme de température

Correct
Pour les siphons, je pense pas que ça pose problèmes pour la mesure de la trajectoire, l'eau y est en générale plutôt calme (par contre ça m'oblige à lester mon système pour avoir une densité quasi-égale à celle de l'eau).
Pour les cascades, au pire c'est de la chute libre, donc une accélération de 1g (enfin, l'accéléromètre mesurera 0g vue qu'il soustrait la gravité). Pour les tourbillons, c'est je pas non plus des accélérations trop brutales ni changeant trop vite. Les chocs contre les partoies risqu'ent d'être un peu plus dur à traiter.

[invitee05a3fcc]

Correct
Pour les siphons, je pense pas que ça pose problèmes pour la mesure de la trajectoire, l'eau y est en générale plutôt calme (par contre ça m'oblige à lester mon système pour avoir une densité quasi-égale à celle de l'eau).

C'était Top Secret Défonce ?
Pourquoi ne pas le dire dès le départ et attendre ma boule de cristal ?

[invite527cb2ce]

C'était Top Secret Défonce ?

Quand même pas.
Mais l'hydro-géologue avec qui j'en parlais semblait d'avis que si ça fonctionne ça pourrait se commercialiser, donc autant éviter de le crier sur tous les toits