The KiwiSDR 2 online store is open for orders! Please visit kiwisdr.nz
Please visit kiwisdr.com (documentation) and kiwisdr.nz (online store)
jks
About
- Username
- jks
- Joined
- Visits
- 31,603
- Last Active
- Roles
- Member, Administrator, Moderator
- Points
- 303
Reactions
-
GPS Admin screen
v1.60, to be released tomorrow, will fix a GPS bug that I finally understood today. Apparently, since v1.38 the GPS acquisition process has not been restarting after active users disconnect like it's supposed to. That will lead to the situation where the admin GPS page says "acq yes" (instead of "acq paused"), but there is no refresh icon shown in the "acq" column next to an incrementing PRN as is typically the case. The satellites that are already acquired and being tracked will be be fine until they drift out-of-range and are dropped. So eventually the GPS page will show nothing even though new satellites should be getting acquired.
-
GPS Admin screen
Quick comment about the GPS page.Bottom row:"acq" Acquisition state, "yes" is acquiring new sats, "paused" if active SDR connections prevent acquisition of new sats."tracking" Number of sats being tracked and appearing in one of the 12 GPS channel slots."good" Of the sats tracked, then number of those that are considered good enough to compute a solution from (min 4 for a solution)."fixes" Total number of GPS position and time fixes computed."run" How long the GPS has been running (H:M:S)"TTFF" Time-To-First-Fix, how long it took to get the very first solution after startup."ADC clock" The GPS-measured true frequency of the ADC clock (nom 66.666600 MHz) In parens after are the number of computed corrections.Channel display: (this is a 12-channel receiver currently)"acq" Shows which channel the acquisition process is working with."PRN" Sat identifier."SNR" Signal-to-Noise-Ratio at time of acquisition. Min 16 to begin tracking."gain" Goes negative if RSSI > about 1500 and software attenuation needs to be applied."hold" How many bits in the current frame, out of 300, have been decoded."wdog" Watchdog that will timeout and free tracking channel if bits are not being decoded. Different timeout values depending on channel state."err" U = tracking loop unlocked. P = parity error. Momentary errors are not necessarily a bad thing."subframe" Colored when GPS subframe correctly received. Blinks grey when updated. Subframes 1-3 required for position solution."novfl" Number of holding register overflows (a debugging aid)."RSSI" Relative Signal Strength Indicator. Above 250-350 means sat actually present. Above 1000 is an excellent signal. -
GPS Admin screen
The GPS time displayed is the time computed when the last position solution was calculated. This can be arbitrarily delayed for a bunch of reasons. Maybe I should call it something else.First of all GPS time is offset from UTC by, what, 17 to 20 seconds now because of UTC leap second adjustments? So keep that in mind.Second, the GPS code I use, which is from Andrew Holme's wonderful Homemade GPS Receiver project (http://www.holmea.demon.co.uk/GPS/Main.htm), while excellent is not as sophisticated as what you'll find in a cellphone or modern GPS receiver. The maximum rate at which solutions are calculated is every 4 seconds under the best conditions. Not 10 times a second +/- like most GPSs. Modern GPSs also have better software & firmware algorithms that do better tracking and thus have better sensitivity. That's why they perform better even though we use the same front-end chip (and if you factor out the antenna differences).The GPS process of searching (acquiring) new satellites is stopped when there are active SDR connections on the Kiwi. Existing sats will continue to be tracked (and timing solutions calculated) until they eventually drift out-of-range. This is because the acquisition process uses an expensive FFT which cannot run simultaneously when there are multiple SDR connections. The Beagle doesn't have enough CPU to do all this work and still meet the realtime deadlines.So all these reasons are why the displayed GPS time will lag UTC, sometimes significantly. The GPS isn't used for anything except calibrating the ADC clock. And for that the timeliness of the GPS time measurement doesn't matter (only the difference between the last two GPS time calculations is used). Things like WSPR time presume accurate time is being received over the network (Internet) via NTP. -
V1.57 lost link to sdr.hu
Will be fixed in v1.58 going out at 0200Z. -
received signals delay between "analog"_RX vs KIWI_SDR vs SDR_IQ_RFSpace
The audio delay (lag) is a consequence of delivering buffered web audio over the Internet. WebSDR is better in this regard due to the advanced techniques they use. It is possible we might match them sometime in the future but it would take a lot of work. Their current method is proprietary.The KiwiSDR is not designed to be a ham radio QSO receiver with associated performance. It is a "shortwave receiver" class device with limited specifications from use of a 14-bit ADC, relatively low ADC clock frequency, lack of a better RF front-end, no direct IQ output etc. But it is designed to be self-contained, Internet enabled, multi-user and relatively inexpensive given its capabilities. A lot of this is explained in our design document, which is now somewhat out-of-date: https://dl.dropboxusercontent.com/u/68809050/KiwiSDR/KiwiSDR.design.review.pdf
-
new WSPR decoder in release v1.54
Okay, I see now what the problem is. The callsign hash table used for the new type 2 and 3 messages is allocated in an unfortunate way for the limited physical memory (500 MB) of the Beagle. I'll release a fix for that today. Until then please only run one instance of the decoder to keep it from crashing. -
Local Timeout
For the next release I've changed it to ignore the inactivity timeout for local network connections.Ignoring it for password-required connections is a little more complicated because you can imagine people wanting that behavior to be configurable. -
static ip does not change
Yeah, those fancy "state-full" deep packet inspection routers must be a headache. Especially when they do the wrong thing on traffic you want to get through. Fortunately I've never had to deal with them. -
release v1.45: improvements to WSPR and no more upload to wsprnet.org?
That's probably more of a question for the official WSPR group: http://wsprnet.org/drupal/My impression is that they take all loggings seriously and some people even do analysis on the database (which goes back to 2008!)There is an open feature request to allow the WSPR extension to be started automatically and run unattended (no browser connection necessary) which is in the spirit of collecting lots of spots. -
Blue Light Flash [power cable voltage drop]
Okay, but if you put more than 5v into it the outcome is uncertain. If the Beagle alone comes up using a 5v supply then you probably didn't fry it. Did you mean 6 and 12 WATT 5 volt supplies? The 5v input on the Kiwi goes though the headers into the Beagle for power management before coming back to the Kiwi. So hopefully the worst that can happen from any over-voltage is you have a dead Beagle.I can tell you what's probably wrong because this identical issue happened to me recently: the cable between your power supply and Kiwi has too much voltage drop because the wire gauge isn't large enough (or it's something besides decent copper). I sent a BBG + Kiwi to a guy here in NZ recently. He asked if I could include a USB/A-to-2.1mm adapter cable. I didn't have any, but I found some on the web and had one drop shipped to him and some sent to me.He had the same problem as you. Except that the Beagle power LED didn't even flash when the Kiwi board was installed. But with the Kiwi removed, and the BBG powered through its micro-USB input, the Beagle alone worked fine. So dead Kiwi board, right? He sent the whole thing back to me. I plugged it in to my standard 5v supplies and everything worked fine! I tried the adapter cable and NADA. Even though power at the Kiwi measured 5 volts!Using a BBB (not BBG) which has a 2.1mm input connector like the Kiwi I noticed this: With a multimeter at the BBB input connector it would briefly drop from 5v to 4v when power was applied and the Beagle's power management IC (PMIC) tried to startup. Then it would jump back to 5v because the PMIC rejected the 4v input and stopped drawing current.So this probably explains your situation. With the Beagle alone drawing 300 - 400 mA your cable must not drop below 4.75v which is about the PMIC lower limit. But with the Kiwi board the 1000+ mA draw is too much and the PMIC refuses to startup. But it's enough that the power LED still manages to flash.
