Hamnet 70cm

Règles du forum
Cette section est dédié a vos projets, descriptions et demandes d'aide.
Merci de limiter le nombre de sujet par projets.
Lorsqu'un sujet deviens long vous pouvez éditer le premier message pour maintenir à jour le descriptif et garder en lisibilité
F4HDK
Messages : 79
Enregistré le : 10 juin 2017, 19:04

Re: Hamnet 70cm

Messagepar F4HDK » 25 juil. 2017, 19:31

f4grx a écrit :de mon coté après une pause je reprends le si4463 avec de nouvelles ouvertures, le reverse de WDS est possible, ce qui va me premettre de finir le driver
Ca veut dire que tu as l'accord de Silicon-Labs pour le reverse?

coté nuttx, celui ci contient maintenant un driver pour SPIRIT1 de ST ce qui permet d'envisager l'utilisation parallèle des SPSGRF a 12 euros
http://fr.farnell.com/stmicroelectronic ... dp/2729723
j'ai des PCB breakout que je tiens a la dispo des essayeurs.
Je ne connaissais pas ce chip. Mais il reste limité à 500kbps, et surtout il ne propose pas de 4FSK. Pour les liaisons radio avec un bon SNR mais des réflexions multiples, on a tout intérêt, pour atteindre un même débit, à réduire le SR et augmenter le nombre de bit par symbol, donc passer en 4FSK. Ca serait dommage de proposé une carte qui ne puisse pas faire du 4FSK.

d'après l'auteur le forwarding de paquets IP est maintenant possible entre une interface ethernet et une autre interface, genre radio.
Tu veux dire qu'il a déjà tout codé pour faire ça, et pas seulement le driver? Du coup, tu ferais la même chose avec ton driver SI4463 pour Nuttx?

Ceux qui utilisent WDS ... est ce que vous vous heurtez aux limitations de la version gratuite?
De mon côté, j'utilise WDS uniquement pour générer le fichier .h de configuration initiale, et absolument rien d'autre, vu que je n'ai jamais acheté leur kit de dev avec microcontrôleur 8bits asthmatique. J'avoue que je ne savais même pas qu'il existait une version payante.
Du coup, de quelles limitations est-ce que tu parles? Les seules limitations que j'ai vues sont sur des paramètres de config (longueur des champs) que l'on ne peut pas régler sur toute la plage, et sur de nombreuses options de l'API non présente dans le configurateur. Mais c'est très facilement contournable si on lit l'API-Documentation qui est quand même bien foutue.
Je ne suis pas certains que ce sont des limitations liée à l'aspect "non payant", vu les réponses que j'ai vues sur les forums Silicon Labs.

----------------------------

De mon côté, je n'ai pas trop avancé, mais j'ai pris quelques décisions :
* J'intègre un serveur DHCP dans le modem pour simplifier la vie aux utilisateurs.
* Je compte coder un proxy ARP, pour pouvoir transporter des paquets L3 IP (pas d'Ethernet), sans faire de routage L3.
* Les "clients/esclaves TDMA" d'une base envoient dans chaque trame l'état de leur buffer d'uplink, sur 8 bits seulement, un peu comme en GPRS, pour que le Master TDMA ajuste les temps de parole.
* La configuration du modem se ferait par Telnet

Il faudra aussi que je rédige une spécification du protocole que je suis en train de coder, et qui est pour l'instant dans ma tête et sur un cahier.

73,
Guillaume F4HDK
Avatar de l’utilisateur
f4grx
Messages : 881
Enregistré le : 26 sept. 2016, 13:58

Re: Hamnet 70cm

Messagepar f4grx » 26 juil. 2017, 09:12

F4HDK a écrit :
f4grx a écrit :de mon coté après une pause je reprends le si4463 avec de nouvelles ouvertures, le reverse de WDS est possible, ce qui va me premettre de finir le driver
Ca veut dire que tu as l'accord de Silicon-Labs pour le reverse?

Non, j'ai confirmation d'une absence de volonté de fournir les formules de calcul. du coup j'ai plus de raison pour éviter de reverser. Reverser, si ca arrive, c'est jamais avec l'accord du fournisseur, sinon le reverse est inutile :D

F4HDK a écrit :
coté nuttx, celui ci contient maintenant un driver pour SPIRIT1 de ST ce qui permet d'envisager l'utilisation parallèle des SPSGRF a 12 euros
http://fr.farnell.com/stmicroelectronic ... dp/2729723
j'ai des PCB breakout que je tiens a la dispo des essayeurs.
Je ne connaissais pas ce chip. Mais il reste limité à 500kbps, et surtout il ne propose pas de 4FSK. Pour les liaisons radio avec un bon SNR mais des réflexions multiples, on a tout intérêt, pour atteindre un même débit, à réduire le SR et augmenter le nombre de bit par symbol, donc passer en 4FSK. Ca serait dommage de proposé une carte qui ne puisse pas faire du 4FSK.
Il faut tenter le 4fsk en effet, mais comme pour le moment tous ces paramètres ne sont pas fixés, avoir un chip de plus dans les possibles reste intéressant.
le si4463 est également limité a 500 ksps, donc 500 kbps en 2FSK et 1Mbps en 4FSK mais avec sensibilité réduite. Je me demande si on peut pas agréger des liens.

F4HDK a écrit :
d'après l'auteur le forwarding de paquets IP est maintenant possible entre une interface ethernet et une autre interface, genre radio.
Tu veux dire qu'il a déjà tout codé pour faire ça, et pas seulement le driver? Du coup, tu ferais la même chose avec ton driver SI4463 pour Nuttx?
Oui tous les morceaux de code sont disponibles, faut les assembler dans un système qui fait le job. J'ai effectivement l'intention de produire un driver compatible pour le silabs. Tu devrais commencer a regarder nuttx pour t'y familiariser car ce sera l'OS de la carte que je développe. c'est tellement plus pratique que le bare metal, et tous les drivers sont déja la. et y'a une communauté active pour le support.

F4HDK a écrit :
Ceux qui utilisent WDS ... est ce que vous vous heurtez aux limitations de la version gratuite?
De mon côté, j'utilise WDS uniquement pour générer le fichier .h de configuration initiale, et absolument rien d'autre, vu que je n'ai jamais acheté leur kit de dev avec microcontrôleur 8bits asthmatique. J'avoue que je ne savais même pas qu'il existait une version payante.
Du coup, de quelles limitations est-ce que tu parles? Les seules limitations que j'ai vues sont sur des paramètres de config (longueur des champs) que l'on ne peut pas régler sur toute la plage, et sur de nombreuses options de l'API non présente dans le configurateur. Mais c'est très facilement contournable si on lit l'API-Documentation qui est quand même bien foutue.
Je ne suis pas certains que ce sont des limitations liée à l'aspect "non payant", vu les réponses que j'ai vues sur les forums Silicon Labs.

Idem, ici c'est uniquement pour observer les valeurs générées en fonction des paramètres entrés. Mais il y a des paramètres cachés (qui apparaissent brièvement quand l'UI est en cours de rafraichissement :D) que tu peux touiller, en particulier sur le paramètre BT en GFSK. pour de l'expérimentation c'est pratique de pouvoir les changer. Menfin si t'en as pas eu besoin, ca doit pas te manquer :)
F4HDK
Messages : 79
Enregistré le : 10 juin 2017, 19:04

Re: Hamnet 70cm

Messagepar F4HDK » 26 juil. 2017, 19:27

f4grx a écrit :Il faut tenter le 4fsk en effet, mais comme pour le moment tous ces paramètres ne sont pas fixés, avoir un chip de plus dans les possibles reste intéressant.
le si4463 est également limité a 500 ksps, donc 500 kbps en 2FSK et 1Mbps en 4FSK mais avec sensibilité réduite. Je me demande si on peut pas agréger des liens.
Quand tu dis "tous ces paramètres ne sont pas fixés", j'ai du mal à te suivre.
On est bien d'accord que l'utilisateur final devra impérativement pouvoir sélectionner différents Symbol Rate, et différentes modulations (notamment 2GFSK et 4GFSK).
Il faut que ça soit souple, réglable.
Les besoins/contraintes ne sont pas les mêmes en fonction de chaque situation : besoin en débit, qualité de la liaison en terme d'obstacles, de réflexion, de distance, de puissance d'émission.

Pour l'agrégation de liens radios, ca serait possible, surtout en "managed TDMA", mais ça n'est pas la priorité, loin de là.
En Managed-TDMA, tu maitrises, tu décides tous les instants d'émission / réception.
De même, pour un "relais radio" avec plusieurs clients, avec du managed TDMA, tu peux faire facilement du Multi-Frequency TDMA, même en TDD. Comme le GSM/GPRS. Ca augmente considérablement la capacité du "relais radio". Chaque client ne se connecte que sur une fréquence, mais le relais émet et reçoit sur plusieurs fréquences en même temps.
Avec le protocole que je conçois en ce moment, c'est clairement faisable.
Mais ça n'est pas la priorité, je ne sais même pas si ça aurait un intérêt pour nos petites utilisations amateur.

f4grx a écrit :Tu devrais commencer a regarder nuttx pour t'y familiariser car ce sera l'OS de la carte que je développe. c'est tellement plus pratique que le bare metal, et tous les drivers sont déja la. et y'a une communauté active pour le support.
Pour Nuttx, il y a un très gros problème pour que je puisse m'y mettre : je ne trouve aucune documentation accessible à quelqu'un de mon (faible) niveau en programmation. La doc semble lourde, et ça semble exclusivement dédié à des initiés. C'est tout le contraire de ce que l'on trouve pour Arduino, Mbed, etc...

Avec des tutoriels détaillés, dédiés débutant, des exemples simples, je m'en sortirais... mais là, ça me semble une marche infranchissable.
Est-ce que tu aurais de la doc accessible sur le sujet?

73,
Guillaume F4HDK
Avatar de l’utilisateur
f4grx
Messages : 881
Enregistré le : 26 sept. 2016, 13:58

Re: Hamnet 70cm

Messagepar f4grx » 27 juil. 2017, 10:25

F4HDK a écrit :
f4grx a écrit :Il faut tenter le 4fsk en effet, mais comme pour le moment tous ces paramètres ne sont pas fixés, avoir un chip de plus dans les possibles reste intéressant.
le si4463 est également limité a 500 ksps, donc 500 kbps en 2FSK et 1Mbps en 4FSK mais avec sensibilité réduite. Je me demande si on peut pas agréger des liens.
Quand tu dis "tous ces paramètres ne sont pas fixés", j'ai du mal à te suivre.
On est bien d'accord que l'utilisateur final devra impérativement pouvoir sélectionner différents Symbol Rate, et différentes modulations (notamment 2GFSK et 4GFSK).
Il faut que ça soit souple, réglable.

C'est exactement ce que je voulais dire par "pas fixé" :D
Et c'est aussi pour ca que je reverse le si4463 et que le SPIRIT1 est dans ma ligne de mire.

Les besoins/contraintes ne sont pas les mêmes en fonction de chaque situation : besoin en débit, qualité de la liaison en terme d'obstacles, de réflexion, de distance, de puissance d'émission.

Absolument

Pour l'agrégation de liens radios, ca serait possible, surtout en "managed TDMA", mais ça n'est pas la priorité, loin de là.
En Managed-TDMA, tu maitrises, tu décides tous les instants d'émission / réception.
De même, pour un "relais radio" avec plusieurs clients, avec du managed TDMA, tu peux faire facilement du Multi-Frequency TDMA, même en TDD. Comme le GSM/GPRS. Ca augmente considérablement la capacité du "relais radio". Chaque client ne se connecte que sur une fréquence, mais le relais émet et reçoit sur plusieurs fréquences en même temps.
Avec le protocole que je conçois en ce moment, c'est clairement faisable.

rôh sexy!
Mais ça n'est pas la priorité, je ne sais même pas si ça aurait un intérêt pour nos petites utilisations amateur.
certes.

f4grx a écrit :Tu devrais commencer a regarder nuttx pour t'y familiariser car ce sera l'OS de la carte que je développe. c'est tellement plus pratique que le bare metal, et tous les drivers sont déja la. et y'a une communauté active pour le support.
Pour Nuttx, il y a un très gros problème pour que je puisse m'y mettre : je ne trouve aucune documentation accessible à quelqu'un de mon (faible) niveau en programmation. La doc semble lourde, et ça semble exclusivement dédié à des initiés. C'est tout le contraire de ce que l'on trouve pour Arduino, Mbed, etc...

Oui. Alors on peut en discuter a coté, genre wiki. faut pas se palucher la doc, mais prendre le code existant, builder une carte existante, et modifier ce qui marche. genre ta carte nucleo-l432 est supportée (mais pas le wiznet)

Avec des tutoriels détaillés, dédiés débutant, des exemples simples, je m'en sortirais... mais là, ça me semble une marche infranchissable.
Est-ce que tu aurais de la doc accessible sur le sujet?

Oui, grace a Alan @acassis qui fait beaucoup d'efforts la dessus
https://www.youtube.com/nuttxchannel
Aussi sur son blog
https://acassis.wordpress.com/

Voir ici pour la conception de la carte
viewtopic.php?f=16&t=442
F4HDK
Messages : 79
Enregistré le : 10 juin 2017, 19:04

Re: Hamnet 70cm

Messagepar F4HDK » 28 juil. 2017, 14:33

Salut,
f4grx a écrit :Tu devrais commencer a regarder nuttx pour t'y familiariser car ce sera l'OS de la carte que je développe. c'est tellement plus pratique que le bare metal, et tous les drivers sont déja la. et y'a une communauté active pour le support.

Pour savoir si je franchis le pas pour Nuttx (c'est loin d'être gagné), peux-tu stp me décrire quels seraient les avantages par rapport à programmer mon microcontrôleur en "bare metal" comme tu le dis? Spécifiquement pour notre application de modem radio? J'avoue que j'ai du mal à voir pour l'instant.
Et puis est-ce qu'il n'y a pas un risque de perdre en perfo sur un petit microcontrôleur?

73,
Guillaume F4HDK
Avatar de l’utilisateur
f4grx
Messages : 881
Enregistré le : 26 sept. 2016, 13:58

Re: Hamnet 70cm

Messagepar f4grx » 30 juil. 2017, 22:18

-stack IP déja validée
-driver ethernet stm32
-environnement de programmation POSIX (UNIX) qui te permet de travailler avec des API linux standard
-multithread préemptif
-support de nombreux périphériques externes en plus des périphs internes de chaque SoC
-du coup, portable rapidement sur toute la gamme de CPU si nécessaire

perso, je veux plus perdre de temps a
-écrire des drivers moi même
-utiliser le code de stm32cube qui est souvent buggé ou peu flexible

même si l'appli est simple, avoir des bouts de softs déja fonctionnels peut faire gagner beaucoup de temps.

note que t'es jamais obligé d'utiliser ce truc si t'aimes tout faire en bare metal (ou tu pourras y passer plus tard si tu le souhaites) mais je trouve que ca garde l'avantage du bare metal (on controle ce qui se passe) tout en faisant gagner du temps

bref, d'abord fais toi plaisir et utilise des outils que tu maitrises.
si tu dois passer un temps incroyable a apprivoiser nuttx et que ca te fait perdre du temps et de l'envie, alors ne le fais pas, tout simplement.
F4HDK
Messages : 79
Enregistré le : 10 juin 2017, 19:04

Re: Hamnet 70cm

Messagepar F4HDK » 28 août 2017, 19:14

Salut à tous,

Comme promis, j'ai commencé à rédiger une spécification qui montre mes idées, ce que je suis en train de coder.
C'est encore incomplet, mais ça vous donne une bonne idée du truc, il y a déjà beaucoup de choses.
http://f4hdk.free.fr/NFPR/NFPR_specification.docx

N'hésitez pas à me faire un maximum de remarques, critiques questions; de préférence sur le forum, que tout le monde puisse suivre.
J'espère vous faire un point d'avancement technique prochainement.

J'ai 2 questions en retour par rapport à la spécification qu'a rédigée Sébastien-F4GRX:
* A quoi correspondent les 2 octets "client ID" qui sont en plus du callsign à l'intérieur de l'adresse MAC?
* Pourquoi définir une "server MAC address"? A quoi sert-elle?

73,
Guillaume F4HDK
F4HDK
Messages : 79
Enregistré le : 10 juin 2017, 19:04

Re: Hamnet 70cm

Messagepar F4HDK » 02 sept. 2017, 16:41

Comme promis, un "petit" point d’avancement.

J’ai fabriqué une 3ieme carte, plus simple que les 2 premières, avec un seul module 30dBm, toujours câblée en wrapping, mais par le dessous.
Ca me permet de tester sur un vrai réseau Point à Multi-Points avec 1 maitre et 2 clients (parce que du point à point, c’est trop facile).
Pour mes tests, j’utilise 2 machines virtuelles Linux sur mon PC, qui sont les 2 « clients », en plus de mon PC sous Windows sur lequel je développe. Chaque machine virtuelle a sa propre carte réseau physique dédiée.
J’ai donc 3 machines et 3 cartes réseau pour 3 réseaux vraiment indépendants sur mon PC, pour tester mes 3 modems radio.
IMG_0531_small.JPG
IMG_0531_small.JPG (974.62 Kio) Vu 5627 fois


Le soft :
C’est clairement la partie la plus grosse, et ça a bien avancé.
Je me rends compte que j’avais largement sous-estimé les besoins en RAM pour une telle application. Les 64ko de ma carte STM L432 sont très insuffisants, surtout pour le Master.
Mais ça n’est pas grave, je continue à coder, l’investissement en temps dans le codage n’est clairement pas perdu ! J’attends avec impatience la carte que développe Sébastien-F4GRX, et ses 512ko de RAM !
En espérant que je réussisse à porter le code déjà développé.

Ce que j’ai déjà codé et testé (en vrac) :
• Driver SI4463 (chip radio), et toute la gestion « temps réel » qui va avec.
• Driver W5500 (module Ethernet)
• Construction et décodage des trames radio dans mon format
• Segmenteur / reassembleur pour encapsuler de l’Ethernet ou de l’IPv4 jusqu'à 1500octets dans des trames de petites taille (~300 octets maxi).
• FEC (Forward Error Correction) à base de XOR
• Serveur DHCP pour les machines qui sont raccordées en ethernet aux modems « clients » : chaque modem client peut obtenir 1 ou plusieurs IP selon son besoin. Serveur DHCP désactivable si besoin (IP fixe).
• Proxy ARP : pour pouvoir transporter directement de l’IPv4 unicast sur l’air (sans l’Ethernet, sans l’ARP, et sans tout le broadcast), tout en restant dans le même sous-réseau IP (donc adressage IP très souple). C’est le même principe que de nombreux VPN L3.
• Routage IPv4, spécifique pour l’usage en proxy-ARP.
• Managed TDMA : une première version basique, qui prend en compte les besoins en uplink et downlink de chacun des clients
J’ai donc en théorie quelque chose d’utilisable. En théorie seulement, car ça plante aléatoirement! Donc il faut prévoir de grosses séances de débug… N'étant pas un pro, ça prend du temps.

Reste à coder (j’en oublie certainement beaucoup).
• Toute la « signalisation » : Connexion et déconnexion des nouveaux clients, gestion des indicatifs radio, allocation d’IP, etc…
• Managed TDMA : gestion des multi-frames. Basculement sur des « multi-frames » pour l'uplink des clients avec peu de besoin en uplink.
• Configuration : gestion de tous les paramètres configurables « en live », stockage des paramètres
• Proposer plusieurs config radio sélectionnables : Symbol Rate, modulation, fréquence. J’imagine 8 config pour SR+ modulation, à voir.
• IHM via telnet (et port série ?)
• Les « virtual channels » : pour transporter de la voix ou de la vidéo prioritaire, de manière optimisée (sans header TCP/UDP/IP), avec bande passante garantie. Un gros morceau!

Tout sera évidemment Open Source.

Pour finir la pavé, une petite démonstration du managed-TDMA à l’analyseur logique.
principe_m_TDMA.PNG
principe_m_TDMA.PNG (8.26 Kio) Vu 5627 fois

Les 3 courbes montrent les instants de transmission des 3 modems. En blanc le Master, et en orange et rouge les clients.
Le client orange télécharge un truc. Il envoie des TCP-Ack, et recoit beaucoup de données du Master. Le Master s’alloue donc beaucoup de temps de parole.
A l’instant marqué B, le client rouge veut transmettre un gros paquet IP de 1500octets, mais il n’a qu’une toute petite allocation, donc il n’en transmet qu’1/5ieme. Le Master est alors prévenu du nouveau besoin du client rouge (chaque trame d'uplink contient 4 bits représentatifs de l'état de remplissage du buffer d'uplink), et lui alloue, juste pendant la trame TDMA suivante, un slot suffisamment long.

Le brouillon de spécification est toujours au même endroit : http://f4hdk.free.fr/NFPR/NFPR_specification.docx

73,
Guillaume F4HDK
Avatar de l’utilisateur
f4grx
Messages : 881
Enregistré le : 26 sept. 2016, 13:58

Re: Hamnet 70cm

Messagepar f4grx » 05 sept. 2017, 09:26

Hello,
dsl de pas avoir pris le temps de répondre plus tot, mais ton bo travail n'est pas négligé.
Pour tout dire j'ai lu ta spec un peu en diagonale et je bute sur la forme, mais pour ca on verra plus tard (ex: french sur la première page qui nous exclut directement du reste du monde, coté communication ca le fait pas du tout, mais c'est pas important a ce moment de la discussion).

Ton mode est probablement mergeable avec mes propositions sans slots.
J'aime moyennement la FEC car pour moi ca veut dire code lourd, paquets non alignés sur des octets et perte de débit, mais c'est a voir. je n'ai pas de mesure des améliorations de bilan de liaison, donc je sais pas si le jeu en vaut la chandelle. je trouve aussi ton utilisation "manuelle" et sélective des bits de parité un peu complexe. J'aurais plutot compté sur le packet handler du si4463. Aussi les slots extensibles me semblent cacher une possibilité d'attaque par déni de service en déclarant une taille de queue tx énorme, ce qui allouerait tous les slots a un seul client (sauf limite prévue)

Mais globalement je vais plutot remettre ces détails a plus tard car 1 - la diversité d'opinions est une bonne chose et 2 - je veux d'abord avoir du hard qui marche :D

En tout cas chapeau pour ta réalisation triple qui effectivement te permet de tester du multiclient directement :)
F4HDK
Messages : 79
Enregistré le : 10 juin 2017, 19:04

Re: Hamnet 70cm

Messagepar F4HDK » 05 sept. 2017, 19:23

Merci Sébastien, Ca fait plaisir de voir au moins une personne qui s'intéresse à mon travail ;)
f4grx a écrit :Pour tout dire j'ai lu ta spec un peu en diagonale et je bute sur la forme, mais pour ca on verra plus tard (ex: french sur la première page qui nous exclut directement du reste du monde, coté communication ca le fait pas du tout, mais c'est pas important a ce moment de la discussion).
Pour le nom, New French Packet Radio c'était d'abord pour le fun. Il ne faut pas se formaliser pour ça. On peut effectivement changer.

J'aime moyennement la FEC car pour moi ca veut dire code lourd, paquets non alignés sur des octets et perte de débit, mais c'est a voir. je n'ai pas de mesure des améliorations de bilan de liaison, donc je sais pas si le jeu en vaut la chandelle.
Je n'ai pas compris ton "paquet non aligné sur des octets". Dans ma gestion basique, et dans d'autres algos FEC, on se retrouve avec des octets entiers.
De même, pourquoi parles-tu de "code lourd"? Je ne vois pas.
Faire un protocole radio qui se veut moderne, mais sans FEC, j’y crois moyen. C’était une des grosses critiques du packet radio : l’absence de FEC.
Rejeter tout un paquet juste à cause d’un seul bit…
En limite de réception, avec un SNR désavantageux, le FEC devient quasi indispensable!
Si on veut transporter (comme je l'imagine) de la vidéo, sans avoir besoin de répétition de paquets perdus, c'est juste indispensable.

Je trouve aussi ton utilisation "manuelle" et sélective des bits de parité un peu complexe. J'aurais plutot compté sur le packet handler du si4463.
En fait, je n’ai pas eu le temps de mettre des commentaires, et justification, mais c’est lié aux tâches temps réel et tâches « best effort ».
Tout ce qui est "gestion TDMA" est géré par des tâches « temps réel ».
En émission, chaque trame radio est traitée 2 fois par le logiciel :
* une partie best-effor/non temps réel : construction de la trame, algo FEC, puis stockage dans un buffer en attente d'émission
* une partie temps réel : ajout de l'octet TDMA qui ne peut être construit qu'au tout dernier moment, juste avant l'envoi.
Entre les 2, il peut se passer plusieurs centaines de millisecondes.
Donc j'ai préféré protéger par bit de parité séparé les octets utiles aux tâches de management TDMA (temps réel).

Une solution alternative, pour virer ces bits de parité, ça serait de coder / décoder le FEC dans la partie "temps réel". Je ne sais pas si ça passe, mais je peux tester ça, effectivement.

En soi, un bit de parité, ça prend très peu de ressource à calculer. Donc pour juste 2 octets parmi une centaine…
Mais dans tous les cas, le packet handler du SI4463 (et des autres chips radio) ne permet pas de faire du FEC, ou de protéger 1 seul octet, c'est pauvre.
Autre chose : je n'ai pas trouvé comment faire calculer le CRC par le SI4463 en cas de paquet de taille variable. Tu as une solution?

Aussi les slots extensibles me semblent cacher une possibilité d'attaque par déni de service en déclarant une taille de queue tx énorme, ce qui allouerait tous les slots a un seul client (sauf limite prévue)
Je n’ai pas compris. Qu’est-ce que tu appelles une attaque par déni de service ?

En fait, il manque un point d'explication vital dans ma spec :
le Master fait l'allocation des slots en temps réel, selon les besoins de chacun des membres du réseau (master et clients), en assurant une répartition EQUITABLE entre tous les membres du réseau.
Le mot EQUITABLE est super important.
Donc même si un client annonce une queue d'uplink énorme (sic!), le Master arbitre et il prendra en compte tous les besoins des autres clients.
Donc si d'autres clients veulent aussi causer en même temps, le Master leur allouera des temps de parole.
C'est exactement comme en GPRS (et certainement en 3G et 4G, mais je ne connais pas).
C'est la magie, la beauté de ce genre de protocoles : même en cas de saturation, le réseau reste utilisable!
Si un des clients sature la connexion (en uplink ou en downlink, peu importe), les autres clients continuent à pouvoir utiliser leur part du gâteau, sans aucune augmentation du ping pour eux, tant qu'ils ne saturent pas leur part du gateau!
Il faut bien voir que en 2017, la situation de saturation doit être considérée comme une utilisation nominale sur un réseau bas débit, ça arrive tout le temps si on essaye de faire une utilisation "web" sur un réseau à 500kbps.

Un autre truc que je n'ai pas dit : à terme, il y aura autant de buffer de downlink dans le Master que de clients, pour garantir la répartition équitable aussi en downlink.
Et il y aura aussi des buffers dédiés à chacun des "virtual channels" à débit garanti.
Bref, c'est la QOS nécessaire pour faire de la vidéo ou de la voix en plus des données.

73,
Guillaume F4HDK

Retourner vers « Les Projets »

Qui est en ligne

Utilisateurs parcourant ce forum : Aucun utilisateur enregistré et 1 invité