Yocto-SPI et Alphasense OPC-N3

Yocto-SPI et Alphasense OPC-N3

La documentation du Yocto-SPI comprend un exemple pour interfacer le compteur de particules OPC-N2 d'AlphaSense. Depuis, AlphaSense a sorti un nouveau modèle, l'OPC-N3, et les commandes pour l'interroger sont légèrement différentes. Cette semaine, à la demande générale, on vous explique comment faire fonctionner l'OPC-N3 avec un Yocto-SPI et on en profite pour vous présenter une petite nouveauté :-)




A première vue, rien ne distingue un OPC-N2 d'un OPC-N3, à part l'étiquette d'identification qui se trouve sous le capteur.

Un OPC-N3 à côté d'un OPC-N2
Un OPC-N3 à côté d'un OPC-N2


En revanche l'interface de contrôle SPI est juste assez différente de la version précédente pour que si on utilise le protocole de l'ancienne version, cela plante littéralement le capteur. C'est d'ailleurs un détail à retenir, si pendant vos essais avec un OPC-N3, une de vos commandes SPI ne fonctionne pas comme vous vous y attendiez, vous aurez avantage à faire un power-cycle du capteur pour repartir sur une base saine.

Connexion électrique

La connexion physique SPI ne diffère pas de l'ancienne version, face au capteur, les fils sont, de gauche à droite : GND, SS, SDI, SDO, SCK et +5V. N'oubliez pas que vous devez croiser SDI et SDO entre le capteur et le Yocto-SPI.

Connexion électrique, vue de dessus
Connexion électrique, vue de dessus


La configuration du port SPI du Yocto-SPI reste aussi la même: l'OPC-N3 est alimenté en 5V, mais la communication SPI se fait en 3.3V. Vous trouverez la totalité des réglages dans la capture d'écran du VirtualHub ci-dessous:

Configuration du port SPI
Configuration du port SPI


Interrogation du capteur

C'est là que les choses se corsent. Grâce à son système de jobs, le Yocto-SPI est capable d'interroger automatiquement le capteur, mais Alphasense a modifié le protocole SPI entre les version N2 et N3. En particulier, le ventilateur et le laser doivent être contrôlés indépendamment dans la version N3. Pour piloter l'OPC-N3, vous devez créer un job qui contient trois tâches:

  1. Une tâche périodique d'initialisation qui attend un peu que le capteur démarre, puis allume le ventilateur et le laser:

    • wait 3000
    • writeHex 03
    • wait 10
    • writeHex 0307
    • wait 10
    • writeHex 03
    • wait 10
    • writeHex 0303

    Cette tâche ne doit bien sûr être exécutée qu'une seule fois.

  2. Une seconde tâche périodique, qui attend 150ms, pour être sûr de causer un timeout sur une éventuelle commande précédente qui ne se serait pas terminée correctement, puis qui essaye de lire le capteur en envoyant la commande 0x32 16 fois de suite, mais en attendant 10ms après le premier byte.

    • wait 150
    • writeHex 32
    • wait 10
    • writeHex 323232323232323232323232323232

    Cette tâche doit être répétée à intervalle régulier, typiquement 2.5 seconde. Si vous essayez d'aller trop vite, il arrive que le capteur plante au bout de quelques minutes de fonctionnement.

  3. Enfin une troisième tâche, réactive celle-là, qui détecte une réponse qui commence par 0xF3 et interprète les trois valeurs et le CRC qui se trouvent derrière et les affectent aux generic sensors 1,2 et 3 du Yocto-SPI. Ces valeurs, qui correspondent aux particules PM1, PM2.5 et PM10, sont exprimées en µg/m³.
    • expect F3($1:FLOAT32)($2:FLOAT32)($3:FLOAT32)(WORD)

Ce job fonctionne très bien sur l'OPC-N3. Mais sachant que les tâches d'un job tournent en parallèle, il y a de bonnes chances pour que le Yocto-SPI essaye d'interroger le capteur avant d'avoir allumé le ventilateur et le laser, ce qui manque un peu d'élégance. Il se trouve que tous les modules qui disposent du système de jobs viennent d'hériter d'une nouvelle instruction: assert.

Interrogation du capteur: variante

Cette instruction assert évalue une expression booléenne et stoppe l'exécution de la tâche si l'expression est évaluée à Faux, ou si l'expression contient une erreur de syntaxe ou encore si elle fait référence à une variable non définie. Ça n'a l'air de rien présenté comme ça, mais combiné avec les variables de l'instruction Compute, cela permet de créer des machines à états, et ça, ça ouvre de nouvelles perspectives :-). Par exemple, on peut légèrement modifier le protocole précédent pour être sûr que l'interrogation n'ait lieu qu'après l'initialisation.

  1. Tâche 1 (périodique une fois)

    • assert !isset($state)
    • wait 3000
    • writeHex 03
    • wait 10
    • writeHex 0307
    • wait 10
    • writeHex 03
    • wait 10
    • writeHex 0303
    • compute $state=1

  2. Tâche 2 (périodique toutes les ~2.5s)

    • assert $state==1
    • wait 150
    • writeHex 32
    • wait 10
    • writeHex 323232323232323232323232323232

  3. Tâche 3 (réactive)

    • expect F3($1:FLOAT32)($2:FLOAT32)($3:FLOAT32)(WORD)

Si vous mettez le firmware de votre Yocto-SPI à jour avec au moins la version 37101, vous aurez accès à cette nouvelle instruction magique.

Conclusion

L'OPC-N3 est un capteur un peu susceptible qu'il est difficile d'interroger. Mais une fois que votre protocole est bien au point, il marche remarquablement bien. Pour vous éviter de devoir définir ces protocoles à la main, on vous les a mis dans ce fichier ZIP et vous n'aurez plus qu'à les uploader sur le système de fichiers de votre module.

Commenter aucun commentaire Retour au blog












Yoctopuce, get your stuff connected.