开云体育

ADIF 3.1.5 has been approved by a majority vote. Files: ADIF 3.1.5 Released Specification http://adif.org.uk/315/ADIF_315.htm ADIF 3.1.5 Released Specification (annotated) http://adif.org.uk/315/ADIF_315_annotated.htm ADIF 3.1.5 Released Resources http://adif.org.uk/315/ADIF_315_Resources.htm ADIF 3.1.5 Released Resources (annotated) http://adif.org.uk/315/ADIF_315_Resources_annotated.htm ADIF 3.1.5 Released ADX Schema Version http://adif.org.uk/315/adx315.xsd ADIF 3.1.5 Released ADX Schema Generic Version http://adif.org.uk/315/adx315generic.xsd There is also a zip containing the above files: http://adif.org.uk/315/ADIF_315_released_2024_11_28.zip Exported data files and test QSO files are available in: https://adif.org.uk/315/ADIF_315_resources_2024_11_28.zip (Note: to include a link in documentation or web pages that always redirects to the most recent released version of the ADIF Specification, use http://adif.org.uk/adif ) Poll Details: Do you approve of the ADIF 3.1.5 specification and agree that it is ready for publication? Results 1. Yes 100% 14 votes 2. No 0% 0 votes For details, please see http://adif.org.uk/adif_voting_members/ADIFVotingmembers_2024_11_28.csv Thank you to everyone who has contributed towards this version. -- 73 de Graham G3ZOD

Here are the final poll results for Items 162, 160, 158, 157,151, 144: Should "162: Add a MY_DARC_DOK field" be included in the next proposed ADIF Specification? Yes: 15 (100%) No: 0 (0%) Should "Item 160: Add support for New Zealand Regions award" be included in the next proposed ADIF Specification? Yes: 15 (100%) No: 0 (0%) Should "Item 158: Add QSO Field QSLMSG_RCVD" be included in the next proposed ADIF Specification? Yes: 15 (100%) No: 0 (0%) Should "Item 157: Add QSO fields to support the DARC DCL online service" be included in the next proposed ADIF Specification? Yes: 15 (100%) No: 0 (0%) Should "Item 151: Add QSO fields to represent a Morse code key" be included in the next proposed ADIF Specification? Yes: 14 (100%) No: 0 (0%) Should "Item 144: Add download date/status fields for QRZ.com" be included in the next proposed ADIF Specification? Yes: 15 (100%) No: 0 (0%) For details of votes, please see: http://adif.org.uk/adif_voting_members/ADIFVotingmembers_2024_10_29.csv -- 73 de Graham G3ZOD

FreeDATA is a versatile, open-source platform specifically designed for HF communication. It leverages Codec2 data modes to facilitate robust global digital communication. Key features of FreeDATA include: Network-based server-client architecture REST API Multi-platform compatibility Messaging system FreeDATA is rapidly gaining more users and stands out due to its unique features, which do not fit into the existing modes and sub modes in the ADIF format specification. I would appreciate the opportunity to discuss this proposal further. For more information: https://wiki.freedata.app/en 73 de LA3QMA, On behalf of the FreeDATA development team

Hello, I'm new here and would like to thank you for the ADIF format. I'm a programmer (and also radio amateur), but my second hobby is law (intellectual property law). This proposal is from this second hobby, but I would like to propose something new in the future. So as a law-hobbyist (not lawyer) and as a programmer who must conform with the copyright, patent and trademark laws, I propose the following: I would like to propose a change to ADIF specifications (yes, all versions, including all resources). All ADIF specifications are not licensed under any license. My proposal is to add a free license to all specifications, like CC-BY 4.0, MIT, or CC0. This is because ADIF specifications are made by the community to radio amateurs' community. With free-licensed specification, the following can be done (legally): - using XSD files in software - copying parts of specification to code or comments in the code - creating documentation for that software based on specification text - including a copy of the specification for the software - deriving to other texts, books, and documentation - making a version with annotations - creating suggestions to the official specification by adding some text - adding specification to the software that uses file format with extensions to it with specification describing full file format but with extensions instead of creating document only with specified changes. - archiving purposes I hope my proposal will be accepted, because it would be good for the community. Best Regards Marcin

The Go programming language is copyright "The Go Authors", for example. The Zig license is "Copyright (c) Zig contributors." The Z Shell license lists some individual authors and says "in what follows, they are referred to as 'the Zsh Development Group'" and notes that it's for convenience and has no legal status (https://github.com/zsh-users/zsh/blob/master/LICENCE). TensorFlow is "COpyright 2015 The TensorFlow Authors." After Bram Moolenaar passed away, Vim copyright lines changed to "The Vim Project"; it's not clear to me if that's a legal entity or not. I like this analysis as far as it goes, I think it is a great idea, in fact, but it still wishes away the existing contributions by people who may not be paying attention or those that are and don't give their explicit assent. The downside is you can't form a group like this and pretend it includes everyone. It will include whomever "signs" the statement forming the group, whatever form that statement takes, and nobody else. But you could also require new contributors to sign/join up in the future before anything they propose is incorporated into the document. Over time, that may do a great deal of practical good and fairly quickly at that. As far as "clean room" goes, I'm no lawyer, but if you wait until you are sued, I suspect the clean room won't avail you very much. Far better to do it long before the suit is filed I suspect, but who knows. I do like the idea, however, that there could be a significant subset of the authors, many with longstanding ties, that form some entity like this, whether it has to be an actual corporation or just some sort of sufficient declaration of joint ownership (insert lawyer here). That could, if done in a manner legally sufficient, put a potentially large subset of the document on the right track and after the fact at that. For those folks that sign, anyway. However, this would require some work, some sort of something where rights are assigned. I don't think it is enough just to declare something called The ADIF Authors. Not without some sort of statement by participants where they acknowledge they freely contribute to this group. In other words, some affirmative showing that the rights were, in fact, assigned to the group by specific authors; as many as you can get. + You can't describe a plausible lawsuit, but you continue suggesting this nonsensical cleanroom approach.. + Cite one example when a clean room specification was successfully employed to defend against copyright infringement of a specification. + The famous 1986 clean room implementation of the NEC V20/V30 microprocessor firmware is not an example, as the developer's starting point was the instruction set specification and his output was firmware - not a specification. + Exactly what would be the starting point of a clean room re-creation of the ADIF specification? How would you prove that the clean room developers had never seen ADIF in the past 29 years, given its broad use across amateur radio applications and services? de AA6YQ

The recent discussions have brought back to mind something that I’ve been wondering about for a while. I think it would be worthwhile to have a voluntary and open-ended list of names that are being used in PROGRAMID/APP_ fields perhaps on the website or in the specification or a link in the specification to the website. It would reduce the risk of name clashes and perhaps be informative too. 73 de Graham G3ZOD

Good evening. VaraC has gained popularity and growth. The ADIF specification added support in Dec 2022. LoTW has not yet implemented support for VARA QSOs. Please consider signing the following petition to encourage the ARRL to add support in LOTW. https://chng.it/SCb995cQMC

To whom it may concern, On behalf of the Contest Department of the DARC e.V., I would like to request that the following list of ADIF keys and long names be included in the contest listing: ADIF-Key Name (de) Name (en) DARC-CWA CW-Ausbildungscontest CW trainee contest DARC-10 DARC 10m Contest DARC 10m contest DARC-TRAINEE DARC Ausbildungscontest DARC trainee contest DARC-HELL DARC Hell Contest DARC Hell contest DARC-MICROWAVE DARC Mikrowellen-Wettbewerb DARC microwave contest DARC-SHORTRY DARC RTTY-Kurzcontest DARC RTTY short contest DARC-UKW-SPRING DARC UKW Frühlingswettbewerb DARC UKW spring contest DARC-UKW-SUMMER-FIELD-DAY DARC UKW-Sommer-Fieldday DARC UKW summer contest DARC-UKW-WINTER-FIELD-DAY DARC UKW-Winter-Fieldday DARC UKW winter contest DARC-VHF-UHF-MICROWAVE-JULY DARC VHF-. UHF-. Mikrowellen-Wettbewerb (Juli) DARC VHF-, UHF-, microwave contest (July) DARC-VHF-UHF-MICROWAVE-MAY DARC VHF-. UHF-. Mikrowellen-Wettbewerb (Mai) DARC VHF-, UHF-, microwave contest (May) DARC-VHF-UHF-MICROWAVE-MARCH DARC VHF-. UHF-. Mikrowellen-Wettbewerb (M?rz) DARC VHF-, UHF-, microwave contest (March) DARC-EASTER DARC-Ostercontest DARC Easter contest We would be very pleased, if this could be realized! Best 73 Kim DG9VH DARC FT4 Contest Manager

Hi, there's a bug in the ADIF 3.1.5 spec: MORSE_KEY_TYPE Enumeration Morse Key Type the contacted station's Morse key type (e.g. straight key, bug, etc). Example for a dual-lever paddle: <MORSE_KEY_TYPE:3>DLP ... but DLP is not valid for Morse Key Type, that should be DP. 73, Christoph DF7CB

I have just started doing some QSOs using the new mode LONGCHAT. While logging those QSOs, I came along this topic. How to do it withinh my logbook? No ADIF mode defined so far!? In ARRL TQSL I have mapped this mode to DATA. Is this the correct way? Please let me know. Thank you. regards, Suitbert, DF2PI

I just noticed that the "lotwreport.adi" file that Logbook of the World generates for data exports ends with the text "<APP_LoTW_EOF>" after the final "<eor>" marker. I had thought this was invalid: outside the text length specified by a data specifier, an open-angle-bracket character should begin either a data specifier or be <EOH> or <EOR>. But other than > If the first character of an ADI file is <, it is presumed to be the first character of the first QSO-Data-Specifier of the first QSO Record of an ADI file that does not include a Header. I don't see anything that says a "<" MUST be the start of either a data specifier field or a well-known tag. Is the expectation that ADIF importers encountering "<FOO>" to treat it as "the insertion of any other information an ADI-exporting application cares to provide"? Allowing this seems like it makes bugs in exporting software harder to detect. "<CALL>W1AW <BAND:3>20m <EOR>" becomes a record with a single BAND field and a comment, rather than detecting an error that the exporter failed to include a length with the CALL field. Other than LoTW, do any programs include this kind of not-a-field tag? 73 de WT0RJ -- =-=-=-= Trevor Stone -=- [Flwyd] -=- <tstone @ trevorstone.org> =-=-=-= Computer science, eclectic philosophy, games, wits, esoterics, odd hats https://twitter.com/flwyd Thou reeky fly-bitten measle! {embrace culture} HACKERS do it graphically. Her enthusiasm was infectious. I was on antibiotics for two weeks. -- @Brain_Wash

+ AA6YQ comments below The X-QSO is a valid QSO, but not to be submitted as part of the particular contest record. It is perfectly valid for other things. As an example, if during a domestic contest I work a new country who is not in the contest, I will X-QSO that line, but it will go into the LOTW database and count for my country total. Thus the X-QSO is for a specific purpose, but does not indicate an invalid or bad QSO. + So do we need a different X-QSO to mean "don’t' submit to contest X, but do upload to LoTW"? "don’t' submit to contest X, but do upload to eQSL"? "don’t' submit to contest X, but do upload to ClubLog"? "don’t' submit to contest X, but do upload to QRZ"? "don’t' submit to contest Y, but do upload to LoTW"? "don’t' submit to contest Y, but do upload to eQSL"? "don’t' submit to contest Y, but do upload to ClubLog"? "don’t' submit to contest Y, but do upload to QRZ"? + etc? 73, Dave, AA6YQ

I've added "168: For the exported Specification tables, add JSON format" to the list of proposals. This is NOT about exporting or importing ADIF as JSON! It's just adding JSON to the existing file types (.csv, .tsv, .xlsx, .ods, .xml) 168: For the exported Specification tables, add JSON format Currently tables in the ADIF Specification are exported as XML, TSV, CSV, Excel, & Calc; add JSON to this. The files created and structure will be similar to the XML. This is an outline of the structure of all.json: { "Adif": { "Version": "3.1.5", "Status": "Proposed", "Date": "2024-11-10T00:00:00+00:00", "DataTypes": {}, "Fields": {} "Enumerations": {} } } Here is an example of “Enumerations” using a cut-down Ant_Path enumeration: { "Adif": { "Version": "3.1.5", "Status": "Proposed", "Date": "2024-11-06T00:00:00Z", "Created": "2024-11-18T18:19:44Z", "DataTypes": null, "Enumerations": { "Ant_Path": { "Header": [ "Enumeration Name", "Abbreviation", "Meaning", "Import-only", "Comments" ], "Records": { "G": { "Enumeration Name": "Ant_Path", "Abbreviation": "G", "Meaning": "grayline" }, "O": { "Enumeration Name": "Ant_Path", "Abbreviation": "O", "Meaning": "other" }, ... “Fields” and “DataTypes” will be similar except for not having an extra level equivalent to an enumeration name. Unlike the XML files, the property names are capitalized (e.g. “Enumerations” rather than “enumerations”. This is to simplify serialization and de-serialization with programming language classes where the convention is to start a class name with a capital letter (while it may be possible explicitly to map the class names to JSON property names, that seems an unnecessary complication). In order to allow indexing rather than always needing to iterate through records, each record will have a Property name, e.g. “G” in: "G": { "Enumeration Name": "Ant_Path", "Abbreviation": "G", "Meaning": "grayline" }, The Primary Administrative Subdivision enumeration comprises a table per DXCC entity and the different tables may contain the same values. For this reason, the Property names will be suffixed with a dot and the DXCC entity number, e.g. "NS.1" for Nova Scotia in DXCC entity 1 (Canada). Also, Primary Administrative Subdivision names are occasionally duplicated for a DXCC entity, with one marked as “Deleted”. The property names for these will additionally be suffixed with a dot and the word “Deleted”, e.g. M?rket in DXCC entity Aland Is. will be “051.5.Deleted”

SCAMP is a set of digital modes currently supported by fldigi and RFBitBanger, a complete mode specific transceiver; https://www.qrz.com/articles/node_1692683709. There are probably others as well. I have an RFBitBanger made available for testing. The SCAMP signal is either FSK or OOK (on/off keying). I propose the following, but am not sure how to fit the OOK data stream mode into the current ADIF specification. ADIF_MODE ADIF_SUBMODE Notes --------- ------------ ---------------------------- FSK SCAMPFSK SCAMP frequency shift keying FSK ? SCAMPOOK SCAMP on/off keying FSK SCFSKFST SCAMP fast FSK FSK SFSLW SCAMP slow FSK FSK ? SCOOKSLW SCAMP on/off slow keying FSK SCFSKVSL SCAMP very slow FSK 73, David W1HKJ

While adding the ability to infer CQ Zones from DXCC fields in ADIF Multitool, I noticed that the Primary Administrative Subdivision enumeration has CQ Zone and ITU Zone properties. The CQ Zone property is filled in for states/provinces in some but not all countries which span multiple CQ Zones: * Canada has the CQ Zone property set, and uses comma as a delimiter when a province is in multiple zones, e.g. "02,05" for Québec. * Asiatic Russia has the property set and for some reason has "S=16 T=17" as the zone for OB Orenburg/Orenburgskaya oblast. What does that mean? (See note later.) * European Russia has the CQ Zone property set, even though the value is always 16. * The sole subdivision in Kaliningrad has the CQ Zone property set (to 15). * USA has the CQ zone property set. There are two countries which span a pair of CQ zones which don't have the CQ Zone set on primary administrative subdivisions: * China: GS Gansu, NM Nei Mongol, NX Ningxia Huizu, QH Qinghai, SN Shaanxi, XJ Xinjiang Uygur, and XZ Xizang (Tibet) should all be in CQ Zone 23, the others should all be in CQ Zone 24. See the bottom of https://mapability.com/ei8ic/maps/cqzone.php for a good view of the dividing line. * Australia: NT Northern Territory and WA Western Australia should be in CQ Zone 29, the rest is in CQ Zone 30 (not including islands that have their own DXCC entities). I propose adding the CQ Zones to primary administrative subdivisions for China and Australia. I'm also curious if it would be reasonable to add CQ Zone as a property of the DXCC enumeration. Most entities would have a single zone; the above-mentioned entities plus Antarctica and Yemen (Socotra is in Zone 37) could have a comma-separated list. This would make it easy for log-processing software to confirm or infer the CQ Zone based on the DXCC code and possibly the state field. It looks like ARRL DXCC text files have CQ zones listed. I [just derived the data from CQWW](https://github.com/flwyd/adif-multitool/blob/main/adif/spec/cq_zones.go) and could easily produce the mapping in whatever format is convenient. -=-=-=-=- Regarding Orenburg, https://mapability.com/ei8ic/maps/cqzone.php and https://zone-check.eu/ show Orenburg in zone 16, and the thematic coloring in the mapability map seems to indicate it's in European Russia rather than Asiatic Russia, since it lies south and mostly west of the Ural mountains. https://cqww.com/cq_waz_list.htm says "UA9 (S,T,W)" is in zone 16 and "UA9 (A, B, C, D, F, G, J, K, L, M, N, Q, R, X) is in 17 and I have no idea what those letters mean. While on this topic, I noticed that Canadian provinces use a comma to separate multiple ITU Zones (e.g. "03,04"), but USA states use a slash (e.g. "07/08"). This makes parsing this value unnecessarily complicated. Is there a reason for this difference? Could it be fixed in the next ADIF version? 73 de WT0RJ -- =-=-=-= Trevor Stone -=- [Flwyd] -=- <tstone @ trevorstone.org> =-=-=-= Computer science, eclectic philosophy, games, wits, esoterics, odd hats https://github.com/flwyd Thou ruttish shag-eared harpy! {embrace society} CBers do it on the air. 1) Start with ingredients. 2) Use ingredients throughout the whole process. 3) Finish with ingredients, and consume. -- Molly Bee

Hello all, After sending this email to Jim (I don't know if he is in the list so I am CCing him) I have checked the WAC page (http://www.arrl.org/wac) and I see that there are only 6 continents, not 7 and Antarctica is not recognized as a Continent by the ARRL. WAC: Africa, Asia, Europe, North America, South America. ADIF: Africa, Asia, Europe, North America, South America + Antarctica Wikipedia shows some proposals but one of them is Africa, America, Asia, Europe, Antarctica (North & South America count as one single continent) but it is also showing the ADIF selection. IMHO the ADIF proposal is for me the best one adding "us" (the hamradio folks) more options :-) but it is not aligned with the WAC. How did we get to the selection of 7 continents instead of 6, would it make sense to contact the WAC commitee from the ADIF group for this topic? :-) Thanks for reading. Jaime, EA4K -------- Mensaje reenviado -------- Asunto: Antarctica: DXCC vs Continent & ADIF Fecha: Wed, 21 Aug 2024 17:35:05 +0200 De: Jaime Robles <jaime@...> Para: Jim Reisert AD1C <jjreisert@...> Hello Jim, Testing KLog I have found some potential inconsistency between ADIF and your file that I would like to share with you. In ADIF.org you can see 7 continents (https://www.adif.org/314/ADIF_314.htm#Continent_Enumeration). Number 7 is Antarctica. Antarctica is the DXCC 13 in ADIF. In your cty.csv you can find: "CE9,Antarctica,13,SA,13,74,...." You are listing continent "SA" for "Antarctica" with DXCC 13. I obviousy recognice CE as Chile and Chile as SA... but I think that your file should be updated and define "Antarctica" a Continent "AN", Antarctica. What do you think? Thank you for all your work! Jaime, EA4K

Johan PA3EXX has established a new online iota-developers group /g/iota-developers to facilitate interactions with the developers of software that interacts with IOTA software. e.g. change announcements, defect reports, and enhancement requests. Johan passed along the information appended below. 73, Dave, AA6YQ The IOTA API endpoints have changed, an API key is no longer required. The following files are available for download in JSON format from our website: * All IOTA groups, subgroups and islands <https://www.iota-world.org/islands-on-the-air/downloads/download-file.html?path=fulllist.json> * IOTA groups <https://www.iota-world.org/islands-on-the-air/downloads/download-file.html?path=groups.json> * IOTA islands <https://www.iota-world.org/islands-on-the-air/downloads/download-file.html?path=islands.json> * DXCC matches one IOTA <https://www.iota-world.org/islands-on-the-air/downloads/download-file.html?path=dxcc_matches_one_iota.json> * Activations accepted for QSO matching <https://www.iota-world.org/islands-on-the-air/downloads/download-file.html?path=activations_qso_matches.json>

Contesti ID could include the annual International Naval Contest, which is held annually in December -- 73 de OH1MIE Veikko Sr Nieminen oh1mie@... https://www.oh1mie.fi