It looks like you're new here. If you want to get involved, click one of these buttons!
Software release information
Configuration and Operation
Installation, Antennas and Interference
WSPR, wsprdaemon, kiwirecorder
Problems and Issues
Problems Now Fixed
My Kiwi works well in all ways except the GPS. It will occasionally lock onto a single PRN, but always loses lock within about 30 seconds. Once I saw it lock two PRNs at once, but then it lost both. Has anyone else had problems like this?
I though that my GPS was broken. Then I figured out that KiwiSDR searches (acquire=yes) new GPS satellites only if the is are one or less listeners online AND good satellites count are less than 4. If you have for example two listeners online, satellites just fade away and KiwiSDR does not even try to search new ones (acquire = paused). This behaviour is defined in /root/Beagle_SDR_GPS/gps/search.cpp row 458 (KiwiSDR 1.16)
If you want to change this behaviour, you can change code. I tried that. Worked OK. Also my finding is that default small black GPS antenna need clear visibility to sky to get more than few satellites at time. It has so short cable that it is diificult to install in a good place. Therefore I buyed another active GPS antenna from ebay "10M GPS Active Marine Navigation Antenna 10 Meters With BNC Male Plug Connector" and installed it outdoors. It is a lot better than black small one which I got before.
Thanks for that tip - I will look into that part of the search code.
I'm a little worried that that's not it, since I have zero listeners (I'm not even connected to it myself). I've tried two different GPS antennas - the one that came with the kickstarter kit, and another one I have had for a while. When the PRNs sync in the admin page, the SNR and RSSI are both good, so I think the antennas are OK. It seems like something is causing it to lose lock during the search.
Regardless, I'll dive into the code and see if I can make sense of it. All other advice welcomed!!
Third antenna and it works now. It appears that the GPS hockey puck that came with the kit is DOA. Interestingly, the one I received with the Kickstarter kit has a roughly 5 meter cable, not a short cable as OH1KK reports. Regardless, it's an equipment problem, nothing with the board or software.
Thanks for the help.
OH1KK is correct. The GPS acquisition is paused under various circumstances for performance reasons. That's why the "acquire" status is shown on the status panel.
Because the GPS acquisition FFT takes up significant runtime on the Beagle it is paused when there is more than one user connected so it doesn't slow down everyone's waterfall update rate. The existing sats acquired are still tracked (until they go out-of-range of course). On startup acquisition is not paused, no matter how may users connected, until the first fix is found and the ADC clock is calibrated. If there is only one user connected then acquisition is done if there are fewer than the minimum number of sats necessary to produce new fixes (4).
It is quite common for the acquisition to decide there might be a signal because a particular PRN / doppler combination exceeds the SNR threshold (16). Then you'll see the RSSI show a value as the tracking loop attempts to lock. But the "hold" value never goes non-zero which indicates that no valid nav bits have been decoded. The watchdog will eventually timeout and the channel search is dropped. The unlock "U" and parity "P" flags will probably flash during all this.
But I also agree that the GPS sensitivity has always seemed less than it should be. This is an issue I hope to revisit at some point.
Sorry to hear about the DOA antenna. We'd be glad to replace it if you like.
Thanks for the detail - the backoff strategy sounds like a reasonable tradeoff to me.
Don't sweat it about the antenna - I always include a 40% DOA expectation on anything shipping straight from China. Sad, but true. I have two others so it's no big deal.
I'm just glad I'm not diagnosing the kiwi itself!! So far the board has good performance. The power levels reported on the web display are (surprisingly to me) quite close to dBm values from other test equipment on the bench. Noise floors are good and the spurs are decent. From an analog standpoint, I'd have to say that so far this board is a delight compared to some others (Red Pitaya take note).
I need to make the S-meter (and overall system) amplitude correction factor an adjustable parameter in the admin config tab. I set the default by injecting calibrated levels from an hp 8657b. There is also a digital NCO with attenuator in the FPGA that can be selected in place of the ADC input. I used this to help get the bugs out of the waterfall FFT gain correction. That was a real learning experience for me having had little prior experience working with FFTs.
Well, for my part, I appreciate the time you put into these details. It shows.
Hello all, my first comment at this forum.
I received my KiwiSDR Kit a few days ago.
I am using the kit's GPS black blob at a window with limited sky view. I was seeing very poor results.
After noticing the magnetic base, I had a thought; "Does it want a ground plane?"
Clinging to a pie plate at the same location appeared to give much better results with RSSI above 500 occasionally; I also did see the five subframes with colors showing a few times. Currently I'm seeing poor numbers so who really knows if it was a good satellite view at that time. Next time I see a good signal, I will remove the "ground plane" to see what happens.
Your mileage may vary but perhaps worth a try.
I am on V1.19, which seems to be an update to yesterday's update. Until v1.18, my GPS reception was very good with 5 or so locked Sats and RSSIs of 600-1200 typically. As of v1.18, the reception is OK, but there are a lot of underruns and parity errors, so the watchdog time cycle runs through to 60 and drops the channel. Other than some obvious changes to extensions and the UI, I do not know what changed with GPS reception, but it's not working.
My GPS antenna is a Trimble bullet shared with a Thunderbolt; I couple the Kiwi connection in with a 0.1uF RF cap and it has been this way for more than a week. The Thunderbolt is seeing many birds on the same antenna. I also tried an Adafruit GPS active patch antenna with the Kiwi and see the same results.
edited November 2016
Absolutely nothing changed with the GPS code in the latest release. The complete commit log is here:
Now, that's not to say that something hasn't gone wrong. You never know about these things.
I've always felt the GPS hasn't performed well in a couple of ways. FIrst, it has never had the basic sensitivity I thought it should given that it uses the same GPS front-end chip as everyone else. When comparing it to an old Garmin Nuvi the Kiwi doesn't hear anything indoors while the Garmin works fine. They are both using similar patch antennas. One possibility is that the Kiwi is experiencing de-sense from self-interference, like a harmonic of some clock frequency. This problem actually existed on an old prototype that used a commercial FPGA development board when the ADC/FPGA clock harmonic fell smack in the middle of the GPS L1 band. I had to turn the SDR off to run the GPS! Given this experience we carefully chose the Kiwi clock not to have this problem. We also checked all the Beagle clocks. We even looked at the spectrum plot in the Beagle FCC compliance testing report to see what frequency the clock spurs were at in case we missed any. The other possibility is that commercial receivers like the Garmin are just using fancier code techniques to achieve better sensitivity. This of course would be difficult to discover.
The other problem is that I get the feeling there is some loop instability in the Costas data recovery loop. This is because although the GPS seems to acquire sats okay the nav data recovered seems to be "noisy" to me. This results in the parity errors you see all the time. But this also might be normal behavior for weaker signals. Andrew has pointed out to me that I need to pull the IQ data out of the loop and take a look at it to see what's going on. With strong signals the loop seems to be fine. Because there is firmware involved in closing the loop, and I have added code to the embedded processor running this code for other tasks, it is possible I have screwed up the response time such that it no longer meets the real time requirements of the loop closure. This is one area in which my implementation differs from Andrew's original design. I measure the overall embedded processor load but not if the loop closure real time requirement is being met.
I've also noticed tremendous variability with signal reception. Sometimes like you say I'll get 4-5 sats with RSSIs over 800 and everything is fine. Other times it struggles to find the minimum number required for a fix (4) and sats that are acquired are dropped for seemingly no reason. Again, this seems to me to be a weak signal problem. The constellation is full enough now that there should always be enough sats capable of producing strong signals, even for me down here in New Zealand.
I'd be interested knowing what you're seeing on a longer timeframe.
, I'll monitor the situation and re-post later. One change I did make, that I can easily un-do, is that I put the Kiwi in an aluminum enclosure. I did not see decreased performance with the GPS when I did this, in fact on the HF side, the background noise from my Plasma TV disappeared.
Well, that didn't take long. I removed the Kiwi and sure enough, tracking 10 Sats with 7 good. Yeah, I'd say the aluminum underneath the RF section of the GPS front-end was not appreciated :-) I guess I'll have to go with a plastic case instead hi,hi. Thanks.
edited November 2016
Oh, now this is good information! I've always been under the impression that a metal enclosure didn't really matter as all of the interference problems we've seen here have been "conducted" over the connecting cables (especially the GPS and RF coaxes). That's why adding choke toroids has been so effective. And the choice of grounding (AC system, CATV system, none, ground rod) makes an even larger difference.
Is your enclosure connected to any Kiwi grounds or is it just floating?
, it was connected to the Kiwi board ground plane, by virtue of the SMA connectors being in full contact with the enclosure metal on the inside face; because I removed the powder coat so this would be true. Since you asked, I slid the enclosure back onto the Kiwi + BBB but did not make connection with the end mounting panel the SMAs are attached to. While the reception and error rate were definitely affected, it was no where near as bad as when the enclosure was electrically conductive all the way around.
With the Trimble bullet, which is better than the Adafruit active patch antenna (and higher up), I was just seeing 12 tracking and 9 good, with RSSIs up to 1120. It's a clear day here and this is roughly what I would expect to see if all is well.
Don't hesitate to ask for any additional testing, documentation, etc. I am a working EE in the computer industry, tons of test equipment, blah, blah.
Well, that's a surprise given that the GPS front-end is in a shield can and most of the 6-layers in that area of the board are ground layers. Was the enclosure floating or grounded to the Kiwi?
unfortunately it was floating because the only M3 standoffs I had were nylon. It would be worth a try to use metal standoffs and then see what changes result. I'll have to try that and report on the results, but is will be a few days. Good thing Digikey is only a few hours away ;-)
Forum Software Powered by Vanilla