jks

After looking at this in more detail (after the other post complaining about the exact same thing).

What you describe above should not be happening. Once you mouse-down on the passband edges to adjust the passband width the edges should track as long as the cursor stays anywhere in the entire grey frequency scale area. That means the upper part, where the passband symbol is. And the lower part, where the frequency ticks and numbers are.

The edge tracking will stop, and the entire passband will move, if the mouse moves into the area above (i.e. dx labels, top bar or spectrum) or below (waterfall). This is what I've been meaning to fix. When you adjust the entire passband and move into these areas the passband movement continues because there is code to handler this special case. There needs to be something similar for PB edge adjustment.

If you know of a Kiwi that does what you claim (stops tracking below the lower red line) I would like to see that myself because I need to understand why that is. I tried a bunch of public Kiwis running different versions and it never happened.

This has been on my list to fix for a long time now. It's annoyingly difficult to fix.

There are other methods for adjusting the passband: http://kiwisdr.com/info/#id-user-pbt

Yes, the overlapping bars are not the problem (as long as the color blending doesn't look too bad). It's just the text collision (overlapping) as you zoom in.

I tried a couple of times to fix the problem: The text from overlapping band bars can collide as you zoom in certain situations. Overlapping bars is not really a problem. It's just the text conflict. I couldn't come up with a good algorithm to fit it.

No there isn't. The regular web interface isn't even properly documented yet.

About all you can do is take a look at kiwiclient / kiwirecorder or the server source code.

An alert Kiwi owner/admin has sent me some suspicious log messages. They are obvious hacking attempts. If you see anything similar or unusual in your logs I'd appreciate it if you could forward the relevant log messages to support@kiwisdr.com

I'm particularly interested in log messages containing ### SECURITY: NO AUTH YET:

And also **** unknown stream type

And any attempted admin login messages from IP addresses you're not expecting.

So far the Kiwi security mechanisms appear to be working and there has not been any evidence of any breaches. Please be sure you have a good, strong admin password in place.

The IP address in question has been added to the IP blacklist which your Kiwi should receive during the overnight update window. You can also update it manually on the admin page, network tab.

Thank you.

Remember that on the admin config tab you can adjust the ident field (name/callsign) length from the default 16 characters all the way up to 64.

I wish I could find some open source code that does FSK signal parameter classification (and digital classification in general). But software like that tends to be proprietary and cost money (and for good reason).

Under the "decode" menu are two modes "scope" and "framing" that I used during development to help classify unknown signals to establish their parameters. But they are tricky to use and are not documented anywhere.

From your description it certainly sounds like an open attenuator. Especially if you're getting the self-test patterns, just attenuated by 40 dB.

Please send an email to sales@kiwisdr.nz (note ".nz") requesting a repair. We're having to figure out some sort of formal solution to this problem since a significant number of people are asking.

By request: the list is now sorted in 0-30 MHz SNR order.

There is a new menu to select the alternate 1.8-30 MHz (HF) order.