|
Ce week-end, j'ai cherché à exploiter l'étalement de spectre avec l'OFDM. Comme j'utilise un nombre fixe de porteuses RF, j'ai testé des solutions permettant de répartir les lignes vidéo sur 24 blocs de porteuses.
Afin de minimiser les effets des interférences sur une porteuse donnée, comme c'est le cas avec la TNT, j'ai effectué quelques tests de base, qui semblent présenter un avantage par rapport à l'approche actuelle. Je souhaitais exploiter certaines des idées que j'avais développées avec le CDMA, car l'étalement de spectre présente des avantages par rapport à l'OFDM, notamment en ce qui concerne la propagation des ondes ionosphériques HF.
L'autre problème sur lequel je travaille concerne l'alimentation des informations de synchronisation entre l'OFDM et le CDMA. Ma méthode est très différente de celle utilisée avec la vidéo analogique ou numérique. Elle s'apparente davantage à la DRM, où je multiplexe les informations de synchronisation dans des porteuses pilotes insérées entre des blocs de porteuses modulées, réparties sur les 192 porteuses.
Ainsi, la vidéo se verrouille automatiquement sans qu'il soit nécessaire de trouver le point de départ de l'information vidéo. Cela facilite également grandement les expérimentations avec le CDMA et la recherche du point de départ des codes PN pour reconstruire les formes d'onde QAM de départ. Par conséquent, pour encoder la synchronisation dans ces systèmes de modulation, je dois d'abord libérer de la bande passante, ce qui est actuellement un obstacle : trouver 12 kHz, voire 6 kHz supplémentaires pour intégrer les informations de synchronisation.
Les blocs constituent désormais l'encodeur vidéo/audio vers UDP. GNU Radio dispose d'un bloc de traitement pour l'étalement des lignes vidéo et l'encodage de la synchronisation, avant l'étage de modulation OFDM ou CDMA. Il est temps d'expérimenter ces idées et de les tester pour voir comment elles fonctionnent avec le bruit à différents niveaux.
Grant, VE3XTV
J'ai beaucoup travaillé avec GNU Radio pour construire le modulateur et le démodulateur de ce nouveau système de transmission hybride NBTV. L'OFDM fonctionne bien et permet à certaines parties du système CDMA de fonctionner avec l'étalement de spectre, deux avantages pour la HF.
L'inconvénient du CDMA est qu'il nécessite une référence GPS pour fonctionner, car il est étalé en fréquence et dans le temps. Pour ce faire, j'ai dû connecter deux unités HackRF avec une horloge commune pour effectuer les tests, chaque partie vidéo/audio disposant d'un code PN prédéfini pour récupérer les informations. L'OFDM est donc plus facile à utiliser, à envoyer et à recevoir avec une configuration TX/RX de base avec le HackRF.
En dehors de cela, peu d'autres travaux ont été réalisés avec l'interface graphique, comme vous pouvez le voir sur GitHub. Je suis donc en train d'intensifier les tests RF sur 29 MHz et de construire l'équipement pour cette bande.
73 de Grant Taylor, VE2XTV, North York, Ontario, Canada
Je n'ai pas fait grand chose avec le projet NBTV au cours du dernier mois, car j'ai atteint la limite de la puissance de traitement de mon PC avec GNU Radio.
Je pense ajouter un modulateur et un démodulateur d'accès multiple par répartition de code (CDMA) qui occuperont la même bande passante que l'OFDM en utilisant des codes PN. En faisant cela, j'utiliserai une approche à spectre étalé où les 192 porteuses seront multiplexées sur toute la bande passante. Comme j'utilise l'étalement de code, cela devrait me permettre de contourner les problèmes liés au domaine temporel que j'ai rencontrés lors des expériences TDM, car il y a tellement d'inconnues à tester et à résoudre à ce stade.
Les inconnues sont l'impact du QSB sélectif et des interférences et bruits, pour autant que je sache, le CDMA rejettera tout signal indésirable, s'il n'y a pas de corrélation avec les codes PN. D'après les recherches que j'ai effectuées sur ce sujet, le CDMA est très efficace pour lutter contre le multipathing, ce qui est très utile dans cette application.
Pour faire quoi que ce soit avec le CDMA, j'ai d'abord besoin d'un ordinateur plus rapide car il y a beaucoup plus d'étapes de traitement que ce qui était nécessaire avec l'OFDM. D'après les tests de base effectués sur GNU Radio, cela semble être une bonne façon de diffuser la télévision sur HF, c'est l'une des idées avec lesquelles je compte jouer au cours de la nouvelle année. De cette façon, vous aurez deux types de modulation à utiliser sur HF, l'une étant OFDM et l'autre CDMA.
Grant, VE3XTV
J'ai eu une bonne question sur le fonctionnement de l'audio numérique avec le système hybride NBTV, il était basé sur une technologie permettant d'envoyer l'audio sur des lignes téléphoniques vers des sites de transmission radio.
Lorsque chaque ligne téléphonique a une réponse en fréquence de 300 Hz à 3 kHz et que vous avez besoin de 15 kHz d'audio par exemple, dans ce cas, vous aurez 5 sous-bandes. Par conséquent, 5 circuits téléphoniques sont utilisés pour ces sous-bandes et le site de l'émetteur empile ces sous-bandes pour reconstruire 15 kHz, avec des circuits d'égalisation. Il s'agit d'un aperçu très simple de la manière dont j'encode l'audio sur OFDM, avec des sous-bandes de 500 Hz pour l'envoi des données. En procédant ainsi, la bande passante RF est la même que celle du SSB, ce qui permet à la radio 1:1 d'utiliser à nouveau le spectre de manière 100 % efficace.
En adoptant cette approche d'envoi de données sans correction d'erreur, vous obtiendrez du bruit, mais avec la réduction du bruit et l'utilisation de l'OFDM, les niveaux de bruit sont faibles. C'est pourquoi j'ai joué avec ce système pour les communications vocales, en utilisant 64 porteuses pour s'adapter à un canal SSB, car la réponse en fréquence audio est la même que celle de la SSB, mais avec un très bon rapport signal/bruit. Lorsqu'il y a du bruit, cela ressemble à un bruit de fond FM, vous obtenez donc une qualité sonore FM, avec un bon rapport porteuse/bruit entrant dans le récepteur.
Je ne suis pas très intéressé par la communication vocale à ce stade, car je dois consacrer mon temps aux développements de NBTV, en apportant toutes les améliorations possibles. Au cours des derniers jours, j'ai publié une autre mise à jour sur GitHub pour le logiciel d'encodeur/décodeur, la version 3.4 a quelques bugs corrigés et j'ai ajouté un affichage de réglage synchronisé. J'ai également essayé quelques nouvelles idées pour obtenir des niveaux de compression plus élevés, avec un pull down YC 1:8:8, mais cela n'a pas fonctionné, j'ai juste eu beaucoup de gros blocs de couleur dans toute l'image. Je testais une nouvelle façon de compresser la luminance et je n'ai pas réussi à la faire fonctionner aussi bien, nous sommes donc toujours à 96 kHz pour envoyer ce mode TV. A moins que je supprime les informations de couleur -12 kHz, ou que je supprime le son -24 kHz, cela donnera 60 kHz d'informations vidéo uniquement, comme la NBTV d'il y a 100 ans. Je pense qu'il est important de souligner mes échecs ainsi que mes succès, car parfois beaucoup de mes idées ne se déroulent pas comme prévu, jusqu'à présent il n'y a plus de grandes améliorations par rapport à ce qui a été fait.
Grant VE3XTV Au cours de la semaine dernière, j'ai travaillé sur les schémas de modulateur et de démodulateur de GNU Radio en utilisant le format hybride NBTV, car il a montré quelques avantages par rapport au système entièrement numérique. Mais je n'ai toujours pas la puissance de traitement requise avec mon PC i7, lors des tests de bouclage, j'ai résolu un problème avec les délais de filtrage et l'impact sur les multiplexeurs, avec l'obtention des données récupérées. Avec des tests de bruit entre le système numérique et hybride, le 1/2 FEC n'était bon que lorsque l'image était au-dessus du niveau P4, puis le numérique se coupait à ce stade. Ce qui n'est pas bon lorsque l'on travaille avec la propagation des ondes hertziennes, c'est pourquoi je suis revenu au traitement du signal analogique pour garder l'image TV verrouillée même pendant le QSB.
Le principal problème avec le système entièrement numérique est le 16PSK, car je dois passer au QPSK ou au BPSK pour descendre au niveau P2 du système hybride. Faire cela dans les 100 kHz est presque impossible à ce stade, car il faudrait augmenter la bande passante requise à environ 500 kHz pour répondre à ces améliorations du rapport signal/bruit. Pour l'instant, nous sommes enfermés dans le système hybride avec différents modes disponibles, descendant en dessous de 100 kHz de bande passante, à moins que quelqu'un ait de nouvelles idées sur la façon dont cela pourrait être fait ?
J'ai essayé quelques approches différentes et obtenir des niveaux de signal proches de ce que je considérerais comme utilisable est encore loin. Aujourd'hui, j'ai installé Zoom sur les deux ordinateurs de l'atelier, mon plan est maintenant de faire des démonstrations de cette technologie, en soulignant ce qui peut être fait avec NBTV et SDR, pour ceux qui sont intéressés à faire quelque chose de nouveau dans ATV.
Il semble qu'il y ait encore un grand nombre d'ATVers enfermés dans une forme ou une autre de système d'exploitation Windows et je devrai donc peut-être en dire plus sur la mise à niveau vers Linux, car le support de Windows 10 s'épuise. Comme je ne suis pas sûr de l'efficacité avec laquelle ce logiciel NBTV fonctionnerait avec une configuration de machine virtuelle Linux sous Windows 10 ou 11, cela signifierait qu'il y aurait encore moins de puissance de traitement disponible pour travailler.
Grant VE3XTV
La semaine dernière, j'ai été occupé à tester le
logiciel NBTV Digital Encoder/Decoder, qui propose
deux tailles d'image, 120 x 96 et
240 x 192 à 12,5 f/s.
L'encodeur prend l'image au format bmp non compressé
et envoie cette image à une gamme d'encodeurs jpg
fonctionnant tous en parallèle (X, Y), chacun à un
niveau de qualité différent entre 5 et 95 %.
Ce faisant, il est possible de regrouper ces images
en blocs de 3 ou 6 images, qui sont transmises par
l'encodeur de données de longueur d'exécution (Hoffman),
pour le composant Z. En utilisant ces types, zlib,
bzlib2 et zstd, voici les liens :
https://github.com/facebook/zstd
Je suis toujours en train de parcourir les informations sur l'encodeur vidéo x.264, en essayant de déterminer comment je peux au mieux ajouter ce type de compression. Comme le débit binaire de l'encodeur vidéo change avec le contenu vidéo, je me suis retrouvé avec des trous dans chaque trame de données, qui peuvent être utilisés pour envoyer un fichier jusqu'à 64 Ko, j'ai abandonné l'utilisation du système DominoEX Varicode et suis passé au HTML standard, pour les informations du programme. Ceci est encodé autour des données vidéo compressées, où la longueur du fichier et la trame de départ sont ajoutées à l'en-tête de chaque trame de données. Cela facilite grandement la synchronisation dans le décodeur, car les données du fichier sont supprimées avant que les données vidéo ne soient envoyées au décompresseur vidéo. Il y a également 6 octets réservés dans l'en-tête pour un indicatif d'appel, tout se met en place lentement, mais l'idée de base du travail est là.
Avec toutes ces améliorations apportées à l'encodeur vidéo, je suis une fois de plus à court de puissance de traitement du processeur, car une qualité de compression plus élevée s'accompagne de meilleures performances du processeur.
Du côté hybride NBTV, j'ai téléchargé la version 3.2
sur GitHub il y a quelques jours, il y a eu un
certain nombre de téléchargements, mais aucun retour
sur le déroulement du processus d'installation.
Avec tous les problèmes liés à la mise à niveau de
Windows 10 à 11, il semble que quelques personnes
migrent vers Linux, je peux proposer une gamme plus
large de packages d'installation, mais encore une
fois, j'ai besoin de savoir quels types de
distributions Linux sont utilisées. Voici une capture d'écran de l'encodeur et du décodeur Digital NBTV, montrant ce que j'expérimente. J'espère bientôt rendre ce logiciel public pour des tests sur la bande 10m, à côté du système hybride. Comme le format numérique aura besoin de son propre logiciel de modulateur et de démodulateur, GNU Radio fournira la correction d'erreur et l'étage de multiplexage audio et vidéo.
"Disons 200 kHz, sur une partie de 10 avec l'objectif de faire des expériences numériques de propagation d'ondes courtes à longue distance dans un spectre plutôt inutilisé ?"
La plupart du temps, il n'y a presque aucune activité à 10 m au-dessus de 28,5 MHz, donc je pense que 300 kHz pourrait être un bon point de départ, peut-être 29,1 à 29,4 MHz par exemple. Comme il y a des signaux vocaux AM dans 29 à 29,1 MHz et des signaux vocaux FM de 29,4 à 29,7 MHz. Il semble y avoir un écart entre ces deux emplacements avec une très faible activité, c'est pourquoi j'ai testé NBTV dans et autour de 29,2 MHz. Si quelque chose se produit, cela prendra des années, pour le moment il s'agit d'une transmission expérimentale et cela nous permettra de faire les tests nécessaires pour l'instant (pour les pays en dehors des États-Unis).
Ces derniers jours, j'ai fait des tests avec la compression numérique, pour la propagation des ondes radio, en recherchant d'autres moyens de le faire, grâce auxquels il sera possible d'afficher une image vidéo avec 10 % d'erreurs. J'ai donc décidé de ne pas faire grand-chose avec le h.264 et plus à ce stade, car ces encodages ont des taux de compression très élevés et ils seront beaucoup plus impactés par les erreurs.
J'ai mis en place une expérience pour tester mjpg avec l'encodage jpg (K) et Huffman (M), ils ont tous deux bien fonctionné. L'étape suivante consiste à opter pour l'approche jpg/Huffman, car elle offre plus de flexibilité pour ajouter un système de rétroaction afin de mieux contrôler le débit de données, dans le cadre de cela se trouvera la correction des erreurs. Comme avec le système hybride, une moyenne sera effectuée entre les trames vidéo, cela fonctionne bien si une carte de test est envoyée. Dans le cas d'une vidéo en mouvement, il y aura moins de correction d'erreur utilisée pour libérer plus de bande passante de données, cela fera apparaître des blocs car l'encodeur a moins de place pour travailler. Comme indiqué précédemment, je prévois de conserver la configuration actuelle du modulateur/démodulateur, car elle offre la possibilité d'intégrer la correction d'erreur nécessaire et me permettra également de tester des résolutions vidéo plus élevées jusqu'à 480x384 à 12,5 images/seconde. Ne vous attendez pas à ce logiciel d'encodage/décodage de sitôt, car il y a beaucoup de choses que je dois travailler, comme par exemple comment ajouter une correction d'erreur. Comme je n'ai jamais travaillé avec cela auparavant et que cela prendra du temps, je devrai également réécrire le logiciel actuel. Il y a encore beaucoup à venir avec ce nouveau système NBTV HF, car je vois plusieurs façons différentes de le faire.
Grant VE3XTV
"Le signal numérique à 100 kHz ne va pas passer", à ce stade, tout ce qui est inférieur à 96 kHz n'est tout simplement pas possible car il m'a fallu 2,5 ans pour faire fonctionner quelque chose qui ne soit pas une forme de SSTV. Cela se résume en grande partie aux lois de la physique, je prévois de continuer à travailler sur le projet NBTV avec le mode 96 kHz probablement pendant environ 5 ans, car cela donnera la possibilité d'essayer de nouvelles idées.
L'efficacité du spectre est déjà à 100 %, car il n'y a pas de correction d'erreur, pas de porteuses polyphoniques, il n'y a qu'une réduction du bruit utilisée pour récupérer les informations envoyées. Comme je l'ai déjà dit, nous avons déjà un très bon système de transmission pour DATV avec DVB-T qui fonctionne bien sur VHF et UHF, il ne reste donc que la HF pour trouver un bon moyen d'envoyer de la vidéo, car il s'agit d'une toute nouvelle expérimentation qui implique beaucoup de nouvelles technologies, pas seulement dans la radio amateur, mais dans la radio en général.
Vous soulevez un très bon point avec Over The Horizon Radar, car c'est l'un des domaines qui feraient bon usage de la technologie que je développe, il y a aussi la navigation radio qui est un autre domaine. Comme les technologies clés sont le détecteur avancé et le processeur de signal, qui n'ont pas encore été rendus publics, je suis encore en train de résoudre bon nombre de ces problèmes pour que cette technologie fonctionne à un niveau qui me convienne.
À ce jour, tous les tests que j'ai effectués se situent dans les 700 kHz supérieurs de la bande des 10 m, car je n'ai pas l'intention de faire de tests en dessous de ce point à ce stade. Je pourrais envisager de le faire avec une version plus récente à une date ultérieure, une fois que j'aurai surmonté les problèmes de compression des données et que cela fonctionnera suffisamment bien dans le spectre requis. Pour ce faire, il faudra beaucoup de tests aériens et de simulations pour trouver les meilleurs moyens d'avancer, car il s'agit d'un mode 100 % expérimental et ces tests ne peuvent être effectués qu'avec la propagation des ondes célestes, car c'est à cela que sert ce mode.
Au stade de développement, passer de 96 kHz à 24 kHz est un fantasme, car vous devrez supprimer des parties vidéo ou audio, et ce faisant, vous vous retrouverez à avoir un autre mode de transmission SSTV. D'après les commentaires que j'ai reçus jusqu'à présent de ceux que vous avez examinés sur mon travail, il a été indiqué que maintenir le spectre d'utilisation en dessous de 100 kHz est un très bon compromis. Alors, qu'est-ce que la NBTV ?
C'est un moyen d'envoyer des images animées avec du son dans des bandes passantes très faibles. Pour vous donner une idée, j'envoie des images télévisées avec une bande passante inférieure à celle utilisée pour les transmissions stéréo FM, qui utilisent 180 kHz, qui ne transportent que deux canaux audio. La bonne nouvelle est que la plupart des pays en dehors des États-Unis ont permis d'expérimenter de nouvelles formes de transmissions radio dans les bandes de radioamateurs et j'en ai pleinement profité au cours des 30 dernières années, en expérimentant de nouvelles idées, il reste quelques-uns d'entre nous dans la radio amateur qui aiment construire notre propre équipement radio, donc le passe-temps est-il en train de devenir verrouillé pour quelques opérateurs radio, ou accueillons-nous toujours les nouvelles idées et l'innovation ?
Voici une autre façon de voir les choses sur 70 cm en zone ZL, qui va de 430 à 440 MHz, le canal ATV de 70 cm est large de 7 MHz, ce qui signifie que 7/10 de cette bande se chevauchent avec d'autres modes, en zone VE, la bande de 430 à 450 kHz est de 6 MHz, 3/10 étant utilisée. Regardons maintenant 10 m de 28 à 29,7 MHz, où NBTV 100 kHz, cela correspond à 1/17 de la bande qui se chevauche avec nos modes, bien en deçà de la bande de 70 cm. Comme dans un rayon de 70 cm, la puissance de transmission de l'ATV est répartie sur 7 MHz et donc le signal ATV n'est rien de plus qu'un bruit de fond pour l'émetteur-récepteur SSB. Encore une fois, comme je l'ai déjà dit avec le NBTV, chaque porteuse représente environ 100 mW de puissance moyenne en utilisant un amplificateur HF de puissance de 1 kW, ce ne sera rien de plus qu'un faible niveau de bruit de fond sur le récepteur SSB.
Quand j'écoute sur 10 SSB et FM ces jours-ci, il n'y a plus autant d'activité que dans les années 1990, quand j'ai commencé, il semble que la bande soit pleine de pirates, j'ai des services mobiles terrestres asiatiques et CB et ils semblent être libres d'opérer, pourquoi ne pas nous concentrer sur ces opérations ? Je vais maintenant revenir pour envoyer des mises à jour sur les progrès et les développements logiciels, car c'est là que je dois consacrer mon temps, car il reste encore beaucoup de travail à faire sur ce projet.
Grant VE3XTV
Grant développe un système de transmission TV de type OFDM (à plusieurs porteuses) capable d'être utilisé sur ondes-courtes. Ses messages en anglais sur la liste Digital TV seront dorénavant traduits en français ici.
Il a fallu plus de deux ans pour arriver à ce point, avec la conception et le codage de l'encodeur/décodeur et maintenant le premier test HF sur la bande 10m.
J'ai toujours des problèmes avec la charge du CPU avec GNU Radio, où il tourne 10 secondes avant de s'arrêter et cela me donne juste le temps d'obtenir des images d'écran. Passer de 36 porteuses à 192 a été un avantage avec une meilleure performance du signal sur bruit et j'ai amélioré l'encodage Wavelet pour mieux rejeter le bruit. Il reste encore beaucoup à faire avec GNU Radio pour fournir un meilleur filtrage qui améliorera l'efficacité du spectre, mais je dois attendre de pouvoir obtenir un ordinateur plus rapide ou que des améliorations de vitesse soient apportées avec GNU Radio.
J'ai fait des tests de bruit avec ce nouveau mode et avec un meilleur filtrage logiciel dans le décodeur pour fournir une image avec du bruit. Je dois également ajouter une randomisation des porteuses pour décaler des parties de l'image vidéo afin d'aider à rejeter les interférences et le bruit. C'est là que le système TV de Con (ZL2AFP) a eu des problèmes car toutes les lignes vidéo étaient en ordre. L'autre chose qui a été faite a été d'ajouter des lignes alternatives de phase (comme le système PAL) pour aller entre chaque ligne adjacente, pour inverser tout décalage de phase, qui fonctionnera avec l'étage de traitement du signal comme un deuxième niveau de correction. Les photos montrent le spectre de sortie sortant sur 29,15 MHz. La section supérieure est plate car une modulation sonore a été envoyée. La majeure partie du spectre HF a été utilisée pour les informations vidéo comme vous pouvez le voir. Le moniteur montre chaque partie de la vidéo côte à côte, où les ondelettes et les trames de mouvement sont la partie qui est la plus impactée par le bruit car ce sont les parties les plus compressées. Le décodeur vidéo montre une image P3 revenant pour le test de boucle de retour de GNU Radio avec du bruit ajouté via UDP, ce qui me donne une idée de l'impact du bruit sur la vidéo.
La dernière image montre la disposition des blocs de construction de
GNU Radio, qui ont été utilisés pour créer le modulateur avec
l'utilisation de plusieurs couches en dessous de ce que vous voyez.
Comme pour toute nouvelle technologie, il y a toujours des bugs à
résoudre et je devrai passer le même temps à les corriger tous,
c'est pourquoi je rendrai le logiciel public une fois que ce sera
fait.
Je serais cependant heureux de transmettre les fichiers d'installation si
quelqu'un souhaite tester les parties encodeur/décodeur.
Grant, vous aurez besoin d'un filtre passe-bas, surtout si vous prévoyez d'utiliser un amplificateur. Nous sommes autorisés à émettre car nous sommes considérés comme responsables et savons comment ne pas provoquer d'interférences avec nos transmissions. Une antenne ne suffira pas comme filtre, surtout pas pour les harmoniques. Si vous utilisez un SDR comme un HackRF ou un Lime, il aura probablement besoin d'un filtre passe-bande à bas niveau en raison des sorties parasites et de l'aliasing, qui pourraient également perturber le PA ou au moins augmenter les intermodulations. À 200 mW, personne ne le remarquera peut-être, mais il est toujours préférable de s'efforcer d'obtenir une transmission aussi propre que possible.
Un filtre est facile à fabriquer, surtout à faible puissance. Vous ne devriez pas avoir besoin d’un circulateur, à moins que vous ne prévoyiez de travailler en duplex. Ici au Royaume-Uni, nous utilisons l’amplificateur 10 m du kit de démarrage MRF300 avec une puissance de sortie d’environ 100 W avec un bon résultat. Nous l’avons polarisé pour minimiser l’étalement spectral et avons obtenu un assez bon résultat, nous avons traversé l’Atlantique plusieurs fois mais seulement à 18 kb/s, le principal problème étant celui que vous abordez avec votre approche multi-porteuse. Le DVB-S n’est pas tolérant aux trajets multiples, donc malgré un très bon rapport signal/bruit, ce n’est qu’à de très rares occasions que les trajets multiples se sont alignés sur un signal suffisamment cohérent. Le multi-porteuse va nécessiter un PA beaucoup plus linéaire, donc moins de puissance en sortie, mais le défi de la réception n’était pas la puissance du signal, donc cela n’a peut-être pas autant d’importance. Le bidirectionnel semble impossible avec les amateurs américains car ils ne peuvent pas envoyer des signaux suffisamment larges, mais ce n’est pas un problème dans le reste du monde. J’ai hâte de voir quelques photos.
Mike Willis willis.mj@gmail.com
2024.08.26
Oui, je prévois de construire un filtre passe-bas, à l'entrée et à la sortie de l'amplificateur de puissance. Ce que j'ai fait auparavant était de placer un circulateur entre la sortie RF et le filtre de sortie. Je vais jeter un œil à l'amplificateur MRF300 Start kit 10m, car j'utilise 192 porteuses, la linéarité sera un facteur important. Oui, la tolérance aux trajets multiples est la partie la plus importante lorsqu'il s'agit d'utiliser la propagation des ondes hertziennes, avec la façon dont je transmets, l'OFDM est efficace à 100 % du spectre car je n'ai pas besoin de porteuses pilotes et d'encodage numérique. Cela est dû au fait que chacune des 192 porteuses est sa propre référence de phase, ce qui permet de séparer la porteuse de la modulation, avec une sortie démodulée et une sortie porteuse. En obtenant le bon croisement, tous les décalages de phase peuvent être compensés entre le signal entrant et la porteuse de référence de phase, une fois que vous avez un verrouillage de phase. Pour autant que je sache, je suis le seul à travailler sur cette technologie et ce système NBTV sera le premier à l'utiliser pour la correction de phase.
C'est là où j'en suis en ce moment car cela prendra un certain temps pour tout régler et je ne pense pas que mon PC ait suffisamment de puissance de traitement pour cette charge de travail. Le bidirectionnel semble impossible avec les amateurs américains car ils ne peuvent pas envoyer des signaux suffisamment larges, mais ce n'est pas un problème dans le reste du monde. J'ai été informé que les États-Unis ont des problèmes qui limitent ce qu'ils peuvent faire, mais ils devront résoudre ce problème.
En ce qui concerne le logiciel, je peux mettre l'encodeur et le décodeur à disposition pour les tests, veuillez noter qu'il y a encore des bugs dans ce logiciel, donc si vous souhaitez l'essayer, je peux vous envoyer les fichiers d'installation. Le modulateur OFDM fonctionne à ce stade, je prévois de l'envoyer bientôt pour des tests, mais je sais qu'il y a encore quelques problèmes sur lesquels je travaille également.
Grant VE3XTV
Ce week-end, j'ai commencé à faire des tests de simulation avec 192 porteuses avec différents niveaux de bruit et les performances porteuse/bruit ont beaucoup en commun avec AM-VSB. L'OFDM-QAM fonctionne, mais selon ces simulations, il n'est que de 10 dB meilleur que l'AM au niveau de l'image 5, où les ondelettes ne sont bonnes qu'entre les niveaux P4 et P5. En dessous, il ne s'agit que de bruit, où l'on passe de 240 x 192 x 12,5 à 120 x 96 x 12,5.
Je pense donc supprimer les ondelettes et les remplacer par de meilleures trames de mouvement. Si j'avais plus de puissance de traitement CPU, je passerais également à 480 porteuses pour l'OFDM et cela devrait apporter un autre gain de performances. Je voulais utiliser 256FSK car cela améliorerait le rejet du bruit sur les porteuses QAM, mais je reviendrais à 192 kHz de bande passante, ce qui me laisserait très peu d'options pour apporter d'autres améliorations.
L'image trace le rapport de la porteuse au bruit par rapport aux points d'image, c'est comme ça.
Il y a aussi les problèmes avec les retards de groupe de filtres qui impactent les différentes parties de la vidéo et du son, encore une fois, ce sont les parties du signal numérique qui sont les plus impactées. Les ondelettes et les canaux sonores numériques ont les plus gros problèmes, je peux les diminuer en passant à des espacements de porteuse de 1 kHz et en utilisant des atténuations de filtre plus douces. Mais cela fera passer la bande passante à 192 kHz, j'utilise donc beaucoup de pré-correction avant que les étapes de filtrage minimisent ces problèmes, pour rester à 96 kHz. Le processeur de signal fait tout pour fournir une meilleure correction de phase des effets des ondes hertziennes, c'est un autre domaine où il faut plus de puissance de traitement du processeur, des tests de base ont été effectués avec des stations de radio à ondes courtes. En surveillant la porteuse et en suivant les changements de phase et d'amplitude, le principal problème est d'obtenir un décalage de correction égal mais opposé à la porteuse TX et également de compenser les temps de retard. Je vais devoir continuer à travailler là-dessus, car cela ne fonctionne pas comme je l'espérais en SDR, j'ai eu de meilleures performances avec PWM dans un FPGA.
Grant, VE3XTV
Côté NBTV, la situation est donc bloquée, la
législation en vigueur ne nous autorise pas à tester sur
ondes-courtes ce que nous développons. Sauf en Suisse,
qui l'autorise pour autant que nous ne débordions pas des
limites de nos bandes et ne fassions pas de QRM aux autres
utilisateurs de la dite bande.
Réponse de M5AKA
Quelles restrictions les radioamateurs américains pensent-ils que la partie 97 impose aux transmissions DATV en 29 MHz ?
D'après ce que je lis dans la partie 97, il n'y a aucune restriction sur la bande passante d'une transmission d'image, c'est le cas depuis des décennies et il n'y a aucune restriction sur le nombre de porteuses qu'une transmission peut avoir. La décision de la FCC de l'année dernière d'accepter enfin la demande de longue date de l'ARRL d'imposer une limite de bande passante aux transmissions de données ne devrait pas avoir d'impact sur l'image. Les transmissions « données » et « image » ne sont pas la même chose dans les réglementations de la FCC, elles ont des définitions FCC différentes.
Je ne suis pas sûr de l'avantage qu'apporterait une demande générale envoyée à la FCC. En pratique, de telles demandes sont traitées par un employé de bureau qui n'a pas l'autorité pour interpréter la politique de la FCC. La réponse typique qu'ils donnent est d'indiquer au questionneur la partie concernée de la partie 97 et de lui dire de la lire, il est peu probable qu'il donne des réponses claires par oui ou par non.
73 Trevor M5AKA
De Ron W6RZ
97.307(f)(2) est l'article pertinent.
« Aucune émission non téléphonique ne doit dépasser la bande passante d'une émission téléphonique de qualité communicationnelle du même type de modulation ». Cette règle s'applique à toutes les bandes inférieures à 420 MHz. En conséquence, nous ne pouvons même pas transmettre de la télévision numérique sur 6 mètres, même si cette bande fait 4 MHz de large.
Ron W6RZ
De Justin G8YTZ
Des règles étranges de la FCC en effet !
Au Royaume-Uni, à l'exception de la bande de 5 MHz où la bande latérale double est limitée à 6 kHz, nous n'avons aucune limitation de ce type, à part la convention de plan de bande, qui n'est pas une condition de licence.
Y a-t-il quelque chose dans votre licence qui indique combien de porteuses modulées vous pouvez transmettre simultanément ? COFDM ? Chaque porteuse a une bande passante très faible et peut être bien dans la bande passante requise pour la voix. C'est juste que vous allez avoir plusieurs centaines de transmissions à la fois.
Justin g8ytz
De Trevor M5AKA
Les mots clés ici sont « émission téléphonique du même type de modulation ». Il ne s'agit pas d'une limite de bande passante fixe, la bande passante autorisée peut varier en fonction du schéma de modulation utilisé, il n'est pas interdit d'utiliser un schéma de modulation qui occupe une large bande passante. Il y a eu une discussion sur cette question au tournant du siècle, la conclusion était que des transmissions téléphoniques et d'images plus larges étaient autorisées sur HF pour les transmissions de type ODFM. Vous pourriez avoir une transmission large de 250 kHz centrée sur 29,150 MHz comprenant 192 porteuses fonctionnant chacune à 600 ou même 1200 bauds et l'utiliser pour transmettre la voix. Il ne s'agit pas d'une « émission à bande latérale indépendante » et elle n'est donc pas affectée par la restriction de la deuxième partie de 97.301(f)(2). Étant donné que rien n'interdit les émissions vocales à large bande, vous pouvez faire de même pour l'image.
Trevor M5AKA
Au cours des deux dernières semaines, j'ai apporté des améliorations à l'application Encodeur/Décodeur, en ajoutant 3 nouveaux modes NBTV:
Le mode 4 a une bonne réjection du bruit avec le niveau de compression le plus bas utilisé, alors que le mode 1 a une mauvaise réjection du bruit. Le mode 4 est plutôt un mode de télévision à balayage lent, avec seulement 8,1/3 images par seconde, ce qui est correct pour les mouvements lents, les vidéos de cabane à partir d'une caméra fixe ou des cartes de test. Tout se résume donc à la différence entre SSTV et ATV, c'est pourquoi j'ai choisi 120x96x12,5 comme base de référence pour ce projet.
L'image montre l'une de ces nouvelles mises à jour où il est désormais possible de capturer des vidéos YouTube en utilisant l'option de découpe vidéo sur le site YouTube et en la redimensionnant pour l'adapter, dans ce cas avec un format d'image 16:9 et en bouclant le périphérique audio. En plus de la capture vidéo, il existe également le streaming IP et la lecture de fichiers, du côté du décodeur, il y a l'enregistrement en Mpeg2 et la sortie vidéo via la carte vidéo analogique PVR-350.
Pour ce qui est de la diffusion, je recherche un amplificateur de puissance de 1 kW, car le rapport crête/moyenne est de l'ordre de 50 à 1, donc la puissance moyenne est de 20 W, c'est ce que vous obtenez avec OFDM, où DVB-T est à peu près le même, il n'y a pas de réelle différence ici.
Avec le modulateur/démodulateur, je progresse toujours très lentement en utilisant GNU Radio, car je n'ai pas assez de puissance de traitement requise, je dois donc économiser sur un ordinateur plus récent, quelque chose avec 16 cœurs devrait faire l'affaire. Grant VE3XTV 2024.09.17_de KD6W... 100 kHz
Les règles de la FCC sont en général prescriptives (ne faites pas de bêtises), mais dans certains cas restrictives (ne franchissez pas cette ligne). Je suis retourné au texte de la partie 97.307 du 47 CFR américain (normes d'émission) et je pense que la sous-section sur laquelle les gens sont bloqués concerne les émissions de « type téléphone » où de nombreux types d'émissions sont possibles en vertu de la 97.307.
Le principe principal de la sous-section 307 est de prescrire ou d'ordonner aux opérateurs amateurs américains de ne pas faire de bêtises et c'est pourquoi au paragraphe (a) il est indiqué... (a) Aucune transmission de station amateur ne doit occuper plus de bande passante que nécessaire pour le débit d'information et le type d'émission transmis, conformément aux bonnes pratiques amateurs. {...ce qui signifie, soyez gentil et ne vous éclaboussez pas partout.} Et à ce sujet, les paragraphes b, c, d et e concernent tous la classification et les restrictions des émissions parasites. Ensuite, au paragraphe f, la réglementation aborde les différentes normes et limitations d'émission. (f)
Les normes et limitations suivantes s'appliquent aux transmissions sur les fréquences spécifiées dans § 97.305(c). (passez maintenant au paragraphe 2)
(2) Aucune émission non téléphonique ne doit dépasser la bande passante d'une émission téléphonique de qualité communication du même type de modulation. La bande passante totale d'une émission à bande latérale indépendante (ayant B comme premier symbole), ou d'une émission multiplexée d'images et de téléphones, ne doit pas dépasser celle d'une émission A3E de qualité communication. J'interprète ce paragraphe comme ayant une seule fonction : contraindre les « émissions non téléphoniques » (c'est-à-dire non A3E), c'est-à-dire une porteuse modulée, « du même type de modulation » (c'est-à-dire téléphonique) utilisée pour transporter des données d'image multiplexées (pensez à SSTV) et téléphoniques (voix) dans une forme d'onde qui ne dépasse pas la même taille qu'une porteuse A3E. Lorsque l'image multiplexée (pas au pluriel) et l'émission téléphonique citent clairement le cas de SSTV et de téléphone envoyés sur la même fréquence, mais multiplexés par répartition dans le temps, d'abord le téléphone, puis SSTV, puis le téléphone, etc.
Allons de l'avant... Alors que le paragraphe 2 limite les porteuses vocales modulées numériquement en HF, le paragraphe 13 définit les données à haut débit en HF. Veuillez prendre note de la dernière phrase. (13) Une émission de données utilisant un code numérique non spécifié dans le cadre des limitations énumérées dans le § 97.309(b) { RTTY et codes d'émission de données } peut également être transmise. La bande passante autorisée est de 100 kHz. J'interprète le paragraphe 13 comme signifiant que si nous construisons une méthode de modulation des symboles pour transmettre de la vidéo codée (images animées) et de l'audio (téléphone), multiplexés ensemble dans le même canal d'information, et que nous convenons d'un ensemble de symboles qui ne doivent pas être considérés ou interprétés à tort comme du contenu crypté (aucun brouillage autorisé), alors nous pouvons utiliser cette technique en toute sécurité tant que nous ne dépassons pas un total de 100 kHz pour transporter ces symboles, ou dans ce cas autant de sous-porteuses dans un OFDM que cela peut contenir dans les 100 kHz.
Ce qui est bien avec « non spécifié », c'est la définition littérale d'une politique de porte ouverte, donc nous ne sommes pas obligés d'utiliser d'anciens codes ou définitions de symboles ! Plus précisément, les opérateurs amateurs ne sont PAS non plus limités à transmettre avec des codes « spécifiés » comme le seraient ceux publiés dans un certain nombre de revues ou de publications comme DUBUS ou QEX par exemple. Ces sources peuvent être citées comme un moyen de spécifier une méthode pour promouvoir les cas d'utilisation pour l'expérimentation, car nous ne nous réunissons pas formellement pour établir des normes pour l'utilisation de la radio amateur, nous exploitons simplement les outils de ceux qui nous ont précédés et inventons de nouvelles choses. Comme Grant, nous partons et inventons des choses et nous nous tournons vers les règles pour nous guider. Si l'expérience enfreint les règles (ou explose), nous revenons en arrière pour la réparer jusqu'à ce qu'elle fonctionne. Et lorsque les règles sont obscures ou pire, restrictives, nous nous activons dans les campagnes d'e-mails et de lettres pour aider à convaincre les autres de faciliter le changement pour le bien du hobby et/ou pour faire progresser l'état de l'art. Joel Wilhite KD6W
Oui, désolé, mais si c'est la FCC qui bloque, alors nous ne pouvons pas faire grand-chose et la restriction ne s'applique pas aux autres administrations, donc cela n'empêchera pas les radioamateurs d'autres pays d'expérimenter. Même s'ils ne peuvent pas transmettre, cela n'empêche pas les radioamateurs américains de recevoir des signaux.
Il se trouve que moi-même, M0DTS et G4XAT et quelques autres du Royaume-Uni avons envoyé des signaux à travers l'Atlantique fin 2022. John, K0ZAK à Baltimore a réussi à recevoir quelques images et 10 secondes de vidéo de moi marchant dans ma cabane. Le SNR était bon mais l'ennemi étaient les réflexions multiples, nous utilisions le DVB-S et devions utiliser un débit de symboles très faible, 18 k/s afin de pouvoir surveiller notre réception via KiwiSDRs et SDRAngel.
Cela a été rapporté dans CQTV278. Tout cela a été déclenché par la réception de cet étrange répéteur FM 29MHz new yorkais (FM, 29.620 MHz, 100W, antenne 5/8ème) qui est une sorte de balise pour les Européens. Nous savions que les trajets multiples seraient un problème, les expériences avec des bandes passantes plus larges étaient infructueuses mais à ce moment-là nous n'avions pas l'alternative OFDM. Une fois que nous en aurons une, nous ferions mieux de nous y mettre car le cycle solaire n'attendra pas.
Ci-joint quelques images de l'article de CQTV. Les trajets multiples sont très évidents, mais parfois ils sont suffisamment minimisés pour obtenir un verrouillage. J'ai également essayé le DRM en utilisant la fonctionnalité TX de DREAM, mais cela n'a pas permis d'envoyer de vidéo.
G0MJW Mike Willis
Description: https://www.qsl.net/zl1bpu/NBTV/OFDM.htm
Images de test reçues sur 80 mètres
à 500km:
2024.09.20_Installer le NBTV encoder /
decoder sur Windows 10 / 11 Au cours de cette semaine, j'ai testé l'encodeur/décodeur NBTV sur Windows 10, en utilisant le sous-système Windows pour Linux (WSL), comme moyen de porter mon application Linux NBTV.
Avec WSL, il est possible d'installer Ubuntu sous Windows 10/11, en tant que système VM, voici ce que vous entrez sur la ligne de commande : wsl --install --distrbution Ubuntu-22.04, cela configurera WSL et installera Ubuntu 22.04 automatiquement.
Une fois cela fait, vous devez installer la dernière version de Gambas3 pour exécuter l'application NBTV_RX.dev. Le seul vrai problème est que l'interface graphique entre Windows 10 et Ubuntu 22.04 présente quelques bugs qui doivent être résolus, là où les applications Linux dans le terminal fonctionnent bien. Mais j'utilise une interface graphique qui est un peu aléatoire, si elle fonctionne, comme beaucoup de problèmes avec ce projet en 2024, il faut attendre un matériel plus rapide, des logiciels et une meilleure interface du système d'exploitation pour fonctionner entre Linux et Windows. Il semble que nous y serons dans environ 12 mois, où WSL s'améliore dans le travail avec les applications GUI, comme je l'ai vu avec les nouvelles mises à jour qui viennent de sortir.
L'utilisation de GNU Radio avec Windows 10 semble également possible, car avec le logiciel NBTV, vous devrez d'abord installer la couche Python, puis GNU Radio, je n'en suis pas encore là.
Si vous souhaitez tester le logiciel NBTV, il serait beaucoup plus facile d'installer une version mise à jour de Linux comme système d'exploitation hôte/principal sur votre ordinateur, car il s'agit d'un processus simple à installer et à configurer. Comme je ne sais pas combien d'utilisateurs potentiels sont encore bloqués dans Windows de nos jours, ces problèmes de travail entre les systèmes d'exploitation ne sont peut-être pas un problème, car je m'attendrais à ce qu'au sein de la radio amateur, il y ait une forte adoption des systèmes d'exploitation Linux. Si possible, j'aimerais me concentrer uniquement sur les systèmes Linux à ce stade, car il reste encore beaucoup à faire. Grant VE3XTV
2024.09.23_Téléchargement des fichiers
J'ai créé un compte GIT-HUB aujourd'hui, avec les fichier NBTV_TX et NBTV_RX version 2.9. En voici le lien: https://github.com/GrantXTV/NBTV-Project
Faites moi savoir si vous les avez chargé et installé (Il y a encore des bugs dans le logiciel).
Version 2.9 NBTV
Cette application est un encodeur-décodeur hybride analogique-digital pour recevoir de la Télévision à bande étroite (NBTV). Elle est développée dans le but d'envoyer de la TV, images et son, sur ondes-courtes à la norme ODFM avec 192 porteuses faite en 4 parties. L'encodage et le décodage acvec le modulateur et le démodulateur est réalisé en GNU Radio.
Le logiciel travaille via la couche d'interprétation Gambas 3 (Visal Basic pour Linux) pour ces fichiers. Il y a 4 modes où le 4ème a le degré de compression le plus faible.
L'entrée peut être une adresse Internet où se trouve un fichier vidéo ou une capture d'écran. Le logiciel envoie les données via UDP de l'encodeur au modulateur et ceci doit être paramétré par l'utilisateur. Ou bien ce peut être un test en boucle entre les sections d'encodage et de décodage.
Scan génère le balayage horizontal et vertical, et de gauche à droite.
4:3 ou 16:9 détermine la géométrie désirée.
Dans le décodeur, il y a View pour mettre en route le décodeur.
Wavelet on / off pour autoriser le décodage au moyen des ondelettes (Vawelet) pour le mode 240 x 192, seulement avec le mode 1, sinon cette fonction est hors service.
Y+C enclenche la couleur, sinon c'est en noir et blanc.
Frame auto affiche seulement les images de référence (key frames), sans les images de mouvement (moving frames).
L'enregistrement audio et vidéo est sauvegardé en Mpeg2 dans un répertoire temporaire.
Grant VE3XTV
Aujourd'hui, en expérimentant différentes idées pour les configurations du modulateur et du démodulateur, j'ai testé la nouvelle conception avec l'envoi vers un fichier et la réception depuis un fichier. Comme je fais toujours tourner mon processeur à 100 %, ce qui me donne une fréquence d'images d'environ deux images vidéo par seconde.
Une fois que j'aurai reçu des commentaires du logiciel d'encodage/décodage sur GitHub, je mettrai les fichiers GNU Radio à la disposition d'un nombre limité d'utilisateurs pour qu'ils les testent. Comme ce n'est pas si facile de faire un test complet avec mon matériel actuel, jusqu'à ce que je puisse obtenir un ordinateur plus récent pour travailler avec.
Voici quelques images montrant la couche GNU Radio du modulateur et du démodulateur GNU Radio, l'autre montrant la carte de test F, de la vidéo revenant au décodeur. Je testais avec le mode 4, le mode vidéo non compressé à 120 x 96 x 8, 1/3, car j'obtiens un certain nombre d'erreurs avec les modes 1 à 3, ce qui est encore en cours de traitement.
Grant VE3XTV
Commentaire
La transmission TV sur ondes-courtes se heurte au théorême de Shannon qui exprime que la largeur de bande d'une transmission dépend du nombre de bits transmis. Dans le cas du mode 4 non compressé ci-dessus, cela fait 1920 bits à transmettre puisque l'image fait 120 x 96 pixels. Grant les transmet non compressés en OFDM à l'aide de 192 porteuses et une bande passante de 100kHz. Mais cette définition d'image est vraiment très faible comparée à celle à laquelle on peut arriver en DVB-S et, de mon point de vue, insuffisante par rapport aux critères de qualité actuels.
En DVB-S, on arrive à transmettre de belles images TV couleur avec une résolution de 320 x 240 en utilisant un SR (Symbol Rate) de 32 kb/s/s ce qui fait une bande passante d'environ 40kHz.. La différence est que le DVB-S est fortement compressé à l'émission, ce qui est la seule façon d'augmenter le nombre de bits transmis. Cela signifie qu'en DVB-S on arrive à transmettre de la TV avec une résolution 40 fois meilleure dans une bande passante 2,5 fois plus petite.
Le problème, avec le DVB-S, est que cette norme a été développée pour le trafic par satellite où il n'y a ni QSB, ni QRM ce qui fait qu'elle est très sensible à ces deux perturbations particulièrement présentes sur ondes-courtes. On le voit bien sur 10 mètres, le correspond ne reçoit qu'une image de temps en temps car, en présence de QSB et de QRM, le récepteur n'a pas le temps de synchroniser entre deux pointes de QSB. En OFDM, le fait d'utliiser 192 fréquences fait que si une de ces fréquences est QRM, les 191 autres permettent quand-même de décoder le signal sans erreur. C'est l'avantage du DVB-T (OFDM) par rapport au DVB-S.
Si le but atteindre est la compatibilité de la NBTV avec nos bande ondes-courtes, il ne faudrait pas dépasser 20kHz de bande passante. En OFDM, cela signifie diminuer l'immunité au QRM/QSB puisqu'on diminue le nombre de porteuses qui permet une redondance du signal. En gros, en passant de 100kHz de bande passante à 20kHz, le nombre de porteuses passerait de 192 à 38 (192/5). Est-ce suffisant pour garantir une bonne immunité au QRM/QSB sur ondes-courtes ? C'est la question que je me pose.
Et puis une autre: est-il possible de compresser de 40 fois (320x240/120x96) en OFDM avec la puissance de nos PC sans trop augmenter le temps de latence entre 2 images successives ?
Une chose est absolument sûre: si on veut transmettre des images avec une bonne résolution dans une bande passante de 20 kHz, il faut énergiquement les compresser sinon on n'obtient que des images de piètre qualité. De mon point de vue, le but à atteindre devrait être de pouvoir transmettre au minimum des images en noir-blanc ayant 320 x 240 pixels de résolution à 4 images/s.Cela pose la question de la faisabilité de transmettre de la NBTV en OFDM. Ne serait-il pas préférable de travailler en DVB-S en optimalisant les codeurs/décodeurs pour augmenter l'immunité au bruit pour les bas SR ?
Accessoirement cela me donne une idée: Ce serait bien que la future norme NBTV comporte la possibilité de changer la cadence des images afin de pouvoir montrer une image fixe de bonne qualité, par exemple pour afficher un schéma. On aurait alors des images noir-blanc de résolution suffisante pour montrer un shack avec l'opérateur en mouvement et un bouton pour transmettre une image fixe en haute résolution lorsqu'on le désire. C'est peut-être prématuré de le proposer mais il faut le suggérer aux concepteurs pendant que les idées sont là...
Michel HB9AFO
2024.30.09_PA 10 m et version 3.0
Ce week-end, je travaillais sur des idées de conception d'un amplificateur de puissance RF de 1 kW pour 10 m, je vois que beaucoup de pièces sont disponibles sur Ebay, boîtier, modèles d'amplificateurs et cartes de filtrage.
Comme je l'ai déjà mentionné, le rapport crête/moyenne est d'environ 50:1, ce qui me donne 20 W de RF totale avec laquelle travailler, ce qui équivaut à un peu plus de 100 mW par porteuse, donc la puissance de transmission est très faible. L'important est d'avoir une bonne linéarité, bien au-dessus de ce dont vous avez besoin pour la SSB, j'ai donc besoin d'un peu de gain d'antenne pour faire passer mon signal NBTV au Royaume-Uni et dans l'UE.
Du côté logiciel, j'ai apporté une modification au mode 4 dans la façon dont fonctionne l'encodage vidéo, ainsi que sur la récupération du signal, comme la plupart des autres systèmes NBTV, aucune information de synchronisation n'est envoyée, c'est pour économiser sur l'utilisation de la bande passante. Par conséquent, comme avec les systèmes NBTV de ZL2AFP, vous devez définir manuellement le point de départ de la trame de données entrante pour le démodulateur, une fois cela fait, il reste synchronisé sans réajustement (à tester à l'antenne).
Gardez donc un œil sur GitHub car je téléchargerai la version 3.0 d'ici une semaine environ pour l'essayer, car j'attends toujours d'avoir des retours sur la version 2.9 sur les problèmes détectés. Il serait plus facile de faire une mise à jour que plusieurs petites, mais je verrai comment cela se passe au cours de la semaine à venir. L'image est celle du spectre de sortie du signal HackRF amplifié, il semble y avoir beaucoup de bruit de fond provenant du HackRF, car j'espérais obtenir un meilleur rapport signal/bruit, encore une fois c'est ce qu'il est.
Grant VE3XTV |
Il y a deux sortes de justice: vous
avez l'avocat qui connaît bien la loi, et vous avez l'avocat qui connaît
bien le juge
(Coluche)
|
Ce mode de transmision d'images est intermédiaire entre la SSTV (Slow Scan TeleVision, télévision à balayage lent) et la FSTV ou ATV (Fast Scan TeleVision, télévision à balayage rapide). Il permet d'échanger des images qui bougent mais à basse résolution, et ce même sur ondes-courtes puisque le spectre occupé est moindre que celui nécessaire pour transmettre la parole. A noter que des essais de télévision plus rapides que la SSTV, la MSTV (Medium Scan TV), donc avec la transmission de mouvements, ont été faites notamment par feu Don Miller W9NTP et Robert W0LMD en 1978. Ils ont diffusé pendant plusieurs années des images animées sur 28 MHz par l'intermédiaire d'une balise mais hélas sans suite car l'équipement était compliqué à construire. Avec l'arrivée des logiciels SSTV-FAX, ces développements seraient intéressants à reprendre. La bande passante de la MSTV était d'environ 36 kHz, compatible avec la largeur de notre bande 28 MHz.
L'association NBTVA (NBTV
of America) a adopté le standard de 32 lignes avec un balayage
vertical. Ce dernier commence en bas à droite de l'image et se termine
en haut à gauche, identique à celui adopté par J.L.Baird. Ses images
avaient un rapport de 3/7, ce qui est trop étroit aussi le rapport
horizontal/vertical de 2/3 a été adopté. Le jack 3.5 mm est normalisé
comme câble d'interconnection.
Conforme au standard TV, une inpulsion de synchronisation "plus noire
que le noir" est envoyée à chaque fin de ligne, sauf à la fin de la
32ème, où cette absence d'impulsion de synchronisation redémarre le
balayage vertical au début d'une image.
Comment débuter en pratique Le plus simple est de commencer par l'émission et réception à l'aide des logiciels de ZL2APF. Commence par les télécharger sur le site d'ON1AIJ. Con (c'est le prénom de ZL2APF et ce n'est pas de ma faute s'il s'appelle comme ça. En plus, à voir ce qu'il développe, ce n'en est pas un!) a développé plusieurs logiciels pour PC et j'attends encore quelques informations de sa part pour les interfacer avec ma caméra. Télécharge RXFMTV32.EXE et TXFMTV32.EXE qui sont tous deux conçus pour la norme de transmision à 32 lignes. Ce sera vite fait car ils ne font chacun que quelques dizaines de kB et n'utilisent pas de DLL externes. Je les fais fonctionner moi-même sour Windows ME mais toutes les versions de Windows à partir de Win 95 peuvent les supporter. Pour simplifier le travail et sérier les problèmes, la première phase consiste à générer une image NBTV et à l'enregistrer (sur un mini-disc en ce qui me concerne). Double-clique sur TXFMTV32.EXE pour démarrer le logiciel d'émission. La fenêtre suivante apparaît:
Ce logiciel transmet
l'image qui se trouve cadrée dans l'écran de gauche de la fenêtre et
qui se trouve quelque part sur l'écran de l'ordinateur. En fait ce
logiciel transmet 32 points x 32 lignes d'une partie de l'écran
sélectionnable avec les deux ascenseurs et dont les coordonnées X et Y
apparaissent en haut à droite. Il faut cependant que l'image ne soit
pas dans une autre fenêtre, dans Winword par exemple, l'idéal étant un
fond d'écran. J'ai cependant trouvé une exception avec PaintShop, qui
permet d'afficher une image utilisable avec TXFMTV32. Une fois quelques minutes d'image enregistrées, le premier essai consiste à injecter ces signaux dans la carte son du PC. Un simple câble suffit entre l'enregistreur et l'entrée ligne de la carte. Double-clique ensuite sur RXTVFM32.EXE pour afficher la fenêtre de réception que voici:
Un clic sur "Adjust input"
permet de régler le niveau d'entrée de la carte son et tu verras
immédiatement son effet sur l'image reçue. L'image affichée ci-dessus
correspond à du souffle mais dès qu'un signal NBTV apparaît (à la
norme 32 lignes je précise, sans cela aucune réception n'est possible
avec ce logiciel) tu verras apparaître une "image", disons quelque
chose sur l'écran, qui, en général, défile horizontalement et
verticalement. En mettant la croix à "Sync on" (et en ayant fait de
même en émission), l'image se stabilisera dans le sens vertical. Avec
les réglages par défaut, les images générées par TXFMTV32 (et
seulement par lui) seront visibles et stables. Sinon il faut encore
trouver la bonne position du potentiomètre à glissière "Slant adjust"
afin que l'image ne soit plus en oblique. Ce réglage est très fin.
Dans un premier temps, ne pas toucher 4 autres potentiomètres car
leurs valeurs par défaut correspondent à celles du logiciel
d'émission. Une fois que tu auras pu recevoir correctement tes images avec une liaison par fil, tu pourras passer à une liaison radio, sur deux mètres par exemple. Il te suffira d'injecter le signal sortant de l'enregistreur à l'entrée "modulation" de l'émetteur, soit à la place du micro (en adaptant correctement le niveau BF), soit sur une entrée ligne si ton transceiver en a une (utilisée généralement pour le packet radio). Pour un premier essai il te faudra un autre récepteur avec sa sortie BF reliés à l'entrée "ligne" de la carte son du PC. En tâtonnant un peu, tu trouveras facilement les bons réglages. Dans mon cas, la liaison radio est de moins bonne qualité que la liaison par fil mais, à-priori, on devrait pouvoir obtenir la même qualité avec une liaison HF de bonne qualité. Mais je n'ai pas encore eu le temps d'investiguer et nous en reparleront. Les dernières étapes consisteront à transmettre des images animées provenant d'une caméra, à faire un QSO avec un correspondant équipé de la même manière et, finalement, à recevoir et à se faire recevoir par une station équipée d'un émetteur-récepteur mécanique. Il y a encore du boulot!...
Voilà la première image que j'ai générée et transmise sur 144 MHz. C'est mon portrait, sous la neige, de la page d'accueil. La prise de vue n'est pas terrible et manque de contraste mais c'était mon premier essai et ce n'est déjà pas si mal que ça !... Pour comparaison
Signal basse fréquence, donc transmissible en SSB sur ondes-courtes TV à balayage lent, des
images fixes mais qui peuvent atteindre de hautes résolutions et la
couleur.
Nécessite une bande passante d'au moins 6 MHz, donc utilisable qu'à partir de 430 MHz. TV "normale" à 625 lignes PAL couleur identique, à la TV commerciale. Quelques links indispensables:
HB9AFO/26 décembre 2001 |
