docs(miotiq): plan to integrate lat/lon/misc into NebuleAir Pro 4G descriptor

Today these 3 fields appear in the JSON final but are absent from the 83B
descriptor. The 11-byte 'reserved' block has room for all three (4+4+1=9).

TODO section now proposes concrete encoding lines:
  8|latitude|hex2dec|degrees|x/1000000|
  8|longitude|hex2dec|degrees|x/1000000|
  2|misc|hex2dec|||
...with an open question on whether Miotiq hex2dec supports signed ints,
and a note to keep 2 bytes reserved for future growth.

parsers/udp-miotiq.md

@@ -164,7 +164,7 @@ Layout octet par octet :
 | 72     | 11     | `reserved`        |         |        | À ignorer (évolution future du descripteur) |
 | **83** | total  |                   |         |        |                                          |
 
-> Les champs `latitude`, `longitude`, `misc` présents dans le JSON final (voir [`json-payload.md`](../formats/json-payload.md#géolocalisation--contexte)) **ne sont pas** dans ce descripteur 83B — à documenter : ajoutés par Miotiq depuis les métadonnées device, ou transmis via un autre canal.
+> Les champs `latitude`, `longitude`, `misc` présents dans le JSON final (voir [`json-payload.md`](../formats/json-payload.md#géolocalisation--contexte)) **ne sont pas** dans ce descripteur 83B. **À intégrer** : voir la section [À faire](#à-faire) — l'emplacement naturel est le bloc `reserved` de 11 octets (4+4+1 = 9 octets suffisent).
 
 ### MobileAir (17 octets — legacy, pré-descripteur)
 
@@ -284,9 +284,25 @@ Côté PHP (cf. implémentations existantes `udp_miotiq_byte.php` / `udp_miotiq_
 
 ## À faire
 
+- [ ] **Intégrer `latitude` et `longitude` dans le descripteur NebuleAir Pro 4G** — aujourd'hui absents du descripteur 83B mais attendus dans le JSON final. Emplacement proposé : dans le bloc `reserved` de 11 octets. Encodage suggéré (à valider) — `hex2dec` signé sur 4 octets chacun, équation `x/1000000` pour obtenir des degrés WGS84 avec précision ~10 cm :
+
+  ```
+  8|latitude|hex2dec|degrees|x/1000000|
+  8|longitude|hex2dec|degrees|x/1000000|
+  ```
+
+  > À confirmer : Miotiq supporte-t-il les entiers **signés** sur `hex2dec` ? Si non, décaler les coordonnées (ex. `(x - 2^31) / 1000000`) via la colonne equation, ou passer en représentation non-signée avec un offset.
+
+- [ ] **Trouver un emplacement pour `misc`** (contexte de mesure 0–6) — 1 octet `hex2dec` sans unité ni équation. Placement proposé : à la suite de `longitude` dans l'ancien bloc `reserved`.
+
+  ```
+  2|misc|hex2dec|||
+  ```
+
+- [ ] Une fois les trois champs ajoutés : il reste **2 octets** sur les 11 du `reserved` initial (4+4+1 = 9). Garder une ligne `4|reserved|skip|||` (2 octets) pour évolutions futures, ou les réallouer.
+
 - [ ] Confirmer l'endianness des champs multi-octets (big-endian supposé).
 - [ ] Confirmer le caractère signé/non-signé de `battery_current` (décharge = négatif ?).
-- [ ] D'où viennent `latitude` / `longitude` / `misc` dans le JSON final ? (pas dans le descripteur 83B ; métadonnées Miotiq ? trame séparée ?)
 - [ ] Migrer MobileAir du format binaire 17B vers un descripteur Miotiq formel.
 - [ ] Ajouter un descripteur ModuleAir Pro 4G quand dispo.
 
@@ -298,3 +314,4 @@ Côté PHP (cf. implémentations existantes `udp_miotiq_byte.php` / `udp_miotiq_
 | 2026-04-23 | v2       | Refonte autour du format descripteur Miotiq, ajout NebuleAir Pro 4G (83B).  |
 | 2026-04-23 | v3       | Format descripteur aligné sur doc officielle Miotiq : 6e colonne = export JSON (W/Y/N), ajout base functions `hex2bin` et `userdef`, colonne `equation` (expression en x). |
 | 2026-04-23 | v4       | Correction : `string` produit du hex (pas ASCII). Correction ISO_39=PM2.5 et ISO_24=PM10 (inversion). Gaz confirmés (NO₂/CO/H₂S/NH₃/O₃). Lien vers JSON canonique AirCarto 2026. |
+| 2026-04-23 | v5       | Extension prévue du descripteur NebuleAir Pro 4G avec `latitude`, `longitude`, `misc` dans le bloc `reserved` — proposition d'encodage dans la section À faire. |