Le cimetière des idées

ci dessous la liste des toutes les bonnes et mauvaises idées que je n'ai pas retenu pour le projet, enfin surtout les mauvaises....

Contexte :

Chaque équipement des joueurs et du board est alimenté de manière autonome avec une batterie de type powerbank pour téléphone portable.

Si j’équipais en plus ceux-ci d'un écran OLED, est ce que je pourrais avoir un témoin de charge de la batterie.

Réponse : non

Pourquoi :

L'affichage de la charge sur une téléphone portable est une operation complexe qui dispose de sa propre puce.

En plus, une powerbank est composé de plusieurs cellules et delivrera toujours du 5v au bornes jusqu'a épuisement, on ne peut donc pas mesurer une perte du voltage via les ports analogiques d'un arduino par exemple.

07/11/2017 - Ca me coûte énormément, mais je dois me rendre à l’évidence. La trame de données telle que je l'ai construite est intellectuellement très satisfaisante mais elle entraîne des contraintes trop importantes en terme de codage et de coûts.

Tous les modules étant en HTTP, il doit être possible de les adresser et de transmettre des données via une requête Http simple.

Les contraintes de securité n’étant pas forte, ce format reste acceptable de mon point de vue.

De toute façon, le code n'est pas perdu et pourra revenir dans une version ultérieure.

L'idée était d'avoir un programme unique pour les 2 type des modules RFID, et de réserver les Pins sur les modules arduino ou esp8266.

Compte tenu des contingences de mémoire, ce n'est pas retenu.

Il y aura donc un programme par type de RFID, et ils utiliseront les mêmes Pins

Joli module mais le cablage des pinouts pour 2 modules ( un ecran Oled et RFID) a été impossible.

De plus j’étais limité sur les solutions RFID car le voltage en sortie des pins est de 3.3v

J'ai réinventé une trame courte et suffisante, avec 2 premiers champs de longueur fixe, et un dernier champs de longueur variable.

Par rapport à mon besoin, JSON n'est donc pas indispensable.