J'arrive maintenant à parser toute la table ap wifi à la recherche d'une mac adresse.
Me reste encore à faire le voting pour savoir dans quelle paterne elle se trouve
Et après de parser toute la table pet tracker
Je commence à charger le fichier pet tracker dans un tableau que je vais après parser
pour rechercher des corespondances dans les patternes ap wifi du quartier afin de pouvoir
trouver les coordonnées GPS de chaque lieu de passage
Et là où j'ai fait fort, c'est que j'ai pris à chaque fois où j'avais le
maximum de signal, et on peut bien voir la disposition de mes ap wifi perso
tout autour de la maison. Je suis vraiment très content que mon principe
fonctionne enfin
d'ap wifi *vu* par le NodeMCU
Maintenant il faut que j'extrais les coordonnées GPS de chaque
ap wifi les plus proches afin de pouvoir afficher dans un google
mymap tous les ap wifi du quartier
J'ai vu que j'avais beaucoup trop de doublons au niveau des noms
des ap wifi comme par exemple *upc free*, j'enregistre donc
maintenant l'adresse mac de l'ap wifi aussi, ainsi j'arrive à
les différentier
Je change de méthode pour trouver les positions GPS, plus avec
Wigle car il y avait trop de bruit, mais maintenant en
enregistrement // du NodeMCU et du OSMand+ pour avoir la
corrélation GPS avec les timestamps d'enregistrement.
Reste encore maintenant à faire le calcul post traitement
pour pouvoir *coller* le positions GPS aux ap wifi *vu* par
le NodeMCU
Les données de géolocalisation des ap wifi de Wigle sont pourries !
Je dois m'y prendre autrement pour pouvoir *étalonner* la
géolocalisation du trajet de mes ap wifi :-(
L'ancien cat.lua, faisait sauter le buffer RAM de socat.
Le nouveau attend entre chaque ligne 50mS afin que le socat ait le
temps de vider le buffer de la trame réseau
Ajouté aussi, pour des tests de post traitements, le tout premier
fichier de logs des ap wifi quand j'ai fait le tour du quartier à
pied avec mon NodeMCU dans une boîte
Mon socat ne fonctionne plus avec les nouvelles version du firmeware
et mon pet tracker utilisait le module rtc-mem qui ne se trouvait pas
dans la version de dec 19.
J'ai donc dû modifier la procédure de boot afin de ne plus devoir
utiliser le module rtc-mem et de pouvoir revenir au firmeware de
dec 19 et pouvoir utiliser à nouveau mon socat qui est indispensable
afin de pouvoir récupérer les logs des ap wifi scannés lors de la sortie du chat
J'utilisais la possibilité de sauvegarder le flag de dsleep dans la rtc-mem afin de pouvoir différencier lors du boot si c'est un reset ou une sortie de sommeil profond.
Maintenant je vais partir du principe que quand il y a un *hardware RESET* c'est forcément une sortie de dsleep.
Si on veut avoir la *seconde chance* lors de la procédure de boot, il faudra utiliser le *power on RESET*
J'ai fait un sacré moment car quand le NodeMCU se réveille d'un dsleep il est toujours vu comme venant d'un hard reset et pas moyen alors de détecter que l'on était en dsleep.
Maintenant je sauve un flag dans la rtc-mem et je peux tester ce flag au moment du reset et détecter si je sors du dsleep.
Reste encore à mieux faire la détection wifi pour savoir si on arrête le dsleep ou si on le relance
Je pensais que c'était un problème de firmware où il manquait la collection des modules rtc_x que
je n'avais pas de boot reason avec un retour de dsleep. Ce n'est pas le cas, je ne sais pas pourquoi
je réveille pas avec un bootreason=5. Je vais donc devoir traiter le réveil du dsleep à la mano avec
une mémoire sur le rtc_mem
