Jump to content
Sign in to follow this  
F5OWL

linhpsdr : offset rx en CW ?

Recommended Posts

F5OWL

Bonjour,

J'utilise depuis peu linhpdsr avec une carte redpitaya 14 bits non modifiée juste précédée d'un transformateur élévateur d'impédance.

ça marche très bien en SSB mais j'ai un problème avec le mode CW (U ou L). Pour entendre un signal je suis obligé de me décaler de la valeur "side tone frequency".

En plus ou moins selon CWU ou CWL.

Ce qui fait que l'indication de la bande passante (en gris) est décalée par rapport au signal reçu. ce n'est vraiment pas pratique.

Avec GQRX j'ai le signal bien au milieu de la bande passante.

J’utilise la dernière version du dépot git, compilée sous ubuntu 20.04. Comme c'est déjà ancien je suis étonné que personne n'ai vu le problème.

Est ce que j'ai loupé quelque chose dans la configuration ou lors de la compilation ?

73,

Philippe

image.png.9564128db46edbad37cd476ee531020b.png

 

 

Edited by F5OWL
correction du titre

Share this post


Link to post
F6ITU

Bonsoir Philippe

Je vais tenter de reproduire la chose de mon côté. 

Avez vous tenté de joindre John Melton à ce propos ? ses travaux sur LinHPSDR sont relativement sporadiques, et il n'a pas touché au "code principal" hormis pour ajouter le support de radioberry et de Soapy... Ce qui fait que même les plus inconditionnel ont plus ou moins relégué ce soft. "Belle Philis, on désespère, alors qu'on espère toujours" 

Pour ma part, sous les Unix-like, je n'utilise plus que Quisk, PiHPSDR, Spark et GRC. Sous Windows, Thétis, Spark, Quisk, SDR Console et kiss konsole. Je n'ai plus retouché à un soft de John (HPSDR Android, LinHPSDR, GHPSDR) depuis plus de 2 ans, Pihpsdr mis à part 😞 

73++ 

Marc

PS : de toutes les modifs de la RP14, c'est vraiment celle concernant l'alim de l'ADC qui est la plus importante

https://wiki.electrolab.fr/Projets:Lab:2018:Red_Pitaya#Troisi.C3.A8me_modification.2C_l.E2.80.99alimentation_de_l.E2.80.99ADC

entre celle-ci et s'enquiquiner à réaliser l'adaptation d'impédance du transfo d'entrée, il n'y a pas a hésiter. C'est 10 dB de mieux sur le plancher de bruit

 

Share this post


Link to post
F5OWL

Bonjour,

Merci pour votre réponse. C'est d'ailleurs grâce à un de vos messages que j'ai découvert ce soft.

Je vais essayer d'ouvrir une "issue" sur github mais comme c'est une fonctionnalité assez basique, je me disais que ça avait plus de chance que ça vienne de moi qui utilise mal la chose.

Si on veut rester sous linux il y a moins de choix de soft et il faut reconnaître que linhpsdr est vraiment pas mal si on veut exploiter plusieurs récepteurs.

Sinon j'utilise GQRX plus simple mais un seul récepteur.

Tous ces logiciels SDR sont pleins de possibilités mais ne sont pas vraiment prévu pour le trafic bête et méchant. Je comprends que les dxeur/contesteur en restent aux interfaces classiques.

Pour l'instant je n'ai pas modifié la redpitaya car elle ne m'appartient pas. Nous avons acheté ça au boulot pour un projet qui n'a pas abouti.  Comme elle dormait dans une armoire, je me suis permis de l'utiliser.

On verra si on est certain de ne plus l'utiliser je pourrais la modifier. Mais pour l'instant je trouve que c'est déjà très bon out of the box. En tout cas incomparable avec un RSP1A que je possède et pour lequel des radiodiffusions apparaissent un peu partout.

Le transfo d'entrée a nettement amélioré la sensibilité sur les bandes hautes même si ça me semble manquer encore un peu sur 24 et 28 (par rapport à mon TS590).  je l'ai fait sur une carte annexe avec deux SMA donc sans toucher à la redpitaya.

J'ai écrit un petit soft pour synchroniser GQRX avec mon TS590 (via rigctld). ça me permet d'émettre avec le TS590 et de recevoir avec la RP (et ou le TS) : https://github.com/parlotto/gqrx-hamlib2

ça permet aussi de changer de mode plus facilement en utilisant les boutons du poste et aussi d'utiliser la fonction auto-tune en CW.

J'ai fait une autre version avec interface graphique qui permet de couper la synchro pour faire une sorte de split et de recaler automatiquement GQRX sur un pas de fréquence donné (5kHz pour l'écoute broadcast, 8.33 en aréro,...) (trop alpha pour mériter d'être sur github).

Je pense faire la même chose avec linhpsdr. c'est possible mais un peu plus compliqué car le pilotage se fait à plus bas niveau (commande CAT du TS2000 au lieu de hamlib).

Je suis très intéressé si vous pouvez reproduire le problème de décalage.

73 Philippe

 

 

Edited by F5OWL

Share this post


Link to post
F5OWL

Bonjour,

Je crois qu'il y a bien un bug.

J'ai annulé le décalage dans le fichier radio.c :

void frequency_changed(RECEIVER *rx) {
  if(rx->ctun) {
    gint64 offset;
    rx->ctun_offset=rx->ctun_frequency-rx->frequency_a;
    offset=rx->ctun_offset;
  /*  if(rx->mode_a==CWU) {
      offset-=(gint64)radio->cw_keyer_sidetone_frequency;
    } else if(rx->mode_a==CWL) {
      offset+=(gint64)radio->cw_keyer_sidetone_frequency;
    }*/
    if(rx->rit_enabled) {
      offset+=rx->rit;
    }

Avec cette modif l'indication de la bande passante (en gris) est  bien calée par rapport au signal reçu.

Le problème c'est que quand on clique sur un signal cw la zone grise se décale de l'offset !

Quelques recherches me conduisent dans le fichier receiver.c et là on voit que dans le cas du mode CTUN l'offset n'est pris en compte :

void receiver_move_to(RECEIVER *rx,long long hz) {
  long long delta;
  long long start=(long long)rx->frequency_a-(long long)(rx->sample_rate/2);
  long long offset=hz;
  long long f;
  if(!rx->locked) {
    offset=hz;
    f=start+offset+(long long)((double)rx->pan*rx->hz_per_pixel);
    f=f/rx->step*rx->step;
    if(rx->ctun) {
      delta=rx->ctun_frequency;
      /* mon ajout */
      if(rx->mode_a==CWU) {
          f=f+radio->cw_keyer_sidetone_frequency;
        } else if (rx->mode_a==CWL) {
          f=f-radio->cw_keyer_sidetone_frequency;
        }
      /* fin ajout */
      rx->ctun_frequency=f;
      delta=rx->ctun_frequency-delta;
....

Si j'ajoute le décalage de la valeur du side tone : BINGO ça marche !!

image.png.04b42f884746386ae4db366d25b8ce1f.png

En l'état ça me convient mais je n'ai peut être pas mesuré toutes les implications de mes modifs.

Si ça se tient je soumettrai mes suggestions sur le dépôt git.

c'est pas beau l'open source ?

Philippe

 

Edited by F5OWL
erreur dans le code c
  • Message intéressant 1

Share this post


Link to post
F6ITU
Le 01/11/2020 à 21:15, F5OWL a dit :

..c'est pas beau l'open source ?

🙂 

Bravo. Sincèrement. 

oui, le "bug" (ou le défaut de conception) est reproductible de mon côté (réinstaller Linhpsdr avait un goût sacrément nostalgique). Et à part jouer du décalage réception, il n'y a aucune autre astuce hors le patch du code. 

Ca mérite effectivement une soumission de modif, peut-être que ce pourrait même inciter John à reprendre son développement. 

En fait, il avait été question d'utiliser le socle Linhpsdr pour y intégrer d'autres code du même auteur, notamment la fonction "remote" de son ancien GHPSDR. Annonce faite il y a bien 5 ans, et je suis toujours comme soeur Anne. C'est vraiment dommage, car seul un SDR est capable d'expédier ses paquet I/Q et ses signaux de contrôle périphériques dans des trames IP, offrant ainsi la possibilité d'avoir l'intégralité des fonctions d'un émetteur-récepteur haut de gamme sur le client distant (et ce, sans déployer d'usine à gaz). La seule chose qui manque, c'est un bloc de gestion de la QoS qui adapte le spectre échantillonné en fonction de la bande passante réseau utilisable.

Pour les contesteurs, John avant fait la démonstration d'un réseau de PiHPSDR concentrés sur un seul SDR, capable de deux émissions simultanées (une par DAC bien sur) et 9 récepteurs... la parfaite usine à "multi". C'était plus un PoC qu'autre chose

73++ 

Et encore bravo... je laisse mon LinHPSDR installé 🙂 

Marc

 

 

Share this post


Link to post
F5OWL

Bonsoir,

Merci d'avoir réinstallé le soft juste pour moi.

En fait avec ma modif ce n'est pas encore parfait.

ça ne marche que dans le mode CTUN. c'est le mode que je préfère : le spectre vu est fixe et on déplace la fréquence reçue.

Dans l'autre mode la fréquence reçue est toujours au centre et là ça ne marche pas bien en CW.

J'ai encore du mal à comprend la logique du code mais il y a plein de cas particuliers avec CWL et CWU preuve que ce n'est pas simple.

J'ai découvert d'autres bugs (ou comportement étrange) avec le SUBRX.

J'ai fait mon fork sur github et je ferai un pull request quand ça sera plus abouti.

J'ai pas mal joué avec gnuradio et autres mais en V/UHF avec des pluto, rtlsdr, RSP1A et hackrf mais plutôt pour du hacking et de l'expérimentation que pour trafiquer.

Je découvre le SDR en bande HF pour faire vraiment du trafic.

Et je crois que je ne reviendrai pas en arrière... Même si pour l'instant je me limite à une fonctionnement hybride : redpitya en RX et TRX classique en TX.

C'est une solution de flemmard qui m'évite d'avoir à monter un ampli et des filtres et qui va bien pour mes activités radio en mode détente : trafic CW, quelques contest CW et écoute utilitaire en HF.

Pour cette dernière activité c'est royal : la surveillance d'un large spectre est bluffante. Les stations CW militaires se repèrent quasi instantanément.

Et je peux laisser un récepteur en surveillance sur une fréquence et continuer avec un autre. Au bout d'un moment ça devient tout de même dur de ne pas s'y perdre avec toutes ces cartes sons...

Avec GQRX ça marche bien mais je n'ai qu'un récepteur à la fois. Par contre le système de bookmark de GQRX est plus sympa car les stations déjà identifiés apparaissent sur le waterfall.

J'ai aussi tout plein de balise 10m. En un coup d’œil je peux connaître l'état de la propagation. Je n'ai pas réussi à avoir ça sur linhpsdr.

image.thumb.png.8c6837e32659259cc2ae90a89aadc5e2.png

Je n'ai vraiment pas tout essayé mais je crois que les softs SDR libres sont plutôt fait par des hacker/expérimentateur et ne prennent pas vraiment en compte les

besoins de ceux qui veulent juste utiliser leur radio. Il y a souvent d’innombrables possibilités de configurations mais rien de vraiment pratique et rapide.

Par exemple avec SDR angel vous pouvez faire plein de choses sympas mais c'est super galère de passer de AM à USB : il faut enlever le demod AM et ajouter le démo USB.

Sur un poste classique ça prend une seconde.

LinHpSDR me semble être un bon compromis. Quand j'aurais écrit le petit bout de soft pour le synchroniser avec rigctld, je pense que j'aurais ce que je recherche. le meilleur des deux mondes.

 Affaire à suivre...

73 et merci pour vos posts sur les différents projets SDR qui nous permettent de nous tenir au courant de l'évolution de notre hobby.

 

Share this post


Link to post
F6ITU

Bonjour Philippe

Le problème de l'émission sur un SDR, c'est que c'est un terrain encore plus addictif que celui de la réception. La qualité d'émission est remarquable, les mécanismes de prédistorsions totalement bluffant. Je n'ai toujours pas eu le temps de jouer avec EER en "grandeur nature" (autrement dit avec autre chose que des IRF510 qui offrent le meilleur rapport claquage/enseignement/prix) mais je compte bien m'y atteler un jour avec de véritables transistors HF. Et les quelques tests avec GRC pour faire de l'émission numérique "data"  bande large sur 100 ou 200 kHz de bande passante sont sacrément encourageants. 

je n'ai jamais tenté de voir si SparkSDR pouvait reconnaitre une Red Pitaya. C'est un soft sacrément intéressant pour monter rapidement une station FT8 octobande pour littéralement "voir" se lever la propagation et se déplacer la greyline, constater l'éveil ou la disparition d'une bande... c'est magique. 

je suis intimement convaincu qu'il n'y a rien de mieux qu'un transceiver "bande de base" pour le hacking et l'expérimentation. Que ce soit en échantillonnage direct ou via quelques transverter. Plusieurs raisons à ça

- on "sait" ce qui est susceptible de provoquer tel ou tel artefact, tel ou tel oiseau , et l'on peut y remédier, ce qui est plus difficile sur un sdr UHF truffé de changements de fréquences

- le spectre offert est considérablement plus large que les plateformes orientées hacking, la dynamique est monstrueusement plus importante, les erreurs de quantification plus faibles... 

- ... et c'est un outil de vulgarisation formidable pour l'éveil au reverse de signal (ne serait-ce qu'en jouant sur les whatdouzmill machins RFID qui se promènent sur 13 MHz) 

 

j'admets toutefois que pour aller plus vite, j'ai toujours un hackRF ou un Airspy sous la main. Mais une Red Pitaya ou un Hermeslite (sans même mentionner un Hermes "plein") comme fréquence intermédiaire de qualité derrière un transverter un peu soigné, c'est tout de même plus "propre" coté spectre. 

😄 

73'

Marc, (vendeur de drogues dures)

Share this post


Link to post
F5OWL

Bonjour,

Je suis au boulot alors je répond rapidement...

C'est vrai que l'émission data large bande c'est impossible avec un trx classique.  Je commence à découvrir que ça existe en HF aussi où on voit des signaux couvrant 30kHz voire plus.
Le FT8 c'est pas trop mon truc. C'est dommage de mettre autant d'intelligence dans un truc aussi vain. Feraient mieux de développer des transmissions de DATA rapide en HF par exemple.

Au moins ça sert de balise.

Vrai également que la redpitaya (c'est le seul SDR à échantillonnage direct que j'ai essayé) n'a absolument rien à voir avec les RSP1A, hackRF et autre. Il n'y que les signaux qui sont vraiment là.

Avec le RSP1A il y a toujours une radiodiffusion qui traîne sur des fréquences où elle n'ont rien à faire....

Pour l'instant , je vais essayer de passer un peu de temps à essayer d'améliorer linhpsdr.

73,

Philippe

Share this post


Link to post
F5LOL

Si ca peut aider, voilà comment se comporte un transceiver normalement constitué en LSB, USB et CW (basé sur le FT1000 MP) 

USB LSB décalages.pdf

Share this post


Link to post
F5OWL

Bonjour,

Oui c'est simple on affiche toujours la fréquence de la porteuse. Pour l'instant en SSB l'affichage est bon.

J'utilise RWM sur 4996 kHz dont on peut être certain de la fréquence.

En CW c'est maintenant bon le battement et l'affichage de la bande passante sont ok (en mode CTUN)  mais l'affichage de la fréquence n'est pas bon.

J'ai un décalage de deux fois la valeur du sidetone. 4997.2 = 4996 + 2 x 0.6

Y a encore du boulot...

image.thumb.png.205f36b0921570bedee0e926096648a9.png

 

 

image.png

Edited by F5OWL
deux fois l'image

Share this post


Link to post
F5OWL

Bonjour,

J'ai corrigé l'affichage (en mode CTUN uniquement pour l'instant). Je n'arrive pas à comprendre pourquoi je dois me décaler de deux fois la valeur du sidetone.

Une fois je veux bien mais deux ? Je dois avoir fait quelque chose à l'envers.

Mais ça marche... jusqu'au prochain bug.

Il y a encore pas mal de truc à régler. Le changement de mode vers USB n'est pas naturel, normalement on change la fréquence affichée mais pas la fréquence reçue. Là tout change...

Il faut aussi régler le cas du mode non CTUN.

La modif sur github : https://github.com/parlotto/linhpsdr

J'arrête pour ce soir maintenant un peu de CW pour se détendre.

73,

Philippe

Share this post


Link to post
F6ITU

je descend otut ça illico illico 🙂 

... je me demande si je vais forker 😄

Merci encore

Marc

Share this post


Link to post

Please sign in to comment

You will be able to leave a comment after signing in



Sign In Now
Sign in to follow this  

×
×
  • Create New...