Pour le moi de Juin l'objectif est d'obtenir les cartes électronique précédemment schématisées. Une vérification du schéma en groupe sera toutefois nécessaire au préalable afin de s'assurer qu'il ne réside pas d'erreur de conception. En parallèle une version “éparpillé” de la carte sera développer là encore dans le but d'observer le comportement du circuit non intégré.

Le micro développé par l'institut d'Alembert a été ajouté au schéma, de même l'utilisation du GPS à également été approfondie.

Comme déterminé en réunion avec R. Marchiano. Il est préférable d'utiliser le micro ainsi que l'accéléromètre avec le microcontrôleur déjà développer par les ingénieurs de l'Institut. La communication avec l'Arduino se fera via le protocole SPI avec le microcontroleur étant l'esclave. Le prototype est constitué d'une carte stm32nucleo sur laquelle sont branchés les composants micro et accéléromètre. Cette version bien que fonctionnel n'est pas intégrable sous cette forme actuel, il convient d'intégrer le composant de la carte nucleo au schéma. Le micro ainsi que l'accéléromètre ont été ajouté conformément au schéma du prototype, pour le microcontroleur STM32F103CBT6 la conception est d'avantage compliquée. En effet, seul le liaison SPI et I2S seront utilisés, par conséquent il est judicieux de repérer les sortie du processeur qu'il est utile de connecter et celle qui ne le sont pas. Il est de même important de vérifier que le microcontrôleur pourra être programmé. La possibilité d'utiliser le même port USB que celui utilisé pour la programmation du RFduino doit être assuré. Une discussion avec les ingénieur du prototype pourra être entreprise.

mouvie_v2_v1.pdf

Le protocole SPI donne des résultats étrange. Après utilisation de la fonction SPI.transfert avec en argument l'octet à lire. Seul des 0 sont obtenus. Problème de compréhension du fonctionnement de SPI, comment sont transmise les données du GPS et où sont elles stockée (buffer, registre???). Au niveau des signaux observés à l’oscilloscope, la sortie MOSI transmet un signal tandis que MISO et CLK sont nuls. Ce résultat est étrange puisque l’Arduino n'est pas sensé transmettre des données. La bibliothèque tinyGPS à également été utilisée celle ci permet de convertir des données au format NMEA en donnée accessible pour l'utilisateur. L'ensemble des codes donnés en exemple n'utilise que la liaison série toutefois une fois la transmission SPI maitrisée les fonctions de conversion pourront être utilisée.

Une modification du schéma a été effectué avec l'ajout de sample and hold. De même l'étude de la transmission du SPI à été approfondie.

Le Sample and Hold permet de faire un échantillon d'un signal en maintenant une valeur sur une durée donnée. L’intérêt est de pouvoir comparer les valeurs auxiliaire et et réel des capteur alphasense au même instant.

On branche, à l'entrée du composant choisit (LF398M), la référence logique qui va envoyer un signal créneau indiquant à l'état haut la période d'acquisition et à l'état bas le temps de “holding”. On prendra 2µs pour l'échantillonage (notice d'utilisation) et le temps d'acquisition des mesure pour le maintient.

mouvie_v2_v2.pdf

Le protocole SPI fonctionne généralement en buffer circulaire. Le maitre envoie une données à l'esclave qui renvoi une donnée au maitre.

Il faut don connaitre l'organistation des registre de l'esclave pour obtenir les données. Cependant aucune information n'est donnée à ce sujet dans le détail de fonctionnement du GPS

Journée essentiellement consacrée à l'étude du GPS.

Comme vu précédemment afin de récupérer les différentes données du module A2235h il est nécessaire de connaître les registres. http://update.maestro-wireless.com/GNSS/A2100-AB/Maestro_GPS_AppNote_SPI_Interface_On_GPS_Receiver_A2100_AB.pdf

Le précédent document décrit d'avantage le processus SPI pour le GPS A2100. Même si ce module est différent de celui que nous souhaitons tester il possède un fonctionnement similaire.

Dans cette fiche technique on note que le buffer permettant le stockage des données est de 1024 byte. Ainsi 1024 registre pouront être récupéré. Des interruptions sont prévus pour le cas ou la mémoire est vide.

Pour le programme il faut: définir les paramètres (vitesse, poids du premier bit et Mode du SPI)

Vérifier que l'horloge génére bien un signal

Lire la trame NMEA byte par byte

Si le GPS ne recoit pas de donnée les valeurs lue sont 0xB4 ou 0xA7.

On se propose donc de tester le code suivant:

#include <SPI.h>
#define VITESSE 6800000

unsigned int result=0;
int reg=0x00;
int i=0;
void setup() {
  Serial.begin(9600);

  // start the SPI library:
 SPI.beginTransaction(SPISettings(VITESSE,MSBFIRST,SPI_MODE1));
  pinMode (SS, OUTPUT);

}
void loop() {

  for(i=0;i<=1023;i++){
    digitalWrite(SS, LOW);

result=SPI.transfer(reg);
  digitalWrite(SS, HIGH);
  reg=(reg<<8);
  Serial.println(reg,HEX);
delay (1000);
  //SPI.endTransaction();
  Serial.println(result,HEX);
  }

}

Les résultats obtenus sont 0 pour le registre puis 0 pour la valeur avant de se bloquer après une boucle.

Aucun signal d'horloge n'est envoyé au GPS, ce qui mène a penser que le module est mal branché entraînant une absence d'horloge de son coté. Un kit dévaluation devra être envoyé.

Le code Shinyei+alaphasense a été développé, de même des stratégies concernant l'insertions du micro ont pu être élaborées à la suite d'une réunion avec les membres de l'institut d'Alembert.

Le code Arduino visant à contrôler simultanément les capteurs d'Ozone/NOx Alphasense et le compteur de particules Shinyei, à été développée quelque jour plus tôt mais pas testé. Après une première mesure vérification des sortie on remarque en niveau limitant PM2.5 PM10 beaucoup trop élevé. En débranchant puis branchant à nouveau le câble on retrouve le niveau souhaité. Il conviendra de vérifier à nouveau qu'une telle erreur ne se produit pas. Concernant le calcul du taux de PM2.5 et de PM10 il à fallut ajouter les concentration de PM2.5 à celle de PM10. En effet le capteur distingue les valeurs en dessous et au dessus de la limite PM2.5/PM10 afin de déterminer des taille de particule, seulement, il ne faut pas oublier qu'une PM10 comprends toute les valeurs inférieur à 10 µm et par conséquent les PM2.5. Ces erreurs corrigée le code suivant est obtenu.

Une conversion pcf/0.01cf à ppm pourra être envisagée.

Pascal Chalande et Héléne Moingeon, les développeurs du compagnon sur le stm32, étaient présents. Le but était d'aboutir à une solution pour enregistrer les données du micro sur la carte SD.

Pour rappelle le composant micro est constitué d'un accéléromètre et d'un microphone produisant 8 types de données stockées toute les secondes sur le microcontrôleur stm32.

La première idée envisagée est de connecter le stm32 à l'arduino via le protocole SPI l'arduino étant le maitre et le micro l'esclave. Cette solution suscite de nombreuses questions au niveau de la transmission des données puisqu'il est difficile d'interpréter comment sont enregistrée les valeurs et si l'arduino attends que son esclave soit prêt.

La deuxième solution consiste à s'astriendre de la connexion avec l'Arduino en communiquant directement avec la carte SD. En effet il est possible de gerrer une utilisation commune en attendant, si la carte est occupée avec un des microcontroleurs que celle ci est fini pour procéder au stockage.

C'est la deuxième solution qui sera testée dans un premier temps.

Pour l'intégration du micro sur le schéma on se propose de connecter uniquement les composant propre aux sorties SPI et I2S. La programmation ne se fera pas via l'USB mais à l'aide d'embase déjà présente sur la carte de développement du stm32 (nucleo).

Plusieurs modifications ont été apportée au schéma. Le micro à été développé en ajoutant et connectant le LQFP-64 (microcontroleur du stm32).

Les branchement ont été effectués conformément au remarques de la réunion du 09/06.

Les connections SPI ont également été modifiée en utilisant plusieurs pin différentes pour chaque SS.

Ajout d'un indicateur de niveau de batterie.

L'idée consiste à comparer la valeur de la tension délivrée par la batterie avec une tension de référence qui fera office de seuil. Quand le niveau de la batterie descend sous ce seuil la diode une diode va s'allumer.

Pour comparer les deux tension on utilisera un amplificateur opérationnel. En branchant la batterie sur l'entrée - et la valeur de référence sur la borne +, on obtiendra un signal créneaux positif quand la tension de la batterie est inférieur au seuil et négatif quand il est au dessus. On utilisera un indicateur pour chaque batterie et on reliera chacune des sortie avant d'alimenter la DEL.

Sur le schéma on observe que lorsque la courbe bleu correspondant à Ve passe sous la valeur seuil en vert la tension de sortie passe de 0 à 3.3V.

Sur le circuit on utilisera des diode zener pour réguler la tension.