jks

About

Username
jks
Joined
Visits
27,720
Last Active
Roles
Member, Administrator, Moderator
Points
203

Reactions

508Helpful462Awesome

  • ADC Clock Frequency Correction via GPS Timing

    jksjks
    The ADC clock counting occurs before the DDS and is unaffected by any tuning compensation. You're correct, the "slightly off" sample rate derived from the division of the ADC clock is not corrected. But it doesn't matter. You just want to fix the downstream effects of the sample rate being slightly off. Namely getting the waterfall to look "on frequency" and the audio to produce the exactly correct tones. If you can determine what the exact, slightly off, constantly changing sample rate is using the GPS then this should be similar to having used a very expensive TCXO/VCTCXO with no GPS involved at all. Fixing the tuning completely compensates for the sample rate being off.

    The 48-bit counter in the FPGA, clocked by the ADC clock and sampled by the GPS, is very similar to a traditional frequency counter. If the gate time of the counter is known to be accurate then the ratio of the counter to the gate time gives you the frequency: ADC_clk (Hz) = ADC_count / GPS_gate_time, where Hz is "counts" per second and GPS_gate_time is the difference between two GPS time samples measured in seconds. Another way:

    ADC_clk (counts)   ADC_count (counts)             1
    ---------------- = ------------------- X -------------------
            (sec)                            GPS_gate_time (sec)

    The software GPS in the Kiwi doesn't even have a 1 PPS. It produces a new GPS position/time solution every 4 seconds or so and GPS_time is simply the difference between two successive solutions. Since both solutions are accurate to roughly a microsecond the "gate time" is accurately known. There is one more thing required. In the FPGA the ADC clock counter is sampled simultaneously when the GPS hardware that determines a solution is sampled. So the sampling is synchronized.

    MikeR

  • v1.95 release: new admin page features

    jksjks
    v1.95 adds two new features to the admin page (e.g. kiwisdr.local:8073/admin)

    The sdr.hu tab has a new multi-choice menu for entering the domain name or ip address of the Kiwi. There continues to be some confusion about what exactly is required for this entry. Hopefully the new UI will give a little more guidance.


    image


    The network tab has a new dialog to help check that the Kiwi can be reached by the URL setup in the previous step. This also checks that the external port in your router has been successfully opened to let Internet users contact the Kiwi. This can be used to help debug problems with incorrect setting of the router NAT entry or port blocking by the ISP.

    image

    f1jek

  • Nice email from a listener

    jksjks
    I received this email just now:

    Good afternoon. I was hoping you could relay a group message to all those currently providing remote access on SDR.hu

    “I would like to extend my deep appreciation to all the remote providers. The service you provide has given me countless hours of enjoyment. Unfortunately, I am not in a position to purchase my own equipment. Possibly, one day in the future.

    The remote providers continue the amateur radio enthusiast’s exemplary commitment to public service.
    Thanks again for providing this wonderful service. The time, not to mention expense, required to provide this service, has not gone unnoticed.”

    rickf
    Hilliard, OH, USA
    WA2ZKDKA7UBjarneTonda

  • I keep getting a "connection refused" message in the browser [software install issue]

    jksjks
    Hi Bill,

    If your public ip is static (unchanging) then yes, you can use that in the domain name/ip address field on the sdr.hu tab of the admin page. If your ISP provides you a dynamic public ip then you have to use a DDNS service as we describe here: http://kiwisdr.com/quickstart/index.html#id-net-duc Some people who own their own domain use that domain name, or a sub-domain, in place of a hardcoded ip address.

    There should be no risk to your LAN (I know, famous last words etc.) When you modify the NAT settings on your router to re-direct port 8073 packets from your public ip address to the local ip address of the Kiwi that should be all that is allowed. There should be no other inbound connections possible, like to other computers and/or ports. On the Kiwi, accesses to port 8073 only transfer files associated with the Kiwi user interface and setup communication with the Kiwi server (i.e. audio and waterfall). There is nothing else that should be a risk. The Kiwi server might have its own security problems (it has in the past) where an attacker could crash it or change the configuration. But this should be confined to the Kiwi software alone and not a threat to your LAN.


    wjniemi

  • Bad parameters ?

    jksjks
    Yes, anytime the sound or waterfall processes receive an unrecognized command on the web socket stream a message is logged. But there is also a bug I recently fixed where _any_ command received after the server thinks the connection is "closed" is logged. This is incorrect and there will be a fix in the next release. You will occasionally see random stuff logged. Unless it is causing you a problem you should not worry about it.


    f1jek