jks
About
- Username
- jks
- Joined
- Visits
- 32,614
- Last Active
- Roles
- Member, Administrator, Moderator
- Points
- 348
Reactions
-
kiwid restarts after assertion failure in support/coroutines.cpp [fixed in v1.184]
No, that shouldn't be related. There was definitely a bug in the task lock code for a special case. It's just that the case only ever occurs when the GPS acquisition is enabled or disabled as users make SDR connections. I was able to trigger the bug on my own Kiwi by artificially increasing the rate of occurrence of the special case. -
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. -
What is the status of the WSPR background and autostart features? [added in v1.181]
-
GPS: Galileo reception possible on Kiwi? [working as of v1.178]
-
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.pdfYou 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 -
GPS: Galileo reception possible on Kiwi? [working as of v1.178]
v1.177 is out with Galileo support. Not perfect, but good enough for some widespread testing.On the admin GPS tab the switch labeled "Plot Galileo?" determines if separate position solutions including Galileo, and not, are computed and displayed. But note that this only works if there are at least 4 sats of each category present (i.e. 4 Galileo, 4 Navstar/QZSS). On the new "Map" display different color pins will be used to show the differences. See the legend at the bottom of the map.Sometimes when Galileo sats are used the positions don't agree with Navstar/QZSS (i.e. the green and red/yellow pins will be spaced some distance apart). This may be due to the well known false-peak locking issue with the Galileo waveform. We are still implementing a solution for this issue. -
Is it possible to transform kiwi sdr on Xilinx Zynq FPGA a single chip solution [for GPS only]
Okay, you did not tell me this. So like Andrew's design you will have to follow the limiter with an ordinary D flip-flop in the FPGA to sample the data. Now you will have to carefully select the clock frequency for this D-FF. And this clock will also become the system clock for the rest of the GPS circuits and embedded processor.Andrew's scheme is this: After his mixer IF = 22.6 MHz. Then comes hard limiter. Then D-FF runs at 10 MHz which is also the system clock. So FS = 10e6, FS_I = 10000000 in the code. The D-FF under samples the 22.6 to produce 2.6 MHz as the final IF. So FC = 2.6e6 in the code.So for the gp2015 you have IF of 4.309 MHz. Now you must sample with a D-FF. The gp2015 does this with a 5.71 MHz clock to produce a final IF of 1.405 MHz. If you use something else, like 10 MHz, you would get 10 MHz +/- 4.309. The difference term would be 5.691 and you can set FC to that. Then it should work. -
GPS Antenna aiming
I've been using this site to see when Galileo sats will appear in my antennas limited field-of-view: https://www.n2yo.com/whats-up/?c=22You can see from the orbital tracks why the shadow hole exists if you're located close enough to the poles. From the north pole all GPS sats would appear biased toward the south.Here's a great animation of various satellite orbital heights: https://upload.wikimedia.org/wikipedia/commons/b/b4/Comparison_satellite_navigation_orbits.svgDue to QZSS I learned there is a difference between the terms geosynchronous and geostationary. 3 of the 4 QZSS sats trace the same figure-8 pattern on the Earth because they are geosynchronous (and have a high inclination). QZS-3 is truly geostationary (appears at a single point on the Earth) like the majority of the communications satellites. -
GPS antenna alternatives
-
GPS Admin screen