NB Station for Es'hail-2

  • Jan PA0SSB made a hardware version of this method. He uses an old DRO LNB for reception. In his shack he generates a reference signal (12.8 MHz TCXO) which is multiplied (with varactors etc) to somewhere around 10.x GHz. This indoor signal is pointed to his dish outside (into the LNB). On the IF side you've two (instable!) signals but stable relative to each other. He amplifies the reference signal, mixes this with the wanted signal (the RX signal) ... and there you go!

  • Do you have an sd image of your solution to test it ?

    After opening of the NB transponder i am currently working on further detail improvements and testing of the software. Unfortunately it will take a while. But i am optimistic to make an image for first "beta" tests as soon as possible ;-)

  • DL3DCW : Is your code available yet. I'm trying something similar in Gnuradio, but running into performance issues when I scale to the level that fldigi needs (Probabaly me trying to be too clever!)


    I'd like to compare the techniques, and maybe get some ideas as to what you are doing differently to me



    73s


    Iain

  • I have started to build some program to do this type of stabilization, and what I already have now is a big improvement in handling of the station already.

    It is a program that I use in a small window alongside GQRX on Linux, it displays the current LNB LO and Rx frequency and when I hit a key it switches to either beacon, I can tune that to a predefined audio frequency (in the audio spectrum/waterfall subwindow) and hit another key. It then re-calculates the LNB LO according to the tuning done and switches back to the frequency where I was tuned.

    During listening I can also keep the frequency of the received station OK using left/right arrows and it will tweak the LNB LO setting so the indicated station frequency remains the same.

    The next step will be some automated tuning. The problem is that GQRX has only a single virtual receiver, so I cannot keep a receiver tuned to the beacon. However, that should be possible to add as it is built on GNU Radio.


    I also have a key that instantly transfers the tuned receive frequency to the corresponding Tx frequency on the FT-817 used for uplink via CAT. Much more convenient than whistling and watching the sweeping carrier on the waterfall!

  • g7iii


    My modest raspberry drift correction solution is very simple because it is not the main component of the software. And I'm just a hobbyist. For drift correction, I scan a defined frequency range and search for maximum amplitude. For this I use the tool "rtl_power". The deviations correct the LO frequency of GQRX over the TCP remote interface.


    Unfortunately, it takes some time because I am not completely satisfied with these and the other features of the software. But I work on it every day in my free time ;-)

  • pe1chl


    GQRX sometimes has a slight frequency change of some 100Hz when I change settings or after restart GQRX. Or if I tune the frequency via the large frequency digits.


    This happens completely independently of my software and must be an issue of GQRX, the rtl_sdr driver or my SDR stick.


    Can you also observe that on your system?

  • I also have a key that instantly transfers the tuned receive frequency to the corresponding Tx frequency on the FT-817 used for uplink via CAT. Much more convenient than whistling and watching the sweeping carrier on the waterfall!

    Yes, CAT control of transceiver is a "must have". At first I used software UART via GPIO of my raspberry but sometimes it crashed. Now I'm using CP2102 USB/TTL converter and everything seems to be ok. One problem less ;-)

  • DL3DCW the frequency stability of my system is by far not good enough to observe that kind of behaviour...

    I normally tune by rolling the mousewheel while in the waterfall or spectrum (not in the frequency bar of course) and it works smoothly.

    Initially I was re-adjusting the LNB LO frequency manually via the "configure I/O devices" dialog when it had drifted too far, and when doing that it would forget the settings of the panoramic display.

    But now I am controiling it via the TCP port and this is no longer happening...


    I have one of those "special CAT cables" which comes with a USB serial converter and the mini-din plug for the FT-817. It is an FTDI chip which was programmed to look like special for some software package but using an FTDI tool I have re-programmed it to look like an ordinary USB serial and it shows as /dev/ttyUSB0.

    At first I had the trx constantly tracking the tuning, but then I remembered that Yaesu transceivers sometimes crash or even corrupt their settings when sent many many CAT commands so I changed it to only set the frequency when hitting a key.

    This is better anyway, as now I can tune the receiver while transmitting without risking to re-tune the transmitter. I even can do a re-calibrate while talking.

  • Ok, at the moment i transmit new TX frequency settings via CAT only if there are changes in RX frequency. I think the the biggest problem was bad timing during serial CAT commands depending of my software UART. With the CP2102 USB interface now it works fine. Since yesterday ;-)

  • At first I did that too, but of course "only if RX frequency changes" is quite a lot when you are tuning around the band, and it is kind of useless to make the TX track all that.

    Yaesu CAT is a dumb protocol and when timing works out incorrect all kinds of things can happen. There exist simple commands that say things like "erase all memories" and "return to factory initial settings" that you do not want the radio to execute, yet they are just 5-byte sequences of which only the last byte is significant, no checksumming whatsoever.

    So I prefer to limit the transmission a bit and hitting a key before transmitting is not much effort for me. For you with the touchscreen solution it may be different.

  • On 1201,5MHz (10951.5MHz) a strong Beacon signal can be found.


    Looks like it originates from Astra 2C on 23,7".


    I will test if it is stable relative to the EH2 Beacon and can be used as a reference for my software drift correction in the next days.


    vy73 DB8TF

  • Hi, nice project ,will it be possible to test/evaluate the software with CAT ?

    The program controls the FT817 transceiver via CAT (USB/TTL converter like CP2102) and the up-converter MKU2424 via RS232 (USB/RS232 converter like FTDI). PTT input (from the transceiver) and output (to the up-converter) is possible via the handshake lines. For the up-converter an additional NPN transistor is required. Receive only operation is also supported.


    The basic functions are given, but there are still errors. Because it's just a quick, stupid and dirty solution. Currently I am preparing a raspberry image with a very early experimental version. This version should only show how a possible solution may be can look like. Without any warranty and without support.


    At me it runs on a raspberry pi 3B+ with the official 7" touch display of the foundation. Other displays are possible. In this case, some adjustments may be required. SDR sticks with rtl-sdr support can be used as a receivers. Myself prefer the NooElec NESDR Nano3 with 0.5 ppm TCXO. Because they fit perfectly to the small raspberry.

  • DL3DCW

    Hello,

    you mentioned, that you have also a "remote conrol"-part for the MKU2424 via RS232 in your software.

    Is it possible to "isolate" this part as a stand alone application for the remote control of this device (e.g. on/off; temperature; FWD, REF...) ?


    Unfortunately I have not the capability to make such a program myself (yet).


    73 de Johannes, DL5RDI

  • Maybe later. Because remote control of MKU2424 is just a small "nice-to-have" and not the main part. In the moment the easiest way is to use it as it is. But you can feel free to delete all stuff in the source you dont want to use. And/or modifiy it like you want.