Reprise du message précédent :
Le GPIO passe aussi de 26 a 40 pins.

Merci.
Excellente nouvelle donc. J'aurais pas craché sur un petit IR intégré, mais c'est déjà une bonne avancée

 
Esthétiquement, ça dépasse pas, c'est la bonne nouvelle.
 
Pour la fiabilité, ça dépend. Le mécanisme est à ressort et la carte dépasse pas, donc on risque moins d'éclater l'emplacement et de casser la carte. La fiabilité de la carte elle-même, c'est plutôt pire : c'est la même technologie derrière, mais avec des puces plus petites, donc souvent gravées plus finement, ce qui veut dire généralement moins endurante. Et ça nécessite un adaptateur pour être lu dans pas mal de PC.

Oui je pensais à l'aspect mécanique (et le fait que, personnellement, j'ai déjà vu des SD s'ouvrir en 2 à force de les manipuler), pas à la technique derrière.

Bonjour,

j'ai un petit soucis avec mon raspberry pi. Je pense que c'est parce que j'ai essayé de brancher une enceinte sur le port jack .

Mon raspberry pi ne boot plus, plus de signal, j'ai juste la LED rouge/power allumée (qui ne clignote pas).
J'ai vérifié la tension entre TP1 et TP2, elle est OK (5.32 V).

Apparemment une LED rouge signifie que le pi ne trouve pas les fichiers pour booter.
J'ai donc essayé de réinstaller raspbmc sur la carte SD, même problème. Idem en installant par USB (les fichiers de boot sont sur la clé USB).

mon Pi est-il mort ?

edit : bon ça a l'air de passer avec une autre carte SD, étrange vu que la première carte ne semble pas poser de problème sur le PC.

T'as qu'une carte SD pour tester ?    

J'ai édité mon message, en testant avec une autre carte SD ça passe effectivement .
Ca ne m'était pas venu à l'idée tout de suite car la carte a l'air de fonctionner normalement sous windows.
Bon du coup j'en profite pour installer le système sur USB !

Question par rapport à l'install USB :
J'ai une sauvegarde de ma précédente SD, est-ce que je pourrais écraser le contenu de la clé USB par le contenu qui vient de la carte SD ? Ou est-ce qu'il y a des fichier qui diffèrent selon l'install SD/USB (je pense modifier le fstab à la main, mais à part ça ?)  ?

 
il faut obligatoirement laisser une carte sd pour rediriger le boot vers la cle.

Oui ça c'est Ok, je me demandais si je pouvais écraser le contenu de ma clé USB avec une sauvegarde de mon système qui avant était installé sur ma carte SD .

Oui tu peux sans soucis, c'est d'ailleurs la technique pour passer le root de SD à USB. Faut juste modifier le fstab et le cmdline.txt
Par contre n'oublies pas de formater correctement la partition sur la clé USB (ext3 ou 4 et pas fat/ntfs).

En fait je viens de faire une nouvelle install par USB, donc la partition USB et le cmdline sont OK, reste que le fstab alors, cool .
 
Bon le temps de tout copier je reviens cet aprem pour vous dire si ç a a fonctionné .

Quelqu'un pour m'aider là dessus ?

Il faudrait aussi que la build gère les applications GPS capables de fonctionner avec GPS Bluetooth.

Et pilotables via smartphone évidemment.

http://raspberrypiaustralia.com.au [...] del-b-plus
 
Model B+ comparé au Model B
 
ce qui ne change pas:
 

•    Broadcom BCM2835 Chipset
•    512MB RAM
•    port HDMI
•    port Ethernet 10/100  
•    port caméra CSI et port d'affichage DSI
•    port micro USB pour l'alimentation

Ce qui change:
 

•    4 ports USB au lieu de deux
•    un port GPIO de 40 pins au lieu de 26. La compatibilité des premiers 26 pins est conservée avec le Model B si vous voulez passer un projet de Model B à Model B+
•    un slot Micro SD au lieu de SD tout court.
•    Le Model B+ balance maintenant 1200mA sur l'ensemble des ports USB. (il vous faudra une alimentation fournissant 2000mA au minimum).
•    La carte du Model B+ consomme maintenant 600mA au lieu de 750mA pour la carte du Model B.
•    Le port jack est maintenant subdivisé en 4 points de connexion pour combiner son stéréo + vidéo, afin de suppléer à la disparition du port vidéo RCA.

https://twitter.com/element14/status/488625990458150912

(edit: demandez de l'extra sauce Raspberry au stand et on vous file un B+ gratos)

 
Pourquoi il parle du Full HDMI 1080P ? Ils ont l'air de presenter ca comme une nouveaute du B+.
 
Genre ici:

C'est pas une nouveauté, c'est une caractéristique.

Merci pour la comparaison, on voit directement les points intéressants .

Du coup ça me permet de poser une question pour l'ampérage de l'ensemble des ports USB: elle est de combien max pour le modèle B normal et est-ce que ça suffit pour alimenter un disque 2.5" autonome (pour peur qu'on aie un transfo qui suive derrière, off course ) ?

Moi j'ai un adap de 1000mA et je peux pas alimenter mon dd externe 2.5" en tout cas

Est-ce qu'un chargeur micro-usb pour Kindle peut faire l'affaire comme transfo?

Il sort quand ce nouveau pi ?

Non, car le port d'alimentation Micro-USB du modèle B est protégé par un Polyfuse, limitant le courant max global à environ 1A, ports USB compris.

Il faut soit :
- court-circuiter le Polyfuse
- alimenter par le port GPIO
- alimenter par les points de soudure "test points"
- alimenter via l'un des deux ports USB host.

Personnellement je l'ai fait sans aucune plainte de la part du disque dur, sur plusieurs mois. Ceci dit, je soupçonne que ce n'est pas suffisant parce qu'après plusieurs mois justement, il a commencé à faire des bruits pas très réguliers (je n'ai plus le nom du modèle sous la main)

 
la limite est plutot vers 1.1A au global. donc 300/400 dispo pour lusb . ca doit suffire pour la majorité des disques. avec deux ce serait limite

 
OK . Merci pour les infos . J'imagine que les 200mA globaux qu'on aura en plus ne seront pas suffisant pour un DD 2.5" ?
Ca serait con car c'est quand même plutôt intéressant comme support "de voyage".  
 
Bon sinon, j'ai commencé samedi le setup de mon Pi pour mon usage perso et même si la mise en place de tout mon merdier est parfois un peu compliquée vu les ressources limitées du Pi (entendre: ne lui demander de faire qu'une seule chose à la fois), voici ce que j'ai d'opérationnel + liens pour les gens intéressés:
 

• ddclient pour DNS Dynamique (via dnsdynamic.org - ne paye pas de mine mais est gratuit et fonctionnel -). Petit guide ici, les fichiers de confs proposés dans le "guide" et sur le site du fournisseur sont pourris; j'ai les corrections si ça intéresse quelqu'un.
• RPi-Monitor pour surveiller globalement ce qu'il se passe sur le Pi. Plutôt intéressant, surtout au début pour vérifier dans quelle mesure le Pi peut être affecté par l'une ou l'autre tâche ou modification (overcloking, mémoire, réseau & co). Si vous avez une alternative plus complète, ça m'intéresse, je trouve les infos trop sommaires.
• Compilation + installation dernière version Sabnzbd+ : voir le guide
• Compilation + installation de "unrar-nonfree" (oui parce que la version free, faut pas déconner non plus ) : voir la partie sur "unrar" dans ce guide un peu trop touffu
• Compilation + installation dernière version de Sickbeard. Là c'était une première, Pi ou non Pi. Voici le meilleur guide que j'ai trouvé en la matière en termes de complétude/clarté/précision. Néanmoins, il n'est pas parfait car volontairement simplifié (ex: on laisse l'installation dans /home/pi) et après l'exemple du fichier de conf, le guide laisse un peu à désirer. Là j'ai recoupé avec plusieurs sources, dont le site officiel et ce guide de configuration sabnzbd+/sickbeard. Au final j'ai fait quelque chose à ma sauce qui marche au poil .
• Installation serveur NFS + configuration des montages exportés. Voir ce petit guide presque suffisant mais comportant quelques petites erreurs et qui n'est pas auto-portant. Entendre par là qu'il est nécessaire de se bouger un peu les fesses et lire un peu de manpage (man exports + man exportfs). Je viens de finir, ça fonctionne sans grande difficulté; il faut que je teste maintenant à l'utilisation et que je tweak certaines options pour les performances. Utilité: 1. Faire joujou . 2. Automatiser l'accès au disque externe de 1TB que je lui ai collé, sans utiliser SFTP (sous-système de SSH, vous l'avez donc d'activé si le serveur SSH est activé ).

A suivre sur ce Pi:
 

• Finalisation des points de montage NFS.
• Couchpotato
• Automatiser mes backups de mon desktop vers le disque externe du Pi. Pour le moment je fais du rsync manuel.

S'il arrive à encaisser tout ça, je le laisserai en paix après . Pour ma partie mediacenter, je pense que je vais rester sur mon vieux portable Asus A6ja (CoreDuo) + Lubuntu 14.04 LTS + XBMC; j'ai pas tellement envie de m'emmerder avec toutes les considérations de performances - et le portable me sert déjà de media center depuis des années -.
 
Pour un prochain Pi (B+ ), j'ai pour projet d'y foutre une centrale IPBX asterisk-based. Plus précisément, la dernière Xivo quand j'aurai un peu de temps pour tenter la cross-compilation. Avec ça je collerai un dongle 3G/GSM Huawei Pi-compatible puis je dégage ma ligne téléphonique physique en faisant porter mon numéro sur OVH et en utilisant le dongle GSM comme relais gratuit (60 min gratuit par jour de mon opérateur à mon opérateur ). Adieu FT/Belgacom ensuite . Mais bon, ça sera pour plus tard .
J'ai confirmation d'un maintainer de Xivo qu'en son temps, sur une version moins performante, le Pi pouvait gérer jusqu'à 10 conversations; largement assez pour un usage domestique donc .
 
Voilà qui clôture mes premiers projets/envies avec le Pi. Je dois pas vraiment être le gars le plus doué en la matière mais si vous avez des questions, n'hésitez pas .

 
Faudrait que j'essaye avec un transfo plus balaise que celui que j'ai qui de la récup de mon Nexus S (5V, 700mA); c'est juste suffisant pour le Pi (mais overclock medium quand même ).
Parce que j'aimerais bien pouvoir lui coller mon Seagate Expansion 500 GB en 2.5" quand j'ai besoin de récupérer des données ou autre.

Ha, un truc que j'ai trouvé super important pour utiliser le Pi dans de bonnes conditions: ne pas lui coller de disque en NTFS.
C'est vraiment *la* difficulté que j'ai rencontrée ce week-end.

Je savais que le reverse-engineering sur le NTFS n'est toujours pas (et ne sera probablement) jamais parfait dans les drivers de linux et bouffait du CPU mais ça se ressent énormément sur le Pi.

Conclusion: j'ai passé à peu près 24h à transvaser mon 1TB + full check au milieu + formater le disque en ext4. Sinon, le driver NTFS bouffait entre 30 et 40% de CPU lorsque Sabnzbd+ téléchargeait à ~800ko/sec, qui me bridait de facto vu que ma ligne peut monter jusqu'à ~1200ko/sec.

/NTFS 2 cents

Merci pour ton retour
Concernant Rpi-monitor, il peut monitorer plusieurs Rpi ? Et on peut programmer des alertes ?

Ya aussi RaspControl pour faire du monitoring mais faut installer Apache/PHP, c'est pas très pratique je trouve
 
J'avais commencé à bosser pour faire une version qui surveille plusieurs Rpis en remote mais ça fait des mois que j'ai plus rien fait

Non a priori c'est vraiment pensé pour le Pi, donc:

• self-contained: ça s'installe sur le Pi et on y accède en HTTP; je pense que le merdier doit tirer un serveur http minimaliste genre jetty mais je n'en suis pas sûr.
• Consomme un minimum en ressources du Pi (c'est totalement vrai ) et déporte un maximum la charge de travail vers le client web (=> c'est le navigateur client qui se tape tout le boulot d'assemblage des données, mise en forme & co).

A priori, pas d'alerte programmable mais je pense que ça serait une feature à proposer à l'auteur (qui me semble être francophone ).

Page GitHub: https://github.com/XavierBerger/RPi-Monitor
Son blog: http://rpi-experiences.blogspot.fr/

Si tu veux voir à quoi ça ressemble en vrai avant de t'embarquer à l'installer, je peux te donner accès à mon RPi-Monitor si tu veux ; j'ai qu'un port à ouvrir .

 
Oh putain le truc showstopper .
 

 
Ici c'est vraiment un dev très lightweight et très propre, c'est très sympa:  
 

pas mal

le genre de truc qui doit détruire la SD (io)

Bon alors j'ai essayé de déplacer raspbmc d'une carte SD vers une clé USB et je n'arrive pas à booter.

J'ai un message d'erreur (switch_root: can't execute /sbin/init  input/output error) je pense qu'il doit y avoir un problème de droit mais je ne vois pas comment y remédier (transfert fait d'une machine virtuelle sous ubuntu en root, les droits devraient être conservés non ?)

 
Ca dépend de quoi on parle . Ce qui risque de vraiment bouffer ma SD, pour le moment, c'est que je m'en sers comme espace de stockage temporaire avant de traiter le contenu téléchargé pour l'expulser vers le stockage USB. J'ai fait ça parce que j'ai une clef 32GB et aussi parce que sinon les performances sont tout simplement catastrophiques .
Pour le reste, le NFS ne tape que l'USB.
 
Si j'avais un deuxième disque à coller pour le stockage temporaire, je le ferais volontiers mais là je suis à court de matos de récupération.
 
Mais j'avoue que n'ayant pas de recul par rapport à ça, je me suis déjà dit qu'une fois que j'aurais fini - rapidement - le restant de ma liste sur ce Pi, je vais faire une image de la SD .
 
Fini de fignoler mes réglages NFS d'ailleurs: j'ai du passer en asynchrone car les perfs du pi ne permettaient pas une utilisation agréable en lecture vidéo. Je suis plutôt content; en bourrinnant mon Pi comme une vache j'arrive encore à lire du 1080p par le réseau .

Bon courage avec ça, j'espère que tu n'as pas une grosse connexion ou bien que le temps de download/post-traitement n'est pas important pour toi.
Quand je vois comme mon ancien NAS équipé d'un armada 300 (1.2GHz) en chiait pour dépasser les 1.2Mo/s en DL alors qu'il avait lui des I/O dignes de ce nom (en tout cas comparé à une SD). Et je ne parle pas de la vérification des PAR et de la décompression qui rendait (single core oblige) toute autre opération, download compris, impossible pendant ce temps ... et quand on parle de fichier de plusieurs Go ça devenait simplement interminable.

Ca s'emmerde un peu d'installer des choses en plus sur les rpi, ils sont pas grands choses dans le lard.
 
Tu faisais comment comment pour transférer les infos entre les différents rpi ?
 

Non, ça va, je vais tester sur un de mes rpi, ça sera plus simple.
Merci

Par contre sympa rpi-monitor, je ne connaissais pas. Merci The Geddons

 
Je ne suis pas un petit nouveau sur sabnzbd+ donc je partageais les même appréhensions que toi . Ma réponse va être: je pense que tu as raison sur le fond mais que le Pi reste quand même intéressant pour cette utilisation. La seule condition pour que le système "marche": c'est accepter la contrainte de temporalité. Je m'explique.
 
Si c'est pour faire un D/L à la sauvette et avoir tout tout prêt là tout de suite à l'instant, ça ne convient pas je pense - quoi que -. Néanmoins, quand c'est pour une utilisation de fond, en continu, le Pi est parfait pour les qualités qu'on lui connaît:
 

• 0 db
• Consomme très peu (~5W)
• faible coût de remplacement si orage

 
Pour ce qui est des temps de post-processing, les précautions suivantes rendront l'affaire tout à fait acceptable:

• ne pas lui coller de disque externe NTFS pour les raisons citées ci-dessus.
• si possible, ne pas avoir l'espace de téléchargement temporaire sur le même disque le complet pour ne pas faire de la lecture/écriture sur le même support à la fin. Moi j'ai une carte SD32GB (à changer plus tard) pour le temporaire et un disque USB 1TB en EXT4 pour le définitif.
• activer absolument sur le Pi ou tout autre système à puissance modeste pour ce genre d'utilisation l'option suivante: Pause Downloading During Post-Processing et ça aidera grandement .

Faudrait que je regarde sur des échantillons tests les temps de traitement, mais sur des morceaux de 1.5 à 2GB, franchement c'est tout à fait raisonnable pour le moment .
 

 
De rien, enjoy .

Via SSH.

En fait je reprenais les directives et la présentation de RaspControl et je faisais passer tout ça par SSH.

Genre lire la température du CPU:

Pour revenir sur le temps de post-processing, en fait j'ai réfléchi que je pouvais déduire fiablement ce temps de mes graphes réseaux puisque Sabnzbd+ se met en pause au niveau du post-processing. Donc pendant la nuit j'ai une alternance de gros blocs de download à vitesse maximum et des petits creux à 0. Résultats grâce à RPi-monitor + ses fonctions de sélection plage horaire:
 


 
Grosso modo, ça prend 4 à 5 minutes pour faire un post-processing complet (check, repair, unrar + post-processing Sickbeard) sur une archive d'environ 1,5 GB.  
C'est clairement pas une foudre de guerre mais ça reste acceptable .

Ce qui donnerait quand même plusieurs heures pour une ISO BR
Mais c'est vrai que pour de petites archives c'est tout à fait acceptable !