CTY-3007 Country Files - 18 April 2020
The Country (CTY) Files were updated on 18 April 2020: https://www.country-files.com/cty-3007-18-april-2020/ For installation instructions, start at: https://www.country-files.com/ Hover your mouse over the word Contest in the menu, then select the software you are using. To install the file, follow the link to your software at the top of the page. If you are interested in a bigger CTY.DAT for everyday logging, you can get it here: https://www.country-files.com/big-cty-18-april-2020/ Note that the release notes (and Version Entity) for this larger file are different than what is shown below. There is a separate link to them. As a reminder, there is an RSS feed of the latest country file announcements: https://www.country-files.com/feed/ Here are the release notes: 18 April 2020 (CTY-3007) VER20200418, Version entity is San Marino, T7 Added/changed Entities/Prefixes/Callsigns: * AM95WARD, EA2AU/URE, EA2KU/EKA and EA9AA/7 are all Spain, EA * GB1SOS, GB4NHS, GB75VED and GB8SJA are all Northern Ireland, GI * GB0SH is Wales, GW * AB3AI and NR4L are both United States, K in CQ zone 4, ITU zone 8 * K9CHP is United States, K in CQ zone 5, ITU zone 8 * K4XV, KB3HXI, KG5IVP and N0VYO are all Hawaii, KH6 * K7BUF and N7DUD are both Alaska, KL * KC2GRZ, KC5FWS and WQ2N are all Puerto Rico, KP4 * LU4ERS/I and LU9DPI/I are both Argentina, LU * TA1C/2 is Asiatic Turkey, TA * UB5O/1 is in ITU zone 29, not ITU zone 19 * R1994YU, R1996VK, R2014NC, RU20DS and UE20DS are all European Russia, UA * UB5O/9 is in ITU zone 31, not ITU zone 30 * UB5O/9 is in CQ zone 18, not CQ zone 17 * RX6DL/8 is Asiatic Russia, UA9 * RA4FCJ/9 is Asiatic Russia, UA9 in ITU zone 20 * UB5O/4 is Asiatic Russia, UA9 in CQ zone 16 * RA3AV/0 is Asiatic Russia, UA9 in CQ zone 19, ITU zone 25 Removed Entities/Prefixes/Callsigns: * 4UNR in Vienna Intl Ctr, *4U1V * IQ1QQ/9 in Sicily, *IT9 * B9/BH1NGG in China, BY * CE9/SQ1SGB, DP0GVN, IA0/DK5SXQ and RI1ANZ in Antarctica, CE9 * GB0GGR and GB5AG in Scotland, GM * GB1SDD in Wales, GW * KN4IAS in Guam, KH2 * WY6F in Hawaii, KH6 * KD5WYP in Alaska, KL * LU5DQ/D, LU8YD/W and LW3EK/D in Argentina, LU * 4UNR in Austria, OE * R120FL, R2020LS and R89DRA in European Russia, UA * R9MI/0 and RW3YC/9 in Asiatic Russia, UA9 * HF0ANT in South Shetland Islands, VP8/h 73 - Jim AD1C -- Jim Reisert AD1C, , https://www.ad1c.us
1.5 release plan
Hi there, is there any plan to release the version 1.5? The Debian has an ftbfs (fails to build from source) issue: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=957876 I checked the build log, but looks like all affected part of code had fixed in current master, so the version 1.5 builds as well with gcc10. If the new version will come, we don't need to make any backport patch (this affects only the Debian Sid, if the new version will released, we can upload it and problem will solved). Thanks, 73: Ervin
Re: so2r
* On 2020 18 Apr 05:02 -0500, m5evt wrote: > The SDR setup really lends itself well to so2r (and at low cost). I have > been thinking about implementing an OTRSP (https://www.k1xm.org/OTRSP) > listener within linhpsdr. I think I am correct in saying hamlib doesn't > have this OTRSP protocol embedded within? No, Hamlib does not have any concept of controlling multiple devices through a single instance. However, there should be no limit, aside from computer resources, on the number of Hamlib instances a program can create so long as they're each accessing a unique device on a unique port. Likewise, multiple instances of rigctld/rotctld can be run so long as each is opening a unique device on a unique port and each *ctld instance is bound to a unique TCP port. BTW, I like the rest of your ideas, even though I probably will never do SO2R! 73, Nate -- "The optimist proclaims that we live in the best of all possible worlds. The pessimist fears this is true." Web: https://www.n0nb.us Projects: https://github.com/N0NB GPG fingerprint: 82D6 4F6B 0E67 CD41 F689 BBA6 FB2C 5130 D55A 8819 signature.asc Description: PGP signature
so2r
Thank you for the response on list and off list regarding cwdaemon. Between Kamil and myself we have got alsa working, but it needs more testing at high speeds. Last weekend I used my tlf->linhpsdr->HL2 setup for over 150 qsos. It seems to be working reliably. It is great to not have a mass of cables and do everything through ethernet ports for CAT, netkeyer etc. As a side note, I have only enabled this for the Hermes-Lite 2 so far, but it should work with any protocol 1 OpenHPSDR/Anan SDR. If anyone on list has one and wants to be a beta tester for this please let me know? The SDR setup really lends itself well to so2r (and at low cost). I have been thinking about implementing an OTRSP (https://www.k1xm.org/OTRSP) listener within linhpsdr. I think I am correct in saying hamlib doesn't have this OTRSP protocol embedded within? I have already got the basics in place in linhpsdr for audio in left/right channel for specific receivers etc. I'm not really proficient enough yet to make too much use of so2r, but it seems like an interesting challenge, both in terms of computer programming and operating so this motivates me. I know that so2sdr exists for linux, but I'm not aware of any other logging software supporting so2r? I have read through the archives of this list and seen that with the LAN connection tlf can do pseudo so2r. I have been looking at the tlf code and pondering over what it would take to add some basic so2r, single keyboard functionality using the OTRSP protocol. Shift key would seem a candidate to bind so2r switching. Shift is used for some things like "+" to switch S/CQ and resend last serial is an _. But does shift plus numbers or letters have a key bind? The other stumbling point I hit in this mental exercise was the band map. You would need some sort of intelligence in code for grabbing a bandmap spot. It could perhaps figure out the band and if one of the radios was on this band, QSY said radio. It would result in the code being littered with if(so2r). I am reasonably motivated to try and branch the code to see if this is possible in some sort of proof of concept. I would appreciate some advice about the general idea from the experts on this group. I'm not familiar with ncurses so it may take me some time to get up to speed. Final question, unrelated, is there anything documented for the contest simulator? With pulseaudio, I was thinking we can have more than one audio sink, so with a seperate application listening on a netkeyer port, it could be possible to make pileups (from random callsigns in callmaster), add atmospheric noise etc. It seems like the simulator doesn't really give any feedback whether I have a callsign correct or incorrectly logged? Is this correct or am I doing something wrong? I feel like this could be a really nice feature to offer to people and enhance tlf. Lots of people seem to use MorseRunner and DXlog together. 73 Matthew M5EVT.
