F6ITU

SDR4Net, coller un SDR antique sur réseau Ethernet

3 messages dans ce sujet

Ploum ploum

Personne ne semble avoir déjà mentionné sur ce forum le récent lancement d’une campagne de financement participatif destiné à industrialiser SDR4Net https://www.indiegogo.com/projects/sdr4net-networking-your-homebrew-sdr-transceiver-radio#/. Une oeuvre signé Christos SV1EIA, qui est déjà connu pour sa version de PowerSDR et sa carte audio USB2SDR

J’entends déjà l’admin du forum râler en me faisant remarquer « ouai, c’est du commercial, faut pas en parler dans la section Homebrew ».

Certes

Mais c’est plus l’idée que le produit qui est intéressante (ou pas).

En gros, il s’agit d’une interface située entre n’importe quel SDR type I/Q à conversion directe (softrock, YU1LM, UHFSDR, KX3 et j’en passe), et qui, au lieu d’expédier ce signal I/Q vers une carte son d’ordinateur, la saucissonne et l’encapsule dans une trame Ethernet (802.1), protocole IP, couche applicative Metis,  la même que celle utilisée par les HPSDR, Hermes, Anan, Hermes lite… bref, du solide, éprouvé et répandu (et accessoirement open source). Il y a de véritable morceaux d’intelligence et de travail là-dedans.

Du coup, les ribambelles de vieux nanards à mélangeur de Tayloe que l’on s’est construit au fil des ans peuvent être extirpés des poubelles, branchés sur un réseau local, partagés éventuellement entre plusieurs usagers (les contesteux vont bicher comme des poux), utilisant ainsi un client léger standard : client pour GHPSDR-3 Alex, OpenHPSDR, HPSDR-IQ, QTRadio, cuSDR… j’en oublie certainement. Et accessoirement, utiliser une kyrielle de codecs et autres outils de décodage logiciels sans avoir à s’enquiquiner avec des boitiers externes, des câbles exotiques, des adaptateurs de niveau. 

avantages :

-       -    recyclage et exhumation de SDR techniquement dépassés mais toujours performants si l’on se contente d’un spectre d’écoute étroit (192kHz) mais avec une dynamique plus qu’acceptable (24 bits d’échantillonage, soit 140 dB à la louche, bien que cet argument soit discutable).

-        -   Cohabitation avec des appareils de classe DDC/DUC (Anan, Hermes lite, Red Pitaya) avec un client universel -pratique pour ne pas sacrifier un transceiver genre Angelia pour faire de la mesure de propag en JT65, que peut très bien assurer un simple softrock)

-       -    Plus de transceiver dans les pattes et sur les étagères : au fond du grenier, au cul des antennes éventuellement. Ca va simplifier le rangement du shack

-  - socle protocolaire open source

Inconvénients :

-          -  Son prix (wesh, 400 euros tout de même, 4 fois le prix d’un softrock)

-         -  Perfs limitées, même si le «front end » est gonflé aux stéroïdes anabolisants (softrock avec mobo par exemple).

-          - Pas compatible « J16 », le standard de commande de commutation de filtres du TAPR (ce qui nécessiterait de toute manière une refonte de certains SDR)

-         -  Concurrent des SDR2Go et autres stm32sdr qui sont plus appréciés -car moins couteux- et renouent avec la vieille marotte du « SDR sans ordinateur »  (une ineptie à mon humble avis)

 - développement hard et firmware closed source et lié à la bonne volonté d'un développeur unique. 

p  - pas de version " à monter" qui incite à réfléchir... c'est encore une bidouille génération "je branche et je demande pourquoi le soft y marche paaaaaaa passke je comprends pas comment ça maaaaaarche" (à quelques exceptions, bien entendu)

-    - arrivée sur le "marché" pour bidouilleurs de véritables transceivers DDC/DUC qui sont "natifs Ethernet", qui envoient aux orties cette horreur qu'est le bus USB, et qui, pour un prix inférieur, offrent entre 12 et 14 bits d'échantillonnage entre 60 et 120 megasamples par secondes. Donc, entre "continuer à utiliser une techno du siècle dernier" quoi qu'il en coûte, et commencer à jouer avec des fpga, des ADC rapides et des cms en 0805 ou 0402, pour un prix inférieur à 200 euros, il y a un choix à faire. Vintage or not vintage. 

.... on peut également avoir un compte en banque confortable et s'engager dans un plan d'investissement visant à faire cohabiter les deux technos, Tayloe et DDC/DUC. Mais ce coté "chef d'oeuvre en péril" ne me convainc pas totalement. Exception faite des possesseurs de KX3, ces softrock montés en graine, je ne vois pas trop qui cela pourrait intéresser.

mes deux centimes

Marc

 

 

 

 

 

 

Modifié par F6ITU

Partager ce message


Lien à poster

En effet Marc, ce produit arrivera bien tardivement sur le marché et à un coût disproportionné, mais why not.

On peut faire la même chose avec une carte Odroid à 40 euros, une carte son usb trouvée sur ebay pour qq euros de plus, et, il faut le reconnaitre, un peu (voir beaucoup) de temps libre pour configurer linux et ghpsdr3-alex dessus....ce dernier dispose d'un serveur, et de 3 clients, sous Linux, Windows et Android. J'ai fait qq qso autrefois depuis mon mobile android connecté en WIFI, puis en téléphonie 3G (ou moins, en pleine rue !) sur le serveur ghpsdr+softrock depuis l'autre bout de la France. Cà marche , mais avec une audio critiquable en émission. Le projet de Chistos serait intéressant s'il pouvait re-travailler les codecs pour une meilleure audio. L'absence de compatibilité J16 est une erreur marketing. On lui souhaite bonne chance.

73

Partager ce message


Lien à poster

Bonjour Pascal

La situation évolue... Christos n'est pas opposé à une version "lite" à moins de 200 euros, sans affichage (très secondaire en fin de compte). Reste à savoir si les OM Français sont partants (si cela en intéresse certains, qu'ils le fassent savoir, soit directement à Christos SV1EIA, soit en m'envoyant un "ping" que je transmettrais).

Pour l'instant, les quelques OM que j'ai interrogé et qui possèdent un QSD/QSE ne sont pas très chauds, car ils comparent le prix de cette interface avec celui attendu du Hermes lite V2.0  (200 euros environ) ou du Red Pitaya (240 Euros, moins cher pour les "elektor members"). "Tant qu'à faire, je préfère oublier l'UHFSDR et me plonger dans les DDC/DUC" m'a dit l'un d'eux.

L'option GHPSDR3-Alex, qui fait strictement la même chose avec un Odroid ou un vieil ordi de récup, est bien évidemment intéressante. Reste que le code évolue et peut faire peur à des gens qui n'ont pas l'habitude de jouer à "je compile mon code comme un grand". Entre le how-to que j'avais écrit il y a 5 ans (déjà !) et aujourd'hui, il a du passer une bonne vingtaine de releases et modifs diverses, et les conseils de l'époque sont totalement dépassés. Je reconnais que ça puisse en décourager quelques-un. (au passage, je ne l'ai utilisé qu'en "local cuivre", et n'ai pas franchement rencontré de gros problèmes... mais coté client, QT est assez capricieux selon les versions). 

Ensuite, le choix du soft client conditionne pas mal de choses. La solution de Christos permet d'utiliser le très populaire PowerSDR en remote sur un vieux softrock ou UHFSDR, voir cuSDR, OpenHPSDR sous Android (marche sacrément bien), voir KissConsole ou PiHPSDR que John Melton vient de sortir. Y'a du choix.

Une solution GHPSDR-3 Alex offre QtRadio, glSDR... tout le monde n'aime pas nécessairement

Pour ce qui concerne J16, je comprends la position de Christos. Sur des transceivers de cette génération, beaucoup possédaient déjà un système de commutation de bpf dérivé de la commande I2C pilotant le Si570. Softrock avec mobo 6.3 (atmel intégré), SDR de tous types pilotés soit par une SDR-Widget, soit par la carte de Christos USB2SDR (4 bits de sortie pour les filtres), idem pour ceux qui utilisent l'USB Bit Whacker d'Alex Lee... et je mets de coté les SDR2Go et STM32SDR qui ont également une sortie "commande filtre". Beaucoup d'ailleurs utilisent les appels de code de DG8SAQ qui permettent de paramétrer les "crossover point" des filltres. C'est donc un standard assez répandu à sa manière.

Mais effectivement, tirer 7 bits "J16" du processeur ARM qu'il envisage d'utiliser, c'est pas franchement insurmontable. Au pire, ça bouffe une sortie et un registre à décalage s'il est limité coté I/O. 

Dans tous les cas, affaire à suivre... et si quelques autres OM pouvaient donner leur avis, ajouter leur grain de sel, ce serait assez intéressant. On parle trop peu d'architectures des SDR et des problèmes de standardisation sur les ML Françaises

73'

Marc

 

Partager ce message


Lien à poster

Créer un compte ou se connecter pour commenter

Vous devez être membre afin de pouvoir déposer un commentaire

Créer un compte

Créez un compte sur notre communauté. C’est facile !


Créer un nouveau compte

Se connecter

Vous avez déjà un compte ? Connectez-vous ici.


Connectez-vous maintenant