Lorawan-stack: Considérez Rx1 et Rx2 séparément pour la taille maximale de la charge utile

• Dans quel PHY êtes-vous?
• Quel débit de données utilisez-vous pour la liaison montante lorsque vous voyez cette erreur?

Node Telit Re866 + uC (EU863-870 - lorawan 1.0.2 Classe A)
pkt info de femtocell kerlink + spf (tx): pour les données limitées à 52B (binaire)
Réseau local (Kerlink Ethernet <=> PC Etnernet)
Modulation: LORA
codr: 4/5
imme: faux
rfch: 0
puissance: 14
ipol: vrai
ncrc: vrai
taille: 65
datr: sf7bw125

RSSI (rx): -80 dBm

Les mêmes paramètres pour la longueur de la charge utile: 62B (binaire)
Je scanne toutes les possibilités pour DataRate (tout échoue).
Datarates de liaison montante testés (données non reçues sur le nœud + WARN "payload too long" sur le serveur):
SF7bw125 ---
SF12bw125 ---
SF11bw125 -
SF10bw125 -
SF9bw125 -
SF8bw125 -
SF7bw250 --- jointure d'erreur
FSK - jointure d'erreur

Cela se produit car le débit de données Rx2 configuré est SF12BW125 (DR0). Dans la classe A, NS planifie actuellement la liaison descendante de telle sorte qu'elle soit conforme aux paramètres Rx1 et Rx2. Selon le tableau de la spécification des paramètres régionaux, la taille maximale de FRMPayload dans DR0 qui peut être utilisée pour Rx2 (en cas d'absence de FOpts) est de 51, ce qui est inférieur à ce que vous essayez de faire.

@johanstokking Je pense que nous devrions changer ce comportement et NS devrait en fait séparer les demandes d'ordonnancement Rx1 et Rx2 à GS si la charge utile ne rentre pas non plus.

@rvolosatovs oui, il devrait certainement le faire.

Pouvez-vous déposer un problème?

Existe-t-il une solution de contournement rapide? Pouvons-nous appliquer le débit de données dans la configuration json de liaison descendante?

Nous devons envoyer des centaines de paquets de liaison descendante pour la mise à niveau du micrologiciel:

• environ 200B chacun (meilleur des cas)
• environ 70B chacun (pire des cas)

Nous envisageons d'ajouter une passerelle LoRaWAN supplémentaire juste pour la mise à niveau du micrologiciel afin d'établir une «bonne portée» et différents serveurs de réseau / d'application (pour l'environnement de production).

Existe-t-il une solution de contournement rapide? Pouvons-nous appliquer le débit de données dans la configuration json de liaison descendante?

Vous pouvez modifier les paramètres Rx2 pour le périphérique final, voir ttn-lw-cli dev set --help , avec lequel vous pouvez régler le débit de données Rx2 sur une valeur élevée, c'est-à-dire 5 (SF7BW125 dans EU868).

Merci @johanstokking cette solution pour résoudre le problème.

Actuellement, je mets à niveau le micrologiciel du module LoRaWAN et je dispose de la classe C.

@ecities cela ajouter ce référentiel en étoile ou vous abonner aux notifications de publication.

salut
maintenant nous avons des problèmes à suivre:
"ERREUR La taille de la charge utile de liaison descendante générée ne convient ni à RX1, ni à RX2, ignorez l'emplacement de liaison descendante de classe A band_id = AS_923 dev_addr = FC005138 classe_périphérique = CLASS_A ..."
nous utilisons sf10 pour defaul, je ne comprends pas pourquoi

Salut @ viethoa14
Les informations que vous avez fournies ne sont pas suffisantes pour déboguer ce problème. Si vous êtes client TTI, veuillez contacter notre équipe d'assistance via le système de billetterie.
Si vous êtes un utilisateur open source, veuillez fournir les éléments suivants reproduisant clairement le problème:

• Journal de pile
• Journal des événements de l'appareil