Electrolab::Forum

Je poste ici avec l'autorisation de Sébastien-GRX, même si je ne suis pas membre.
L'objectif de ce "fil de discussion" est de partager les idées de chacun sur le sujet, de suivre l'avancement des différentes personnes intéressées.

Principe général:
L'objectif du projet est de fournir des liaisons HamNet à moyen/bas débit (centaines de kbps sur support brut de 200kbps à 1Mbps), en utilisant les fréquences radioamateur plus basses que le 2.4GHz ou 5GHz (qui, elles, sont souvent trop contraignantes).
2 modes de fonctionnement prévus : point à point, et point à multipoint. Le mode "full mesh" est inenvisageable en conditions réelle à mon avis : SNR trop faible pour de tels débits, et gestion des collisions trop complexe.

L'apparition de nombreux chips modem radio low-cost (TI, Silicon Labs) va nous simplifier énormément la vie.

Nous sommes plusieurs à réfléchir à des choses similaires : F4GRX, F4HOF. J'espère qu'on pourra bosser ensemble.

Si possible, créer des modems prêts à l'emploi, avec branchement en Ethernet, et facilement configurables via telnet. Mais ça n'est pas pour tout de suite.

Détails techniques de ma solution en cours de développement.
C'est du TDMA. On sépare le temps en "macro slot" de l'ordre de 30 à 100ms. Ce seront les cycles de base à l'intérieur desquels les participants parleront tour à tour (s'ils ont quelque chose à dire).

Managed TDMA.
Le principe est que un seul "maitre" (chef d'orchestre) donne la cadence. A la fois dans un mode de fonctionnement point à point et aussi point à multipoint. Le modem maitre, c'est le "relais" que l'on va mettre sur un point haut bien dégagé.
Le maitre donne un "top chrono" à chaque macro slot, et les esclaves s'alignent dessus.
Le protocole doit être robuste à la perte d'un top sur 2 (ou 2 sur 3?).
C'est le maitre qui alloue les "temps de parole" à chacun, y compris à lui.
Le maitre est tenu au courant en temps réel de l'état de remplissage des buffers d'uplink (sens esclave vers maitre). Ca ne prend que très peu de place (1 octet par salve TX uplink).
Et le maitre alloue les temps de parole en fonction de ça.

Pourquoi faire du "managed TDMA" plutôt que du CSMA? Parce que même en cas de saturation, un tel réseau reste utilisable. Il peut être utilisé en théorie à quasi 100%. Un utilisateur n'est (en théorie) pas pollué par son voisin. Et sur un réseau "bas débit", la saturation est une situation très fréquente, il faut donc la gérer. C'est en gros comme ça que fonctionne la 2G et la 3G.

Je suis au tout début du codage de cette partie TDMA, je n'ai codé qu'une synchro basique, et fixe (temps de parole fixes).

Trames radio courtes.
Je vise des trames radio de longueur variable, de 50 à 300 octets (non encore décidé à 100%). Pas plus. Pourquoi?
Pour les débits faibles, des trames longues engendreraient un délai et/ou jitter trop important : il faut attendre l'émission totale d'une trame longue. 1500 octets c'est 60ms sur du 200kbps, c'est beaucoup.
En fait, je vise aussi de faire passer de la voix, et il faut donc pouvoir prioriser les paquets de manière efficace. Et pourquoi pas (soyons fous) de la vidéo basse qualité en full duplex. Cette partie serait peut-être transportée dans des "virtual channels", ça n'est pas encore décidé.
Côté "interface Ethernet" du modem, je garde un MTU de 1500, pour ne pas que les utilisateurs aient à s'embêter avec une config spécifique. Donc les paquets IP longs seront découpés/segmentés en plusieurs trames radio, et réassemblées à l'arrivée en une seule trame IP. C'est donc un mécanisme très différent de la "fragmentation IP".

L'état d'avancement des travaux :
Ce WE, pour la première fois, ça pingue chez moi. Mais attention, il reste encore énormément de choses à coder, ce n'est que le début du projet. Pour l'instant, c'est une config très basique et inutilisable en conditions réelles, et il y a des bugs.

Le matériel
* module radio Nice-RF à base de SI4463 : pour l'instant des RF4463PRO (20dBm); puis plus tard j'utiliserais des RF4463-F30 (30dBm) que j'ai déjà achetés.
(bien évidemment, il faudra rajouter un ampli radio et un switch T/R pour utiliser sur de grandes distances... pas simple)
* microcontrôleur ST NUCLEO-L432KC, programmé via "MBED".
* module ethernet W5500.

Le soft est clairement séparé en 2.
Partie "non temps réel" / "best effort":
* interface avec W5500
* un début de serveur DHCP
* Interprétation des trames radio reçues, et création des trames radio à émettre

Partie "temps réel":
* interface avec le module radio SI4463 : réaction aux IT du module, déclenchement très précis des instants d'émission et de réception.
Pour chaque paquet radio reçu, je le date, et je note le RSSI (puissance du signal radio)

Pour l'instant, je ne partage pas le code en public, mais tout sera open source bien évidemment.

73, Guillaume F4HDK

c'est super d'avoir avancé, bravo pour le ping!

la solution TDMA est intéressante mais attention aux effets 'temps de propagation' le GSM prévoit ca et recalcule les instants d'émission pour que ca arrive pile au bon moment sur le récepteur. je sais pas si ta précision de timing a besoin de ces corrections (timing advance)

ma solution CSMA a l'avantage d'être plus simple mais pourquoi ne pas intégrer ta fonction dans ma spec en cours, ca me dérange pas

ca ressemble du coup BEAUCOUP au zigbee notre affaire!

niveau fragmentation je ne suis pas contre non plus a la fragmentation 'low level' c'est a dire que le rx ne réassemble QUE la frame en cours avant de la passer a IP.

De mon coté je prévois des échanges directs de trames longues mais c'est surtout pour le mode "trunk", lien point a point et pas avec des clients.

Ici comme dit j'en suis au driver si4463, que je veux rendre indépendant de wireless developer studio.

c'est plus faisable qu'avec le cc1101 car on arrive a comprendre les paramètres générés, et il n'y a pas de valeurs magiques, le contenu des registres est plus logique.

Je travaille également sur une carte a base de si4463 (RFM26 probablement en option) avec stm32 et interface ethernet. vu que tu travailles aussi avec le 4463 ca pourrait t'intéresser. cette carte aura des signaux RF tx et rx indépendants, avec disponibilité du "ptt" pour pouvoir faire des essais avec PA/LNA/switch extérieurs.

Merci Sébastien, ça fait plaisir de dialoguer avec quelqu'un qui étudie le même sujet que moi, c'est tellement rare!
Quelques éléments de réponse:

f4grx a écrit :la solution TDMA est intéressante mais attention aux effets 'temps de propagation' le GSM prévoit ca et recalcule les instants d'émission pour que ca arrive pile au bon moment sur le récepteur. je sais pas si ta précision de timing a besoin de ces corrections (timing advance)

J'ai effectivement prévu de mesurer / intégrer les temps de propagation. Le Master enverrait une consigne d'offset temporel par rapport au top synchro, pour chaque esclave, et ajusterai cet offset en fonction de l'instant où il reçoit réellement les trame de l'esclave, donc en fonction de la distance. Avec un premier calcul de cet offset à l'initialisation de la communication et ajustement en temps réel.
Ca peut paraitre complexe au premier abord, mais en fait ça ne l'est pas tant que ça.
Le STM32 et le SI4463 permettent de mesurer/effectuer des actions à mieux que 10us de précision (je règle le SI4463 en mode SEQUENCER_MODE=GUARANTEED), c'est suffisant à priori, j'ai un peu réfléchi au sujet, mais il faudra bien évidemment confirmer tout ça par des tests.
Mais surtout: contrairement au GSM, les cycles complet TX/RX seront plus lents : 30 à 100ms (non encore décidé et peut-être variables) contre 4.6ms pour le GSM. Ces cycles plus long permettent aussi et surtout de se contenter d'un PA et switch radio TX/RX plus lent, donc plus faisable en amateur.

f4grx a écrit :niveau fragmentation je ne suis pas contre non plus a la fragmentation 'low level' c'est a dire que le rx ne réassemble QUE la frame en cours avant de la passer a IP.

On est d'accord! C'est exactement ce que je vise.

f4grx a écrit :Je travaille également sur une carte a base de si4463 (RFM26 probablement en option) avec stm32 et interface ethernet. vu que tu travailles aussi avec le 4463 ca pourrait t'intéresser. cette carte aura des signaux RF tx et rx indépendants, avec disponibilité du "ptt" pour pouvoir faire des essais avec PA/LNA/switch extérieurs.

Tu prévois d'intégrer un petit PA (30dBm) sur la carte? Ca semble nécessaire si on veut attaquer directement un module PA hybride puissant derrière (20W). Dans ce cas, pourquoi ne pas directement utiliser sur la carte un module tout fait type RF4463-F30 ou équivalent, beaucoup plus facilement soudable en amateur?

73, Guillaume F4HDK

je prévoyais surtout un MMIC, qui dans mon cas sera dans le PA lui même. les modules MX20 n'ont besoin que de 150 mW IN pour 20W OUT.

si tu as un modèle de module si4463 je peux mettre une empreinte. j'ai déja prévu une option rfm26w.

je vais ouvrir un thread pour parler de la carte.

bjr
mes deux centimes d'euros : un mitsubishi RA30H4047M1 sort 45 dBm/30W avec 27 dB de gain, et c'est l'un des modules les plus répandus en 70 cm. Donc 18 dBm/60mW d'excitation max. Moins on atténue, plus on économise d'énergie, moins on chauffe :-) (tant qu'il y a 3 dB de stabilisation d'impédance, entre 20 et 25 dBm devraient contenter tout le monde je pense)

Marc

tu as les bestioles en stock? moi non. mais j'ai 4 MX20-1. Donc MX20-1 ce sera sur mon proto

(toujours pas fait le topique, dsl)

marc a écrit :bjr
mes deux centimes d'euros : un mitsubishi RA30H4047M1 sort 45 dBm/30W avec 27 dB de gain, et c'est l'un des modules les plus répandus en 70 cm. Donc 18 dBm/60mW d'excitation max. Moins on atténue, plus on économise d'énergie, moins on chauffe :-) (tant qu'il y a 3 dB de stabilisation d'impédance, entre 20 et 25 dBm devraient contenter tout le monde je pense)

C'est ces modules là que je visais également, car ce sont les plus répandus. J'en avais acheté 2 à Papy F1CHF.

C'est bien pour ça aussi que j'envisageais d'utiliser un module modem qui intègre déjà un ampli 20dBm, pour attaquer directement l'hybride PA.
Y-a-plus-ka traiter la partie switch antenne TX/RX... Et le faire avec 20W et plus de 20 commutations par seconde, je ne sais pas si c'est facile, je n'ai jamais fait.

Il faudrait également prévoir une sortie variable 0-5V pour piloter le PA. Dans l'idéal, je voyais l'ajustement de la tension/puissance par le microcontrôleur, mais sans doute la commutation du PA via le chip-modem et non via le microcontrôleur.

Guillaume F4HDK

le si4463 a une sortie pour ramper le PA, mais la puissance se controle depuis le PA du chip. Il sort aussi le PTT pour PA et LNA.

le tx/rx c'est forcément de la diode PIN vu les délais de commut, et c'est pas facile mais ca se tente. a CJ 2017 j'ai récupéré un bô switch solid state mais... y'en a qu un

on trouve des diodes PIN chez farnell, la BAP64 semble convenir http://www.farnell.com/datasheets/1930051.pdf

mais faut faire un montage bande étroite pour avoir suffisamment d'isolation

Salut à tous,

J'avance tout doucement. J'ai fait 3 trucs en plus par rapport à mon premier message :
* j'utilise désormais des modules avec ampli 30dBm intégré
* j'ai codé un algo FEC très simple à base de XOR. Il faudra certainement changer pour un truc plus évolué.
* j'ai codé le segmenteur/réassembleur de paquets. Je peux donc transporter des trames de 1500 octets dans des paquets radio de ~60 à 300 octets.

Ca commence à être utilisable, même si j'ai des bugs à corriger et s'il manque des choses. Je peux désormais "surfer" sur un site http sans trop de problème à ~300kbps. Ca faisait longtemps que je n'avais pas utilisé du bas débit, ça fait bizarre!
J'ai beaucoup de pertes de paquets et répétitions, il faudra que j'investigue ce qui ne va pas (mise en place de statistiques).

La suite des travaux :
* le "routage" (actuellement, je fais bêtement passer de l'Ethernet de manière transparente en point à point)
* toute la gestion TDMA managé (allocation des temps de parole)

Il y a encore énormément de boulot, mais ça avance.

73,
Guillaume F4HDK

hello

j'adore ta carte wrappée.

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

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.

d'après l'auteur le forwarding de paquets IP est maintenant possible entre une interface ethernet et une autre interface, genre radio.

donc ma board est plus que pertinente, je vous en livre le schéma inachevé et une copie d'écran de l'état actuel du routage (TODO ce soir):

Je suis preneur de conseils.



Ceux qui utilisent WDS ... est ce que vous vous heurtez aux limitations de la version gratuite?