Autour de machines autonomes d’environnements sonores.

Je reprend une continuation des Espaces Enchevêtrés avec l'idée de poser de machines autonomes dans le paysage pouvant servir de guide poétique pour les balades.

Ajout d'un mode d'hibernation pour réduire les temps de re-mise en route et supprimer totalement la consommation en dehors de l'utilisation… Cet aspect hibernation est par ailleurs un truc original dans l'usage des SBC genre RaspberryPi ou H2…

Il y a 2 parties, une structure réseaux et des machines sonores

1. Réseaux de balises WiFi ESP32/ESP8266 comme autant de balises de suivies et/ou de déclenchement, fixes ou non, elles sont intermittentes.
2. machines ARM, RSP@/nanopi/orangepi/… sur les joueurs (j'ai longtemps hésité arm en fixe pour la gestion des scenes ou mobile avec le joueur …)
   1. soit allumées par les ESP soit toujours en fonction et gérées par les joueurs (pb de gestion des batteries)
   2. diffusant en fonction: des sons, audio/FM/boucle magnétique etc.
   • elle pourront lire du texte directement grâce a une synthèse vocale (picotts)

Les ESP vont servir soit

• à piloter les machines sonores qui elles consomment trop pour le petite batteries prévues.
• soit fonctionner en balises autonomes, objets WiFi visibles et communicantes

Une balise ESP8266/32 ne fait que émettre son identifiant sous la forme SSID_valeurs. Cela permet d'un simple scann de connaitre leur présence avec quelques informations (mode baecon). C'est un peu comme le baecon en Bluetooth , simplement ici je peux tout gérer en WiFi (je ne maitrise pas les balises BLE…)

On peut prévoir des objets qui seront vu par le réseau MycèliumLAN et toute une mécanique de jeu par la lecture des ID/valeurs … et suivre cela comme de simple SSID, les lire entre autre avec des smartphones …

Les participants se baladent avec les petite machines ARM / Casque ou HP ou celui d'un poste de radio 'augmentée'

Principe des balises après quelques modif…

1. sort du mode sommeil toutes les 2 min?
2. scan les reseaux WiFi
3. passe en mode AP avec une SSID qui la définie , peut y ajouter des valeurs propres (ex SSID=myclm_bois_D2_44_B3 pour: reseau myclm, balise du bois,hexa D2,hexa 44, B (objet b vu 3fois) ..
4. reste en mode AP 1 min sauf si il y a une connexion active(ci-dessous)
5. peut être connectée pendant ce laps de temps, timeout 5 min ?
   1. communique ses données (ID, batterie,autres SSID reconnu..)
   2. récupère des informations de jeux (SSID,valeurs,actions)
6. dodo

Principe machine joueur, ex de boucle

1. scanne le Wifi
2. si reconnait un SSID dans la précédente liste, présence, distance (relative) alors
   1. se connecte aux balises reconnues pour les mises à jours d'informations de jeux (SSID,valeurs,actions)
   2. en fonction de la non présence d'un drapeau pour cette balise (éviter double)
      1. allume éventuellement une partie des installations, relai/switch
      2. exécution prog jeux en fonction (historique des SSID,valeurs,drapeaux ..)
      3. re-communique les données évènement (ID_joueur,val,…)
3. se déconnecte
   1. exécution prog jeux en fonction
4. boucle

parce que j'en ai 7…et les Raspebrry pi sont difficile à avoir, mais il faudra faire des essais sur des RSP0 W 2…

• https://wiki.friendlyelec.com/wiki/index.php/File:Duo_pinout-02.jpg
• https://imola.armbian.com/archive/nanopiduo/archive/Armbian_21.08.1_Nanopiduo_focal_current_5.10.60.img.xz
• installation ecasound ecatools lame vorbis-tools swh-plugins alsa-base alsa-utils
  • echo “ladspa-register” | ecasound -c pour la liste des ladspa

les tests audio sont concluants, sortie audio directement sur un casque, pas fort mais correcte.

• installation picotts https://github.com/naggety/picotts fonctionne nickel
  • http://ecasound.sourceforge.net/ecasound/Documentation/users_guide/html_uguide/users_guide.html#sec45
  • cat le_petit_prince.txt | pico2wave -l fr-FR -w le_petit_prince.wav
  • ecasound -i le_petit_prince.wav -el:amPitchshift,0.8,3,20 -o alsa donne une voix acceptable avec une conso 3%CPU 15%MEM … merci amPitchshift
• alternative: le fameux MBROLA (libre depuis 2019!)
  • https://github.com/numediart/MBROLA
  • https://github.com/numediart/MBROLA-voices 7 voix différentes

Récup de 3 ESP, 32 ET 8266 pour test mode LR, le mode MESH me semble peut approprié car les balises sont intermittentes, il faudrait qu'elle soient synchronisées pour s'allumer en meme temps pour créer le réseau MESH…ce qui me parait trop complexe pour le moment.

On se contente de fonctionner en mode balise qui émet de temps en temps.