Planet RaspFR

Bienvenue sur ce planet dédié au Raspberry Pi
mais aussi autres micro-ordinateurs et aux imprimantes 3D de type DIY.

Si vous voulez ajouter votre blog, n'hésitez pas à nous contacter.
Nous vous donnons rendez-vous sur le forum RaspFR

Un nouvel économiseur d’écran pour le Raspberry Pi

La Fondation Raspberry Pi est basée à Cambridge. Quand on dit «basée à Cambridge», cela veut dire que ses bureaux sont à Cambridge. Mais le lien entre le Raspberry Pi et Cambridge est beaucoup plus profond que la simple géographie.

Cambridge, aux sources du Raspberry Pi

Le Raspberry Pi a été créé dans le but d’augmenter le nombre d’étudiants en informatique à l’Université de Cambridge. Le cœur du processeur qui anime le Raspberry Pi a également été développé dans cette ville par ARM, une entreprise qui a bien réussi et qui a elle-même grandi à partir d’Acorn, l’un des pionniers à l’origine de la révolution de l’informatique personnelle des années 1980.

Le processeur graphique original VideoCore a été conçu par le personnel de Cambridge Consultants, l’une des premières sociétés de conseil technique au Royaume-Uni. Ils ont créé une société appelée Alphamosaic pour vendre le VideoCore. Cette société a ensuite été acquise par Broadcom dont les ingénieurs ont amélioré le produit pour aboutir à la version qui gère le multimédia du Raspberry Pi.

La naissance du Raspberry Pi… à Cambridge

Ce sont ces mêmes ingénieurs qui ont mis sur pied le projet «skunkworks» en dehors de leurs heures de travail. Ce projet est devenu la carte Alpha du Raspberry Pi. Lorsque la fondation Raspberry Pi a été créé en tant qu’organisme de bienfaisance et société, il semblait évident qu’elle devait être domiciliée à Cambridge. La plupart de son personnel vit dans ou autour de Cambridge, et beaucoup d’entre eux sont diplômés de l’Université. Cambridge coule profondément dans l’ADN du Raspberry Pi : le président David Cleevely aime à dire que l’histoire du Raspberry Pi ne pouvait pas se dérouler ailleurs, et bien que cela ne soit pas tout à fait vrai, Cambridge a fourni l’environnement qui lui a permis de prospérer comme il l’a fait. Très fière de sa connexion à Cambridge, la fondation a décidé de la célébrer.

L’idée de l’économiseur d’écran vidéo (screensaver)

Il y a quelques mois, Eben Upton et Simon Long regardaient les superbes vidéos du survol de la ville offertes par Apple comme écran de veille sur l’Apple TV. Ils se sont dit que ce serait formidable de pouvoir faire quelque chose de similaire pour Raspbian et ont obtenu l’aide de Cambridge Filmworks, des experts en tournage vidéo avec des drones, à qui ils ont demandé de tourner une vidéo montrant les meilleurs éléments de l’architecture de Cambridge. Le résultat est magnifique.

Dans le même esprit, Eben et Simon ont également pensé que ce serait bien d’avoir des images de fond (wallpaper) pour le bureau qui montraient les plus jolies vues de la ville et de l’Université. Les meilleures photos de Cambridge viennent de Sir Cam, qui prend des photos pour l’Université qui a très généreusement permis à la fondation d’accéder à ses archives. Les images choisies représentent des endroits qui ont une signification particulière.

Le thème Cambridge pour Raspbian PIXEL

Aujourd’hui, la fondation lance le pack thématique Cambridge pour PIXEL : un économiseur d’écran vidéo qui montre l’architecture de Cambridge et un ensemble de fonds d’écran.

Tout ceci est entièrement facultatif, ce ne sont que des bonus pour améliorer la présentation de votre bureau PIXEL, si vous le souhaitez.

Installer les fonds d’écran

sudo apt-get install cantab-wallpaper

Fonds d’écran Cambridge – Cliquez pour agrandir.

Installer l’économiseur d’écran

sudo apt-get install cantab-screensaver

Installer les deux (économiseur vidéo + fonds d’écran)

pi@raspberrypi:~ $ sudo apt-get install cantab-theme
Lecture des listes de paquets... Fait
Construction de l'arbre des dépendances
Lecture des informations d'état... Fait
Les paquets supplémentaires suivants seront installés :
cantab-screensaver cantab-wallpaper libauthen-sasl-perl
.../...
libwww-perl libwww-robotrules-perl miscfiles xscreensaver xscreensaver-data
0 mis à jour, 34 nouvellement installés, 0 à enlever et 0 non mis à jour.
Il est nécessaire de prendre 236 Mo dans les archives.
Après cette opération, 244 Mo d'espace disque supplémentaires seront utilisés.
Souhaitez-vous continuer ? [O/n]

Notez que les fonds d’écran seront installés dans le même répertoire /usr/share/pixel-wallpaper que les images de fond d’écran PIXEL standard. Vous pouvez utiliser la boîte de dialogue Paramètres d’apparence pour choisir le fond d’écran que vous souhaitez.

Notez également que l’économiseur d’écran représente environ 200 Mo de vidéo haute résolution. Ne l’installez pas si votre carte SD est pleine ou si votre connexion réseau est lente.

Une fois que vous avez installé les paquetages, vous devrez configurer l’économiseur d’écran. Allez dans Préférences > Économiseur d’écran dans le menu principal et sélectionnez l’économiseur d’écran appelé ‘Cantab‘.

Si vous voulez uniquement utiliser l’économiseur d’écran de Cambridge, dans la liste déroulante Mode choisissez «Seulement un économiseur d’écran». Si vous ne faites pas cela, vous obtiendrez une sélection aléatoire des économiseurs. Vous pouvez également configurer le nombre de minutes avant que l’économiseur d’écran ne soit activé dans la partie basse de l’écran.

Vidéo

Voici un court extrait de cette vidéo :

Conclusion

Avec cet économiseur d’écran Raspbian dispose d’un outil de mise en veille intégré. Il faudra tester s’il est possible de remplacer la vidéo de Cambridge par une autre (.h264) pour personnaliser à volonté l’affichage du Raspberry Pi après une période d’inactivité…

La vidéo se trouve dans /usr/share/cantab-video/ et les fonds d’écran dans /usr/share/pixel-wallpaper/.

Sources

Cambridge theme for PIXEL

 

Cet article Un nouvel économiseur d’écran pour le Raspberry Pi a été publié en premier sur Framboise 314, le Raspberry Pi à la sauce française.....

Micro:bit -> Diseur de bonnes aventures

Vous allez programmer votre micro:bit pour lui faire lire l’avenir! Il suffit de lui poser une question, et d’appuyer sur un bouton pour qu’il vous donne la réponse !

TRADUCTION D’ARTICLE

Étape 1: Défilement du texte

Commençons par le défilement des instructions sur votre micro: bit.

  • Pour ajouter un peu de texte, cliquez sur la flèche, puis choisissez ‘String‘.

  • Ajouter vos instructions dans la zone de texte.

Voici à quoi votre code devrait ressembler:

  • Testez votre code : vous pouvez le tester dans l’éditeur ou sur le micro:bit lui-même.
  • Le texte de vos blocs say devrait traverser assez lentement l’écran. Pour l’accélérer, vous aurez besoin d’utiliser une autre version des blocs say.

Supprimer votre bloc say, pour que votre onStart soit vide.

  • Cliquez sur la flèche à côté du bloc say et vous verrez un second bloc apparaître. Faites glisser ce bloc dans le onStart.

  • Cette version de say vous permet de décider le temps d’attente (en millisecondes) du défilement. Tapez 10 dans la zone de texte.

Enregistrez votre projet

 Défi: Ralentir le texte

Si vous testez à nouveau votre code, vous verrez que cette fois ci le texte défile trop rapidement. Pouvez – vous changer le nombre de millisecondes dans votre bloc say pour que le texte défile à une bonne vitesse ?

Enregistrez votre projet

Étape 2: Prendre une décision

Admettons que votre micro:bit peut prendre une décision en choisissant au hasard un certain nombre ( 0 pour Non et 1 pour Oui).

  • Ajouter un nouvel événement onPressA à votre code.

  • Nous allons créer une nouvelle variable pour stocker la réponse. Cliquez sur l’icône «Bibliothèque», puis cliquez sur « Globals ».

  • Cliquez sur le + pour créer une nouvelle variable appelée answer.

  • Faites glisser votre nouvelle variable dans votre onPressA.

Comme vous pouvez le voir, les = dans le bloc signifient que vous pouvez définir la réponse à afficher.

  • Cliquez sur l’icône «Bibliothèque», puis cliquez sur ‘Random’.

  • Faites glisser le bloc de Random number (nombre au hasard)  sur le dessus du mot update.

  • Voici à quoi votre code devrait ressembler:

  • Ensuite, vous voulez afficher le mot Non sur le micro:bit uniquement si la réponse (answer) est 0.

Pour ce faire, cliquez sur l’ onglet «Langue», puis faites glisser un bloc if en fin de votre onPressA.

  • Cliquez sur la flèche vers le bas sur le bloc if et cliquez sur left == right .

  • Faites glisser votre answer sur le côté gauche du if , et le 0 dans le côté droit.

  • Tout code présent dans le if bloc sera lancé uniquement si answer est 0. Comme 0 est No , nous allons ajouter un say pour le signaler.

  • Testez votre code.
    • Parfois, answer sera  0, et le micro: bit devrait dire «Non».
    • Parfois, answer sera 1, et rien ne se passera!

Enregistrez votre projet

Défi: Plusieurs réponses

Pouvez-vous ajouter du code de telle sorte que «oui» soit affiché sur votre micro:bit si la réponse est 1? Vous pouvez même changer le texte affiché à quelque chose de plus intéressant que juste «Oui» et «Non»!

Vous pourriez faire dire à votre micro:bit quelque chose comme «peut-être» ou «Demande à nouveau» si la réponse est 2. Pour obtenir cela, vous aurez également besoin de changer votre code pour choisir un nombre aléatoire entre 0 et 2!

Enregistrez votre projet

Défi: Secouez votre micro: bit

Pouvez-vous coder votre micro:bit pour prendre une décision lorsqu’il est secoué au lieu de quand un bouton est pressé?

Enregistrez votre projet

Vous venez de créer, coder et programmer… Un diseur de bonnes aventures et comme on dit, le hasard fait bien les choses !

Et bien sur si vous avez besoin d’aide pour résoudre les défis n’hésitez pas à laisser un commentaire !

Cet article Micro:bit -> Diseur de bonnes aventures a été publié en premier sur Framboise 314, le Raspberry Pi à la sauce française.....

Connectez vous de n’importe où à votre Raspberry Pi avec VNC CONNECT

Du nouveau dans Raspbian PIXEL : VNC Connect est une nouvelle version de VNC, gratuite, qui facilite la connexion sécurisée à votre Raspberry Pi de n’importe où dans le monde. Dans cette version personnelle du produit vous pourrez gérer jusqu’à 5 Raspberry Pi de n’importe où dans le monde.

Cliquez pour avoir de l’information sur les niveaux.

Connectez vous de n’importe où dans le monde à votre Raspberry Pi avec VNC CONNECT

Une première version de RealVNC

Depuis Septembre 2016, Raspbian est livré avec la possibilité d’accès distant et de prise de main distante en affichant l’écran de votre Raspberry Pi sur un autre ordinateur. C’est VNC qui a amené cette fonctionnalité en fournissant gratuitement à la communauté Raspberry Pi la version la plus récente et la plus sécurisée de VNC.

Une des critiques de cette solution était que si la connexion était relativement facile sur le même réseau, il fallait des connaissances plutôt bonnes en réseau afin de se connecter à un Raspberry Pi au travers d’Internet ! Or souvent les utilisateurs débutants du Raspberry Pi n’avaient pas ces connaissances.

VNC CONNECT pour le Raspberry Pi

VNC Connect, une toute nouvelle version de VNC, a été développé suite à ces critiques. Cette version de VNC vous permet non seulement de faire des connexions directes depuis votre propre réseau, mais autorise aussi des connexions sécurisées à votre ordinateur depuis n’importe où dans le monde, sans connaissances spéciales en réseau, à partir d’une large gamme de périphériques.

VNC Connect est disponible pour Raspberry Pi, dès maintenant, dans les dépôts de Raspbian. Il est gratuit pour une utilisation non commerciale et éducative.

Une gestion simplifiée des connexions

Le choix de l’ordinateur utilisé pour se connecter à l’aide de VNC a toujours été fastidieux. Il fallait se rappeler des adresses IP ou des noms d’hôtes, ou utiliser une application distincte pour garder une trace de ces informations. Avec VNC Connect, est apparu un nouveau VNC Viewer avec un carnet d’adresses intégré et une interface utilisateur améliorée, ce qui simplifie considérablement la gestion des périphériques et des connexions. Vous avez maintenant la possibilité d’enregistrer en toute sécurité des mots de passe pour les connexions fréquemment utilisées et vous pouvez synchroniser vos entrées avec d’autres visionneuses VNC, ce qui facilite l’accès à votre Raspberry Pi à partir d’autres ordinateurs, tablettes ou appareils mobiles.

Amélioration de la capture directe

Des améliorations importantes ont été apportées à la fonction expérimentale de «capture directe» de VNC Connect qui est particulière au Raspberry Pi. Cette fonctionnalité vous permet de voir et de contrôler les applications qui sont rendues directement à l’écran, comme Minecraft, omxplayer ou même le terminal. Vous devriez constater que la performance de VNC en mode de capture directe s’est améliorée et est beaucoup plus utilisable pour les tâches interactives.

Comment installer VNC Connect

VNC Connect est disponible dans les dépôts de Raspbian dès maintenant, et peut s’installer en entrant les commandes suivantes sur un terminal :

sudo apt-get update
sudo apt-get install realvnc-vnc-server realvnc-vnc-viewer

Si vous utilisez déjà VNC Server ou VNC Viewer, les mêmes commandes installeront la mise à jour. Il faudra redémarrer pour utiliser la version la plus récente. Une mise à jour du système aura le même effet.

Vous trouverez plus d’informations à propos de l’installation sur la page Raspberry Pi de RealVNC. Si vous souhaitez profiter de la connectivité par Internet, vous devrez créer un compte RealVNC.

Utiliser VNC Connect

Mise en route de VNC Connect

Comme pour les précédentes versions de VNC, il faudra cocher la case d’activation dans la fenêtre de Configuration du Raspberry Pi.

Découvrir VNC Connect

Attention !
Pour la suite de ce chapitre, votre Raspberry Pi doit être connecté à Internet.

Cliquez sur l’icône VNC en haut à droite de l’écran de Raspbian PIXEL. Cette fenêtre d’accueil s’ouvre. Cliquez sur pour connecter en bas de la fenêtre.

Vous arrivez sur la page de connexion de VNC.

Dans la partie GET STARTED entrez votre adresse mail et cliquez sur NEXT.

Renseignez les différents champs, cochez (ou pas) les cases en bas de la fenêtre, puis cliquez sur SIGN UP.

Vous allez recevoir un message à l’adresse mail que vous avez indiquée. Cliquez sur VERIFY MAIL pour valider votre adresse mail.

VNC confirme la vérification de votre email. Cliquez sur GOT IT.

Vous pouvez maintenant activer votre compte gratuit qui vous permet de gérer jusque 5 machines.

Sécuriser la connexion

Le Raspberry Pi que je connecte à Internet n’a pas de grosses applications critiques. Il me sert surtout pour les essais. Alors, bon, si un hacker russe ou chinois se connecte et prend la main, tout ce qu’il risque de récupérer comme info, c’est la température dans le bureau. Au pire il pourra allumer une LED sur la plaque breadboard. Pas de quoi casser trois pattes à un canard 😀

Par contre, si votre Raspberry Pi envoie un flux vidéo, s’il gère une alarme ou votre domotique, y compris la chaudière, on ne va peut être pas laisser des intrus se connecter dessus. Enfin, c’est mon avis. Dans ce cas je vous conseille de valider en bas de la fenêtre précédente la vérification en 2 étapes.

Cela vous envoie sur cette page : cliquez sur ENABLE 2 STEPS VALIDATION

Comme j’utilise déjà Google Authenticator (pour Facebook ou twitter) c’est cette méthode que j’ai choisie. Google Autenticator (GA) génère un code éphémère, calculé à partir d’une clé propre à chaque utilisateur. Lors de la première utilisation GA génère une clef numérique secrète de 80 bits unique pour chaque utilisateur. Cette clef est transmise sous forme d’une chaîne de 16 caractères en base 32 ou par l’intermédiaire d’un code QR (j’ai choisi cette option !). L’application mobile calcule à chaque connexion une signature numérique basée sur cette clef unique, en codant le nombre de périodes de 30 secondes écoulées depuis l’ « epoch» Unix. Un nombre à 6 chiffres est affiché par l’application et l’utilisateur doit le recopier sur le site web, en plus de son mot de passe. Ceci garantit que seul cet utilisateur pourra accéder aux informations.

En cas de perte (vol)  de votre mobile l’application génère des codes de secours qu’il faudra garder précieusement !

Bon, on n’est plus loin de la fin de ce tutoriel. On accède à la page perso VNC… Mais il n’y a pas encore d’ordinateur affiché. On va s’en occuper !

Configuration de VNC Server sur le Raspberry Pi

Dans la partie gauche de la fenêtre : Connectivité, cliquez sur Ouvrir une session. Entrez les informations de login de votre compte VNC.

Choisissez la méthode d’authentification en 2 étapes.

Entrez le code fourni par l’appli sur votre smartphone/tablette. Les codes sont valides une minute.

Choisissez la méthode pour la connexion : directe pour votre seul réseau local, cloud pour une connexion via Internet.

Votre Raspberry Pi est rattaché à votre compte VNC et vous allez pouvoir vous y connecter à distance.

Connexion à votre Raspberry Pi

Liste d’ordinateurs disponibles

Revenez sur la machine distante (ça va, vous suivez toujours ?) Le Raspberry Pi apparait dans la liste des ordinateurs.

Installer VNC Viewer

Si vous ne l’avez pas encore sur votre smartphone ou votre tablette, rendez vous sur la page de téléchargement de VNC.

Cliquez sur le système de votre matériel (pour moi c’est Android).

Et installez VNC Viewer sur le(s) matériels que vous souhaitez utiliser pour la prise de main à distance sur votre Raspberry Pi.

VNC sur tablette ou smartphone

Sur la tablette ou le smartphone, démarrez VNC Viewer.

Le Raspberry Pi qui nous intéresse se trouve dans la Team (l’équipe). Tapez sur Team =>

Dans la Team, le Raspberry Pi apparait. Tapez dessus (pas trop fort, quand même 🙂 )

On va devoir s’authentifier pour se connecter.

Pour se connecter sur la machine il faut saisir le login/password de la machine (ici pi/raspberry).

et on se retrouve sur le bureau du Raspberry Pi 🙂

Les menus sont accessibles normalement, ainsi que les applications.

Par contre si on lance Minecraft on a une fenêtre toute noire. En fait Minecraft comme omxplayer et d’autres applis écrivent directement dans un framebuffer (mémoire d’écran). La dernière version de VNC permet cependant (à titre expérimental) de récupérer les infos qui n’apparaissent pas normalement.

Dans la fenêtre VNC Server sur le Raspberry Pi, cliquez sur le menu (les 3 barres en haut à droite). Dans l’item Options du menu cliquez sur Dépannage, puis cochez la case Utiliser le mode de capture direct (en rouge ci-dessus).

Cette fois Minecraft apparait bien dans la fenêtre !

Conclusion

Avec cette version de VNC Connect, le Raspberry Pi devient accessible de n’importe où via l’Internet. C’est encore une nouvelle possibilité qui va sans doute inspirer bien des makers et nous attendons avec impatience les applications de cette possibilité !

Sources

Get ‘Back to my Pi’ from anywhere with VNC Connect

Cet article Connectez vous de n’importe où à votre Raspberry Pi avec VNC CONNECT a été publié en premier sur Framboise 314, le Raspberry Pi à la sauce française.....

Achat groupé de kit SigFox

Suite à l’article précédent sur la carte SigFox de SNOC, Alexandre m’a informé qu’il a actuellement en cours une commande groupée de cartes XKit. Ces cartes embarquent un module Wisol mais également des capteurs.

Kit SigFox en achat groupé

Cette carte n’a pas du tout la même destination que la carte prototype de SNOC, puis qu’ici la carte embarque un accéléromètre 3 axes, un détecteur de chocs, un capteur de température et pression. On trouve aussi un capteur de lumière ambiante ainsi que 2 LED (rouge et bleue).

Alexandre a lancé une commande groupée, avec une date butoir au 23 février. Il faut 48 commandes pour obtenir le kit à 35 €.

Pour plus de détails sur le contenu du kit, les modalités (et frais) d’expédition, laissez un message à Alexandre dans les commentaires ci-dessous.

Cet article Achat groupé de kit SigFox a été publié en premier sur Framboise 314, le Raspberry Pi à la sauce française.....

Carte de prototypage SIGFOX par SNOC

la SNOC sort une carte breakout (prototypage) de dimensions réduites. Basée sur un module Wisol SFM10R1 cette carte vous permet de disposer des fonctionnalités de SigFox sur tous vos montages. C’est l’IoT à portée de Raspberry Pi !

Après la carte RPISIGFOX destinée à munir le Raspberry Pi de l’accès à SigFox que je vous avais présentée  fin 2015, voici une nouvelle carte équipée du tout récent module SFM10R1 de Wisol. SNOC m’a proposé de la tester sur le Raspberry Pi, ce que j’ai accepté avec plaisir et j’ai donc reçu à titre gracieux ce module (merci Pascal), ce qui vaut à cet article d’être classé comme sponsorisé.

Si vous voulez un rappel sur la technologie SigFox, reportez vous à l’article précédent. Rapidement, on peut dire que la portée d’un émetteur en numérique dépend de sa puissance, mais aussi du débit de données. Avec un faible débit de données, la portée peut être très importante. C’est le principe de SigFox.

============= Article sponsorisé =============

Breakout board – Carte de Prototypage SigFox pour Raspberry Pi et Arduino

La carte SNOC BRKSW01

La carte que propose SNOC est vraiment de dimension réduite puisqu’elle occupe moins de 5 cm2 !

Si on la compare à un timbre poste on voit que son encombrement est à peine supérieur.
Ceci permet d’envisager de l’embarquer dans des montages de taille réduite qui nécessiteraient une connexion à SigFox.
IoT nous voici 😉 !

Le matériel reçu

L’ensemble du matériel arrive dans un carton. Tout est bien protégé. L’antenne et son câble sont dans un sachet plastique zippé.

La carte SigFox est dans une pochette antistatique de bonne qualité. Vous éviterez de trop la manipuler, de mettre les doigts sur les pastilles etc. Ça craint l’électricité statique ces petites choses là !

Le matériel inclus dans le paquet reçu intègre le module lui même, ainsi que les connecteurs à souder (eh oui, il faudra sortir votre fer à souder ! ) pour monter le module à l’horizontale ou à la verticale.

Le montage de gauche permet d’assurer une bonne rigidité en cas de montage sur une breadboard (plaque d’expérimentation) ou sur une carte de circuit imprimé. La version de droite, pour montage vertical autorise un montage/démontage facile sur une breadboard. C’est cette configuration que j’ai choisie.

Le matériel comprend également une antenne adaptée à la fréquence de SigFox, ainsi qu’un adaptateur UFL <=> RP-SMA de 100 mm de longueur, assurant la liaison entre la prise coaxiale présente sur la carte et l’antenne.

Le module WISOL WSSFM10R1

Le module émetteur/récepteur SigFox qui équipe la carte pèse moins d’un gramme (0,85 g) et ne mesure quant à lui que 13 x 15 x 2,21 mm. Il confère à la carte ses caractéristiques, la contribution de SNOC est de faciliter son utilisation par les makers en proposant une carte facile à mettre en œuvre. Le module est en CMS et pas facile à souder avec des moyens amateurs.

Alimenté entre 1,8 et 3,3 volts, il consomme un peu plus de 50 mA en émission et 15 mA en réception (uniquement pendant le temps de ces opérations). En veille, la consommation chute à 2 μA !

Ses caractéristiques :

  • Taille : 13.0×15.0x2.21mm
  • Chipset : AX-SFEU-1-01/ ON Semiconductor
  • Freq. Tx/ Data rate : 868.13MHz/ 100bps
  • Freq. Rx/ Data rate : 869.525MHz/ 600bps
  • Puissance sortie Tx : +14dBm (max)
  • Sensibilité Rx : -127dBm@600bps
  • Alimentation : @+3.3V
  • Tx : 60mA(max), Rx: 15mA (max)
  • Tensions acceptées : +1.8V~+3.6V
  • Température d’utilisation : -30°C à +85°C

Le module utilise un TCXO 48 MHz pour rester dans la tolérance des fréquences SigFox durant toute la durée de vie du produit.

Ce module intègre un circuit ON Semiconductor AX-SFEU dont la documentation est disponible en ligne.

Le schéma du AX-SFEU

Cliquez pour agrandir.

Ce schéma est extrait d’une note d’application du module AX-SFEU (page 16). S’il peut donner une idée du schéma réel du module Wisol dans lequel le AX-SFEU est utilisé, il n’y a aucune garantie qu’il soit exactement celui qui est mis en œuvre. Il n’est donné qu’à titre indicatif.

En résumé :

La carte BRKWS01 requiert au minimum les connexions +3,3v, masse et Tx Rx. Les transmissions de données peuvent être surveillées avec les LED LEDTX et LEDRX. La carte dispose également de deux sorties pour une LED CPU (activité du processeur) et RADIO LED pour l’émission. Il faut réfléchir à l’adjonction de ces LED qui peuvent se révéler utiles pour la mise au point mais seront par le suite consommatrices de courant…

Voilà le schéma de branchement que j’ai retenu.

La carte SNOC embarque un module Wisol SFM10R1… qui embarque un module AX-SFEU 🙂 Avec la doc de ce dernier module on peut donc tirer pas mal d’informations sur le fonctionnement de tout cet ensemble et envisager des trucs rigolos… non ?

Par exemple, d’après SNOC les commandes AT$I=10 et AT$I=11 renvoient l’ID du module et le PAC… Ce qui correspond bien à la documentation du module AX-SFEU.

Attention !
Certaines modifications peuvent mettre en danger le module Wisol embarqué sur la carte SNOC. Vous risquez de compromettre le bon fonctionnement de la carte en modifiant certaines valeurs. Dans ce cas vous perdez bien entendu la garantie SNOC.
Si vous intervenez dans les registres de la carte, vous le faites à vos risques et périls, ni SNOC ni framboise314 ne pourront être tenus pour responsables en cas de dysfonctionnement.

Montage de la carte SNOC BRKWS01

Soudure du connecteur

J’ai sorti mon plus beau fer à souder pour souder le connecteur coudé. Utilisez un fer bien propre et évitez de chauffer trop fortement les pastilles. Éventuellement laissez un peu de temps entre deux soudures pour laisser redescendre la température.

Connexion de l’antenne

L’antenne se connecte sur cette prise, destinée à être montée sur un châssis ou un boîtier. Si vous faites un montage « en l’air » vissez d’abord la prise SMA sur l’antenne pour éviter de soumettre le câble à des torsions trop importantes.

Vissez bien la prise SMA sur l’antenne.

Connexion du câble sur la carte

La carte comporte une prise coaxiale miniature.

La prise présente à l’extrémité du câble d’antenne va venir se positionner sur la prise de la carte. Il faudra bien l’enfoncer pour assurer le contact et une solidité suffisante de la liaison.

Voilà, la prise est connectée à la carte. On est pratiquement prêt à passer aux essais. S’il se fait tard, reportez les essais à demain matin. Lorsqu’on commence à être fatigué il est plus facile de faire des conneries erreurs et vous risquez de mettre la vie de la carte SigFox en danger.

Mise en place de la carte prototype sur le Raspberry Pi

Bon, j’avoue ce n’était pas simple de connecter la carte SNOC BRKWS01 sur le GPIO du Raspberry Pi. Je ne voulais pas faire un montage volant avec des fils de liaison femelle/femelle. C’est un coup à laisser traîner (volontairement ou involontairement) la carte à un endroit dangereux. J’ai donc choisi d’utiliser une carte Explorer HAT Pro récemment arrivée.
Elle offre la possibilité d’accéder facilement à des ports GPIO intéressants dans ce cas : le 3,3 v et la masse, ainsi que les E/S de l’UART, TxD et RxD sur des connecteurs type Arduino.

L’Explorer HAT Pro est également équipée d’une mini breadboard bien pratique pour des essais rapide de petits montages électroniques, et bien adaptée dans le cas qui nous intéresse. Dans un premier temps j’avais positionné la carte « dans le fond » mais à l’usage il s’est avéré plus judicieux de la monter plus en avant et de connecter les fils derrière. Après… vous ferez bien comme vous voulez 😉

Avant de relier les fils, si vous utilisez ce type de carte, pensez à faire un test de bon fonctionnement du Raspberry Pi. Un démarrage du système au minimum pour vérifier qu’il n’y a pas de souci avec la carte seule. Ensuite vous pourrez connecter les fils…
Pensez aussi à tester le bon fonctionnement du port série avant de vous lancer dans les tests ! Pas la peine d’aller plus loin si le port série ne répond pas 🙁
Pour ma part j’ai bouclé Tx et Rx et utilisé putty.
Comme d’habitude, si vous montez, connectez, reliez tout le bazar et que ça ne démarre pas ou que ça ne fonctionne pas… vous ne saurez pas où chercher 😀 Alors allez-y doucement, pas à pas, étape par étape… Vous augmenterez vos chances de réussite !

Connexion et tests

Bon, voilà… tout est connecté on peut passer aux essais. Pour tester la carte SigFox, j’ai choisi d’utiliser putty sur le Raspberry Pi (il n’est pas d’origine dans Raspbian, il faudra l’installer).

Configuration de putty

Configurez l’interface série comme ci-dessus.

Puis connectez vous sur le port série (cliquez sur le bouton Open). Avant de continuer on va faire une parenthèse, je vous explique ce qu’est l’écho. Si vous connaissez déjà… passez au chapitre suivant 🙂

L’écho, qu’est-ce ?

En informatique ça désigne le traitement qui est réservé à un caractère envoyé par un terminal (putty dans notre cas) à une unité centrale (la carte SigFox ici). Si une commande est composée de plusieurs caractères, chaque caractère est traité indépendamment.

Nota
Les plus anciens se souviennent des commandes AT ou Hayes qui permettaient de commander les modems : numéroter (ATDT, ATDP), régler le volume, manipuler les registres internes du modem… Ce sont ces mêmes commandes qui sont utilisées sur les modules SigFox 🙂 Ça ne nous rajeunit pas !!

Premier cas : pas d’écho

Le terminal envoie la commande AT (aussi appelée commande Hayes) à la carte SigFox. En l’absence d’écho, la carte SigFox reçoit la commande et répond OK si elle fonctionne… Le problème c’est que si rien ne s’affiche on ne sait pas si c’est parce que la carte ne fonctionne pas ou si la commande AT est réellement partie… (configuration, problème hard…)

Deuxième cas : écho distant

Lorsque l’écho distant est activé (dans ce cas ça se passe au niveau de l’UC distante, donc de la carte SigFox dans notre cas) le terminal envoie la commande AT à l’UC distante, qui la renvoie vers le terminal. Dans ce cas on est certain(e) que tout fonctionne, la liaison aller-retour ET la carte SigFox. Ensuite si l’UC distante (la carte SigFox) est prête, elle renvoie OK.

Le problème c’est que je n’ai pas trouvé dans les commandes de l’AX-SFEU de commande AT permettant d’activer l’écho 🙁 On ne pourra donc pas utiliser l’écho distant. Par défaut on sera donc en mode sans écho comme ci-dessus dans le premier cas.

Troisième cas : écho local

Pour pallier à l’absence de l’écho distant il existe sur les terminaux un mode écho local qui envoie sur l’écran les commandes saisies, sans les faire transiter par l’UC distante. On voit donc s’afficher la commande et la réponse de l’UC distante. Bien évidemment, en cas de problème de liaison ou de non fonctionnement de la carte SigFox, on se retrouve avec juste AT affiché sur l’écran, sans savoir d’où vient le souci. C’est ce mode que nous utiliserons pour dialoguer avec la carte SigFox. Nous verrons comment activer le mode écho local sur putty.

Quatrième cas : écho local ET écho distant

Là c’est la totale. Lorsque vous tapez AT sur le clavier le terminal affiche AT sur l’écran (écho local) et envoie la commande simultanément via le port série jusqu’à l’UC distante. L’UC distante renvoie la commande AT vers l’écran. On se retrouve donc avec deux affichages successifs de chaque commande. Puis la carte SigFox répond OK. Sa réponse s’affiche sous les deux commandes AT.

Mode écho local sur putty

Dans putty ouvrez la catégorie Terminal et cochez Force on dans la rubrique Local echo. C’est bon nous sommes prêt(e)s pour tester la carte :

On commence par taper AT au clavier, puis Entrée

Yesssss la commande AT s’affiche et… ouf la carte répond OK ! On va pouvoir continuer à explorer les possibilités de la carte.

Inscription sur le site web SigFox

Avant de pouvoir accéder au réseau SigFox, il faut créer un compte sur le site de la société toulousaine. Cette inscription enregistre le numéro de série de votre carte SNOC et autorise le réseau à faire transiter vos données. Avec la carte SNOC, vous avez un an d’abonnement inclus, comprenant 140 messages (jusqu’à 12 octets) en UP par jour, et 4 messages en DOWN par jour.

Accéder à la page d’inscription

Rendez vous sur la page snoc.fr/sigfoxactivate. Cliquez sur le bouton ACTIVEZ.

Vous aboutissez sur le site SigFox. Sélectionnez le prestataire de votre pays. Pour la France… c’est SigFox 🙂

Saisissez les informations relatives à votre carte SNOC BRKWS01 (elles figurent sur les étiquettes du matériel que vous avez reçu).

Saisissez les informations nécessaires à la création de votre compte.

Votre inscription est terminée. Il reste à la valider en suivant le lien que vous avez reçu dans un mail à l’adresse que vous avez fournie.

Cliquez sur le lien dans le message pour terminer votre inscription.

Saisissez votre mot de passe (2 fois) en respectant les consignes : 8 caractères, comprenant au moins une minuscule, une majuscule, un chiffre et un caractère spécial !

Cliquez pour agrandir.

Vous avez maintenant accès à la page de votre périphérique SigFox et allez pouvoir configurer certains paramètres, mais aussi voir les messages envoyés par votre carte.

Votre carte SigFox étant enregistrée sur le réseau, nous pouvons passer aux essais 🙂

Envoi de données via SigFox

Mode manuel

On va envoyer 12 octets de données à partir de putty :

Une commande AT pour voir si la carte répond… OK ! c’est bon ça fonctionne et on entre la commande d’envoi d’un message : AT$SF=   suivie des 12 octets en hexadécimal.
Ensuite on appuie sur la touche Entrée et… on attend quelques secondes, le temps que les données soient envoyées par radio (n’oubliez pas qu’on a une grande portée, mais un faible débit). Quand le OK revient, c’est fait, votre message est envoyé !

On vérifie ?

Bon… Sur la page de mon module , sur le site de SigFox, on retrouve quoi ? La date et l’heure de mon message et le contenu que j’ai envoyé. Super !

En cliquant sur le symbole circulaire sous Location, on a l’affichage d’une carte qui indique la grande région dans laquelle le signal a été capté (carré coloré) et la zone de forte probabilité de la provenance (zones plus sombres). Ça correspond bien à ma position (Le Creusot – 71)

Programme Python

Si vous souhaitez envoyer des messages depuis une application domotique ou depuis une application que vous avez écrite, il est intéressant de le faire de façon automatique. Je vous propose ce programme traduit et adapté du github de SNOC.

#!/usr/bin/env python
# -*- coding: utf-8 -*-

## @package rpisigfox
#  Ce script contrôle la carte BRKWS01 pour l'envoi d'un message SIGFOX.
#
#  V1.0 Permet l'envoi d'un message normal sur le réseau SigFox.
#  syntaxe :
#  ./tx.py MESSAGE
#  où MESSAGE est une chaîne encodée en HEXA. La longueur peut être de 2 à 24 caractères représentant 1 à 12 octets.
#  Exemple : ./tx.py 00AA55BF envoie les 4 octets 0x00 0xAA 0x55 0xBF
#
import time
import serial
import sys
from time import sleep

class Sigfox(object):
    SOH = chr(0x01)
    STX = chr(0x02)
    EOT = chr(0x04)
    ACK = chr(0x06)
    NAK = chr(0x15)
    CAN = chr(0x18)
    CRC = chr(0x43)

    def __init__(self, port):
        # permet de choisir le port série – par défaut /dev/ttyAMA0
        portName = port

        print 'Serial port : ' + portName
        self.ser = serial.Serial(
            port=portName,
            baudrate=9600,
            parity=serial.PARITY_NONE,
            stopbits=serial.STOPBITS_ONE,
            bytesize=serial.EIGHTBITS
        )

    def getc(self, size, timeout=1):
        return ser.read(size)

    def putc(self, data, timeout=1):
        ser.write(data)
        sleep(0.001) # temporisation pour permettre au circuit de se préparer

    def WaitFor(self, success, failure, timeOut):
        return self.ReceiveUntil(success, failure, timeOut) != ''

    def ReceiveUntil(self, success, failure, timeOut):
        iterCount = timeOut / 0.1
        self.ser.timeout = 0.1
        currentMsg = ''
        while iterCount &amp;amp;amp;amp;amp;gt;= 0 and success not in currentMsg and  failure not in currentMsg :
            sleep(0.1)
            while self.ser.inWaiting() &amp;amp;amp;amp;amp;gt; 0 : # bunch of data ready for reading
                c = self.ser.read()
                currentMsg += c
            iterCount -= 1
        if success in currentMsg :
            return currentMsg
        elif failure in currentMsg :
            print 'Erreur (' + currentMsg.replace('\r\n', '') + ')'
        else :
            print 'Délai de réception dépassé (' + currentMsg.replace('\r\n', '') + ')'
        return ''

    def sendMessage(self, message):
        print 'Sending SigFox Message...'

        if(self.ser.isOpen() == True): # sur certaines plateformes il faut d'abord fermer le port série
        self.ser.close()

        try:
            self.ser.open()
        except serial.SerialException as e:
            sys.stderr.write("Ouverture du port série impossible {}: {}\n".format(ser.name, e))
            sys.exit(1)

        self.ser.write('AT\r')
        if self.WaitFor('OK', 'ERROR', 3) :
            print('SigFox Modem OK')

            self.ser.write("AT$SF={0}\r".format(message))
            print('Envoi des données ...')
            if self.WaitFor('OK', 'ERROR', 15) :
                print('OK Message envoyé')

        else:
            print 'Erreur Modem SigFox'

        self.ser.close()

if __name__ == '__main__':

    if len(sys.argv) == 3:
        portName = sys.argv[2]
        sgfx = Sigfox(portName)
    else:
        sgfx = Sigfox('/dev/ttyAMA0')

    message = "1234CAFE"
    if len(sys.argv) &amp;amp;amp;amp;amp;gt; 1:
        message = "{0}".format(sys.argv[1])
    sgfx.sendMessage(message)
    #time.sleep(600) #mise en sommeil pendant 10 mn

Ce programme s’utilise en ajoutant en paramètre les 12 octets à envoyer. Comme parfois l’éditeur de WordPress fait des siennes avec les programmes, vous pouvez aussi le télécharger ici.

Essai du programme SigFox en Python

pi@raspberrypi:~ $ ./tx.py 012345678901AABBCCDDEEFF
Serial port : /dev/ttyAMA0
Sending SigFox Message...
Délai de réception dépassé ()
Erreur Modem SigFox

Quand ça ne fonctionne pas voilà ce qui se passe. En fait ici j’avais laissé putty connecté au port série. Le programme n’a pas pu accéder au port qui était déjà occupé et a retourné une erreur.

pi@raspberrypi:~ $ ./tx.py 012345678901AABBCCDDEEFF
Serial port : /dev/ttyAMA0
Sending SigFox Message...
SigFox Modem OK
Envoi des données ...
OK Message envoyé

Cette fois le message a bien été envoyé. Un tour sur le site SigFox pour confirmer :

Vous voyez que le précédent message est « descendu » d’un cran et que le nouveau message est bien affiché sur la première ligne.

Envoyer le message vers un site web

Principe

La première partie de l’aventure reste la même : le Raspberry Pi envoie un message à la carte SigFox. La carte transmet les 12 octets maxi) par radio au réseau SigFox. A réception du message le serveur SigFox va transférer les données vers un serveur désigné par l’utilisateur. C’est ce qu’on appelle un « callback ».

Paramétrage du callback

Dans l’onglet « Device Type » du site SigFox, en cliquant sur le nom de la carte, on fait apparaître dans la colonne de gauche un menu comportant l’option Callback. En cliquant sur cette option, on ouvre la fenêtre ci-dessus. Le lien encadré en rouge est appelé après réception du message. Le numéro de la carte SigFox {device} et les données {data} reçues sont passées en paramètres à la page sigfox.php, présente sur le serveur VPS hébergé chez web4all.

Vous pourrez aussi passer les infos en PUT et en json si ça vous fait plaisir 🙂 RTFM

Le fichier sigfox.php

<?PHP
// Création de la chaine contenant les données
$data = '';
$data .=  htmlspecialchars($_GET["id"]).PHP_EOL;
$data .=  htmlspecialchars($_GET["data"]).PHP_EOL;

// Création du nom de fihier horodaté
$name = 'data_'.date('Y-m-d H:i:s').'.txt';

$maj = fopen($name,"w+");     // On ouvre le fichier en ecriture
fseek($maj,0);                // On se place en debut de fichier
fputs($maj, $data);           // On ecrit dans le fichier la chaine $data
fclose($maj);                 // On ferme le fichier
?>

Bon, j’avoue que je ne me suis pas foulé 😀 mais l’idée ici c’est de voir si ça fonctionne. Après, quand vous saurez récupérer vos données vous en ferez bien ce que vous voulez… Et puis ça vous fera un peu bosser aussi 😉

Dans le dossier du site web (accès au VPS avec putty) sur le serveur VPS on retrouve le fichier PHP sigfox.php qui récupère les données et les enregistre dans un fichier (par sécurité je vais le renommer avant de publier cet article 😀 😀 ). On voit aussi les fichiers horodatés créés lors des tests de la carte BRKWS01.

Les données enregistrées

root@prebeta1:/var/www/html# cat data_2017-02-14 20:46:52.txt
21xxxx
012345678901aabbccddeedd

Chaque fichier de données contient le numéro de la carte SigFox qui a envoyé le message et sur la ligne suivante le message lui-même.

Libre à vous de stocker ces infos dans une base de données, d’en extraire des moyennes, des statistiques et/ou de jolies courbes…

Dans 12 octets qu’est ce que tu veux mettre ?

Je viens d’un autre siècle. Non, je n’ai pas profité d’une faille spatio-temporelle ni effectué un voyage dans le temps. Mon premier ordinateur avait 1 Ko de mémoire. Pour les plus jeunes : il n’y a pas d’erreur ! Le ZX 81 possédait une mémoire de 1024 octets. Bon, j’ai vite ajouté une mémoire supplémentaire de 16 Ko sinon on ne faisait pas grand chose. Mais à cette époque, Monsieur, on coupait les Bytes en 4. Je m’explique : la place était tellement chère qu’on jonglait avec les données en mémoire pour occuper le moins de place possible. Décalages, rotations et autres masques à base de Et ou de OU logique étaient de rigueur. Aujourd’hui plus personne ne s’en préoccupe avec les Go de RAM disponible.

Sauf que…

Quand on n’a que 12 octets… Comment qu’on fait ?

Gestion des bits de données

Cliquez pour agrandir.

Un exemple sera plus parlant. Ce n’est qu’un exemple, hein, on peut certainement faire mieux et on peut certainement faire pire ! C’est pour faire comprendre à ceux qui n’ont jamais pratiqué ce genre d’exercice…

Une station météo isolée

C’est une demande fréquente dans la région (bin oui, je suis en Bourgogne) de disposer d’une station météo autonome pour surveiller une vigne. Elle doit être alimentée par panneau solaire, et pouvoir renvoyer par SigFox la température sol, la température de l’air, la pression atmosphérique, la vitesse et la direction du vent, la pluviométrie, la tension de batterie, la tension en sortie du panneau solaire et le courant de charge… en 12 octets.

Le bon informaticien replie son ordinateur portable, range sa tablette et sort quelques feuilles de brouillon, un crayon et une gomme. Le mauvais informaticien saute sur son clavier et se met à taper (n’importe quoi en général) frénétiquement… Enfin ça, c’est juste mon avis de vieil informaticien.

Le tableau est juste la transcription de réflexions « papier ». Après, vous ferez bien comme vous voulez 🙂

Température

  • Un bit est nécessaire pour le signe (+ ou -)
  • Trois bits codent le premier chiffre (0 à 7)
  • Quatre bits codent le deuxième chiffre (0 à 9)
  • Quatre bits codent pour la décimale (0 à 9)

Avec 12 bits on code une température entre -79,9 °C et +79,9 °C. On peut réduire le nombre de bits utilisés, au détriment de la facilité de traitement. c’est vous qui verrez en fonction de vos besoins de transmission d’information… Si vous avez eu ce genre de réflexion, n’hésitez pas à en faire part dans les commentaires. Toutes les idées sont bonnes !

Pression

Les valeurs extrêmes enregistrées mondialement sont de 870 hPa et 1086 hPa. Plus modestement en France on peut tabler sur 940 à 1067 hPa. J’ai donc choisi de représenter la valeur (pression – 940) ce qui donne une valeur entre 0 et 127 qu’on peut coder sur 7 bits.

Pour les autres valeurs du tableau, je vous laisse regarder, critiquer…

En bonus quelques commandes supplémentaires

SNOC fournit dans sa documentation les commandes suivantes :

Le jeu de commandes disponibles est assez limité. Heureusement la documentation AX-SFEU vient au secours de l’utilisateur curieux :

Présentation vidéo de la SNOC

 

Conclusion

Toute petite mais pleine de possibilités, cette carte ne coûte que 23,88 € avec les connecteurs, le câble de raccordement et l’antenne, plus un an d’abonnement à SigFox. Rien à redire de ce côté là.

Le fonctionnement est conforme à ce qui est attendu et le traitement des données ne pose aucun problème.

De mon côté j’aurais apprécié d’avoir un câble d’antenne un peu plus long. Il sera peut-être possible d’en trouver dans les accessoires.

Selon le montage qu’on fera, la carte sera au plus près de l’antenne (c’est mieux pour les ondes radio) et reliée au Raspberry Pi via une liaison série. Ici on n’a pas de contrainte de distance aussi forte. Du coup, j’aurais bien aimé trouver un trou de fixation sur le module, pour le monter sur une colonnette à proximité de l’antenne.

Vu la longueur de cet article, j’ai choisi de l’arrêter ici mais il y aura un second épisode car on peut aussi recevoir 4 messages par jour via SigFox (download) et piloter à distance certains équipements (mettre une chaudière en route, régler une température…). Plus prosaïquement, je prévois d’allumer une LED à distance en réglant sa brillance en PWM 😀

Sources

 

Cet article Carte de prototypage SIGFOX par SNOC a été publié en premier sur Framboise 314, le Raspberry Pi à la sauce française.....

Le port série du Raspberry Pi 3 : pas simple !

On ne l’avait pas vue venir, celle-là ! La Fondation nous l’a glissée en loucedé sur le Raspberry Pi 3 : pas de page d’information sur leur blog, juste des réponses dans les forums…
L’adjonction du Bluetooth au Raspberry Pi 3 a amené les concepteurs de la framboise à détourner l’UART du BCM2837 précédemment relié aux bornes 8 et 10 du GPIO vers le Bluetooth.

Cliquez pour avoir de l’information sur les niveaux.

Le port Série du Raspberry Pi 3

Les UART du Raspberry Pi

Un UART, pour Universal Asynchronous Receiver Transmitter, est un émetteur-récepteur asynchrone universel. En langage courant, c’est le composant utilisé pour faire la liaison entre l’ordinateur et le port série . L’ordinateur envoie les données en parallèle (autant de fils que de bits de données). Il faut donc transformer ces données pour les faire passer à travers une liaison série qui utilise un seul fil pour faire passer tous les bits de données. (Wikipedia)

UART0 = PL011

Le SoC du Raspberry Pi est toujours basé sur le même hardware, le BCM2835. Seul le microprocesseur a évolué. Le BCM2835 comporte deux UART, pour les liaisons série. Le premier, le PL011 est un « vrai » UART :

C’est à dire qu’il est autonome, doté de son propre générateur de Baud Rate, et de tous les circuits nécessaires à son fonctionnement.

UART1 = « mini » UART

Le second UART est quand à lui un « mini » UART :

Il ne comporte pas de générateur de Baud Rate et utilise la fréquence du cœur du CPU. Ça pourrait être bien, sauf que la fréquence du CPU est susceptible de varier en fonction de sa charge 🙁

Il ne gère pas non plus la parité.

C’était mieux avant ! Le port série du Raspberry Pi 2

Sur les premières générations de Raspberry Pi (model 1 B, B+ et 2) l’UART0 PL011 est utilisé et il est connecté aux broches 8 et 10 du GPIO. Les messages du système en cours de démarrage sont envoyés par défaut sur ce port. Il suffit de brancher un terminal pour les lire.

Cette entrée série peut également être connectée à un terminal qui servira alors à se connecter au Raspberry Pi après s’être logué.

Enfin, cette E/S série est utilisée dans des applications industrielles ou domotiques, pour lire des données GPS, relier deux Raspberry Pi entre eux, un Raspberry Pi avec un Arduino etc.

Le port série du Raspberry Pi 3 : la cata !

Le SoC du Raspberry Pi 3 est un BCM2837 SoC. C’est un BCM2836 avec un CPU quad-core ARMv8 qui peut fonctionner en 32 ou en 64 bits. Le mode 32 bits est actuellement sélectionné par défaut la firmware du VideoCore sur le Raspberry Pi 3.

Un autre changement intervient dans l’utilisation des UART. Sur tous les Raspberry Pi précédents, le PL011 était le seul UART en service. Le Raspberry Pi 3 accueille un module Bluetooth qui utilise un UART pour se connecter au SoC. Par défaut, c’est le PL011 qui est utilisé pour le Bluetooth car il a une pile FIFO plus importante que celle du « mini » UART.

Le mini UART est donc relié au port GPIO (broches 8 et 10).

Cette modification importante et non documentée a « cassé » des applications qui tournaient bien avec le port série du Raspberry Pi 2 et qui refusaient de fonctionner sur le Pi3. De nombreux articles de blogs qui fonctionnaient avec les générations précédentes de Raspberry Pi sont devenus inopérants. Les auteurs ne pensent pas forcément à revenir sur ces anciens articles et il faudra être prudent(e) si vous les utilisez.

Un UART pour mon SIGFOX

Dit comme ça ça peut sembler bizarre, mais je vous explique. La SNOC (Société Nationale des Objets Connectés) située à Saint-Sylvain-d’Anjou a sorti fin janvier une carte de prototypage pour SIGFOX. Cette BRKWS01 distribuée par Yadom, se connecte… sur le port série du Raspberry Pi (ou tout autre port série en 3,3v). Comme je prépare un article sur cette carte j’avais besoin du port série du Raspberry Pi 3.

Voilà, vous avez tout compris.

Pour faire fonctionner dans de bonnes conditions cette carte SIGFOX, je voulais la connecter au port série du GPIO (8 et 10) mais … ça ne fonctionnait pas et du coup bin voilà cet article 🙂

Rendre à César…

La première chose à faire c’est un choix. Est-ce que j’ai besoin du Bluetooth ? Ma réponse est non. Ça veut dire que je peux dévalider le Bluetooth et du coup récupérer l’UART « kivabien » pour ma carte SIGFOX.

Vous avez 4 options

  • Option 1 : Utiliser l’UART (le vrai !) en perdant la fonction Bluetooth. Il faut permuter les E/S des deux UART. Pour cela, ajoutez à /boot/config.txt : dtoverlay = pi3-disable-bt
    Puis supprimer :
    console=serial0,115200  dans cmdline.txt
  • Option 2 :  Faire fonctionner l’interface série et le Bluetooth correctement, mais la vitesse d’horloge du processeur sera fixée (à une vitesse faible [250MHz] ou à une vitesse élevée [500MHz?]). Ajoutez enable_uart = 1 à /boot/config.txt. Cela affectera les performances du processeur car ça contrôle la vitesse du cache L2, et on notera également une réduction de la qualité audio analogique (voyez ici et ).
    Si vous optez pour la vitesse d’horloge élevée (il faudra vraiment prévoir un ventilateur et un radiateur) pour garder la performance du processeur et la qualité audio, ajoutez également  force_turbo = 1 à /boot/config.txt.
  • Option 3 : Avoir une interface série « pourrie » sur le GPIO (vitesse variable) mais avoir un Bluetooth correcte : Ne rien faire. Ce sont les paramètres par défauts
  • Option 4 : Faire fonctionner correctement l’interface série (UART), avec un Bluetooth qui fonctionne lentement. Permutez les UART : ajoutez dtoverlay = pi3-miniuart-bt  au fichier /boot/config.txt, puis définissez la fréquence à une valeur fixe (faible) en ajoutant, toujours à /boot/config.txt : core_freq = 250. Cela affectera les performances du processeur.  Si vous préférez conserver des performances plus élevées n’ajoutez pas la ligne core_freq = 250 mais plutôt la ligne force_turbo = 1 mais cela nécessite d’utiliser un ventilateur et un radiateur.

J’ai choisi la première.

Les ports série

Si tout va bien en faisant un ls -l /dev vous devriez retrouver un port serial0 qui pointe vers ttyAMA0.

Les tests

Bien entendu pas question de connecter quoi que ce soit derrière le port série sans savoir d’abord si ça fonctionne. Vous me voyez venir ? Alors c’est une question dans les commentaires à la fin de l’article sur la carte SIGFOX (j’imagine, bien sûr : ça ne se produira pas ! 😀 ) :
« Bonjour, j’ai suivi le tuto mais ça ne marche pas ! »
Réponse : « Est-ce que vous avez testé le port série avant de connecter la carte SIGFOX ?  »
« Non, mais j’ai bien suivi le tuto !! ça doit marcher !!« 

Eh bien non, cher(e) lecteur(trice) ! Point ne suffit de suivre à la lettre un tuto ! Tu te dois de vérifier à chaque étape que le résultat attendu est bien au rendez vous…

Certes me diras tu, mais comment qu’je fais moi ? pour tester le port série ?
Fastoche :
Tu vas relier les ports GPIO 8 et 10 correspondant à TXD et RxD (Données émises => Données reçues).
Lorsque tu vas envoyer des données sur le port série TxD, elles vont revenir par le port RxD… Hop là retour à l’envoyeur (ça s’appelle un loopback) ! Et le programme utilisé pour envoyer les données va les recevoir et les afficher 🙂
Suite à une remarque de msg (voir les commentaires) reliez les bornes 8 et 10 avec une résistance pour éviter la destruction des ports (ou pire) en cas d’erreur. 680 Ω ou 560 Ω fera l’affaire.
Bon avant de sortir la grosse artillerie on va dégainer un petit bout de Python, déjà pour se rendre compte de ce qui se passe.

 

Attention !
Le loopback fonctionne bien lorsque l’UART est connecté aux broches 8 et 10. Pensez à débrancher le court-circuit entre ces deux bornes après la fin des tests, sinon vous risquez d’endommager votre SoC !

Un programme en Python

#!/usr/bin/env python
# -*- coding: utf-8 -*-
#
# Test du port série
import serial
test_string = "Je teste le port série 1 2 3 4 5"
port_list = ["/dev/ttyAMA0", "/dev/ttyAMA0", "/dev/ttyS0", "/dev/ttyS0",]
for port in port_list:
  try:
    serialPort = serial.Serial(port, 9600, timeout = 2)
    print "Port Série ", port, " ouvert pour le test :"
    bytes_sent = serialPort.write(test_string)
    print "Envoyé ", bytes_sent, " octets"
    loopback = serialPort.read(bytes_sent)
    if loopback == test_string:
      print "Reçu ", len(loopback), "octets identiques. Le port", port, "fonctionne bien ! \n"
    else:
      print "Reçu des données incorrectes : ", loopback, " sur le port série ", port, " bouclé \n"
    serialPort.close()
  except IOError:
    print "Erreur sur ", port, "\n"

Ce programme (adapté d’un prog du forum raspberrypi.org) va envoyer des données en sortie sur le port série, puis les récupérer  sur l’entrée. Ici le test qui nous intéresse est celui de /dev/ttyAMA0. Vous pouvez mettre les ports que vous voulez tester dans la liste.

Lancez le programme de test et vous devriez obtenir :

pi@raspberrypi:~ $ python tesTxRx.py
Port Série  /dev/ttyAMA0  ouvert pour le test :
Envoyé  33  octets
Reçu  33 octets identiques. Le port /dev/ttyAMA0 fonctionne bien !
Port Série  /dev/ttyAMA0  ouvert pour le test :
Envoyé  33  octets
Reçu  33 octets identiques. Le port /dev/ttyAMA0 fonctionne bien !
Erreur sur  /dev/ttyS0
Erreur sur  /dev/ttyS0

Si vous n’avez pas la confirmation que le port ttyAMA0 fonctionne correctement, inutile de continuer. Il faut d’abord faire fonctionner ce port pour pouvoir l’utiliser.

Minicom un mini émulateur de terminal sous Linux

Pour utiliser Minicom, commencez par l’installer sur votre Raspberry Pi.

pi@raspberrypi:~ $ sudo apt-get install minicom

Configurez le :

Pour adapter le fonctionnement à la carte SIGFOX qui rejoindra ce Raspberry Pi, il faut régler les paramètres du port série à 9600 bits par seconde, 8 bits de données, pas de parité et un bit de stop. Ceci se traduit par 9600 8N1.

Choisissez également le port série pour qu’il corresponde au port raccordé au GPIO : /dev/ttyAMA0.

Il ne reste plus qu’à tester : tapez… n’importe quoi sur le clavier et ça doit apparaître sur l’écran. Si rien n’apparait… C’est que le port série ne fonctionne pas ou que quelque chose est mal configuré.

Conclusion

Ce n’est pas la première fois que la Fondation Raspberry Pi nous fait le coup. On avait déjà connu ça avec l’introduction de systemd, peu documentée. Les habitués de Linux s’en sortaient tant bien que mal, mais cela avais mis de nombreux débutants en mauvaise posture. Pas ou peu d’infos, pas de doc… Système D ( 😀 ) obligatoire.

Eh bien là c’est rebelotte. On modifie les ports série, pas ou peu d’infos… Des surprises à la clé !

Eh les gars pensez aux utilisateurs… Le Raspberry Pi est fait pour l’éducation (aussi) et ceux/celles qui le mettent en œuvre ne sont pas forcément des vieux linuxiens barbus ! Alors s’il vous plait un peu d’infos et de doc, juste un peu 😉

Sources

Raspberry Pi 3 + UART/Bluetooth issues from yeokm1

Cet article Le port série du Raspberry Pi 3 : pas simple ! a été publié en premier sur Framboise 314, le Raspberry Pi à la sauce française.....

Mangeoire d’oiseau filmée par un Raspberry Pi et sa caméra

Une fois n’est pas coutume, aujourd’hui, je laisse la parole à Guillaume pour nous parler de sa mangeoire d’oiseau filmée par un Raspberry Pi alimenté en POE avec une détection de mouvement pour prendre des photos :
C’est un projet de longue date, j’ai d’abord commencé avec un hack NSLU2 (un petit NAS hackable sous Linux) avec une simple webcam d’intérieur en USB, puis de fil en aiguille, j’ai ajouté du POE (Power Over Ethernet), un allumage / extinction à l’aide d’un Arduino en fonction de l’heure de lever et coucher du soleil, une détection de mouvement pour ne prendre des photos qu’au bon moment… Mais après plusieurs années de bons et loyaux services, j’ai enfin pu changer l’ensemble par un Raspberry Pi avec sa webcam.

Les objectifs de ce projet sont les suivants :

  • utiliser du matériel low cost
  • faire en sorte que la solution soit la plus WAF possible  😉
  • que ce soit fun à fabriquer !

Ce premier article présentera le matériel que j’ai utilisé pour mettre dehors mon Raspberry Pi : en démarrant par le choix de la caméra, puis mes expériences avec la nappe de la webcam, l’abri utilisé pour mettre l’ensemble dehors et la mise en œuvre de POE passif.

Caméra

Le modèle de caméra que j’utilise est le standard accompagnant le Raspberry Pi avec la particularité tout de même qu’elle est équipée d’un objectif de 12mm testé dans ce billet. Ce type de caméra possède la particularité d’avoir un objectif avec un pas de vis compatible CCTV (caméra de surveillance) ce qui offre une large gamme d’objectif interchangeable et donc pouvoir le changer si nécessaire.

Webcam du Pi avec un objectif interchangeable de 22 mm

Webcam du Pi avec un objectif interchangeable de 22 mm

Mon idée initiale est d’éloigner la caméra du Pi afin de la mettre dans un petit boitier proche de la mangeoire. La nappe reliant la camera au Raspberry est petite (15 cm) et rigide et les nappes les plus longues mesurent 30 cm max.

Nappe de la camera du Raspberry

Nappe de la camera du Raspberry

Il me faut donc relier la webcam et le Pi avec un câble plus long. Qu’à cela ne tienne, je vais donc m’en fabriquer une ! J’ai utilisé une nappe de câble souple de 2m de long au pas de 1,27 mm de type DIP.

Nappe de 2m au pas de 1.27 mm

Nappe de 2m au pas de 1.27 mm

Le pas de la nappe d’origine est très fin, 0,7 mm de type FFC, j’ai utilisé des adaptateurs FFC ⇔ DIP sur lesquels je vais souder d’un côté la nappe et de l’autre l’adaptateur. Le connecteur FFC doit être soudé sur l’adaptateur.

Connecteur FFC et adaptateur DIP

Connecteur FFC et adaptateur DIP

Après quelques soudures, voici le premier connecteur assemblé :

Connecteur soudé

Le montage consiste donc à relier la webcam avec sa nappe d’origine à l’adaptateur lui même relié à la longue nappe puis de repasser sur l’adaptateur pour se brancher sur le Raspberry Pi.
Je craignais que la longueur de câble pose des problèmes de stabilité d’image mais ce n’est pas le cas. La caméra est bien reconnue et les images transmises sont parfaites.

Connecteur coté caméra

Raspberry Pi connecté

Raspberry Pi connecté

Webcam du Raspberry Pi dans une boite électrique

Webcam du Raspberry Pi dans une boîte électrique

J’ai assemblé le tout dans un boîtier électrique étanche et découpé le couvercle pour y loger une ouverture avec une plaque de plexiglas transparente.
J’ai alors voulu réduire la largeur de la nappe en séparant en 4 et dans le sens de la longueur les brins mais la webcam ne se synchronise plus :'( Je pense qu’il y a désormais trop d’interférences électromagnétiques; une hypothèse serait que l’alternance habituelle d’un fil faisant circuler un signal positif avec son voisin qui fait passer le signal contraire n’est plus conservée. Cela a pour conséquence que le signal reçu n’est plus aussi « propre » et la webcam décroche. Retour à la case départ :'(

Maison d’oiseaux

Pour pallier à cet échec, j’ai décidé de tout mettre dans une même boîte : Raspberry + webcam. J’ai déniché une petite maison d’oiseau de décoration trouvée dans une grande surface de jardinage. En l’adaptant, j’ai tout fait rentrer dedans.

Maison d'oiseau

Maison d’oiseau

J’ai arrangé une fenêtre sur la face centrale pour y loger la webcam du Raspberry pi à l’aide de ma Dremel. La webcam est fixée avec des vis à tête fraisée et des petites entretoises. Avec un morceau de plexiglas provenant d’une boîte de chocolat, j’ai fabriqué une petite vitre placée devant la webcam pour refermer la boite 8-). La petite porte de devant a été fermée à l’aide d’un fond en bois de boîte de camembert découpée à la bonne taille.

J’ai également vernis la maison d’oiseau pour résister aux intempéries.

Maison d'oiseau convertie en caméra de surveillance

Maison d’oiseau convertie en caméra de surveillance

Alimentation

Pour gagner de la place dans la petite maison d’oiseau, je n’utilise pas le connecteur d’alimentation Micro-USB du Raspberry. En remplacement, j’utilise les connecteurs  »4 » et  »6 » du port GPIO pour l’alimenter avec un connecteur fait maison.

Brochage du port GPIO

Brochage du port GPIO

Le Raspberry intègre un régulateur de tension branché juste après le port Micro-USB. En l’alimentant directement par le port GPIO, cet étage de régulation est by-passé. Il faut donc être très vigilant sur la tension appliquée sur les pins au risque de le griller.

POE

La mangeoire sera placée dans le jardin et la longueur du câble entre le Raspberry et le serveur est de 35m. Je ne veux pas faire amener du 220 V au milieu du jardin et j’ai donc regardé comment mettre en place du Power Over Ethernet passif. Pour se faire il existe des adaptateurs POE auprès de sites d’enchères en ligne : d’un côté, il y a l’alimentation + réseau en entrée et de l’autre, le câble Ethernet de transport. Le frère jumeau de l’adaptateur se retrouve de l’autre côté et sépare le courant de la data.

Connecteur POE passif

Connecteur POE passif

Pour fonctionner, il faut savoir que sur un câble Ethernet, en 100 Mbits, seules 2 paires sur les 4 sont utilisées. De nombreuses bidouilles sont alors possibles : POE, double Ethernet

Voici un schéma de l’assemblage final :

POE sur le Raspberry Pi

Pour abréger les souffrances du lecteur, je saute les étapes de calculs de la résistance d’un câble selon son diamètre pour arriver à la formule finale avec :

  • Résistivité :
  • Diamètre :
  • Longueur :
  • Section :

La résistance du conducteur est donc de :

Le Pi est donné pour consommer environ 5 W minimum, soit 1 A avec son alimentation de 5 V.
La chute de tension est donc au minimum (loi d’Ohm) : 3.7*1=3.7 V. En l’alimentant directement avec son transformateur à l’extrémité du câble, il ne recevra que 5-3.7=1.3 V, il ne fonctionne pas avec si peu de courant. Il faut donc une tension d’entrée plus élevée.

Je vais donc utiliser un bloc d’alimentation dédié. Le Pi consommant régulièrement plus de 1 A, il faut donc prévoir une alimentation conséquente, celles habituellement vendues avec les appareils hi-tech sont trop justes.

J’ai finalement opté pour un adaptateur secteur multi tension de 24W environ et j’ai sélectionné une tension de 12V

Pour obtenir 5 V au niveau du Raspberry Pi, plusieurs solutions sont possibles, dont notamment l’utilisation d’un régulateur de type LM7805. Ceux ci sont très simples à mettre en oeuvre mais transforment la chute de tension en chaleur et donc chauffent beaucoup.

Les régulateurs de tension à découpage sont également communs. Plutôt que d’appliquer une résistance variable comme le LM7805, ils hachent le courant avec une fréquence de 150 kHz environ en faisant varier la taille des créneaux haut et bas puis la re-linéarisent afin que la tension moyenne de sortie soit stable. Cela est beaucoup plus efficace et chauffe très peu. De nombreux montages tout prêt sont disponibles sur les sites de ventes aux enchères en ligne à un coût dérisoire.

LM2596

LM2596

Ainsi, en mettant ce régulateur en bout de câble entre l’adaptateur POE et le Raspberry Pi, je peux alors l’alimenter en 5V.

Le réglage de ce régulateur s’effectue à l’aide d’un potentiomètre, d’abord à vide puis en branchant le Pi afin de charger l’alimentation.

Réglage de la tension : de la théorie à la pratique

Réglage de la tension : de la théorie à la pratique

Installation

Ensuite, yapluka faire l’assemblage final, fixer le tout près de la mangeoire et régler l’objectif de la webcam pour avoir une image nette.

Le plus dur a été de tout faire rentrer dedans sans abimer le matériel : le Raspberry, l’adaptateur POE, la webcam et le régulateur d’alimentation.

Raspberry Pi dans sa petite maison

Raspberry Pi dans sa petite maison

Le lecteur attentif aura remarqué que je n’ai rien décrit par rapport à l’étanchéité de l’ensemble : je n’ai en effet rien fait de spécial, le toit de la mangeoire protège bien de l’eau et n’empêche pas l’air de circuler afin d’éviter les phénomènes de condensation. Cela fait maintenant plus d’un an que l’ensemble est dehors de tout temps et je n’ai aucun dysfonctionnement à signaler !

Je les ai fixés sur le haut d’une claustrat avec une grosse équerre.

Gros plan sur la maison d'oiseau avec le Raspberry Pi

Gros plan sur la maison d’oiseau avec le Raspberry Pi

Vue de l'ensemble : webcam avec le Raspberry pi et la mangeoire

Vue de l’ensemble : webcam avec le Raspberry pi et la mangeoire

L’ensemble fini est plutôt propre et le WAF est à un niveau très acceptable ;).

Vue de la webcam

Voici quelques photos prises par la webcam au cours de l’hiver dernier :

Tourterelles . (Cliquez pour agrandir)

Moineaux (Cliquez pour agrandir).

Pie (Cliquez pour agrandir).

Pour résumer

C’est le 2e hiver que mon Raspberry Pi passe dehors et je n’ai pas eu de problème d’humidité ou autre. Les oiseaux se régalent des graines que je dépose et cela fait la joie de la caméra qui capture tous ces moments.

Le matériel un peu exotique utilisé ici provient de sites d’enchères en ligne qui font la joie des bidouilleurs.

Dans un second article, je décrirais la mise en oeuvre logicielle pour mettre en place du stream vidéo sur le réseau local, de la détection de mouvement et un allumage / extinction du Raspberry Pi en fonction de l’heure du lever et coucher du soleil à l’aide d’un Arduino.

Vous pouvez retrouver cet article et bien d’autres encore sur mon site : http://www.monbook.tech/

Edit 13/02 :
merci à « Dodutils » pour l’erreur de typo de l’objectif
merci à « msg » d’avoir pointé une mauvaise application numérique dans le calcul de résistance du cable

Cet article Mangeoire d’oiseau filmée par un Raspberry Pi et sa caméra a été publié en premier sur Framboise 314, le Raspberry Pi à la sauce française.....

Pi Zero et USB-net (2)

Pi Zero et USB-net

Dans l’article précédent, nous avons réussi à nous connecter depuis un PC hôte vers un Raspberry Pi Zero uniquement en employant un câble USB semblable à ceux pour téléphone portable.

Néanmoins, nous avions relevé plusieurs points restant à améliorer :

  • la connexion SSH est un peu longue à établir,
  • le Raspberry Pi Zero n’a pas accès à Internet,
  • il est nécessaire de fixer manuellement l’adresse IP de l’interface USB-net du côté PC.

Réglons ces problèmes un à un.

Accélérer la connexion SSH

Le serveur SSH (démon sshd) présent sur la distribution Raspbian du Pi Zero essaye d’identifier la machine qui vient se connecter en utilisant une résolution DNS. Puisque l’accès au DNS est impossible (pas d’accès Internet), et que même s’il était joignable il y a peu de chances qu’il connaisse le PC hôte, il faut attendre que le démon sshd échoue dans cette identification avant de poursuivre la connexion.

Nous pouvons désactiver aisément ce comportement en éditant le fichier de configuration de sshd (sur le Raspberry Pi Zero).

pi@raspberry:~ $ sudo vi /etc/ssh/sshd_config

Il suffit d’ajouter la ligne suivante à la fin du fichier :

/etc/ssh/sshd_config:
[...]
UsePAM yes

UseDNS no
pi@raspberry:~ $ sudo reboot

À partir de ce moment, la connexion sera plus aisée…

L’avantage de cette première solution est qu’elle est assez générique, je l’adopte sur la plupart des systèmes embarqués que je configure.

Dans notre cas spécifique, où une seule machine est susceptible de venir se connecter sur le serveur SSH, on peut adopter la solution proposée par Stéphane Peters en commentaire de l’article précédent. Il s’agit d’éditer le fichier /media/$USER/etc/hosts pour y ajouter une ligne identifiant le PC :

/media/$USER/etc/hosts:
[...]
192.168.7.1 host-pc

Accéder à Internet depuis le Raspberry Pi Zero

Lorsque nous somme sur le Pi Zero, la seule connexion vers l’extérieur est le lien USB-net point-à-point avec le PC hôte. Pour accéder à Internet il nous faudra donc passer par ce PC (à supposer bien sûr qu’il soit lui même relié au Net). Pour cela nous allons configurer les règles de routage et de filtration du noyau Linux du PC

Une fois la connexion établie, il suffit d’exécuter sur le PC quelques lignes de commande iptables pour activer le NAT (Network Address Translation) ainsi que la redirection (forwarding) au niveau IP.

Je pense que seules les deux dernières commandes sont indispensables, mais j’ai l’habitude d’exécuter le script ci-dessous complet afin de repartir d’une configuration vierge.

set-nat-rules.sh:
#! /bin/sh

# Inside network (without Internet access).
INSIDE=usb0

# Outside network (with Internet access).
OUTSIDE=eth0

# Flush the rules of the NAT table.
iptables -t nat -F  || { echo "$0: error while flushing NAT table rules." >&2; exit 1; }

# Delete the user-defined chains of the NAT table.
iptables -t nat -X  || { echo "$0: error while deleting NAT table chains." >&2; exit 1; }

# Reset the statistics of the NAT table.
iptables -t nat -Z  || { echo "$0: error while resetting NAT table counters." >&2; exit 1;
 }

# Flush the current forwarding rules.
iptables -F FORWARD || { echo "$0: error while flushing forwarding rules." >&2; exit 1; }

# Accept packets from INSIDE network to OUTSIDE network.
iptables -A FORWARD -i ${INSIDE} -o ${OUTSIDE} -j ACCEPT   || { echo "$0: error while conf
iguring ${INSIDE}->${OUTSIDE} forwarding." >&2; exit 1; }

# Apply NAT to OUTSIDE packets.
iptables -t nat -A POSTROUTING -o ${OUTSIDE} -j MASQUERADE || { echo "$0: error while conf
iguring NAT on ${OUTSIDE}." >&2; exit 1; }

# Activate the packet forwarding.
echo 1 > /proc/sys/net/ipv4/ip_forward || { echo "$0: error while enabling IP forwarding."
 >&2; exit 1; }

echo "Configuration OK." >&2

exit 0

J’exécute donc la commande suivante sur mon PC, après avoir ajusté les deux premières variables du script.

$ sudo ./set-nat-rules.sh

Et sur le Pi Zero je tente un accès vers Internet

pi@raspberrypi:~ $ ping www.kernel.org
PING pub.all.kernel.org (198.145.20.140) 56(84) bytes of data.
64 bytes from tiz-korg-pub.kernel.org (198.145.20.140): icmp_seq=1 ttl=46 time=166 ms
64 bytes from tiz-korg-pub.kernel.org (198.145.20.140): icmp_seq=2 ttl=46 time=188 ms
64 bytes from tiz-korg-pub.kernel.org (198.145.20.140): icmp_seq=3 ttl=46 time=174 ms
64 bytes from tiz-korg-pub.kernel.org (198.145.20.140): icmp_seq=4 ttl=46 time=167 ms
^C
--- pub.all.kernel.org ping statistics ---
4 packets transmitted, 4 received, 0% packet loss, time 3004ms
rtt min/avg/max/mdev = 166.502/174.144/188.734/8.915 ms
pi@raspberrypi:~ $

Le temps de ping est un peu long (170 ms environ), à cause du réseau USB-net et de la redirection sur le PC, mais cela fera l’affaire pour notre usage.

On pourra noter qu’au bout de quelques dizaines de secondes, l’heure du Raspberry Pi Zero sera correctement mise à jour. Il inclut en effet un client NTP (Network Time Protocol) qui interroge régulièrement des serveurs distants.

Automatiser l’affectation d’adresse

Pour que le PC reçoive automatiquement une adresse IP lors de l’établissement de l’interface USB-net, il suffit d’installer un serveur DHCP sur le Raspberry Pi Zero.

Ceci est facile à faire, puisque nous disposons de tout le confort de la distribution Raspbian et de ses packages. Nous pouvons par exemple installer le petit serveur udhcpd (provenant de Busybox) facile à configurer.

pi@raspberrypi:~ $ sudo apt-get update
[...]
pi@raspberrypi:~ $ sudo apt-get install -y udhcpd
[...]

Il faut configurer le serveur DHCP pour lui indiquer les adresses qui nous intéressent.

pi@raspberrypi:~ $ sudo mv /etc/udhcpd.conf /etc/udhcpd.conf.backup
pi@raspberrypi:~ $ sudo nano /etc/udhcpd.conf

On peut utiliser une configuration très simple qui impose à notre correspondant (le PC) l’adresse 192.168.7.1 :

/etc/udhcpd.conf:
 start      192.168.7.1
 end        192.168.7.1
 interface  usb0
 max_leases 1
 option subnet 255.255.255.252

Nous devons également faire démarrer le serveur udhcpd automatiquement au boot. Pour cela nous devons modifier une option du fichier /etc/default/udhcpd.

/etc/default/udhcpd:
DHCPD_ENABLED="yes"
[...]
pi@raspberrypi:~ $ sudo reboot

Il devient possible, sur le PC, de modifier la configuration du Network Manager pour que l’interface USB-net soit initialisée automatiquement avec le protocole DHCP.

Boîte "Configuration de connexion filaire 1"

Attention à bien laisser cochée la case “Utiliser cette connexion uniquement pour les ressources de son réseau”. C’est ce qui nous garantit que nous pourrons continuer à accéder à Internet grâce à l’autre interface du PC.

Boîte "Modification des routes IPv4 pour Connexion filaire 1"

Conclusion

Nous avons obtenu une configuration assez confortable pour le Raspberry Pi Zero : simplement branché à un PC par un câble USB standard, il devient joignable via SSH sur une adresse IP connue, et peut accéder librement à Internet (pour peu que le PC fasse le relais).

Raspberry Pi Zero : enfin disponible en France !

Un an qu’on attendait ça ! grâce à Kubii le Raspberry Pi Zero est enfin disponible en France.
Des descriptions de projets il y en avait plein, des cartes d’extensions il y en avait encore plus 🙂
La seule chose qui manquait à l’appel… c’était le Raspberry Pi Zero lui-même !
Aujourd’hui Kubii, partenaire de framboise314, annonce enfin la disponibilité du Pi Zero en France.

Pour pouvoir répondre à un maximum de demandes, et en raison des livraisons limitées, les Pi Zero seront vendus à l’unité.

Raspberry Pi Zero disponible en France chez Kubii

Le Raspberry Pi Zero est disponible seul (5.62€)

Des kits avec adaptateurs

 

Pour ceux qui démarrent avec le Pi Zero le kit de base (17,99€) comporte un adaptateur mini-HDMI <=> HDMI ainsi qu’un adaptateur micro USB <=> USB ainsi qu’une carte micro SD avec le système préinstallé.


A mon avis celui-ci le kit Zero PLUS (23.90€) est préférable. Il comporte une protection qui met les Pi Zero à l’abri des contacts avec des objets métalliques.


Le Kit le plus complet STARTER KIT PIZERO (29.90€) comporte en plus une alimentation. Pour démarrer de zéro 😀 c’est une bonne alternative.

L’ensemble de ce matériel est disponible à partir du 8 février 2017 à 10H sur le site de Kubii.

Cet article Raspberry Pi Zero : enfin disponible en France ! a été publié en premier sur Framboise 314, le Raspberry Pi à la sauce française.....

Overclocker un Raspberry Pi 3 : rêve ou réalité ?

C’est un peu comme les inventions… Quand c’est dans l’air il faut que ça sorte. Après l’excellent article de l’Officiel PC Raspberry Pi sur l’overclocking du Raspberry Pi 3 j’avais choisi de faire imprimer en 3D un boîtier recevant un ventilateur pour tester cette possibilité. Dans le même temps Raspbian-France actualise un article sur le même sujet. Bin là c’est un peu pareil, l’heure de l’overclocking est venue. En français vous appellerez ça le surcadencement ou … surfréquençage 🙂

Cliquez pour avoir une information sur les niveaux.

En raison des risques encourus je déconseille ces tentatives aux débutants (après, chacun fait ce qu’il veut 😉 ) pour les réserver plutôt aux utilisateurs avancés ou confirmés.

Attention, DANGER
L’overclocking est une opération risquée pour un Raspberry Pi. L’augmentation de température qui en découle peut diminuer la durée de vie du SoC, provoquer des plantages du système, voire vous faire perdre la garantie constructeur. Vous faites ces tests à vos risques et périls. Framboise314 ne pourra être tenu responsable en cas de problème.

Tous les composants de même référence sont identiques

FAUX ! Prenez par exemple ce lot de transistors. Ils se ressemblent tous, ils sortent de la même chaîne de fabrication, ils portent la même référence. Ils sont donc tous pareils !

Eh non ! Chacun est un individu différent des autres. Parce que lors de la fabrication la température a varié de quelques dixièmes de degrés, parce que le silicium aussi pur et régulier soit-il a de minuscules défauts, parce que les fils soudés sur les sorties provoquent de légères variations, parce que l’inclusion dans un boîtier amène des perturbations légèrement différentes etc. Chaque composant est différent de son voisin.

Le test final des composants

Comment le fabricant fait-il pour caractériser ses composants ? Il les teste en sortie de chaîne de fabrication. D’une part pour éliminer les composants défectueux, d’autre part pour les trier en fonction d’un certain nombre de critères.

BC547B

Par exemple pour un transistor BC547 on va trouver ces modèles :

  • BC547 : Gain 110 à 800
  • BC547A : Gain 110 à 220
  • BC547B : Gain 220 à 450
  • BC547C : Gain 420 à 800

Vous imaginez bien que le BC547C est vendu plus cher que le BC547 😉

 

Ce qui est intéressant c’est de voir que le même composant peut avoir un gain qui va de 110 à 800 !

Et pour les microprocesseurs ?

C’est pareil ! A la sortie de chaîne de fabrication, chaque composant est soumis à une batterie de tests. On élimine les composants défectueux, on vérifie le bon fonctionnement de chaque microprocesseur et… on mesure sa fréquence maximale de fonctionnement. Ceux qui sont en dessous de la fréquence cible sont éliminés (ou vendus comme déclassés, on les retrouvera éventuellement sur des sites de vente en ligne…).

Par exemple le même microprocesseur BCM2835 fonctionnait à 700 MHz sur les premières générations de Raspberry Pi et à 900 MHz sur le Raspberry Pi Zero. Mais on pouvait déjà augmenter sa fréquence au delà de 700 MHz, jusqu’à 1GHz.

On peut estimer que si un CPU est garanti pour fonctionner à 700 MHz, le fabricant a pris une marge et que 80% des BCM2835 montent à 800 voire 900 MHz. Ça veut dire aussi que quelques pourcents des CPU montent à 1 GHz, et un pouième monte à 1,1 GHz ou un peu plus…

Avec l’amélioration de la qualité en production, ce même BCM2835 est maintenant garanti pour fonctionner à 900 MHz.

Même pour le BCM2837 du Raspberry Pi 3 ?

Il est soumis aux mêmes tests en fin de production et il est garanti pour fonctionner à 1,2 GHz. Maintenant vous savez que ce n’est que la fréquence garantie par le fabricant et qu’en fait votre BCM2837 va monter plus haut en fréquence, et peut-être même beaucoup plus haut 🙂

Overclocker un Raspberry Pi 3

Soyons prudents

Pas question de mettre en danger la vie d’un Raspberry Pi 3. J’ai « investi » dans un jeu de radiateurs. Il y a un radiateur à ailettes pour le CPU, un autre pour le circuit USB/Ethernet et une plaque de cuivre pour assurer le refroidissement de la mémoire.

Montage des radiateurs

Le Raspberry Pi 3 a été équipé de ces radiateurs, munis d’un adhésif présentant un bon coefficient de transmission de la chaleur. Après mure réflexion 😀 j’ai décidé de les coller dans ce sens mais à mon avis comme le ventilateur est juste au-dessus ça doit avoir peu d’importance.

Pour la mémoire, la plaque est plus adaptée. Dans un boîtier, il y a peu de place sous le Raspberry Pi et cette solution peu encombrante permet d’utiliser un boîtier classique.

Ventilation forcée

Pour les tests de l’impression collaborative Freelabster, j’avais choisi un boîtier qui pouvait être équipé d’un ventilateur de 30 mm.

J’ai monté le ventilateur pour qu’il souffle l’air ambiant sur le radiateur du CPU. L’autre possibilité était d’aspirer mais pas sûr que les ouïes d’aération soient prévues pour ça.

Pas besoin d’écrou, le diamètre des trous est plus petit que le diamètre de la vis… La fixation se fait en vissant directement dans le plastique du couvercle imprimé.

On connecte la prise sur les broches 4 et 6 du GPIO (fil rouge +5v sur la broche 4, fil noir GND sur la broche 6).

Pensez à passer le fil par le trou du boîtier sinon il faudra démonter. (On ne rigole pas ça m’est arrivé 😀 )

Allez on met sous tension ! Le ventilo tourne bien (sur la photo on voit le radiateur à ailettes à travers les pales…).

Bon, après quelques minutes il a commencé à faire un bruit pas sympathique du tout, un mélange de bruit de frottement et de souffle d’air. Bin pour faire un mediacenter qu’on va mettre dans le salon, c’est pas top 😉

Allez on oublie le bruit et on va faire chauffer le Raspberry Pi… ou pas 🙂

Que dit la configuration ?

Officiellement, le Raspberry Pi 3 n’est pas overclockable si l’on en croit la fenêtre de configuration affichée dans PIXEL.

Mais quand on regarde dans /boot/config.txt on trouve cette ligne :

#uncomment to overclock the arm. 700 MHz is the default.

On voit qu’avec 700 MHz affichés, c’est un héritage des précédentes versions. Mais c’est bien là que ça se passe 🙂

Qu’est-ce qu’on peut modifier ?

Le gouverneur

governor (gouverneur ou régulateur) indique au système comment gérer la vitesse du processeur.

Les noyaux Linux récents intègrent un pilote cpufreq avec le régulateur « ondemand » activé par défaut. Il n’a aucun effet tant que vous n’avez pas overclocké le Raspberry Pi. Mais si vous le faites, la fréquence du CPU variera en fonction de la charge du processeur. Vous pouvez ajuster les valeurs minimales avec les options de configuration * _min ou désactiver la variation de fréquence d’horloge avec force_turbo = 1.

Le régulateur peut prendre plusieurs valeurs (d’après PhoneAndroid.com) Ces régulateurs sont prévus pour gérer la consommation d’un smartphone, destination première du BCM2837. Pour les lister sous Raspbian :

pi@raspberrypi:~ $ cat /sys/devices/system/cpu/cpu0/cpufreq/scaling_available_governors
conservative ondemand userspace powersave performance 

Les différents régulateurs

  • Conservative : Il est plus économe en énergie que OnDemand car il monte lentement à la fréquence maximale lors d’une sollicitation puis redescend rapidement à la fin de celle-ci. Si vous lancez une appli gourmande en ressources (un jeu par exemple) le démarrage sera ralenti par ce régulateur, le temps que la fréquence maximum soit atteinte.
  • OnDemand : C’est celui qui est défini par défaut sur le Raspberry Pi. Lorsque la demande en ressources des applications dépasse un certain seuil, il définit automatiquement la fréquence à son maximum. Puis il baisse la fréquence par paliers en fonction de la diminution de la charge, et remonte la fréquence au maximum si la demande remonte. C’est un compromis intéressant entre autonomie et puissance malgré une tendance à trop augmenter la consommation du CPU (sur les courtes et moyennes sollicitations). Il peut donc diminuer l’autonomie plus que d’autres régulateurs dans ce cas. (à voir donc pour des applications alimentées par batterie !)
  • Userspace : Ce régulateur ne réagit pas aux demandes système. C’est l’utilisateur qui définit la fréquence d’utilisation. Il est considéré comme obsolète.
  • Powersave : Fait constamment tourner le CPU à la fréquence minimale définie. Écologique mais… le Raspberry Pi va ramer en permanence 🙂
  • Performance : Pousse la fréquence du processeur au maximum en permanence. Il est très gourmand en énergie et en cas d’utilisation prolongée à une fréquence trop élevée, il peut causer des dommages matériels au processeur.

Les deux valeurs qui nous intéressent sont ondemand et performance.

Forcer la valeur du régulateur

Pour forcer le régulateur à performance j’ai utilisé :

echo "performance" |sudo tee /sys/devices/system/cpu/cpu0/cpufreq/scaling_governor

A chaque reboot malheureusement le gouverneur revenait à la valeur par défaut ondemandJ’en ai donc fait un fichier exécutable que j’ai lancé depuis rc.local  (/home/pi/gouv.sh &) à chaque démarrage. Ensuite le gouverneur gardait la bonne valeur lors d’un reboot. Pour vérifier ajoutez l’icône de moniteur de fréquence dans la barre des tâches et passez la souris dessus (image ci-dessus).

Pour info
En utilisation normale (sans forcer le turbo, ni dépasser un over_voltage de 6) l‘overclock et la surtension que vous appliquez sont désactivés lorsque le SoC atteint 85 °C dans le but de le faire refroidir. Vous ne devriez pas atteindre cette limite, même avec les réglages maximum lorsque la température ambiante est de 25 °C.

La vitesse du CPU

Déjà la fréquence ! Plus elle est élevée, plus le CPU pédale ! Mais attention c’est un peu comme votre voiture sur l’autoroute.

L’énergie de la voiture augmente comme le carré de la vitesse… En passant de 90 à 110 Km/h l’énergie augmente de 2000. De 110 à 130 Km/h l’énergie augmente de 2400. De 130 à 150 KM/h l’énergie augmente de 2800. et ainsi de suite. (Pour les sodomiseurs de diptères, on n’a rien à faire des unités, c’est l’accroissement d’énergie qui nous intéresse)

Du côté de la consommation c’est lié, accélérer de 10 Km/h quand vous roulez à 50 Km/h ne consomme pas autant que l’accélération de 10 Km/h quand vous roulez à 130 Km/h d’autant que la résistance de l’air est elle aussi proportionnelle au carré de la vitesse 🙁

Si tout ça vous intéresse faites un tour sur ce site qui propose les courbes pour la Toyota Yaris, tracées avec GNU Plot.

La tension

Donc plus vous roulez vite, plus l’augmentation de vitesse a une incidence sur l’énergie de la voiture et plus vous consommez de carburant. Pour le CPU plus la fréquence augmente, plus il dissipe d’énergie (il chauffe !) et plus il faut augmenter la tension d’alimentation !!

Bon revenons à nos moutons.

Quel est donc le rapport avec l’overclocking ? Pour pouvoir augmenter la vitesse du CPU, il faut jouer également sur la tension du cœur. Pour le BCM2835 le paramètre over_voltage peut varier de -16 à +8. Et l’énergie dissipée est proportionnelle… au carré de la tension !

Par défaut over_voltage vaut 0 et cela correspond à une tension de 1,2 volt appliquée au cœur. -16 correspond à 0,8 volt et chaque incrément augmente la tension de 0,025 volt.

Attention à la garantie

 

Attention !
Une valeur au dessus de 6 pour over_voltage n’est permise que si force_turbo est activé. Dans ce cas un bit est positionné de façon irréversible dans un registre et vous perdez la garantie du CPU !

 Sur l’axe des abscisses figure la valeur de l’over_voltage. L’axe des ordonnées, positionné à la valeur 8, indique la valeur de la tension en fonction de la valeur d’over_voltage. Lorsque over_voltage vaut 0, la tension du cœur est à 1,2 volt. Les deux dernières valeurs d’over_voltage 7 et 8 positionnent de façon irréversible le bit d’un registre qui annule la garantie du BCM2837 !

On voit que la courbe représentant l’énergie dissipée en fonction de la fréquence « grimpe » plus vite que celle de la tension.

Quelques essais

Sans ventilateur

Boîtier ouvert (donc sans ventilation forcée par le ventilateur), avec une charge CPU autour de 50% la température grimpe à 51 degrés.

Avec le boîtier ouvert en lisant une vidéo, la température grimpe à 60 degrés.

Une fois le boîtier fermé mais toujours sans ventilateur, sans charge CPU, la température est à 50 degrés, la même température que si le boîtier était ouvert, mais le CPU chargé à 54%.

Avec ventilateur

Dans les mêmes conditions que ci-dessus : Boîtier fermé, pas ou peu d’activité CPU, une fois le ventilateur mis en route la température descend de 15 degrés ! Quand même…

Et là… avec une charge CPU importante, ventilateur tournant, la température reste à 45 degrés.

On peut donc dire que la ventilation forcée a une forte influence sur la température du CPU.

Tests de vitesse

Les décimales de pi

Comment tester la vitesse de calcul du CPU ? j’ai choisi un test classique, le calcul des décimales de pi. Ça tombe bien, non ? C’est un exemple qui est donné dans le man de la commande bc :

pi=$(echo "scale=10; 4*a(1)" | bc -l)

Qui deviendra dans notre cas

time echo « scale=5000; 4*a(1) » | bc -l

  • time : mesurer le temps d’exécution
  • scale=5000 : Nombre de décimales de pi à calculer
  • 4*a(1) : formules mathématique pour calculer pi. Utilise la fonction Arc Tangente a().
  • bc -l : la formule est envoyée à la commande bc, pour que celle-ci effectue le calcul. L’option -l permet de charger la librairie mathématique standard, nécessaire pour utiliser la fonction Arc Tangente a().

Installation de bc

La calculatrice en ligne de commande bc n’est pas installée par défaut dans Raspbian. Il faut donc l’installer. Au passage on peut voir que l’activité du CPU lors de l’installation reste autour de 45% et la température à 40 degrés. Le boîtier était fermé, ventilateur en fonctionnement.

Calcul de 5000 décimales de pi sans overclock

Lançons le premier test de vitesse qui servira de référence. J’ai testé le calcul de 50, 500, 5000 et 50000 décimales.

pi@raspberrypi:~ $ time echo "scale=50 ; a(1)*4" | bc -l
3.14159265358979323846264338327950288419716939937508
real    0m0.006s
user    0m0.000s
sys    0m0.000s

6 mS pour calculer 50 décimales… ce n’est pas très significatif et les comparaisons ne seront pas faciles

et pour 50000 décimales il faut plus de 8 heures ! Euhhh… ça fait peut-être beaucoup ! Pas simple dans ce cas de multiplier les tests 🙂

J’ai donc opté pour 5000 décimales de pi.

time echo "scale=5000; 4*a(1)" | bc -l

Bon, là c’est utilisable : 1 minute 20 secondes sans overclock ce n’est pas trop long pour un test et avec l’affichage des millisecondes on a suffisamment d’informations pour faire des comparaisons.

Calcul de 5000 décimales de pi avec overclock

Avec la fréquence poussée à 1,4 GHz le temps de calcul tombe à 1 minute et 9 secondes (j’arrondis). La température est bien contrôlée puisqu’elle se maintient à 41 degrés.

Ici un test à la fréquence de 1,450 GHz, on est tombé à 1,7 seconde et la température est toujours vers 40 degrés.

Alors on fait comment ?

Bin… j’aurai tendance à dire chacun sa m…éthode. C’est pour ça que j’ai indiqué que l’article est destiné aux utilisateur avancés. Ici pas de recette du genre : Voilà les valeurs qu’il faut mettre pour overclocker votre Raspberry Pi 3. Ce serait une connerie ignorer que chaque microprocesseur est vraiment unique et que si overclock il y a, il faudra absolument l’adapter à chaque cas ! Ce qui fonctionne chez moi ne fonctionnera peut-être pas chez vous et je vais encore avoir des commentaires du genre : « J’ai bien suivi le tuto mais ça ne marche pas ! Vous avez une idée ? » ou encore « C’est quoi ce tuto pourri qui marche pas ? » 😀

Il va falloir vous armer de patience, et d’un tableur, noter les valeurs que vous mettez dans /boot/config.txt et… tester ! Si vous ne prenez pas de notes après une dizaine de tests vous ne vous souviendrez plus des premiers résultats 😀

Les valeurs que vous pouvez modifier sont ci-dessus : la fréquence du GPU, celle du CPU et celle de la mémoire plus la tension du cœur. Certaines combinaisons fonctionnent, d’autres non 🙁

Parcourez les articles dans les sources pour en savoir plus.

Et c’est pas tout !

On pourrait croire que le fait d’avoir mis des valeurs dans config.txt, redémarré Raspbian et calculé 5000 décimales de pi est suffisant. Eh bin non ! Il faut aussi faire un test en chargeant « vraiment » le CPU, tester la lecture et l’écriture en mémoire et accéder à la carte microSD en lecture et en écriture. A quoi ça servirait d’avoir un Raspberry Pi qui tourne à 1,5 GHz s’il plante dès qu’on appuie sur une touche du clavier ?

Faut pas stresser…

Bin si, justement on va le stresser le CPU avec un programme qui s’appelle… stress-ng ! Commencez par installer ce programme, ensuite vous pourrez l’utiliser.

Lorsque vous lancerez le programme stress-ng, vous verrez l’indicateur de charge CPU bondir à 100% et la température monter inexorablement pour se stabiliser (autour de 60 degrés dans mon cas). Et puis après un moment tout se fige (ou pas) et vous savez que la fréquence CPU est trop élevée.

Diminuez un peu la fréquence et… recommencez !

Surtout, n’oublies rien !

A quoi ça sert d’avoir un CPU qui pédale comme s’il avait un vélo électrique, mais qui oublie pourquoi il pédale ? En clair Si vous augmentez la vitesse de la mémoire, il faut aussi vérifier qu’elle continue de fonctionner normalement.

Pour ça on va utiliser memtester (installez -le).

Avec la commande free, regardez la mémoire disponible et lancez memtester en lui passant cette valeur (en Mo) en paramètre. memtester commence des tests. Considérez déjà que s’il a fait une boucle c’est bon signe. Attention, si memtester plante ou signale une erreur, celle-ci peut aussi être due à un problème de CPU (fréquence ou over_voltage)… Vous voyez c’est pas si simple 🙂

Une carte n’est pas le territoire

Ce clin d’œil à Alfred Korzybski nous amène à la carte micro SD. Là encore, il ne sert à rien de booster les performances de votre Raspberry Pi s’il se produit des erreurs de lecture ou d’écriture sur la carte SD. Ça va forcément se finir en catastrophe.

sdtest.sh est disponible sur elinux.org. En voici une copie :

#!/bin/bash
#Simple stress test for system. If it survives this, it's probably stable.
#Free software, GPL2+

echo "Testing overclock stability..."

#Max out all CPU cores. Heats it up, loads the power-supply. 
for ((i=0; i&lt;$(nproc --all); i++)); do nice yes &gt;/dev/null &amp; done

#Read the entire SD card 10x. Tests RAM and I/O
for i in `seq 1 10`; do echo reading: $i; sudo dd if=/dev/mmcblk0 of=/dev/null bs=4M; done

#Writes 512 MB test file, 10x.
for i in `seq 1 10`; do echo writing: $i; dd if=/dev/zero of=deleteme.dat bs=1M count=512; sync; done

#Clean up
killall yes
rm deleteme.dat

#Print summary. Anything nasty will appear in dmesg.
echo -n "CPU freq: " ; cat /sys/devices/system/cpu/cpu0/cpufreq/scaling_cur_freq
echo -n "CPU temp: " ; cat /sys/class/thermal/thermal_zone0/temp
dmesg | tail 

echo "Not crashed yet, probably stable."

Laissez tourner sdtest.sh. S’il va à son terme tout va bien il a fait dix cycles de lecture et d’écriture sur la carte SD 🙂

Là encore en cas de plantage ou d’erreur il conviendra de jouer sur les paramètres du CPU.

 Ci dessus un test avec une fréquence de 1,350 GHz. La température à la fin du test atteint 63 °C. J’ai réduit le nombre de boucles à 2 lectures et 2 écritures pour accélérer le processus. Quand les paramètres d’overcloking permettent de boucler 2 fois, repassez à 10 boucles et… allez boire un café 🙂

Y-a quoi à gagner ?

Le tableau ci-dessus résume les tests et le gain en temps sur le calcul de pi (ce n’est qu’une indication, il faudrait tester d’autres applications).

Dans mon cas les conditions de fonctionnement stable avec tous les tests sont réunies à une fréquence CPU de 1350 MHz.

Les réglages sont alors ceux-ci. Ce qui ne présage rien pour vos propres réglages.

Le gain en vitesse est de 13% pour une performance (calcul de pi) améliorée de 11%.

Comme quoi c’est pas le tout de faire son cake en annonçant à la cantonade (rien à voir avec le joueur de foot) « Mon Raspberry Pi 3 tourne à 1,5 GHz ! » s’il plante dès qu’on applique une charge au CPU 🙂

Comme je n’ai pas l’intention (pour le moment) de tester le watercooling

ni le refroidissement par module Peltier

je trouve que le jeu n’en vaut pas la chandelle…

La consommation

Pour un Raspberry Pi 3 sans overclock, en faisant tourner stress-ng  on a une consommation de 0.95 A soit 4.75w

Le même Raspberry Pi 3 avec stress-ng et une fréquence CPU de 1350 MHz consomme 1.14 A soit 5,7w

C’est 20% de consommation supplémentaire pour 10% de performance en plus 🙁

Conclusion

Gagner un peu plus de 10% de performance en soumettant un microprocesseur à des conditions pour lesquelles il n’est pas forcément prévu, ce n’est pas mon truc.

Entre un Raspberry Pi un tout petit peu plus lent et le ventilateur qui me casse les oreilles depuis 2 jours (oui le Pi3 tourne à 1,350 GHz depuis 2 jours pleins maintenant, sans planter, même avec des applis ouvertes et utilisées :

J’ai fait mon choix.

Comme on le dit :  il n’y a que les imbéciles qui ne changent pas d’avis. Je n’étais pas fan (jeu de mot) d’overclocking, eh bien je le reste ! Donc… je suis un imbécile ( 🙁 qui a dit ça on le savait déjà ?). Je vais donc remettre mon Raspberry Pi 3 en état « normal » et fermer la parenthèse sur cet épisode.

Bon, après si vous avez des expériences positives de l’overclocking, rien ne vous empêche de les raconter dans les commentaires ci-dessous, avec des photos si vous voulez 🙂

Sources

Cet article Overclocker un Raspberry Pi 3 : rêve ou réalité ? a été publié en premier sur Framboise 314, le Raspberry Pi à la sauce française.....