jks

About

Username
jks
Joined
Visits
29,788
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

  • V1.92 Fax decoder

    jksjks
    The fax code needs an external program to convert .pgm format files, which is what it records, to the .png file for download. I forgot to include installation of that program in the Kiwi makefile. I'll do that for today's release.

    I can change it to not disturb the initial frequency. I always changed to 7880 Hamburg because that was the best signal during development.

    You can always click the "mute" button while the fax extension is running. Not sure I want to make this the default behavior as it might confuse people. It could be a (future) user preference.

    G8JNJ

  • Single URL/bookmark can now open multiple windows/tabs

    jksjks
    In v1.83 you can now say, e.g. kiwisdr.local:8073/?ext=wspr,40m&mute&win2&ext=wspr,30m&mute

    G8JNJWA2ZKDLX1DQf1jek

  • 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

  • No possibility to upgrade [fixed in v1.88, caused problems with new Kiwis first upgrade]

    jksjks
    Okay, please "cdp" and then "up" to download, build and start the new v1.88 release.

    sq5m

  • NOAA FAX

    jksjks
    Because reception of HF fax is poor here in New Zealand I've had to use one of the Kiwi beta sites in Europe to get strong reception of DDH3 & DDK3/6 out of Germany. That image has contrast problems. It should be a well defined black & white. The open source fax code I found is kind of strange. I don't really understand it yet. Especially the FM demod section.
    KA7U

  • NOAA FAX

    jksjks
    Which computer? Computer running browser or Beagle? Can you define "other operations"?

    The Beagle is only meant to be running the Kiwi server and nothing else. There are critical realtime constraints that require Linux to get-out-of-the-way as much as possible.

    On the client computer if the browser/javascript doesn't get the required realtime response to keep up with the audio output demand then you'll drop audio samples and the fax will get shifted. This can be improved by making the Kiwi audio buffer in the browser larger. But then the latency gets longer, and a different group of people get upset with me, lol.

    KA7U