De l’exemple LoRa de 6 km à une FUOTA fiable : portée, airtime et Delta OTA dans un verger de mandariniers

Les valeurs de portée et les temps FUOTA de cet article ne remplacent pas des mesures en laboratoire ou sur le terrain. Chaque hypothèse doit être recalculée une fois le modèle réel de l’appareil, l’antenne, le plan de fréquences régional et les conditions du canal définis.

Résumé

À première vue, le problème paraît simple : un nœud capteur basé sur LoRa peut-il envoyer des données d’un verger de mandariniers vers une passerelle ? Lorsque le produit arrive sur le terrain, une question plus difficile apparaît : comment distribuer de manière fiable plusieurs centaines de kilo-octets de firmware sur cette même connexion ?

Cette étude part de l’exemple d’environ 6 km pour SF9/125 kHz présenté dans le résumé technique de Semtech. Elle explique pourquoi cette valeur ne peut pas être transposée directement dans un verger dense de mandariniers, puis examine le compromis portée–débit entre spreading factor (SF) et bandwidth (BW). Elle montre aussi qu’un link budget ne consiste pas à additionner les puissances de sortie de deux appareils : il faut évaluer ensemble l’émetteur actif, la sensibilité de l’autre récepteur, les gains d’antenne et les pertes environnementales. L’article choisit ensuite un verger de mandariniers parmi plusieurs environnements agricoles et étudie la hauteur des antennes. Enfin, il propose Delta OTA au lieu d’une image complète, des mises à jour en plusieurs étapes et une sélection des routes delta côté serveur.

La conclusion principale est simple : le succès de FUOTA ne consiste pas seulement à trouver la plus grande portée. La capacité downlink fiable, l’airtime total, le duty cycle, la perte de paquets, le placement de la passerelle, la vérification du bootloader et l’orchestration de la mise à jour doivent être conçus ensemble.

1. Pourquoi l’exemple d’environ 6 km de Semtech n’est pas une portée réelle dans le verger de mandariniers

Le résumé technique LoRa de Semtech donne un exemple d’environ 6 km pour SF9/125 kHz. Le même document précise que ces valeurs dépendent du terrain (Semtech, LoRa and LoRaWAN: A Technical Overview). Les 6 km sont une référence pour un réglage de modulation particulier et des conditions idéalisées en espace ouvert ; ce n’est pas une garantie de portée bidirectionnelle fiable dans un verger de mandariniers.

Les principales raisons sont les suivantes :

1. La propagation en ligne de vue sur terrain ouvert n’est pas la même que la propagation NLOS entre les rangées d’arbres.
2. Une antenne de capteur proche du sol est différente de l’antenne surélevée de la passerelle utilisée lors d’un test catalogue.
3. La portée annoncée par le fabricant dépend d’un SF/BW, d’une taille de paquet, d’une antenne et d’une puissance donnés.
4. La portée utilisable doit prendre en compte le sens le plus faible de la liaison bidirectionnelle et le taux de réussite de paquets visé.
5. L’humidité, la pluie, l’irrigation, la densité du feuillage et l’orientation des rangées évoluent pendant la saison.

Des études de terrain dans des vergers de mandariniers et d’autres vergers ont examiné l’effet des feuilles, des branches, des troncs, de la géométrie des rangées et de la hauteur des antennes sur l’affaiblissement de propagation (Vougioukas et al., Influence of foliage on radio path losses for WSN planning in orchards; citrus orchard RF deployment study). Le tableau de 6 km de Semtech peut donc être une hypothèse de départ pour les mesures de terrain, mais pas le résultat.

La question centrale devient donc :

Que deviennent la marge de liaison, le taux de réussite des paquets et l’airtime FUOTA de la référence de 6 km en espace ouvert de Semtech à l’intérieur d’un verger dense de mandariniers ?

2. Comment le SF et le BW modifient-ils la portée ?

Dans la couche physique LoRa, le spreading factor détermine la manière dont les données sont étalées sur les symboles chirp. Le résumé de Semtech explique que, de SF7 à SF12, un SF plus élevé améliore la sensibilité du récepteur mais réduit le bit rate et la vitesse de transfert (Semtech, LoRa and LoRaWAN: A Technical Overview).

La relation peut être résumée ainsi :

Tableau numérique SF/BW–portée pour un verger de mandariniers

Le tableau ci-dessous est une estimation d’ingénierie destinée à la planification pour un verger d’agrumes d’environ 2,5 à 4 m de hauteur, au feuillage dense, irrigué et présent toute l’année. Les cellules utilisent le format portée (m) / bit rate PHY brut (kbit/s) ; pour une conception fiable, il faut retenir la limite inférieure de l’intervalle. Le scénario de calcul suppose un E22-900M22S/SX1262, 868 MHz, CR 4/5, un gain d’antenne de 0 dBi, 2 dB de pertes de câble et de connecteurs, 10 dB de marge supplémentaire pour le fading et la sécurité, et une antenne qui n’est pas enterrée (informations du fabricant E22-900M22S).

Le bit rate PHY provient de la relation R_b = SF × (BW / 2^SF) × 4/5 et ne représente pas le débit réel de l’application. Les en-têtes LoRaWAN, le duty cycle, les temps d’attente, les retransmissions, les métadonnées de fragmentation et les pertes de paquets réduisent encore le débit utile. Les portées indiquées sont des estimations de planification fondées sur les hypothèses RF ci-dessus, et non des mesures de terrain ni des valeurs garanties pour un verger de mandariniers. Les colonnes SF5–SF6 et BW250/BW500 sont des comparaisons LoRa brutes ; les combinaisons hors des data rates LoRaWAN standard EU868 doivent être vérifiées par rapport aux paramètres régionaux.

Les paramètres régionaux LoRaWAN définissent les plans de canaux, les data rates autorisés, les limites de puissance et les restrictions régionales. Un tableau SF/BW doit donc être vérifié par rapport aux paramètres de la région et de la bande utilisées (LoRa Alliance RP002 Regional Parameters ; voir les publications du Technical Committee de LoRa Alliance pour la liste à jour).

Pourquoi l’ADR est-il important ?

LoRaWAN Adaptive Data Rate (ADR) permet au network server d’ajuster le data rate et la puissance d’émission d’un appareil selon la qualité de la liaison. Semtech décrit l’objectif ainsi : conserver la marge de liaison nécessaire tout en utilisant un data rate plus élevé afin de réduire l’airtime et la consommation de capacité réseau (Semtech, Understanding LoRa Adaptive Data Rate).

Pour FUOTA, l’implication est claire : un appareil ne devrait passer à SF12 que lorsqu’il en a réellement besoin. Si la liaison est fiable en SF9 ou SF8, le SF inférieur peut raccourcir la mise à jour.

3. Link budget : les puissances des deux appareils ne s’additionnent pas

Les puissances de sortie de Dragino et d’E22 ne peuvent pas être additionnées telles quelles dans un seul calcul. Chaque direction RF doit être calculée séparément :

puissance reçue =
puissance de sortie de l'émetteur actif
+ gain de l'antenne d'émission
+ gain de l'antenne de réception
− pertes des câbles et connecteurs
− perte de propagation
− pertes environnementales dues au feuillage, aux troncs, au sol et autres éléments

Pour E22 → Dragino, on utilise la puissance de sortie d’E22 et la sensibilité du récepteur Dragino. Pour Dragino → E22, on utilise la puissance de Dragino et la sensibilité d’E22. La portée bidirectionnelle utilisable est déterminée par la direction la plus faible. La sensibilité variant selon le SF, le BW, le coding rate et les conditions de mesure, une seule valeur de « portée de l’appareil » est techniquement incomplète. Le résumé technique LoRa de Semtech décrit le rapport entre paramètres de modulation, sensibilité et bit rate.

Pour les calculs de terrain de cet article, ne supposez pas de valeur nominale en dBm avant d’avoir fixé les modèles exacts de Dragino et d’E22, le type d’antenne, la puissance conduite et les autorisations régionales. Les fiches techniques ne remplacent pas les mesures de terrain.

4. Pourquoi traiter le type de culture comme un problème RF distinct ?

Le même réglage radio ne produit pas le même résultat dans tous les environnements agricoles. Les feuilles, branches, troncs, l’humidité du sol, la géométrie des rangées et la pluie peuvent modifier la diffusion, l’absorption et l’évanouissement par trajets multiples. Des études expliquent pourquoi la ligne de vue est souvent absente dans les vergers et pourquoi le feuillage modifie la perte de propagation (Vougioukas et al., Influence of foliage on radio path losses for WSN planning in orchards).

Nous avons donc d’abord considéré les cultures suivantes comme scénarios candidats :

• maïs,
• betterave sucrière,
• tomate,
• pomme de terre,
• pastèque,
• poivron,
• oignon sec,
• raisin,
• pomme,
• mandarine.

Il ne s’agit pas d’un classement de la production mondiale, mais d’un ensemble de scénarios d’ingénierie combinant besoins des capteurs, sensibilité à l’irrigation/EC, valeur économique et difficulté RF. Pour chaque culture, nous avons d’abord établi un tableau portée–bit rate pour les combinaisons SF/BW, puis un tableau d’airtime FUOTA pour les mêmes combinaisons. Ce sont des estimations initiales destinées à guider un plan de test, pas des garanties de terrain.

5. Pourquoi un verger de mandariniers ?

Un verger de mandariniers constitue un bon test de contrainte parmi ces candidats :

• les arbres sont pérennes et leur feuillage est dense,
• les feuilles et les branches peuvent occuper le trajet RF pendant une grande partie de l’année,
• les nœuds sont souvent installés près du sol ou du tronc,
• plusieurs rangées d’arbres peuvent se trouver entre la passerelle et le nœud,
• la propagation le long d’une rangée n’est pas la même qu’entre les rangées.

L’existence d’études RF dans les agrumeraies qui prennent en compte simultanément le placement du nœud, la hauteur de l’antenne, la profondeur de la végétation et la distance montre que le placement de l’antenne ne peut pas être expliqué par la seule distance en mètres (citrus orchard RF deployment study). Des expériences de placement de capteurs dans des vergers d’agrumes ont aussi rapporté des niveaux de signal reçu différents selon la hauteur des antennes et la couverture des arbres (Deployment Strategies of Soil Monitoring WSN for Precision Agriculture Irrigation Scheduling).

La question critique n’est donc plus « Quelle distance LoRa peut-il couvrir ? », mais :

Chaque capteur du verger de mandariniers peut-il se connecter avec une marge de liaison suffisante, et ce même downlink peut-il terminer un long transfert de firmware ?

6. Hauteur des antennes : 1 mètre, 5 mètres et 50 centimètres

Placer la passerelle à 1 mètre

Un mât d’environ 1 mètre peut laisser l’antenne dans la couche basse des troncs et du feuillage. Les rangées, branches et feuilles entrent alors directement dans le trajet de propagation. Voir l’autre antenne ne signifie pas que la zone de Fresnel est dégagée : les réflexions du sol et les rangées peuvent encore dominer.

Placer la passerelle à 5 mètres

Une hauteur d’environ 5 mètres peut rapprocher l’antenne de la passerelle de la cime de nombreux mandariniers, voire la placer au-dessus. Cela ne crée pas automatiquement une ligne de vue dans tout le verger de mandariniers, mais peut réduire les obstacles du côté de la passerelle, les pertes liées au sol et l’effet des houppiers sur le trajet horizontal. Les mesures en vergers montrent que l’effet du feuillage dépend de la proximité des antennes avec le sol ou la cime (orchard foliage path-loss study).

Un mât de 5 mètres n’est donc pas un « multiplicateur de portée ». Son bénéfice doit être mesuré avec :

• une passerelle placée en bordure, au centre ou en bout de rangée,
• une antenne orientée parallèlement ou perpendiculairement aux rangées,
• le gain d’antenne et le diagramme de rayonnement vertical,
• les pertes du câble coaxial et des connecteurs,
• la pente du terrain et les réflexions du sol.

Placer les deux antennes à 50 centimètres

L’intérêt d’une installation à 50 cm est de placer l’antenne sous la couverture végétale supérieure et d’utiliser le couloir entre les troncs. Mais « ne traverse pas les feuilles » ne signifie pas « il y a une ligne de vue ». À cette hauteur :

• les troncs et les branches basses peuvent être des obstacles directs,
• les réflexions du sol et les pertes sur sol humide peuvent augmenter,
• une liaison entre rangées peut être nettement moins bonne qu’une liaison le long d’une rangée.

Le scénario à 50 cm doit donc être mesuré sur le même parcours que les scénarios à 1 m et 5 m ; il ne faut pas le considérer comme une amélioration théorique de la portée. Dans de nombreux vergers, une hypothèse raisonnable consiste à orienter l’antenne du capteur vers le couloir de la rangée, à placer l’antenne de la passerelle au-dessus des cimes et à ajouter une seconde passerelle si nécessaire. Il s’agit d’une hypothèse de conception déduite de la dépendance à la hauteur et à l’orientation observée dans les études RF de vergers ; elle doit être validée sur le terrain.

7. Une liaison de télémétrie n’est pas une liaison FUOTA

Le fait qu’un capteur puisse envoyer régulièrement un petit paquet de mesure ne signifie pas qu’il puisse télécharger une image firmware de 1 MB sur le même réseau. La télémétrie est généralement un uplink peu fréquent ; FUOTA est une opération longue, principalement downlink, qui nécessite la retransmission des fragments perdus.

Les appareils LoRaWAN Class A ouvrent deux courtes fenêtres de réception après un uplink. Les appareils Class C gardent leur récepteur disponible plus longtemps lorsqu’ils ne transmettent pas, ce qui rend utile un fonctionnement temporaire en Class C pour un gros transfert downlink (LoRaWAN Specification).

FUOTA n’est pas une seule commande « envoyer le paquet firmware ». Les briques de la LoRa Alliance séparent les responsabilités :

• TS004 Fragmented Data Block Transport : fragmentation des données volumineuses et gestion de la session (TS004-2.0.0).
• TS005 Remote Multicast Setup : programmation du multicast temporaire et des fenêtres de distribution Class B/Class C (TS005-2.0.0).
• TS006 Firmware Management Protocol : gestion des versions firmware et hardware, du redémarrage et des images de mise à jour (TS006-1.0.0).
• TS007 Multi Package Access : annonce des paquets et des FPorts du dispositif afin de transporter plusieurs commandes avec moins de downlinks (TS007-1.0.0).

L’utilisation conjointe de ces standards demande un développement complémentaire et une validation HIL, indépendamment de la portée RF.

8. Le coût d’une image firmware complète de 1 MB

Un calcul approximatif de la limite basse pour un firmware complet de 1 MB est :

nombre de bits à transférer / bit rate théorique

Avec 1 MB et 5,47 kbit/s, le seul temps de transfert PHY est d’environ 25,5 minutes. En appliquant une utilisation du canal de 10 % comme hypothèse de scénario, la limite théorique basse passe à environ 4,25 heures. Cela exclut les en-têtes LoRaWAN, les métadonnées de fragments TS004, la parité/redondance, les pertes de paquets, les retransmissions et l’établissement de la session Class C. La réglementation régionale et les limites d’utilisation du canal doivent être vérifiées pour la bande et le pays (RP002 Regional Parameters).

C’est pourquoi choisir les réglages FUOTA uniquement pour « la plus grande portée » peut être un mauvais objectif. Le meilleur réglage minimise l’airtime total tout en conservant une marge de liaison fiable.

9. Delta OTA : transporter la différence, pas tout le firmware

Avec Delta OTA, le serveur envoie la différence entre l’image de base annoncée par l’appareil et l’image cible. L’appareil applique le patch pour reconstruire le firmware cible :

firmware de base sur l'appareil
        +
patch delta
        ↓
firmware cible
        ↓
vérification SHA-256 et signature
        ↓
MCUboot test boot et confirmation de santé

Le projet open source detools est un exemple d’approche delta pour les systèmes embarqués : il documente l’application en streaming de patches séquentiels et l’application incrémentale en C pour les appareils à mémoire limitée (detools README). Dans le projet Agronode, le flux de création et d’application delta est défini avec le SHA de base, le SHA cible, la taille de l’image et le layout MCUboot (documentation Agronode Delta OTA, code d’application delta).

Les mesures actuelles du projet indiquent des deltas entre releases successives d’environ 15–53 KB contre une image complète d’environ 944 KB (documentation Delta OTA du projet). Cette mesure est propre à ces releases ; le même ratio ne doit pas être attendu pour chaque paire de versions.

Avec la même valeur PHY approximative de 5,47 kbit/s :

Ce n’est pas une durée FUOTA réelle, mais une comparaison de tailles. Fragmentation, parité, retransmissions et gestion de session ajoutent du temps.

10. Peut-on mettre à jour de très vieux appareils avec de petites étapes Delta ?

Oui, s’il existe une chaîne delta adaptée :

1.0.0 → 1.1.0 → 1.2.0 → 1.3.0 → ... → 1.8.0

Chaque flèche correspond à une session FUOTA et à une barrière de sécurité distinctes. Le serveur ne devrait lancer le patch suivant qu’après que l’appareil a :

1. terminé la session de fragmentation,
2. vérifié le SHA de base,
3. construit l’image cible et vérifié le SHA cible,
4. réussi le test boot MCUboot,
5. confirmé le nouveau firmware avec un contrôle de santé,
6. signalé la nouvelle version et l’identité de l’image.

Le flux test–confirm–revert de MCUboot peut revenir à l’image fonctionnelle précédente au démarrage suivant lorsqu’une nouvelle image échoue ; c’est un modèle essentiel pour réduire le risque de brick lors des mises à jour à distance (documentation de conception MCUboot, signature d’images et outils MCUboot).

L’inconvénient d’une chaîne en plusieurs étapes est que la configuration de session, l’airtime, l’énergie, le redémarrage et le risque d’échec se répètent à chaque étape. Si chaque hop a une probabilité indépendante de succès de 98 %, la probabilité de terminer dix hops sans retransmission est d’environ 0,98^10 = 81,7 %. Ce n’est pas une prédiction de succès terrain ; c’est un modèle montrant comment le nombre de hops multiplie le risque.

11. Le bon modèle est un graphe delta, pas une liste de fichiers delta

Ne conserver que les releases adjacentes est un modèle simple :

1.0 → 1.1 → 1.2 → 1.3 → 1.4

En production, il est préférable de conserver ensemble les images complètes et plusieurs types de delta :

1.0 ──→ 1.1 ──→ 1.2 ──→ 1.3 ──→ 1.4
 │                  │                  ▲
 └──── checkpoint ──┴── direct patch ───┘

Politique d’artifacts recommandée :

• Conserver une image complète et signée pour chaque release.
• Conserver les deltas successifs N→N+1 comme artifacts immuables à long terme.
• Générer des deltas directs des versions de base réellement présentes sur le terrain vers la release la plus récente.
• Conserver des deltas bridge depuis certaines versions LTS/checkpoint vers la release la plus récente.
• Stocker avec chaque delta les métadonnées SHA de base, SHA cible, carte, révision hardware, variante et géométrie des partitions.
• Ne jamais supprimer les images complètes : elles restent la source canonique pour la génération des deltas, l’analyse forensique et la récupération.

Dans Agronode, le script d’artifacts existant montre la génération de deltas directs depuis les versions de base du terrain (ensure_field_deltas.py). La policy actuelle du backend recherche une correspondance directe base–cible ; un graph/path planner est également nécessaire pour planifier automatiquement A→B→C lorsque A→B et B→C existent (ota_policy.py).

Le serveur peut choisir une route avec cette fonction de coût :

coût de la route =
octets totaux des patches
+ airtime estimé
+ coût de session/reboot par hop
+ risque de perte de paquets et d'échec
+ énergie de l'appareil et coût de maintenance

Une première policy pratique consiste à utiliser un patch direct lorsqu’il existe et que sa taille est raisonnable. S’il est trop grand, essayer une route checkpoint de 2–3 hops contrôlés au maximum. L’image complète doit rester une voie de récupération, de bootstrap ou de transport alternatif, et non un « dernier recours » automatique sur LoRa.

12. Barrières de sécurité nécessaires pour Delta OTA

Delta OTA ne supprime pas les contrôles de sécurité ; il rend l’identité exacte de l’image de base encore plus importante.

Pour chaque patch, il faut vérifier au minimum :

• le SHA-256 du firmware de base communiqué par l’appareil,
• le SHA-256 de base attendu par le patch,
• la carte et la révision hardware,
• la géométrie des partitions/slots,
• le SHA-256 du firmware cible,
• la signature MCUboot et la clé de signature autorisée,
• la conformité de la version cible à la policy de downgrade.

MCUboot vérifie l’intégrité et la signature de l’image et peut fournir un rollback lorsqu’un test boot n’est pas confirmé définitivement (documentation officielle MCUboot). Le code d’application delta doit refuser les incompatibilités de base et de layout avant de créer l’image cible (application delta Agronode).

Pour les appareils très anciens, il faut aussi définir une version bootstrap FUOTA. Si le firmware antérieur ne possède pas de client de fragmentation, de code delta-apply ou du support bootloader nécessaire, l’appareil ne peut pas entrer directement dans la chaîne delta. Il faut d’abord le mettre à jour par BLE, Wi-Fi, réseau cellulaire ou image complète contrôlée.

13. Feuille de route praticable pour ce projet

Étape 1 — Fixer les hypothèses RF

• Confirmer les modèles exacts de Dragino et d’E22.
• Sélectionner la région et le plan de fréquences.
• Mesurer la puissance conduite ou la vérifier dans la fiche technique.
• Relever le gain d’antenne, la perte du câble et la polarisation.
• Mesurer sur le même parcours du verger de mandariniers les scénarios à 50 cm, 1 m et passerelle à 5 m.

Étape 2 — Construire une carte de connectivité terrain

• Relever RSSI et SNR à chaque point de mesure.
• Mesurer le taux de réussite des paquets et la dépendance à la direction.
• Comparer les conditions sèches, irriguées, pluvieuses et les densités de feuillage différentes.
• Mesurer un parcours le long des rangées et un autre en travers.
• Définir séparément la marge de liaison minimale requise pour FUOTA.

Étape 3 — Terminer le transport FUOTA LoRaWAN

• Implémenter la session de fragmentation TS004.
• Implémenter le cycle de vie temporaire Class C/multicast avec TS005.
• Relier la gestion de version firmware/reboot de TS006 et la découverte de paquets de TS007.
• Tester la perte de fragments, les retransmissions, les interruptions et le redémarrage de la passerelle.
• Ne pas promettre le succès Delta FUOTA de bout en bout sur LoRa avant cette étape.

Étape 4 — Ajouter les artifacts delta et la gestion des routes

• Stocker chaque release complète signée comme artifact canonique.
• Générer les deltas adjacents et les deltas directs des bases actives du terrain vers la dernière release.
• Rendre les métadonnées delta immuables avec le SHA base/cible et l’identité hardware.
• Implémenter côté serveur la sélection de patchs directs et de routes multi-hop limitées.
• Après chaque hop, attendre les signaux de version, de SHA, de santé du boot et de santé applicative.

Étape 5 — Définir la métrique de succès FUOTA

Le succès ne doit pas signifier uniquement « tous les paquets sont arrivés ». Il faut rapporter ensemble :

• les octets du patch et l’airtime total,
• le taux de perte des fragments et le nombre de retransmissions,
• le temps d’achèvement de la mise à jour,
• la consommation d’énergie,
• le taux de réussite du test boot,
• le taux de confirmation permanente,
• le taux de rollback,
• le succès par hop et le succès total lorsque plusieurs hops sont nécessaires.

Conclusion

Le problème LoRa dans un verger de mandariniers n’est pas seulement « Quelle distance pouvons-nous couvrir ? ». SF et BW créent un compromis portée–bit rate ; le feuillage modifie la liaison théorique sur le terrain ; la hauteur de l’antenne et l’orientation des rangées changent le résultat ; et FUOTA exige une capacité downlink très différente de celle de petits paquets de télémétrie.

C’est pourquoi la référence de 6 km de Semtech et la distance de mise à jour fiable dans un verger dense de mandariniers ne décrivent pas la même métrique. L’architecture correcte combine un link budget RF mesuré, une hauteur adaptée de la passerelle, un transport FUOTA standard TS004/TS005, des barrières de sécurité MCUboot et un graphe d’artifacts Delta OTA.

Lorsque Delta OTA réduit une image complète de 1 MB à des patches d’environ 15–53 KB, il peut diminuer fortement l’airtime FUOTA. Mais l’algorithme delta seul ne transforme pas cet avantage en produit fiable. Le serveur doit connaître le SHA de base exact de l’appareil, choisir une route directe ou multi-hop limitée, vérifier chaque hop et conserver l’image complète comme source de récupération.

En bref, l’objectif n’est pas la plus grande portée, mais un système LoRaWAN capable d’effectuer une mise à jour firmware mesurable, répétable et réversible dans un verger de mandariniers.

Sources

Normes et documents techniques des fabricants

1. Semtech — LoRa and LoRaWAN: A Technical Overview
2. Semtech — Understanding LoRa Adaptive Data Rate
3. LoRa Alliance — RP002 Regional Parameters
4. LoRa Alliance — TS004 Fragmented Data Block Transport
5. LoRa Alliance — TS005 Remote Multicast Setup
6. LoRa Alliance — TS006 Firmware Management Protocol
7. LoRa Alliance — TS007 Multi Package Access
8. LoRa Alliance — LoRaWAN Specification v1.0.3
9. MCUboot — official documentation
10. MCUboot — boot design and test/revert flow
11. detools — sequential and incremental delta patching

Études de propagation RF agricole

12. Influence of foliage on radio path losses for WSN planning in orchards
13. Test of WSN RF signal propagation based on different node deployments in citrus orchards
14. Deployment Strategies of Soil Monitoring WSN for Precision Agriculture Irrigation Scheduling