Masked frequencies [fixed in v1.637]
Hi All,
I tried to setup some new masked frequencies today, but it didn't seem to work for me.
It's a while since I last used this feature so I could well be doing something wrong, or maybe it doesn't work on a local network connection unless a password is set elsewhere.
Has anyone else experienced any similar problems, or may be able to tell me what I'm doing wrong ?
Thanks,
Martin
Comments
One tricky thing: The
passband
field on the "dx labels" panel of a user connection (or on the admin DX tab) is in Hz. So if you intend a +/- 1 MHz wide mask type "2M" into the field, instead of the more cumbersome 2000000. Similarly "200k" in place of 200000.An entry of a single number is taken as a symmetric passband, e.g. "2M" is the same as "-1M, 1M".
I tried this just now, user and admin, and it seemed to work.
Hi John,
I think there is an odd problem occurring, which is proving difficult to reproduce.
If I choose to add a new DX label in the admin interface, by duplicating an existing entry, it sometimes doesn't load correctly and creates many duplicates.
For example.
I pick one of the first entries in the DX label list, in my case say 18kHz
Duplicate it by using the green circle plus icon
Edit the new duplicated entry to a new frequency of say 18000, and make it masked with a bandwidth of 2000
The new 18000 entry will remain at the top of the list next to the original 18kHz entry.
It takes these values and all seems OK, but the masked frequency may not appear in the DX labels or on the waterfall.
If I then refresh the browser tab showing the admin DX label edit fields, the position of the new 18000 will have moved to the correct position in the DX label list in frequency order, and the masked DX label and section of the waterfall will be blanked out.
However.
The original 18kHz entry that has been initially duplicated will have altered to read 18000 and moved to the correct position in the list of frequencies and several other duplicate 18000 entries will also have appeared.
In the example shown below, the original 18kHz CWN entry had no bandwidth set, so I think that has had the frequency field changed to 18000 in error. The original 18kHz entry has been removed from the list, and the the rest at the new 18000 frequency, consist of the new label and copies of other intermediate edits.
I think this occurs as the data is entered and the table tries to automatically update.
Depending upon when it tries to update during the edit and how many times this occurs, will determine how many new spurious entries are added and the detail they contain.
This is just a theory and I may well be wrong, but it is seems to be a very odd behaviour.
Regards,
Martin
Are the Kiwi and computer running the browser on the same local network (i.e. low latency between the two) or are they separated by a higher latency Internet connection?
I ask because it's quite possible this is occurring because of a timing/race problem in the code if there is a substantial delay in the reply from the Kiwi server. The code implementing the admin DX interface is very complicated.
Hi John,
I have tried a few of mine and it seems to be a problem with all of them, including those on my local network.
Could be because I've got so many tags in the DX file ?
Regards,
Martin
I have a different problem, so I create DX points using existing labels in the DX window, calling the functions Left mouse button + shift. When creating a new tag in the admin DX tab, starting from the top by pressing +, it creates 3 and sometimes 4 clones, what's worse is when I deleted these 3 copies using the - sign, they disappeared but it also deleted the 3 factory-saved tags from the lowest frequencies, i.e. Alpha from VLF and each subsequent one before I realized that something wasn't right. All Kiwis are in the same IP pool as the PC.
Finally, the reason why this happens is because of the use of Unicode Emoji labels in descriptions. This problem does not occur in the newly purchased receiver.
Well, I think I fixed it. I can't quite believe it, but the fix was only 3 lines of added code.
What happens now is that whenever you change the frequency entry it immediately forces a list re-sort and then acts like you entered the frequency in the frequency search box. So you'll see the entry in case the new frequency has taken it off-screen.
The list jumps around a little. But the end result is that the entry with the changed frequency ends up in the correct list position. And subsequent editing of the other fields doesn't cause any corruption. Don't know why this didn't occur to me before..
I'll get this out in an update as soon as possible. Apologies for the trouble it caused.