jks

About

Username
jks
Joined
Visits
36,223
Last Active
Roles
Member, Administrator, Moderator
Points
638
  • v1.190: keyboard shortcuts, IQ display mPSK, FAX alignment, DX label features

    Lots of changes.

    Keyboard shortcuts is a work-in-progress. Press "h" or "?" on your keyboard. Feedback requested, especially from our visually impaired users.

    The mPSK stuff needs a separate discussion. Try QPSK mode with VLF MSK or LF DGPS signals and 8PSK mode with strong, non-fading STANAG 4285 signals on HF.

    FAX: the entire image will now align on shift-click including the part of the image already received. On mobile devices a touch on the image will cause an align.

    More info: https://github.com/jks-prv/Beagle_SDR_GPS/blob/master/CHANGE_LOG

    VK3KHZ
  • v1.188: switching compilers from gcc to clang

    Today's update switches compilers from gcc to clang. This means in the future update builds will run about twice as fast.

    But today's build will take some time as the new compiler is downloaded and installed. Total update/build time will be approximately 15 minutes.
    It is extremely important that you do not interrupt this process and potentially leave your Kiwi in a partially updated state unable to run or update further (i.e. "bricked").

    WA2ZKD
  • kiwid restarts after assertion failure in support/coroutines.cpp [fixed in v1.184]

    Thanks for reporting this. As you can see I added some additional debugging in the latest release (the "ca_pause -1594 ..." stuff).

    I added the assertion a little while ago to make sure a hardware (FPGA) constraint wasn't getting overrun. If it is then a sat that is acquired may not be tracked properly. And we see this behavior sometimes. But this assertion has never occurred in my testing (or at least I've never caught it happening). So if I can understand what's going on and fix a bug this might result in greater tracking successes which would be very helpful.

    UR5VIB
  • kiwid restarts after assertion failure in support/coroutines.cpp [fixed in v1.184]

    Okay Ivan, I've got a fix running on your Kiwi and so far it looks good. I was able to write some test code for my Kiwi that caused the assertion failure to occur. So I'm pretty sure that the bug I fixed is really the source of the problem. I'm not sure why it happens so often with your Kiwi. The problem occurs when the GPS acquisition task is started and stopped as the number of user connections changes between zero and greater than zero. That is the only case that uses a special case of the coroutine task sleep/lock code.

    I'll include this fix in the next update.

    UR5VIB
  • Is it possible to transform kiwi sdr on Xilinx Zynq FPGA a single chip solution [for GPS only]

    Well, you're just going to have to get in there and start checking things.

    I would start by seeing if the e_cpu firmware is sending data correctly to the C code. I'm not sure exactly what codebase you're using. So adjust what I say here to match what you have. In gps.asm change the UploadSamples routine to return a constant pattern instead of data from the FPGA and see if you get this pattern on the C code side. Replace the "wrEvt GET_SAMPLES" with the two instructions "push 0x1234" and "wrReg HOST_TX". Then in search.cpp where the "spi_get(CmdGetSamples, &rx, PACKET)" happens print out rx.word[0] and look for the 0x1234 (it might be byte swapped).

    If that looks ok put gps.asm back the way it was and change the FPGA code to send a constant pattern. In sampler.v send a fixed pattern on dout[15:0] instead of the output from the RAMB16_S1_S4. Say something like "dout <= 16'h1234" inside a "always @ (posedge clk)" block.

    Does the output of your hard limiter sort of look like the output of the SE4150L as shown in the Kiwi troubleshooting guide? http://www.kiwisdr.com/ks/troubleshooting.pdf
    You should always see transitions in the IF signal, even if no antenna is connected.

    Speaking of the antenna. Are you sure you are presenting enough sat signal to the gp2015? Are you using an active antenna and supplying bias voltage on the cable? Are you using too much lossy cable (e.g. rg174) that would result in too weak a signal at the chip? This is extremely important. See here: http://freqelec.com/gps_gnss/gps_ant_issues_r1_5-07.pdf

    jackobian