Aller au contenu


Contenu de Serveurperso

Il y a 392 élément(s) pour Serveurperso (recherche limitée depuis 03-avril 13)



#107707 Conversion d'un bras robot pour Vigibot

Posté par Serveurperso sur 12 février 2020 - 10:55 dans Vigibot

La solution que j'avais trouvé avec des Dynamixels c'est de réduire le couple sur le H-Bridge 1 seconde après le dernier mouvement.

Un moteur DC + une réduction c'est difficile d'aller a contre sens même avec une alimentation faible au niveau du moteurs.

 

Pour simuler ce compotement avec ton retour de position analogique va falloir un algo qui fait la même chose.

Il faut serrer plein pot pendant 1 seconde en suite tu retourne à la position actuelle Minus un Delta configurable.

 

Il reste par essai erreur à configurer ce delta pour avoir une bonne prise qui fasse pas chauffer le moteur.




#107705 Conversion d'un bras robot pour Vigibot

Posté par Serveurperso sur 12 février 2020 - 10:42 dans Vigibot

Oui t'as raison...




#107703 Conversion d'un bras robot pour Vigibot

Posté par Serveurperso sur 12 février 2020 - 09:40 dans Vigibot

La solution est toute simple : tu mets le REINIT sur la pince et ça force l'utilisateur a tenir la souris, quand on lâche hop l'objet tombe




#107597 BigWheels, le robot tout terrain piloté par Vigibot.com

Posté par Serveurperso sur 03 février 2020 - 12:32 dans Robots roulants, chars à chenilles et autres machines sur roues

Hey lardon! T'as oublié d'indiquer la provenance de la majorité de ce matos 😂



#107521 Conversion d'un bras robot pour Vigibot

Posté par Serveurperso sur 28 janvier 2020 - 06:55 dans Vigibot

J'ai pas encore réussi à faire fonctionner ce genre d'adaptateur... j'ai pas passé plus de 10 minutes dessus aussi. Je te recommande plusieurs PI3 A+ vu le prix... ça permet d'avoir des trucs autonomes que tu peux placer partout et plus d'I/O




#107518 Conversion d'un bras robot pour Vigibot

Posté par Serveurperso sur 28 janvier 2020 - 05:58 dans Vigibot

Cool Vinchator il déchire ton bras robotique !

 

L'adaptateur HDMI j'ai le même et toujours trop de FPS inutiles et trop d'instabilité du drivers....

 

Comme les webcam USB j'ai testé différentes logitech le driver v4l2 est moisi ça sort 15FPS max tout en ayant une image assez zoomée et sans piqué...

 

Les seules entrées vidéo convenables sont les caméra PI CSI v1 aftermarket (image style GoPro) la caméra d'origine étant zoom et piqué beark.

 

L'unique exception au détriment de la latence (* 2) c'est Raspberry PI 4 + une carte de capture à 100 euros qui fait du hardware déinterlace + caméra PAL @ 25FPS (éviter NTSC résolution plus faible!)

C'est uniquement valable pour des caméras intéressantes comme du CMOS noir et blanc hyper sensible (voir robot Astro sur vigibot en démo)

Ou du CCD SuperHAD ayant un fort gain vidéo pour voir en indoor couleur même si éclairage faible par contre le bruit vidéo tue la compression H.264 donc <1.5Mbps d'upload s'abstenir.

Le client vigibot sait utiliser ffmpeg avec de l'encodage hardware c'est optimisé a bloc mais malgré cela il faut une PI 4. Ceci a cause de la mauvaise optimisation de la bande passante USB sur les autres PI ça fait des décrochages infâmes @ aux résolutions minimum "réglementaire" sur vigibot soit 640x480 30FPS (digital) ou 720x576 25FPS (analog).

 

Il faut vraiment rester sur du PI Camera v1 vu le prix des PI 3 A+ et faire un couple PI+Caméra par vue de ton bras sur vigibot.

Trouver un multiplexeur multi CSI qui fonctionne serait pas mal car les 2 que j'ai ne fonctionne pas.... dans ce cas on ferais un truc avec les GPIO et hop multi-vue avec 1 seule PI.

 

Une alternative est la caméra PI V2 avec l'upgrade aftermarket du capture + objectif grand angle (car le PCB comporte une puce I2C Crypto qui emêche les copies améliorées de la caméra complète par les chinois). ça donne de la HD sur vigibot, mais c'est plus lourd à décoder, mais il est possible de faire plusieurs profils de flux sur la même caméra (voir IMX219 sur vigibot en démo) par contre pas de filtre IR cut amovible donc usage indoor sombre impossible.

 




#102739 Flipper pilotable à distance

Posté par Serveurperso sur 01 avril 2019 - 01:37 dans Autres projets inclassables

Bravo et bon stages !



#102324 Projet VigiBot, le robot contrôlé facilement par internet pour tous par Vigir...

Posté par Serveurperso sur 03 mars 2019 - 10:15 dans Assistance à la personne

Ce genre de prix ne m'étonne pas du tout en B2B!




#102316 Projet VigiBot, le robot contrôlé facilement par internet pour tous par Vigir...

Posté par Serveurperso sur 02 mars 2019 - 06:40 dans Assistance à la personne

Hop ça avance toujours, un nouveau petit robot qui fait la surface d'une PI !

L'interface affichera de moins en moins de chose, juste ce qui est nécessaire en fonction du robot.

 

 

IMG_20190209_115908.jpg




#102063 Accéder à distance à un Raspberry ou Caméra IP de manière sécurisée

Posté par Serveurperso sur 07 février 2019 - 09:08 dans Projets logiciels, web, ou simulations

Un numéro port TCP est le "numéro de téléphone" d'un logiciel ouvrant ce port, au même titre qu'une adresse IP est le "numéro de téléphone" d'une interface réseau distante.
D'où le nom de TCP/IP.

L'adresse IP + le port (192.168.0.10:1234) forment une socket TCP/IP et si on ajoute le protocole exemple https://192.168.0.10:1234on dispose de l'information complète pour communiquer avec un logiciel sur le réseau.



#102055 Accéder à distance à un Raspberry ou Caméra IP de manière sécurisée

Posté par Serveurperso sur 06 février 2019 - 04:16 dans Projets logiciels, web, ou simulations

gerardosamara parle d'une méthode "mnémotechnique" qui permet de retrouver le numéro de port, dans son cas par calcul, des additions.

 

Par exemple t'as plusieurs caméra dans plusieurs immeubles alors le numéro de port c'est le numéro de l'immeuble + le numéro de la pièces...

 

Dans une maison avec quelques caméra pas besoin de ça, n'importe quelle méthode est valable tant que tu retrouves tes numéros de ports en cas de besoin...

Aussi les routeurs permettent d'ajouter des petites notes associés à l'ouverture de port (forwarding)...




#101849 Flipper pilotable à distance

Posté par Serveurperso sur 23 janvier 2019 - 10:59 dans Autres projets inclassables

Bonjour:D Les estiens ? (ça se dit comme ça ?)

 

Hou la elle est nerveuse la vidéo, ça risque pas d'être trop speed pour être joué à distance ? Il va falloir le calmer avec une inclinaison réduite ? La latence du retour vidéo est d'environ 200ms si la connexion et les performances du client permettent de rester en flux tendu, la latence du contrôle est celle du ping + la celle de la mécanique.

 

ça me rappelle mon jeu avec une bille sensiblement de la même taille : j'ai voulu faire le labyrinthe en bois, j'ai pris le plus gros possible pour que ce soit plus lent, mais le problème est que transmission à ficelle ça se décale assez rapidement, sinon c'était jouable (pilotage X Y de servos 9g) mais il faudrait une prise direct ou courroie crantée genre qu'on utilise sur les moteurs pas à pas en impression 3D...

 

Sinon pour maximiser les performances un electro-aimant pourrait être mieux qu'un servomoteur mais ça risque de compliquer l'interfaçage sur une raspberry pi seule (sans arduino)... Quoi qu'il existe des cartes relais avec PWM en entrée, utilisés par les radiomodelistes...

 

Pour l'instant on dispose des moyens de commande suivants :

 

- De 8 boutons de type inverseurs, switchs ON/OFF -> un clic qui inverse l'état d'une GPIO sur la PI, pratique pour allumer et éteindre des sous systèmes sur un robot avec des relais ou des mosfets... Ils sont mappés sur les touches clavier PC de 1 à 8 (Shift + 1, 2, 3...).

 

- D'un positionnement de servomoteurs par drag'n'drop à la souris sur la vidéo (PWM servo), c'est utilisé pour les têtes et pince (outils) X-Y des robots

 

- De 3 modes de commandes en vélocité, utilisés pour déplacer un robot :

   1 - par joystick-souris ou écran tactile, drag'n'drop sur la croix centrale.

   2 - par impulsions au clavier (touches Z E R S D F) ou au clic "plus / moins" sur les flèches -> le robot à un pilotage de type jeu asteroid, déroutant mais très précis quand on est habitué.

   3 - Façon "tout ou rien" au clavier avec les touches fléchées classiques. -> pilotage au clavier de base qu'on rencontre dans tout les jeux.

 

C'est cette 3ème façon "tout ou rien" sur les flèche du clavier, qui combinée à de simples servomoteurs branchés (la ou habituellement on met les contrôleurs moteurs des roues des robots), peuvent faire un appuis + relâchement comme le souhaite l'utilisateur... de cette façon le servomoteur reproduit un appui tout ou rien identique au doigt de l'utilisateur sur le clavier PC.

 

Il est possible d'y brancher aussi les fameux cartes relais avec entrée PWM de modelisme.

 

Je sais pas si je suis assez claire au pire Mike m'aidera à ajouter de l'info... Par contre ça me donne l'idée de développer un mode "Bouton POUSSOIR" - > appuis clavier ON / relâchement clavier OFF, configurable pour les 8 fonctions qui sont actuellement uniquement des inverseurs type switchs ON/OFF hop liste "TODO"...

 

Avec les touches fléchées ça fait actuellement 4 télé-boutons poussoirs, utiliser tant que possible les switchs inverseurs pour le reste... Les icônes seront customisables par la suite.

 

Bouïnez bien !

 

Pascal




#101689 Accéder à distance à un Raspberry ou Caméra IP de manière sécurisée

Posté par Serveurperso sur 19 janvier 2019 - 03:59 dans Projets logiciels, web, ou simulations

Juste pour pinailler 

Citation

 

 

Sur cette box Orange à faire en sorte que le mot de passe par défaut ne soit pas identique pour tout le monde, c'est sécurisé par défaut.

Voila encore une affirmation à la hache qui peut être vrai comme très fausse. C'est comme dire ya HTTPS donc c'est secure...

 

Quand on pinaille, on explique, on cite des cas possible et on ne mystifie pas la chose :

 - Orange se fait pirater le générateur de mot de passe ou la liste des mots de passe par défaut pour un certain nombre de clients.

 - Un numéro de série dans le boitier permet avec un algo de retrouver ce mot de passe.

 - Le mot de passe par défaut est trop faible...

 

J'ai répondu précisément ça car j'ai testé cette livebox (d’ailleurs je la loue pour rien avec ma fibre pro) et effectivement elle est sécurisée par défaut -> C'est le travail obligatoire des ingés chez Orange et les autres opérateurs de sécuriser par défaut les abonnés afin de protéger leurs vue privée conformément aux condition du service




#101677 Accéder à distance à un Raspberry ou Caméra IP de manière sécurisée

Posté par Serveurperso sur 19 janvier 2019 - 12:39 dans Projets logiciels, web, ou simulations

Sur cette box Orange à faire en sorte que le mot de passe par défaut ne soit pas identique pour tout le monde, c'est sécurisé par défaut.

 

Mais tu peux t'habituer à avoir un mot de passe à toi différent pour chaque chose en utilisant un moyen qui te permet de tout mémoriser facilement + de noter ça en lieu sur ex: les papiers de l'abonnement ou un carnet à mot de passe qui se ne trouve pas a côté de l'ordi ou pire un post-it devant une caméra lol ça c'est déjà vu.




#101668 Accéder à distance à un Raspberry ou Caméra IP de manière sécurisée

Posté par Serveurperso sur 19 janvier 2019 - 09:38 dans Projets logiciels, web, ou simulations

Il n'y aucun débat, tu parles à un informaticien aussi, la première réponse donne assez d'info à celui qui veux faire un serveur PI pour qu'il continue à chercher de lui même, sauf question technique plus précise auquel cas on y répondra avec plaisir.

Si la personne est parano d'entrée sur les attaque de bots lui recommander le changement de ports et l'auth par clé semble la base logique.

 

Ne pas oublier qu'il arrive souvent que ses bidouilles que les passionnés font à la maison sont plus élégantes et performantes que celles des pros ou les équipes mal coordonnées qui ne font ça que pour gagner le salaire à la fin du mois. Genre la petite PI bien bichonée et apt updatée se retrouve plus sécurisée que le vieux serveur oublié dans une baie !




#101663 Accéder à distance à un Raspberry ou Caméra IP de manière sécurisée

Posté par Serveurperso sur 19 janvier 2019 - 12:47 dans Projets logiciels, web, ou simulations

Je ne recommande absolument pas de faire une paire de clé RSA si c'est pas pour automatiser... Pas besoin de plus qu'un bon mot de passe et un apt update/upgrade pour commencer à s'amuser à faire un serveur avec une PI partager des pages ou des fichiers via le répertoire web HTTP.

 

Et non ce n'est pas un sketch, pour la plupart des gens, scotcher la clé de sa maison sur sa porte d'entrée n'est pas pensable et pourtant c'est à peu pret ce qu'ils font avec tout ce qui concerne l'informatique.

Les clé d'une maison oui, mais la il s'agit d'une maisonnette de poupée voir une coquille d’escargot... Et faut pas pousser celui qui se paye une PI et qui à rien que l'idée d'en faire un serveur web à le minimum d'ouverture d'esprit et de capacité de recherche sur internet faut pas les prendre pour des cons... tu amalgames 2 populations sévèrement différentes la.

 

 

:) ça rappelle mon premier serveur perso. Quand je regardais les log apache passer en live, avec les tentatives permanentes pour exploiter les failles. Il y avait aussi toujours une ou deux session ssh (anonyme) qui n'étaient de moi. Sérieusement, je flippais complètement.

Idem sauf que j'ai tellement adoré les sniffer, faire des stats publiques sur le site, les enfermer dans des pots de miels, les faire tourner en bourrique avec des password bidons qui donnent sur rien...

 

Regarde moi ça encore maintenant juste les bots qui tentent des auth HTTP les 96 dernières heure :

graph_image.png

 

Aussi pour les paranos de la sécurité le logiciel de robot vigibot qu'on va diffuser avec Mike est un client -> aucun besoin d'ouverture de port ou de laisser se connecter des gens sur la PI, c'est elle qui se connecte à un serveur lui même sécurisé par des habitués :) ça fonctionne même en 4G sans IP publique... ça va sûrement évoluer en télécommande domotique pourquoi pas




#101659 Accéder à distance à un Raspberry ou Caméra IP de manière sécurisée

Posté par Serveurperso sur 18 janvier 2019 - 11:32 dans Projets logiciels, web, ou simulations

Et au pire, même si le hautement improbable arrive, se faire hacker sa pi et sa box ? la box l'opérateur se débrouille avec, échange gratos. la pi raz la micro SD et on recommence en mieux cette fois ! rien de tel qu'une bonne erreur pour apprendre. c'est meilleur pour le cerveau que le parano qui fait rien qui à peur de tout faire. il est absolument scandaleux de refroidir les débutants en PI pour rien.

 

Déjà le geek qui joue à faire son serveur web avec une PI est capable de lire sur le net et risque forcément moins que celui qui ne fait rien et se fait hameçonner son numéro de CB par email (et même ça osef ya l'assurance systématique&obligatoire) ! Relativise, halte au sketch, c'est que des bouts de fils et de la ferraille y'a strictement aucun risque pour la vie !!!




#101657 Accéder à distance à un Raspberry ou Caméra IP de manière sécurisée

Posté par Serveurperso sur 18 janvier 2019 - 10:41 dans Projets logiciels, web, ou simulations

1024 c'est obsolète le 4096 ne coute rien c'est mon par défaut en RSA partout, vu le nombre de machine sur le LAN j'utilise Ansible ou mussh...

 

Se faire voler une PI domotique ? Le principe d'une clé publique c'est que tu peux justement la diffuser sans aucun risque. Puis surtout c'est plus facile de refaire un ssh-keygen que d'inventer un autre password

 

Aussi les box d'opérateurs je n'utilise pas. Convertisseur ethernet fibre + machine routeur firewall + switch gigabit manageable c'est la base lol... Faire du spécifique à fond pour ne pas rentrer dans l’intéressant à pirater.

 

Toujours suivre le best pratice ça sert a rien d'en faire de trop et se polluer la vie, la parano c'est du 100% commercial, sauf si on est passionné ou pour s’amuser à apprendre.

 

En d'autres mots t'as toujours des gens qui font planer le petit doute sur la sécurité de l'auto hébergement c'est de la foutaise y'a aucun risque, un peu de bon sens comme aucune commande domotique dangereuse, surveillez que ça fonctionne de temps en temps faire les MAJ Debian et c'est tout.... Même si la Debian comporte pendant un moment the big faille de sécurité ce sera très très vite bouché,

 

Les hackers préfèrent toujours s'attaquer a un système de GRANDE série (comme la Livebox du post de cocothebo) qu'a la PI et au système spécifique de monsieur tartanpion. Un hacker chercheur ou propriétaire de 0day (= nouvelle faille de sécu) qui s'attaque à un truc spécifique -> un humain qui bosse à fond pour trouver une faille sans rien espérer de "gloire" en retour = on est dans du hautement improbable (le hacker zéro gloire ni retour) qui se trouve lui même déjà dans du hautement improbable (le mec avec la 0day debian qui arrive sur ta PI). J'ajoute encore une couche suplémentaire de hautement improbable, ce même hacker nogloire 0day veux et peux réussir à faire un truc mal chez toi avec ta PI et c'est pas déjà cassé en ayant vu l'uname -a....

 

Donc bidouillez et mettez des bidules en ligne sans aucune retenue !!!!




#101649 Accéder à distance à un Raspberry ou Caméra IP de manière sécurisée

Posté par Serveurperso sur 18 janvier 2019 - 07:37 dans Projets logiciels, web, ou simulations

Faire tourner un service sous un compte non root permet d'avoir la sécurité Linux en second rempart quand le service comporte une faille. C'est pour protéger le reste du système lui même. Et pour augmenter cette sécurité Linux on peux faire tourner le service en chroot (et pleins d'autres astuces).

 

Mais pour une PI domotique si le service est faillible à quoi bon protéger le reste du système linux d'une raspberry PI ? La réponse c'est de protéger le reste du réseau d'une étude et attaque depuis la raspberry PI et dirigée sur une autre machine. Mais pour ça ya beaucoup mieux.

 

Si ya rien à protéger sur le réseau -> genre une box dont le mot de passe n'est pas par défaut + une PI, faire tout tourner en le service en root n'augmente en rien le risque...

 

Le seul risque sur ce genre de réseau minimaliste box + PI c'est de servir d'hébergeur de proxy pour faire des conneries sur internet sous son identité (IP) et dans ce cas le fait de tourner en compte non-root n'apporte presque pas de sécurité. Pour l'augmenter c'est du côté du réseau que ça se passe : isolation de la pi des autres PCs par VLAN domotique, firewall et filtrage en amont (box), le suft (wget) peut être bloqué depuis la PI...

Avec une bonne conf du LAN même si le service tourne en root sans prise de tête cela ne diminue pas significativement le niveau de sécurité.

 

En gros la parade absolue étant de rendre le hack complètement obsolète "tiens t'es root sur cette raspberry PI amuse toi dessus" mais tu peux rien faire d'autre que tuer l'OS de cette même raspberry pi, tu peux jouer avec l'éclairage mais t'as pas accès a mon LAN ni au Web.




#101643 Accéder à distance à un Raspberry ou Caméra IP de manière sécurisée

Posté par Serveurperso sur 18 janvier 2019 - 06:15 dans Projets logiciels, web, ou simulations

Du coup, utiliser des ports moins connus permet aussi d'éviter les Scan bots les plus courant ?

 

Forcément c'est logique... pour retrouver le SSH le bot doit de scanner un certain nombre de ports TCP (il y en a 65535 car 16 bits sans compter le 0 non dispo pour applicatif) + tester le protocole derrière pour voir si il s'agit bien de SSH et pas autre chose...




#101621 Accéder à distance à un Raspberry ou Caméra IP de manière sécurisée

Posté par Serveurperso sur 17 janvier 2019 - 10:41 dans Projets logiciels, web, ou simulations

Les risques sont *quasi* inexistants... Grand adepte du serveur auto hébergé à la maison depuis les débuts d'internet et j'ai jamais eu le moindre problème.

 

Il suffit d'avoir une distrib Linux (préférablement strict minimale en mode console) tenue up to date (apt update / apt upgrade) et appliquer les bases de sécurité dont on trouve les tutos partout sur le net.

 

La base c'est d'avoir un password SSH correct ou mieux : n'accepter qu'une clé RSA privée

(/etc/ssh/sshd_config décommenter le PasswordAuthentication yes et le foutre à no après avoir mis ton id_rsa.pub dans ~/.ssh/authorized_keys et garder au chaud le id_rsa clé privée)

 

Le quasi c'est :

 

 - Se faire DDOS dans le cas d'une connexion ADSL + un gosse sur internet ne t'aime pas et obtient ton IP systématiquement. ça dure jamais bien longtemps et c'est possible dans le cas ou tu fait un site publique ayant un domaine et que le gosse en question ai une pseudo raison d'être innervé après toi.

 

Pour s'amuser (vécu) on peux faire rentrer les fameux vulnerability scan bots dans de fausses machines qui n'ont accès à rien (PI, VMs...) et étudier leurs actions en live.

C'est encore plus drôle quand le "hacker" crois tenir une trouvaille et se connecte manuellement dans le pot de miel monté comme un escape room prévu pour lui faire miroiter des choses tout en le faisant souffrir sur la durée.

 

"tuer une mouche avec un canon" :

- Qui va se faire chier à exploiter une vulnérabilité zero-day pour obtenir le root sur une PI et gagner l'accès a la lumière du salon de tonton jacky-les-lumières à trifouilly-les-oie ?

 

Il y a beaucoup de choses à dire sur la sécurité mais à partir d'un certain point sur une PI domotique perso ça devient de la parano pure et simple... Sauf si c'est pour s'amuser et c'est ce qui compte !




#100347 Minus V1.0 Un vigibot simplifié pour Noël en précommande ?

Posté par Serveurperso sur 25 novembre 2018 - 01:19 dans Archives vigibot

Tu pourras peut être monter à 3/4 de 1Mbps.

 

Si tu configures 1Mbps pile au niveau du codec vu que c'est un débit cible non garanti ça va forcément prendre du retard et il sera impossible à rattraper sauf si la vidéo devient d'un coup très compressible par exemple dans le sombre.

 

A tester en plein jours avec des mouvements de la tête du robot et voir si la latence n'augmente pas.




#100345 Minus V1.0 Un vigibot simplifié pour Noël en précommande ?

Posté par Serveurperso sur 25 novembre 2018 - 01:12 dans Archives vigibot

Le débit que j'utilise est 2Mbps sortant au niveau de l'encodage ce qui signifie qu'il faut 4Mbps d'upload (minimum par robots) pour ne pas subir de décrochages = augmentation intermittentes de la latence.

 

La qualité chez Snyp est du 250Kbps mais il a une très mauvaise ligne logiquement en ADSL 2+ (1Mbps montant théorique comme toi) on configure 512Kbps au niveau de l'encodage pour avoir une marge de rattrapage de la latence en cas de décrochage. Si c'est très stable tu pourras tester 3/4 du débit théorique mais au risque d'avoir de la latence par moment.

 

Le Wi-Fi à son importance aussi, la PI 3B+ a une superbe compatibilité au niveau des points d'accès j'ai rarement vu de problèmes sauf en 2.4GHz quand il y a des perturbations radio comme parfois chez Mike pour certains robots à certaines heures (micro ondes?) avec des PI 3B sans le 5.8GHz.




#100236 Minus V1.0 Un vigibot simplifié pour Noël en précommande ?

Posté par Serveurperso sur 17 novembre 2018 - 10:03 dans Archives vigibot

Pour la veille : la caméra et les flux data/vidéo/audio sont arrêtés, mais pas encore d'arrêt des signaux PWM, c'est à faire, ça pourrait gratter de l’énergie sur certains servos.

 

Les 2 prochaines tâches à faire les plus urgentes sont la disparition des robots de la liste publique

+ la trame data configurable et modulaire.




#100182 Minus V1.0 Un vigibot simplifié pour Noël en précommande ?

Posté par Serveurperso sur 16 novembre 2018 - 08:53 dans Archives vigibot

Encore énormément de boulot mais techniquement c'est opé.

 

Cette carte son est parfaitement reconnue et avec une entrée micro électret de bonne qualité, en plus elle est compacte, le châssis est prévu pour l'héberger + de l'espace pour le micro :

https://www.amazon.f...0?ie=UTF8&psc=1