clé SDR besoin de conseils

[F6ITU 265]

et ....as tu "double-cliqué" sur les cartouches ? histoire d'admirer, tel Saint Glinglin découvrant enfin la demeure de Godot, le schéma hiérarchique qui vas popuper sur ton écran, et qui évite au kicadeux de base de plonger son lecteur dans les méandres insondables d'un schéma impossible à lire ? 

 Si tu as, dans le root du projet, un fichier RX.sch et un TX.sch, alors tu as tout .

Tout le projet HermesLite est organisé sur le même principe de séparation des fonctions, avec bien plus de talent que je ne pourrais en avoir. Un schéma oscillateur, un autre fpga, un troisième ethernet, un quatrième alimentations, un cinquième frontend etc

Marc

ps : pour le pcb, faudra attendre, je suis dessus, et il faut quelques allers-retours avec Freecad pour modéliser le paneling de la carte... la découpe est assez tarabiscotée 

 

Modifié 8 mai par F6ITU

[F5MI 126]

Ben j'ai trouvé!! Et c'est super bien! Continues comme ça Bravo.

JP

 

[F5MI 126]

Si tu mettais ces schémas avec ton front-end Rx ça donnerais quoi?

 

 

[F6ITU 265]

on s'éloigne du sujet du thread... il faudrait ouvrir un nouveau fil. 

très rapidement : ça serait compliqué, la sortie est prévue pour sortir sur de tout petits fils reliant la carte frontend à l'entrée de l'adc, ou plus exactement sur l'entrée d'un transfo 1:1 à point milieu (pour injecter la tension de bias de l'adc). L'idéal eut été que la RP16 ait une entrée sma "flottante", ce qui m'aurait permis de l'utiliser en mode différentiel... caramba, encore raté. 

Donc le plus simple serait peut-être que tu attendes patiemment que je monte un proto, et s'il tombe en marche, tu ajouteras à l'entrée de ton adc des petits plots de soudure sur ain1 et ain2. Ou plus simple encore, tu conserves l'approche de la note d'application en ajoutant un AD8138 (8 balles à l'unité chez mouser, c'est pas une ruine, et pas de complication avec cette fichue tension de bias) 

Marc

 

[F6FLT 35]

Bonjour,

J'arrive un peu après la bataille. Pour ma part je conseillerais la RSPdx de SDRPlay. Grande sensibilité, peu de signaux fantômes, et tout ce qui va bien côté logiciel pour que ça marche avec tous les logiciels de SDR (SDRUno est le logiciel fourni par SDRPlay, mais j'utilise surtout SDR# via la DLL EXTIO).

Le pb des SDR, c'est trop souvent de voir apparaître des signaux indésirables là où on ne devrait rien avoir. C'est particulièrement le cas des émissions puissantes, notamment celles de la bande FM, et de plus en plus celles du DAB (et dans certain pays, la MW). Avec la RSPdx, on a des filtres tueurs de ces 3 bandes. Démo ici avec mes copies d'écran de SDR# sans et avec filtre (spectaculaire). J'ai superposé la fenêtre de l'interface de la DLL qui pilote pour visualiser le paramétrage utilisé:

 

Quand les filtres sont actifs, on ne retrouve plus rien de ces fréquences dans les autres bandes. On voit de plus avec le dernier exemple que les fréquences de coupure sont plutôt nettes : à 2500 KHz on n'a quasiment plus rien de l'atténuation de la bande MW, idem pour la bande aviation, à partir de 118 MHz, peu impactée par le filtre FM.

Dans ce milieu de gamme des SDR, Airspy m'a déplu à cause de sa confiscation du logiciel SDR# qui était open source au départ, et propriétaire aujourd'hui, avec en plus un entretien d'une idée d'ouverture à cause du support des clés RTL, certes, mais aussi des plugins. Or le développement des plugins n'est pas réellement ouverts aux tiers contrairement à ce pour quoi c'est fait, mais chasse gardée de l'équipe entourant Airspy. Je n'apprécie pas du tout cette philosophie.

SDRPlay me semble être plus ouvert et matériellement faire le meilleur boulot.

73

François

 

 

[F6ITU 265]

Bonjour François

Effectivement, cette histoire du "closed source"  est un sujet que j'ai abordé avec Youssef, et son point de vue se défend. 

De manière lapidaire, le business model d'Airspy, qui est un développement original, ne peut être protégé (aka l'auteur ne peut gagner sa croûte...) par la seule originalité du hardware. Si cela avait été le cas, on aurait vu apparaître des clones Chinois dès la première semaine de commercialisation passée. Reste le soft. 

Ce qui n'est pas le cas des dérivés de récepteurs utilisant une base Realtek, qui ont limité leurs développement au frontend. 

Reste que SDR# reste probablement le client le plus simple qui soit à installer, et ça, pour débuguer un problème de traitement de signal ou de configuration, c'est sacrément appréciable

Tant que ces problèmes ne concernent que les appareils d'entrée de gamme, cette situation est encore supportable. Les "Pro" et les "j'men fiche" de l'open source ou pas open source peuvent trouver une solution qui conviendra à chacun. Avec un avantage croissant du coté des "pro", en raison de la généralisation des logiciels compatibles Soapy, extIOdll etc.

Coté ddc/duc, la question ne se pose même pas : c'est open ou rien, nada, nichts. Et si possible dans le respect des trucs déjà proposés par l'OpenHPSDR (même si le code fait hurler certains, s'ils hurlent, c'est qu'il peuvent au moins le lire, libre à eux de le ré-écrire) . Et comme les tarifs des équipements, même construits "depuis le composant", est un peu plus élevé que les superhétérodynes, acheter du Flex "tel que" revient à se tirer une balle dans le pied (et je ne mentionne même pas les équipements japonais qui sont de véritable systèmes d'enfermement et d'aliénation volontairement consentie) 

Pour le reste, effectivement, dès que l'on sort du domaine des SDR de type DDC et que l'on renoue avec un héritage superhétérodyne, il faut s'attendre à une réception pourrie de produits de mélange, et le seul remède demeure un filtrage énergique, soit interne, soit doublé d'un frontend externe, qui alourdit l'architecture.

Si ça peut consoler, dans certains cas heureusement statistiquement assez rares, il est parfois nécessaire de filtrer "aussi" un DDC (broadcasts proches, malades du kilowatt mal maitrisé et autres émissions baveuses). Mais c'est rare... si l'on est éloigné des grandes villes, les bpf à là papy sont des trucs qui appartiennent au passé. Du moins dans le domaine amateur. 

 

Marc

Modifié 27 juin par F6ITU