Jump to content
F4HTQ

Conception : Traitement numérique du signal

Recommended Posts

F4HTQ

Bonjour,

Voila un sujet qui curieusement n'avait pas été initié.

Et c'est pourtant un domaine tout aussi passionnant que devenu central sur le matériel moderne.

Nous allons donc parler ici de filtrage numérique, échantillonnage,  décomposition IQ, transformée de Fourier ( rapide ou pas), modulations/démodulations avec un DSP ( AM, USB,LSB,FM,CW...), liste non exhaustive.

Les discussions sur GNU Radio sont aussi les bienvenues, même si c'est un peu moins du "code" au sens premier. Même chose pour Matlab.

Il y a un domaine connexe qui est celui des gestion de compression de données et correction d'erreur sur les transmissions numériques, je pense que nous pourrons aussi en discuter ici car cela intéresse généralement les mêmes personnes.

La seule chose que j'aimerais éviter sur ce sujet, c'est des questions sur du matériel commercial dans le genre " le DSP de ce TX A est il meilleur que celui de ce TX B, lequel je dois acheter ?" ou "sur quel bouton je doit appuyer sur mon TX pour passer en mode super-dsp 59 ?". Par contre toute discussion technique sur des choix de conception de matériel commercial est la bienvenue.

Au niveau des abréviations, même si nous sommes en France, je propose de plutôt utiliser les versions anglophones, donc IIR au lieu de RII, FIR au lieu de RIF, FFT au lieu de TFR.... L'idée étant d'utiliser préférentiellement les termes utilisés dans la grande majorité de la documentation disponible.

A vous.

David.

Edited by F4HTQ
  • Message intéressant 1

Share this post


Link to post
F4HTQ

Sur ces questions ça vaut sacrément le coup d'aller perdre son temps sur le site de JP F5MI : http://f5mi640.pagesperso-orange.fr/

D'autant plus qu'il est parmi nous, sur ce forum.

 

Share this post


Link to post
F6ITU

bonjour

n'étant ni codeur ni matheux, je passe mon tour.

J'en profite toutefois pour signaler la sortie de deux vidéos précisément sur le traitement de signal (via hackaday) 

l'une sur les transformées de Fourier qui vont vous décalquer

https://www.youtube.com/watch?v=ds0cmAV-Yek

l'autre sur "comment faire de la radio en faisant le contraire de ce que l'on vous a dit 

https://www.youtube.com/watch?time_continue=149&v=THyM4YiWE0k

(j'aime bien le SDR à 1 bit) 

C'est dans le droit fil de la discussion initiée par David, 

je détourne également ce fil pour répondre partiellement à une question informulée ("Voila un sujet qui curieusement n'avait pas été initié.").  La réponse est "parce qu'il n'y a que de très rares documents de vulgarisation accessibles à tous pour faciliter les premiers pas dans ce domaine". La courbe d'apprentissage est raide aux débuts, et, s'il n'est pas nécessaire de maîtriser l'intégralité de la démarche mathématique, il est tout de même indispensable d'en saisir les grands principes de base. Ceci est impossible sans quelques articles de vulgarisation et interventions telles que celles signalées ci-dessus. 

Sur la correction d'erreur, il me semble avoir vu passer qq chose au fil des échanges sur la liste Rowetel

quant à GNU Radio, c'est effectivement un des sujets qui devrait passionner tous les radioamateurs sans exception. 

Nous avons dressé une liste des principales ressources d'apprentissage concernant GRC 

https://forum.electrolab.fr/viewtopic.php?f=16&t=260&p=1377&hilit=gnu+radio

De quoi remplir 2 ou 3 bons mois à potasser tout ça 

Marc

 

Share this post


Link to post
F5MI

Joyeux Noel, 73 à tous.

Merci à David pour m'avoir fait de la pub!! je préviens : Je ne verse pas de Royalties! ?

Bon,je veux bien participer à ce post, mais auparavant je vais faire le point. Il n'est pas question de se noyer sous les Maths de niveau Bac+5.. ça n'apporte rien et ça noie tout le monde! Et ça fait de la peine à Marc!! HI.

Pour la vue de mon site DSP ça date un peu (Le siècle dernier!).Ce sont pour la plupart des articles qui ont été publiés de 1996 à 1999 et que l'on trouve sur les Radio-Réf de l'époque. Il n'est plus question de recommencer ces bidouilles car les composants sont malheureusement obsolètes.. même pour ceux du DSP 10, qui sont également sur le transceiver 'Picastar' en l’occurrence l'ADSP 2181 d'Analog Devices..

La partie Théorique est bien sur toujours valable, les équations qui y figurent sont élémentaires, et on ne peut pas les ignorer, même dans un bouquin qui s’appellerait 'DSP pour les nuls'.

Un mot quand même pour donner un Prix à mon ami 'Peter Traneus Anderson KC1HR' qui a eu l'idée le premier de faire paraître en 1994 dans les colonnes de QEX un article sur ce que l'on peut appeler  l’échantillonnage direct en réception, avec un HSP50016 d'Harris, précédé par un ADC de 12bits échantillonné à 50 Msps! Et ça a fonctionné! Bravo l'artiste.

Un petit mot pour 'Bob Larkin W7PUA', le concepteur du DSP 10, arrêté en 2014 par manque du composant principal (Le Picastar aussi). Il faut signaler que le soft du Picastar est dérivé du soft du DSP10, car la  version originale, qui utilisait le système Weaver a eu des problèmes!.

Il n'est pas conseillé de transposer les softs prévus pour l'ADSP2181 sur un modèle plus récent, en l’occurrence les 'Blackfin', car ce n'est jamais facile, de plus Analog Devices à un soft 'Visual DSP++  5.2' qui est en utilisation libre pour 90 jours, Après la licence coûte le prix d'un Rolls (d'occase bien sur! ?). Je signale pour ceux qui utilisent ce soft qu’après les 90 jours on peut encore l’utiliser,  pas en C++, mais en allant en mode MS-Dos lancer tous les programmes (Assembleur, Linker, Compilateur, etc) qui sont dans le dossier. Ce n'est pas commode mais ça rappelle l'ancien temps ou Windows n'existait pas!! (Et c’est pas à l'époque des Cavernes!!).

Bon alors un mot sur Matlab/Simulink.. C'est un super truc surtout Simulink, et je me propose d'en reparler!

Il faut télécharger la version gratuite avec les Boites à outils que l'on veut sur Mathworks. Elle dure 30 jours, en parlementant avec un Conseiller par Chat, on peut obtenir 30 jours supplémentaires, le temps de voir largement si on continue ou pas. Ensuite pour un OM ça coûte 100$ et 35$ par boite à outils! La boite à outils pour tester le RTL-SDR est gratuite!

Je dis cela parce que Mathworks a publié un livre blanc à télécharger sur : http://deskstopSDR.com  vaux le coup de s'amuser avec des clés RTL-SDR que nous avons tous, ça permet de tester Matlab/Simulink, et de découvrir plein de choses que l'on ne soupçonnait même pas...  

A vous la suite  

PS: On trouvera sur le REF des articles de F5NB sur le Traitement numérique du Signal parus du 12-2006 au 10-2007..

 

73

Jean Pierre F5MI

 

Edited by F5MI

Share this post


Link to post
F6ITU

C'est pas de ma faute, j'ai une allergie. Et impossible de me faire désensibiliser. Même la table de multiplication me fait éternuer

Ton exemple du Picastar (sans même évoquer le retrait brutal de toute la masse documentaire par XJP) me fait dire que l'avenir, dans notre secteur plutôt étroit, est à l'orientation fpga systématique... le silicium vieillit plus vite que le code et exige des outils très spécifiques. Les principes fondamentaux ne changent pas de toute manière.

Mais même dans ce domaine, les limitations sont rapidement atteintes. Voir par exemple les problèmes difficilement surmontable que rencontre actuellement le groupe HPSDR pour pondre les dernières versions du firmware intégrant protocol 2 avec les plateformes de dev gratuites.  Le prix des workbench complets est franchement dissuasif; 

je me plonge dans ton 

https://www.desktopsdr.com/

.. 1,5 Go tout de même

(là, c'est la bonne url, avec un véritable https et sans s entre desk et top :-0 

je pense qu'on peut déjà faire des choses sacrément intéressantes uniquement avec GNU Radio et une clef RTL (ou même sans) 

Marc

 

 

Share this post


Link to post
F6FVY

Bjr

Concernant Matlab / Simulink, ne peut-on pas envisager d'utiliser des alternatives gratuites et/ou open source comme Octave ou Scilab, accessibles à tous ?

Pour avoir joué un peu avec, si mes souvenirs sont bons, Octave accepte la syntaxe de Matlab (voire considère une incompatibilité comme un bug...). Par contre, je ne sais pas si son simulateur est à la hauteur de Simulink. D'ailleurs selon ce que je lis, Xcos ne s'interface pas directement avec Octave mais plutôt avec Scilab..

73

Laurent - F6FVY

Edited by F6FVY
Précision sur xcos

Share this post


Link to post
F5MI

Bjr Laurent,

Je ne connais d'Octave que peu de choses, un peu plus de Scilab que j'ai installé il y a peu.. Comme c'est gratuit ou open source il n'y a rien à débourser bien sur. Mais à trop se disperser on risque de tout mélanger!! 

En plus je ne sais pas encore qu'elles sont pour ces programmes les conditions à remplir par l'Ordinateur!

Ce que je sais et que je n'ai pas dit hier c'est que pour les versions actuelles de Matlab/Simulink il faut une CPU avec par exemple un Intel core i3 6100T, 8GO de mémoire RAM, un HD Graphics 530 ou équivalent, et Windows 10 64 bits,ce qui sont des conditions que l'on ne trouve pas sur tous les ordi j'en conviens! Sinon ça rame!

Le problème étant à terme de programmer des FPGA, et là je rejoins Marc, d'autant plus que ce que l'on faisait avec des DSP's on peut le faire avec des FPGA.

Un autre truc étant que Simulink est un programmes qui fonctionne avec des blocs modèles, peut être un peu difficile à appréhender au premier abord, mais il viendra un moment pour réaliser du code HDL automatiquement (presque!). et ça c'est appréciable. J'ai vu des exemples qui sont construits sans l'écriture d'une seule ligne de code! une fois les blocs bien programmés! ça ouvre des horizons!

Le problème c'est la mise de fonds initiale sur le programme, si on n'a pas la chance de pouvoir avoir un accès en tant qu'étudiant (les prix sont nettement moindres!) Et je ne dirai jamais assez qu'avant de dépenser le moindre centime dans un soft, il faut savoir si il sera vraiment utile, et si on arrivera à s'en servir, c'est pourquoi j'ai mis un lien vers les RTL-SDR car là ça ne coûte rien, et on va vite voir si on pourra aller plus loin ou pas!

J'essayerai SCIlab, et je dirai la différence.. J'ai vu qq part sur le net 'Matlab vs Scilab' je vais essayer de retrouver.

On peut travailler avec Linux, c'est une complication de plus, sauf pour ceux qui maîtrisent vraiment. Là j'ai une certaine aversion pour 'Le serpent Python' hi.. Je ne suis pas à me compliquer la vie! Un ordi sur W10, un autre sur Linux!.. Bon c'est plus un Shack mais un Labo d'informatique! 

JP F5MI

 

 

Edited by F5MI

Share this post


Link to post
F4HTQ

Bonjour,

Content qu'il y ait de l'activité.

Pour répondre à Marc sur la difficulté d'accès du domaine.

Je pense que je ne m'y serais d'ailleurs jamais mis sur Atari n'avait pas mis sur le marché, au début des années 90,  un ordinateur qui s’appelait le Falcon 030 et qui intégrait un DSP56001 de Motorola. Sur les brochures il était question de traitement numérique du signal.

A partir de la, le virus était inoculé et j'ai dévoré ce que la bibliothèque de la fac pouvait offrir, en l’occurrence un bouquin très complet écrit par Maurice Bellanger 

md1853427368.jpg

Il s'en est suivi plusieurs années de code ( a l'époque en assembleur 68030) afin d'implémenter pas mal d'algos décrits dans ce bouquin ( dont la fameuse FFT).

J'avais même mis au point un nouveau algorithme de compression audio sans pertes, basé sur une interpolation à base de FFT + correction, le tout dans un process multirésolution ( principe comparable à celui des ondelettes avant qu'elles ne soient développées au niveau de la recherche)  . Il n'a jamais été publié mais j'ai toujours le code. Il permettait de réduire quasiment de moitié la taille de stockage d'un audio de qualité CD sans aucune pertes (fichiers binairement identiques). 

Pour revenir sur l'accessibilité du traitement numérique du signal c'est effectivement ardu. Je pense qu'il y a deux raisons à cela:

  • Le bagage mathématique minimal indispensable pour vraiment comprendre ce qu'on manipule. Il est composé au minimum d'un bon niveau en algèbre complexe et avoir une bonne maîtrise des distributions (signaux aléatoires) semble indispensable pour espérer une maîtrise complète. Même si on utilise des librairies toutes faites, ne pas comprendre l’origine des symétries d'une FFT handicape sérieusement.
  • Un travers bien français à complexifier au delà du nécessaire l'écrit sur le sujet. J'ai souvent eu l'impression que les bouquins n'étaient pas fait pour apprendre à ceux qui ne connaissaient pas encore le domaine, mais plutôt pour "briller" au niveau des confrères, le tout sans laisser la moindre faille qui pourrait être interprété comme un manque de rigueur.

C'est ce deuxième point qui fait que je conseille à ceux qui veulent investir du temps sur ce domaine de plutôt viser des bouquins US. Par exemple le "Digital processing of signals" du même Maurice Bellanger mais destiné aux étudiants américains (j'en possède un exemplaire). C'est bien plus digeste.

D'ailleurs ce conseil vaut aussi pour les bouquins de physique, comme par exemple les cours de Feynman.

La suite plus tard ( j'ai du code sur le feu).

David.

 

Edited by F4HTQ

Share this post


Link to post
F6ITU

sic "D'ailleurs ce conseil vaut aussi pour les bouquins de physique, comme par exemple les cours de Feynman."

mouahaharrrrfffffff !!!!

oui, bien entendu... c'est un vulgarisateur qui confine au génie. Non seulement il écrit sacrément bien et parvient à rendre passionnant des cours sur la physique quantique (je jure que je ne suis pas -encore- bourré) mais il arrive également à éluder très souvent les démonstrations mathématiques pour parvenir à ses fins. Et ça, c'est très fort.

Ce que j'apprécie surtout, c'est sa vision générale (holistique disent les Zétazuniens) de la méca, de la physique, de l'électronique, de la chimie, des sciences naturelles, parfois même de l'histoire et de l'anthropologie. Il a toujours une anecdote incroyable et des digressions vertigineuses, même -et surtout- lorsqu'il parle de force gravitationnelle. On retrouve chez Feynman la même effervescence jubilatoire que chez Douglas Hofstadter dans son Gödel-Escher-Bach. 

byte douche_froide()

{

Ses 7 bouquins sont sur ma table de chevet. Mais tout de même... la majorité de ses ouvrages sont classé "niveau master" et certains sont "niveau doctorat"... faut pas dec... ça va concerner 0, 001ppm de la population radioamateur. 

return Val_douche;

}

Marc

 

Share this post


Link to post
F4HTQ

Bonjour,

Une question qui me turlupine.

On prend un SDR...

( exemple virtuel)

J'ai un échantillonneur à 1MS/S, donc 1 point de mesure toutes les µS.

La fréquence maximale échantillonable ( Nyquist) sera donc de 500Khz.

J'échantillonne, je rentre dans le processeur de traitement ( FPGA ou autre) et je mélange ( simple multiplication par un oscillateur software généré en interne).

on va dire que je veux recevoir la bande des 630M ( 474Khz) avec une bande passante de 3KHz.

Je place donc mon oscillateur "software" a 474Khz, et lui aussi fourni une valeur toutes les µS ( échantillonné comme le signal d'origine).

Quand je vais faire le produit, je vais ramasser la différence des deux fréquences.... mais aussi la somme.

Or la somme va être au moins a 948kHz, ce qui est impossible à représenter dans un flux échantillonné à 1MHz ( sortie du critère de  Nyquist), ce qui va m'amener un problème de repliement et potentiellement du bruit.

Première question: Ce problème est il bien réel ou n'existe t'il que dans ma tête ?

Si le problème est bien réel, comment le régler ?

j'ai l'impression qu'on s'en sortirait en interpolant les données issues de l'ADC ( avant le mélange) afin de créer un flux correspondant à une fréquence d’échantillonnage de 2Mhz ( et qui sera donc capable de transporter sans repliement un produit de mélange à 948kHz).

il faudrait alors aussi sur-échantilloner l'oscillateur généré pour pouvoir continuer à faire du produit terme a terme avec le flux qui vient de l'ADC.

Tout ceci doublerais le coût du mélange mais éviterais ces soucis de repliement.

Il suffirait ensuite de juste adapter la décimation pour démarrer de plus haut.

Cela a t'il du sens ?

David.

 

 

 

Share this post


Link to post
FM4PN

Bonjour,

Le probleme est theorique dans la pratique un oscillateur numerique sur 477KHz echantilloné a 1MHz aura trop de bruit de phase il faut qu'il soit echantilloné beaucoup plus rapidement.

Donc la somme ne chevauchera pas la difference, d'autant plus si on choisi une FI nulle.

Traditionnellement suivant le melangeur on a le CIC en decimation qui est un passe bas.

Cette methode marche bien il n'y a pas d'image, si ca vous interresse j'ai fait un recepteur pour le redpitaya.

 

73 JP

Share this post


Link to post
F4HTQ

Bonjour JP,

il y a 8 minutes, FM4PN a dit :

Le probleme est theorique dans la pratique un oscillateur numerique sur 477KHz echantilloné a 1MHz aura trop de bruit de phase il faut qu'il soit echantilloné beaucoup plus rapidement.

ok, donc on échantillonne a plus haute fréquence l'oscillateur pour des questions de bruit de phase, ce qui nous met à l'abri du problème de repliement.

On retombe finalement sur la solution que je proposait ( travailler en interne sur une fréquence d’échantillonnage bien plus élevée que celle de l'ADC) , sauf que évidemment je ne savais pas qu'on était obligé de faire ça pour des questions de bruit de phase.

Merci beaucoup pour la réponse.

il y a 12 minutes, FM4PN a dit :

si ca vous interresse j'ai fait un recepteur pour le redpitaya.

J'y vais tout doucement. J'avais idée, pour débuter sur ce genre de problèmes, de faire un petit récepteur VLF/LW en baseband avec un microcontrôleur capable d'échantillonner à 1MHz sous 12 bits ( STM32 ou autre).

ça me permet de rester sur du C++ classique sur un microcontrôleur  ( je débute a peine en FPGA) tout en dégrossissant un peu la partie traitement de signal.

Mon expérience en traitement numérique du signal est plus dans le domaine du traitement et compression de données et analyse spectrale que dans celui de la radio.

Merci encore.

David.

 

Share this post


Link to post
FM4PN

https://www.analog.com/designtools/en/simdds/?part=AD9914&fin=3.5G&mult=1&ftw=5D9F7391&rso=111111&harmonicDB=-50&useFilters=0

Sur ce site vous pouvez voir la tronche du signal issu du DDS, il faut travailler à tres haute frequence.

Avec un microcontroleur certain microchip sont equipé d'un NCO, sinon on peut essayer avec un timer mais la frequence vas rester tres faible.

On peut essayer sans la partie generatrice de la sinusoide est travailler en signal carré, auquel cas le mixeur est un simple echantilloneur (interrupteur)

 

73 JP

 

Share this post


Link to post
F4HTQ
Il y a 4 heures, FM4PN a dit :

https://www.analog.com/designtools/en/simdds/?part=AD9914&fin=3.5G&mult=1&ftw=5D9F7391&rso=111111&harmonicDB=-50&useFilters=0

Sur ce site vous pouvez voir la tronche du signal issu du DDS, il faut travailler à tres haute frequence.

Avec un microcontroleur certain microchip sont equipé d'un NCO, sinon on peut essayer avec un timer mais la frequence vas rester tres faible.

On peut essayer sans la partie generatrice de la sinusoide est travailler en signal carré, auquel cas le mixeur est un simple echantilloneur (interrupteur)

 

73 JP

 

Ok, c'est noté.

Disons que en me limitant ( dans un premier temps) a de la démodulation AM (grandes ondes), le bruit de phase ne devrait pas être trop génant.

au niveau du microcontrôleur présentant un ADC rapide, il faut que je fasse un choix.

J'ai entre les mains :

  • SAM3X8E ( sur une platine arduino DUE)
  • STM32F407 (le plus rapide de tous)
  • STM32F103 

Pour l'instant c'est qu'un projet "lointain", j'ai pas mal de choses à faire avant ça, mais comme souvent je commence a y réfléchir ( en tache de fond), je me documente, commande le matériel nécessaire, et réalise quelques tests.

j'ai un émetteur AM puissant pas très loin (RMC) ça devrait aider pour la mise au point.

 David.

Edited by F4HTQ

Share this post


Link to post

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now

×
×
  • Create New...