From dagro at dogparksoftware.com Wed Oct 21 17:43:51 2009 From: dagro at dogparksoftware.com (Don Agro) Date: Wed, 21 Oct 2009 17:43:51 -0400 Subject: [MacLoggerContest] Notes from the Skunkworks Message-ID: <810C183B-50B5-46A2-991F-19EB42BEF8BC@dogparksoftware.com> Some new features in the latest 5.17 betas... ? Added Reports. "Reports" under the Log Menu. Lots more to do here but the Reports Prefs allow you to choose which fields to include. ? Memory Scan List enabled check boxes added. Temporarily enable/disable entries in your scan list. ? Added NOAA propagation to Web Map. Web Map Popup shows you Today, Forecast and Space weather with further links. ? Added Serial IO double buffering. Very techie but increases responsive of the serial driver while reducing load. ? Added Auto Increment numeric end of STX_STRING. Not sure if anyone needs this but I remember someone asking for this in V4. Also added some tool tips to the Contest Panel. ? Added adaptive radio polling. Adjusts the radio polling rate based on activity. ? Internationalized frequencies. Allows are European friends to enter and display 10.000,00 instead of 10,000.00. ? DXCC, Specific Call and All Call Alarms no longer require lookup. Lets the alarms stay active without AUtoLookup messing up your data input. ? QRZ Online XML updated to Version 1.15. Fred at QRZ has been busy cleaning up the QRZ databases and improving the XML feed. 73 de VE3VRW Don Agro From dagro at dogparksoftware.com Sun Nov 1 10:03:45 2009 From: dagro at dogparksoftware.com (Don Agro) Date: Sun, 1 Nov 2009 10:03:45 -0500 Subject: [MacLoggerContest] MacLoggerDX Contest panel Message-ID: <8EEFED4D-93C4-4904-969E-DE0B506AB0CB@dogparksoftware.com> We have had a few requests for changes to the Contest Panel and would like to invite you to share your experiences/frustrations with the Contest Panel and Contest Helper in actual contests. David Ferrington (M0XDF) has generously volunteered to moderate this discussion and to pass on the results so that they can be implemented in the next release of MacLoggerDX V5. David is an avid contester has been a Ham since 2003 and passed his Advanced in the U.K. in 2006. Any suggestions/complaints regarding the Contest panel of the Contest Helper are welcome. Thank you. 73 de VE3VRW Don Agro From dagro at dogparksoftware.com Sun Nov 1 10:08:53 2009 From: dagro at dogparksoftware.com (Don Agro) Date: Sun, 1 Nov 2009 10:08:53 -0500 Subject: [MacLoggerContest] MacLoggerDX Contest panel In-Reply-To: <8EEFED4D-93C4-4904-969E-DE0B506AB0CB@dogparksoftware.com> References: <8EEFED4D-93C4-4904-969E-DE0B506AB0CB@dogparksoftware.com> Message-ID: <2B2BC565-A644-4A57-9A53-1DC3B35CE3C8@dogparksoftware.com> On 2009-11-01, at 10:03 AM, Don Agro wrote: > Any suggestions/complaints regarding the Contest panel of the Contest Helper are welcome. Oops! Sorry, that should have read... Any suggestions/complaints regarding the Contest panel OR the Contest Helper are welcome. 73 de VE3VRW Don Agro From ke1b at richseifert.com Mon Nov 2 09:46:30 2009 From: ke1b at richseifert.com (Rich Seifert) Date: Mon, 2 Nov 2009 07:46:30 -0700 Subject: [MacLoggerContest] MacLoggerDX Contest panel In-Reply-To: <8EEFED4D-93C4-4904-969E-DE0B506AB0CB@dogparksoftware.com> References: <8EEFED4D-93C4-4904-969E-DE0B506AB0CB@dogparksoftware.com> Message-ID: At 10:03 AM -0500 11/1/09, Don Agro wrote: >We have had a few requests for changes to the Contest Panel and >would like to invite you to share your experiences/frustrations with >the Contest Panel and Contest Helper in actual contests. > >David Ferrington (M0XDF) has generously volunteered to moderate this >discussion and to pass on the results so that they can be >implemented in the next release of MacLoggerDX V5. > >David is an avid contester has been a Ham since 2003 and passed his >Advanced in the U.K. in 2006. > >Any suggestions/complaints regarding the Contest panel of the >Contest Helper are welcome. > I am also an avid contester, and for the most part have sort of "given up" on using MLDX except in the most "casual" of contest operations. That said, I appreciate Don and David re-opening the discussion forum on this topic. As has been said here before, I don't think anyone is proposing that MLDX be expanded to become a "full featured" contest logger, as that would really be a digression from its core of users (and the core of its technology). The range of contest exchanges, Cabrillo formats, context checking, etc. is simply enormous and constantly changing. I plan to take some time to *think* about what could reasonably done within the framework of MLDX to improve its "casual" contest capabilities, and will post again when I have organized my thoughts. A few things come immediately to mind, however: -Force all text to uppercase, both in the callsign entry and TXSTRING fields. -Do "dupe" checking "on the fly", i.e., don't require hitting TAB or before giving an indication that a station has been worked before. Yes, this may give some intermediate "false dupes" when, for example, you have already worked KE1B and now are working KE1BYL, but that's OK because the operator knows that he is still entering data. -In the same vein, give a BIG BOLD indication of a dupe, not just a listing of a call in ordinary text in the Contest Helper table. (By the way, this suggestion and the previous one reflect the way Chen does it in cocoaModem.) -Make the contest keyer (both CW and voice) run off of the Function Keys or some similar, one-touch operation. Yes, I know that I can define a Function Key to perform any menu operation under OS X, but that would require I change the key definition every time I change the keyer contents (since the "menu item" then changes). Also, using OS X-style function keys today requires an extra to actually trigger the keyer to send. I will post again when I have had time to think about this more. Thanks for opening the discussion. -- -- Rich Seifert Networks and Communications Consulting rich at richseifert.com 21885 Bear Creek Way (408) 395-5700 Los Gatos, CA 95033 (408) 228-0803 FAX From g0dvj at amsat.org Mon Nov 2 11:12:47 2009 From: g0dvj at amsat.org (Jonathan G0DVJ) Date: Mon, 2 Nov 2009 16:12:47 +0000 Subject: [MacLoggerContest] MacLoggerDX Contest panel In-Reply-To: References: <8EEFED4D-93C4-4904-969E-DE0B506AB0CB@dogparksoftware.com> Message-ID: Hi all. Also an avid contester and I completely AGREE with all of Rich's posting and ideas so far. I look forward to hearing about any other ideas. 73 Jonathan G0DVJ .... (M4U, M5C, M1CRO, G0VHF, M6T, GB7HQ, 3Z0I/1 in contests) -- On 2 Nov 2009, at 14:46, Rich Seifert wrote: > At 10:03 AM -0500 11/1/09, Don Agro wrote: >> We have had a few requests for changes to the Contest Panel and >> would like to invite you to share your experiences/frustrations >> with the Contest Panel and Contest Helper in actual contests. >> >> David Ferrington (M0XDF) has generously volunteered to moderate >> this discussion and to pass on the results so that they can be >> implemented in the next release of MacLoggerDX V5. >> >> David is an avid contester has been a Ham since 2003 and passed his >> Advanced in the U.K. in 2006. >> >> Any suggestions/complaints regarding the Contest panel of the >> Contest Helper are welcome. >> > > I am also an avid contester, and for the most part have sort of > "given up" on using MLDX except in the most "casual" of contest > operations. That said, I appreciate Don and David re-opening the > discussion forum on this topic. > > As has been said here before, I don't think anyone is proposing that > MLDX be expanded to become a "full featured" contest logger, as that > would really be a digression from its core of users (and the core of > its technology). The range of contest exchanges, Cabrillo formats, > context checking, etc. is simply enormous and constantly changing. > > I plan to take some time to *think* about what could reasonably done > within the framework of MLDX to improve its "casual" contest > capabilities, and will post again when I have organized my thoughts. > A few things come immediately to mind, however: > > -Force all text to uppercase, both in the callsign entry and > TXSTRING fields. > > -Do "dupe" checking "on the fly", i.e., don't require hitting TAB or > before giving an indication that a station has been worked > before. Yes, this may give some intermediate "false dupes" when, for > example, you have already worked KE1B and now are working KE1BYL, > but that's OK because the operator knows that he is still entering > data. > > -In the same vein, give a BIG BOLD indication of a dupe, not just a > listing of a call in ordinary text in the Contest Helper table. (By > the way, this suggestion and the previous one reflect the way Chen > does it in cocoaModem.) > > -Make the contest keyer (both CW and voice) run off of the Function > Keys or some similar, one-touch operation. Yes, I know that I can > define a Function Key to perform any menu operation under OS X, but > that would require I change the key definition every time I change > the keyer contents (since the "menu item" then changes). Also, using > OS X-style function keys today requires an extra to actually > trigger the keyer to send. > > I will post again when I have had time to think about this more. > Thanks for opening the discussion. > -- > > -- > Rich Seifert Networks and Communications Consulting > rich at richseifert.com 21885 Bear Creek Way > (408) 395-5700 Los Gatos, CA 95033 > (408) 228-0803 FAX > _______________________________________________ > MacLoggerContest mailing list > MacLoggerContest at dogparksoftware.com > http://seven.pairlist.net/mailman/listinfo/macloggercontest From M0XDF at Alphadene.co.uk Mon Nov 2 11:18:23 2009 From: M0XDF at Alphadene.co.uk (David Ferrington, M0XDF) Date: Mon, 2 Nov 2009 16:18:23 +0000 Subject: [MacLoggerContest] MacLoggerDX Contest panel In-Reply-To: References: <8EEFED4D-93C4-4904-969E-DE0B506AB0CB@dogparksoftware.com> Message-ID: <38B280CE-A9C5-46AE-A53A-1ED63067616E@Alphadene.co.uk> Thanks for taking the time to think about it. I see my role as one of correlating requests, trying to put them in some form of priority and with a 'really must have', down to a 'would be nice but..' type structure so Don has something he can work towards and not have to wade through all the ideas etc. So the more input we get here, the more likely we are to have something Don can implement. I will look back through the archives of this reflector to remind myself of previous ideas as well. I agree, I don't think MLDX will ever replace a contest specific logging program and I don't think that is what Don wants to do either. I think the number of contest formats/rules out there will make it difficult to achieve that without the contest part taking over MLDX and that's not what we want. We should bear in mind Cab-Converter and it's value as the go-between MLDX and Cabrillo. Looking for far more input on this list please. 73 de M0XDF -- Do not meddle in the affairs of Dragons, For you are crunchy and taste good with ketchup! On 2 Nov 2009, at 14:46, Rich Seifert wrote: > At 10:03 AM -0500 11/1/09, Don Agro wrote: >> We have had a few requests for changes to the Contest Panel and >> would like to invite you to share your experiences/frustrations >> with the Contest Panel and Contest Helper in actual contests. >> >> David Ferrington (M0XDF) has generously volunteered to moderate >> this discussion and to pass on the results so that they can be >> implemented in the next release of MacLoggerDX V5. >> >> David is an avid contester has been a Ham since 2003 and passed his >> Advanced in the U.K. in 2006. >> >> Any suggestions/complaints regarding the Contest panel of the >> Contest Helper are welcome. >> > > I am also an avid contester, and for the most part have sort of > "given up" on using MLDX except in the most "casual" of contest > operations. That said, I appreciate Don and David re-opening the > discussion forum on this topic. > > As has been said here before, I don't think anyone is proposing that > MLDX be expanded to become a "full featured" contest logger, as that > would really be a digression from its core of users (and the core of > its technology). The range of contest exchanges, Cabrillo formats, > context checking, etc. is simply enormous and constantly changing. > > I plan to take some time to *think* about what could reasonably done > within the framework of MLDX to improve its "casual" contest > capabilities, and will post again when I have organized my thoughts. > A few things come immediately to mind, however: > > -Force all text to uppercase, both in the callsign entry and > TXSTRING fields. > > -Do "dupe" checking "on the fly", i.e., don't require hitting TAB or > before giving an indication that a station has been worked > before. Yes, this may give some intermediate "false dupes" when, for > example, you have already worked KE1B and now are working KE1BYL, > but that's OK because the operator knows that he is still entering > data. > > -In the same vein, give a BIG BOLD indication of a dupe, not just a > listing of a call in ordinary text in the Contest Helper table. (By > the way, this suggestion and the previous one reflect the way Chen > does it in cocoaModem.) > > -Make the contest keyer (both CW and voice) run off of the Function > Keys or some similar, one-touch operation. Yes, I know that I can > define a Function Key to perform any menu operation under OS X, but > that would require I change the key definition every time I change > the keyer contents (since the "menu item" then changes). Also, using > OS X-style function keys today requires an extra to actually > trigger the keyer to send. > > I will post again when I have had time to think about this more. > Thanks for opening the discussion. > -- > > -- > Rich Seifert Networks and Communications Consulting > rich at richseifert.com 21885 Bear Creek Way > (408) 395-5700 Los Gatos, CA 95033 > (408) 228-0803 FAX > _______________________________________________ > MacLoggerContest mailing list > MacLoggerContest at dogparksoftware.com > http://seven.pairlist.net/mailman/listinfo/macloggercontest From lee at ww2dx.com Mon Nov 2 11:51:41 2009 From: lee at ww2dx.com (Lee J. Imber (WW2DX)) Date: Mon, 2 Nov 2009 11:51:41 -0500 Subject: [MacLoggerContest] MacLoggerDX Contest panel In-Reply-To: <38B280CE-A9C5-46AE-A53A-1ED63067616E@Alphadene.co.uk> References: <8EEFED4D-93C4-4904-969E-DE0B506AB0CB@dogparksoftware.com> <38B280CE-A9C5-46AE-A53A-1ED63067616E@Alphadene.co.uk> Message-ID: Just a reminder that there are many other "contest specific" mac programs out there that do a very good job at that - contesting on the Mac. I would suggest giving some of these a try to see if they meet your needs. Here is a list of a few: SkookumLogger 07/03/09 01:14 From the K1GQ Website: "SkookumLogger is my HF single-op possibly-assisted CW and SSB contesting program for Mac OS X 10.5 (Leopard) or later, running on an Apple Intel computer. It behaves a lot like CT, intentionally. SkookumLogger requires an Elecraft K3 radio and a K1EL WinKeyer USB. " URL: http://web.me.com/wlmyers/K1GQ/SkookumLogger.html RUMped Contest Logger Full features logger with too many features to list here. http://www.dl2rum.de/rumsoft/RUMPed.html There is also a Java logger out there as well: http://www.qsl.net/w1jq/ Hope this helps. 73 Lee WW2DX MacHamRadio.com On Nov 2, 2009, at 11:18 AM, David Ferrington, M0XDF wrote: > Thanks for taking the time to think about it. I see my role as one > of correlating requests, trying to put them in some form of priority > and with a 'really must have', down to a 'would be nice but..' type > structure so Don has something he can work towards and not have to > wade through all the ideas etc. So the more input we get here, the > more likely we are to have something Don can implement. > > I will look back through the archives of this reflector to remind > myself of previous ideas as well. > > I agree, I don't think MLDX will ever replace a contest specific > logging program and I don't think that is what Don wants to do either. > I think the number of contest formats/rules out there will make it > difficult to achieve that without the contest part taking over MLDX > and that's not what we want. We should bear in mind Cab-Converter > and it's value as the go-between MLDX and Cabrillo. > > Looking for far more input on this list please. > 73 de M0XDF > -- > Do not meddle in the affairs of Dragons, > For you are crunchy and taste good with ketchup! > > On 2 Nov 2009, at 14:46, Rich Seifert wrote: > >> At 10:03 AM -0500 11/1/09, Don Agro wrote: >>> We have had a few requests for changes to the Contest Panel and >>> would like to invite you to share your experiences/frustrations >>> with the Contest Panel and Contest Helper in actual contests. >>> >>> David Ferrington (M0XDF) has generously volunteered to moderate >>> this discussion and to pass on the results so that they can be >>> implemented in the next release of MacLoggerDX V5. >>> >>> David is an avid contester has been a Ham since 2003 and passed >>> his Advanced in the U.K. in 2006. >>> >>> Any suggestions/complaints regarding the Contest panel of the >>> Contest Helper are welcome. >>> >> >> I am also an avid contester, and for the most part have sort of >> "given up" on using MLDX except in the most "casual" of contest >> operations. That said, I appreciate Don and David re-opening the >> discussion forum on this topic. >> >> As has been said here before, I don't think anyone is proposing >> that MLDX be expanded to become a "full featured" contest logger, >> as that would really be a digression from its core of users (and >> the core of its technology). The range of contest exchanges, >> Cabrillo formats, context checking, etc. is simply enormous and >> constantly changing. >> >> I plan to take some time to *think* about what could reasonably >> done within the framework of MLDX to improve its "casual" contest >> capabilities, and will post again when I have organized my >> thoughts. A few things come immediately to mind, however: >> >> -Force all text to uppercase, both in the callsign entry and >> TXSTRING fields. >> >> -Do "dupe" checking "on the fly", i.e., don't require hitting TAB >> or before giving an indication that a station has been worked >> before. Yes, this may give some intermediate "false dupes" when, >> for example, you have already worked KE1B and now are working >> KE1BYL, but that's OK because the operator knows that he is still >> entering data. >> >> -In the same vein, give a BIG BOLD indication of a dupe, not just a >> listing of a call in ordinary text in the Contest Helper table. (By >> the way, this suggestion and the previous one reflect the way Chen >> does it in cocoaModem.) >> >> -Make the contest keyer (both CW and voice) run off of the Function >> Keys or some similar, one-touch operation. Yes, I know that I can >> define a Function Key to perform any menu operation under OS X, but >> that would require I change the key definition every time I change >> the keyer contents (since the "menu item" then changes). Also, >> using OS X-style function keys today requires an extra to >> actually trigger the keyer to send. >> >> I will post again when I have had time to think about this more. >> Thanks for opening the discussion. >> -- >> >> -- >> Rich Seifert Networks and Communications >> Consulting >> rich at richseifert.com 21885 Bear Creek Way >> (408) 395-5700 Los Gatos, CA 95033 >> (408) 228-0803 FAX >> _______________________________________________ >> MacLoggerContest mailing list >> MacLoggerContest at dogparksoftware.com >> http://seven.pairlist.net/mailman/listinfo/macloggercontest > > _______________________________________________ > MacLoggerContest mailing list > MacLoggerContest at dogparksoftware.com > http://seven.pairlist.net/mailman/listinfo/macloggercontest From M0XDF at Alphadene.co.uk Mon Nov 2 13:04:20 2009 From: M0XDF at Alphadene.co.uk (David Ferrington, M0XDF) Date: Mon, 2 Nov 2009 18:04:20 +0000 Subject: [MacLoggerContest] MacLoggerDX Contest panel In-Reply-To: References: <8EEFED4D-93C4-4904-969E-DE0B506AB0CB@dogparksoftware.com> <38B280CE-A9C5-46AE-A53A-1ED63067616E@Alphadene.co.uk> Message-ID: <1364D0D4-FE8B-47F3-8D93-FA928F4DC200@Alphadene.co.uk> Thanks for the summary Lee. Yes we agree, there are now quite a few Mac Contest Loggers out there, many more than when MLDX started. As has been said, it is not the intent to rival these programs. There are a number of MLDX users out there who casually contest and don't want to have to learn an entirely new program in order to log contests or perhaps don't want to have to switch over between them, import logs etc. Our aim is to provide the best experience for those users, short of providing a 'full blown' contest logging program. 73 de M0XDF -- Always remember, half the people in the world are above average intelligence! On 2 Nov 2009, at 16:51, Lee J. Imber (WW2DX) wrote: > Just a reminder that there are many other "contest specific" mac > programs out there that do a very good job at that - contesting on > the Mac. > > I would suggest giving some of these a try to see if they meet your > needs. > > Here is a list of a few: > > SkookumLogger > > 07/03/09 01:14 > From the K1GQ Website: > "SkookumLogger is my HF single-op possibly-assisted CW and SSB > contesting program for Mac OS X 10.5 (Leopard) or later, running on > an Apple Intel computer. It behaves a lot like CT, intentionally. > SkookumLogger requires an Elecraft K3 radio and a K1EL WinKeyer USB. " > > URL: http://web.me.com/wlmyers/K1GQ/SkookumLogger.html > > > RUMped Contest Logger > > Full features logger with too many features to list here. > > http://www.dl2rum.de/rumsoft/RUMPed.html > > > There is also a Java logger out there as well: > > http://www.qsl.net/w1jq/ > > Hope this helps. > > 73 Lee > WW2DX > MacHamRadio.com From M0XDF at Alphadene.co.uk Sat Nov 7 13:02:56 2009 From: M0XDF at Alphadene.co.uk (David Ferrington, M0XDF) Date: Sat, 7 Nov 2009 18:02:56 +0000 Subject: [MacLoggerContest] [macloggerdx] Re: Sections in ARRL SS In-Reply-To: References: Message-ID: <53EEE1B2-C29E-4A58-B026-B74C68F95A92@Alphadene.co.uk> Not the goal of MLDX DX, but could be for MLDX contest? Please mail macloggercontest at dogparksoftware.com with this as a proposal, IF, it's something you'd like to see in the contest panel. Please do not go into any further detail on this list (macloggerdx at yahoogroups.com ), since macloggercontest at dogparksoftware.com is the place to do that. Apologies for the cross posting, thank you. 73 de M0XDF -- In theory, there is no difference between theory and practice, but in practice there is. On 7 Nov 2009, at 17:50, w8bc wrote: > I see. I was looking for a little easier way to tell if you have > worked all the sections. Using this method one would have to > manually scroll the log. I think it is probably easier just to use a > piece of paper with all the sections on it and mark them off as > worked. One of the goals of ARRL SS is to work all 80 sections. > There is a sort of prize for this. So some of us amateur contesters > scan the bands looking for a needed section in order to get a "clean > sweep." MLDX would have to read the string in the "Sent" box and > pick up the section. Nice feature but I don't assume that is the > goal of MLDX. > -------------- next part -------------- An HTML attachment was scrubbed... URL: From ke1b at richseifert.com Wed Nov 11 11:48:34 2009 From: ke1b at richseifert.com (Rich Seifert) Date: Wed, 11 Nov 2009 08:48:34 -0800 Subject: [MacLoggerContest] MacLoggerDX Contest panel In-Reply-To: <8EEFED4D-93C4-4904-969E-DE0B506AB0CB@dogparksoftware.com> References: <8EEFED4D-93C4-4904-969E-DE0B506AB0CB@dogparksoftware.com> Message-ID: At 10:03 AM -0500 11/1/09, Don Agro wrote: >We have had a few requests for changes to the >Contest Panel and would like to invite you to >share your experiences/frustrations with the >Contest Panel and Contest Helper in actual >contests. > >David Ferrington (M0XDF) has generously >volunteered to moderate this discussion and to >pass on the results so that they can be >implemented in the next release of MacLoggerDX >V5. > >David is an avid contester has been a Ham since >2003 and passed his Advanced in the U.K. in 2006. > >Any suggestions/complaints regarding the Contest >panel of the Contest Helper are welcome. > OK, here's what I think is probably my biggest "wish" with respect to MLDX contesting. If there was a way for users to create a contest template, the application would naturally grow to support a myriad of contests, large and small. The "Template Editor" would have to be relatively simple to use, i.e., more like a scripting language than writing code. The user should be able to define at least three things: -The fields in the contest exchange (syntax) -The range of valid values (and defaults) for each of those fields (i.e., context checking), and -How pressing certain keys (e.g., space, Return, Tab) cause the cursor to navigate around the fields. There is no particular need to try to "force fit" the contest database into the standard database layout used for everyday logging. Export can be to Cabrillo, or if that is too limiting/cumbersome, at least to a tab or comma-delimited file. From that, one can manipulate the data into whatever format is needed for log submission. The problem, of course, is support when things don't work. Since the contest templates would be user-generated, they would also be subject to the errors and flaws common to non-professional software. That said, over time the more widely-used templates would become more stable and reliable, and the oddballs would fall by the wayside (a Darwinian approach). Once the template syntax and semantics are defined, one could then define various real-time "contest parameters" calculated from the database, e.g., multipliers, run-rates, etc. At some point, though, you have to draw the line and say "this is not a full-blown contest logger; if you want all that stuff, then this isn't the program for you. This is why I regard the "templating" as a much higher value-item than the "real-time scores." Still thinking ? Rich, KE1B -- -- Rich Seifert Networks and Communications Consulting rich at richseifert.com 21885 Bear Creek Way (408) 395-5700 Los Gatos, CA 95033 (408) 228-0803 FAX From M0XDF at Alphadene.co.uk Wed Nov 11 14:05:16 2009 From: M0XDF at Alphadene.co.uk (David Ferrington, M0XDF) Date: Wed, 11 Nov 2009 19:05:16 +0000 Subject: [MacLoggerContest] MacLoggerDX Contest panel In-Reply-To: References: <8EEFED4D-93C4-4904-969E-DE0B506AB0CB@dogparksoftware.com> Message-ID: <3580C154-BD73-445B-A052-38C3FD9F83A8@Alphadene.co.uk> Thank you for your input, you are one a the few who has done so. I'll be reading this completely later and correlating it with others. 73 de M0XDF -- Don?t complain. Nobody will understand. Or care. And certainly don?t try to fix the situation yourself. It?s dangerous. Leave it to a highly untrained, unqualified, expendable professional. On 11 Nov 2009, at 16:48, Rich Seifert wrote: > At 10:03 AM -0500 11/1/09, Don Agro wrote: >> We have had a few requests for changes to the Contest Panel and >> would like to invite you to share your experiences/frustrations >> with the Contest Panel and Contest Helper in actual contests. >> >> David Ferrington (M0XDF) has generously volunteered to moderate >> this discussion and to pass on the results so that they can be >> implemented in the next release of MacLoggerDX V5. >> >> David is an avid contester has been a Ham since 2003 and passed his >> Advanced in the U.K. in 2006. >> >> Any suggestions/complaints regarding the Contest panel of the >> Contest Helper are welcome. >> > > OK, here's what I think is probably my biggest "wish" with respect > to MLDX contesting. If there was a way for users to create a contest > template, the application would naturally grow to support a myriad > of contests, large and small. > > The "Template Editor" would have to be relatively simple to use, > i.e., more like a scripting language than writing code. The user > should be able to define at least three things: > > -The fields in the contest exchange (syntax) > > -The range of valid values (and defaults) for each of those fields > (i.e., context checking), and > > -How pressing certain keys (e.g., space, Return, Tab) cause the > cursor to navigate around the fields. > > There is no particular need to try to "force fit" the contest > database into the standard database layout used for everyday > logging. Export can be to Cabrillo, or if that is too limiting/ > cumbersome, at least to a tab or comma-delimited file. From that, > one can manipulate the data into whatever format is needed for log > submission. > > The problem, of course, is support when things don't work. Since the > contest templates would be user-generated, they would also be > subject to the errors and flaws common to non-professional software. > That said, over time the more widely-used templates would become > more stable and reliable, and the oddballs would fall by the wayside > (a Darwinian approach). > > > Once the template syntax and semantics are defined, one could then > define various real-time "contest parameters" calculated from the > database, e.g., multipliers, run-rates, etc. > > At some point, though, you have to draw the line and say "this is > not a full-blown contest logger; if you want all that stuff, then > this isn't the program for you. This is why I regard the > "templating" as a much higher value-item than the "real-time scores." From g0dvj at amsat.org Wed Nov 11 20:32:59 2009 From: g0dvj at amsat.org (Jonathan G0DVJ) Date: Thu, 12 Nov 2009 01:32:59 +0000 Subject: [MacLoggerContest] MacLoggerDX Contest panel In-Reply-To: References: <8EEFED4D-93C4-4904-969E-DE0B506AB0CB@dogparksoftware.com> Message-ID: <88ECBFCE-1A3A-4469-AD13-15AAD1806890@amsat.org> Hi Rich, David, Don et al. On 11 Nov 2009, at 16:48, Rich Seifert wrote: > At 10:03 AM -0500 11/1/09, Don Agro wrote: >> We have had a few requests for changes to the Contest Panel and would like to invite you to share your experiences/frustrations with the Contest Panel and Contest Helper in actual contests. >> Any suggestions/complaints regarding the Contest panel of the Contest Helper are welcome. > > OK, here's what I think is probably my biggest "wish" with respect to MLDX contesting. If there was a way for users to create a contest template, the application would naturally grow to support a myriad of contests, large and small. Agreed > The "Template Editor" would have to be relatively simple to use, i.e., more like a scripting language than writing code. The user should be able to define at least three things: > > -The fields in the contest exchange (syntax) > > -The range of valid values (and defaults) for each of those fields (i.e., context checking), and > > -How pressing certain keys (e.g., space, Return, Tab) cause the cursor to navigate around the fields. Agreed ... I have included some suggestion for the latter in (2) below. > At some point, though, you have to draw the line and say "this is not a full-blown contest logger; if you want all that stuff, then this isn't the program for you. This is why I regard the "templating" as a much higher value-item than the "real-time scores." Agreed! But if templating is a step too far, then I have some other suggestions ... 1. Simplify the Contest Panel. - remove all generally not needed fields for most contest exchanges - order the fields according to sent and received then other received - keep Freq and Mode reminders on screen but out of the way of data entered - remove date and time because it is already displayed above the contest panel - Grid only appears on the contest panel if a new checkbox in Contest Prefs is checked. (This is for VHF & up contesters). - RSTS & RSTR are both default populated as 599 (if mode is CW) or 59 (if mode is phone). Sent sn is maintained as self-incrementing beginning at 001 (not zero) and displaying leading zeros as 3 figure serials. -------------- next part -------------- A non-text attachment was scrubbed... Name: ContestPanel.png Type: image/png Size: 28015 bytes Desc: not available Url : -------------- next part -------------- 2. Implement specific TAB, SPACE and return actions for field navigation for the contest panel: - TAB moves between all displayed fields in order from left top to right bottom. - SPACE moves directly from Call field to Rcvd sn field then to Rcvd field (then to Grid if included) and then back to Call and so on. - Return behaves like SPACE unless all fields are non-empty in which case the QSO is logged and Call, Rcvd sn and Rcvd fields are cleared ready for the next QSO. - No lookups are done. - Shift-TAB continues to move back one field at a time as at present. 3. Provide an Auto Map Rcvd field to other MLDX field preference: - The drop down selection should include CQ Zone, ITU Zone, Power, First name, State, IOTA. i.e. the Rcvd field contents get auto-copied to the selected field for each contact. The user would set this as appropriate before the contest so for CQWW they would set CQ zone, for IOTA would set IOTA, etc. - Additional preferences should allow the most common configurations to be varied ... (not shown on mockup below): - Exclude serial numbers - Exclude RS(T) reports -------------- next part -------------- A non-text attachment was scrubbed... Name: ContestPrefs.png Type: image/png Size: 38701 bytes Desc: not available Url : -------------- next part -------------- 4. Miscellaneous: - Display the Sent sn at least double size (not shown in mockup above) - If Dupe (as defined in contest helper) is found as typing the call in, turn text or background of the Call field RED. Apologies if any of this is not well explained ... its nearly 2am as I find time to write this over here! 73, Jonathan G0DVJ -- From M0XDF at Alphadene.co.uk Thu Nov 12 19:58:00 2009 From: M0XDF at Alphadene.co.uk (David Ferrington, M0XDF) Date: Fri, 13 Nov 2009 00:58:00 +0000 Subject: [MacLoggerContest] MacLoggerDX Contest panel In-Reply-To: <88ECBFCE-1A3A-4469-AD13-15AAD1806890@amsat.org> References: <8EEFED4D-93C4-4904-969E-DE0B506AB0CB@dogparksoftware.com> <88ECBFCE-1A3A-4469-AD13-15AAD1806890@amsat.org> Message-ID: some comments on Rich's & Jonathan's suggestions - these more or less echo their thinking, I'm just mostly reinforcing it On 12 Nov 2009, at 01:32, Jonathan G0DVJ wrote: >> The "Template Editor" would have to be relatively simple to use, >> i.e., more like a scripting language than writing code. The user >> should be able to define at least three things: > But if templating is a step too far, then I have some other > suggestions ... Yes, I think templating in the form of a script is too far, for the following reasons: it would invariably cause problems as Rich suggested because of syntax errors etc scripting for MLDX is not very MLDX like, better to have some form of preferences selection as has been said, there are other contest logging programs for the Mac out there and some do use templates > - order the fields according to sent and received then other > received I would like to be able to reverse this order, the programs I've come across expect you to enter values in the order of an exchange if you were running (calling CQ), but I search & pounce a lot and generally want to enter values in a different order. So being able to specify the tab order of the fields would be very useful. however, it might result in people (myself included) getting confused as to where they are in the sequence - the jurys still out on this one - I'm leaning to your 'SPACE' idea. > - Grid only appears on the contest panel if a new checkbox in > Contest Prefs is checked. (This is for VHF & up contesters). Yes, that's really important for VHF contests in UK. Can I get some feedback from US contesters about that please - don't take part in US VHF contests from over here, but what a lift that would be if I did :-) > - RSTS & RSTR are both default populated as 599 (if mode is CW) > or 59 (if mode is phone). Sent sn is maintained as self-incrementing > beginning at 001 (not zero) and displaying leading zeros as 3 figure > serials. The way MLDX does this is to start at the number you give it, this allows you to start with a number higher than 001. I think it will also continue from the number currently in the field, so if you needed to skip some numbers (perhaps you had a problem and logged some on paper while you rebooted), you can do. > - Return behaves like SPACE unless all fields are non-empty in > which case the QSO is logged and Call, Rcvd sn and Rcvd fields are > cleared ready for the next QSO. If this is a VHF contest, the RSTR is meaningful (at least in UK), so space should go to that first. We don't always require 'Rcvd sn field' > - Display the Sent sn at least double size (not shown in mockup > above) I'd like to be able to display the exchange I'm sending in large text, this would require a way to enter that in the prefers pane, but something like M0XDF xxx IO91PK where 'xxx' is the serial number I'm sending. This text could be on the RHS of the 'Contest' panel. On the log format, I think just logging this in the normal MLDX log and then producing an ADIF file is the way to go. Then we can use Cab-Converter to create the correct Cabrillo format based on the Contest-ID. I'd like to get CC producing REG1TEST for VHF+ contests too, but that's a different thread. I don't think we want to burden MLDX with calculating the score etc, since I think that involves too much work 'knowing' how thar is done and that's what CC does. I do think it might be worth providing some simple stats on QSOs per hour. I'd like to get more input from everyone on this list and especially the US, I've only seen Rich'sd input from there (thank you Rich). 73 de M0XDF -------------- next part -------------- An HTML attachment was scrubbed... URL: From M0XDF at Alphadene.co.uk Thu Nov 12 20:04:36 2009 From: M0XDF at Alphadene.co.uk (David Ferrington, M0XDF) Date: Fri, 13 Nov 2009 01:04:36 +0000 Subject: [MacLoggerContest] MacLoggerDX Contest panel In-Reply-To: <88ECBFCE-1A3A-4469-AD13-15AAD1806890@amsat.org> References: <8EEFED4D-93C4-4904-969E-DE0B506AB0CB@dogparksoftware.com> <88ECBFCE-1A3A-4469-AD13-15AAD1806890@amsat.org> Message-ID: some comments on Rich's & Jonathan's suggestions - these more or less echo their thinking, I'm just mostly reinforcing it On 12 Nov 2009, at 01:32, Jonathan G0DVJ wrote: >> The "Template Editor" would have to be relatively simple to use, >> i.e., more like a scripting language than writing code. The user >> should be able to define at least three things: > But if templating is a step too far, then I have some other > suggestions ... Yes, I think templating in the form of a script is too far, for the following reasons: ? it would invariably cause problems as Rich suggested because of syntax errors etc ? scripting for MLDX is not very MLDX like, better to have some form of preferences selection ? as has been said, there are other contest logging programs for the Mac out there and some do use templates > - order the fields according to sent and received then other > received I would like to be able to reverse this order, the programs I've come across expect you to enter values in the order of an exchange if you were running (calling CQ), but I search & pounce a lot and generally want to enter values in a different order. So being able to specify the tab order of the fields would be very useful. however, it might result in people (myself included) getting confused as to where they are in the sequence - the jurys still out on this one - I'm leaning to your 'SPACE' idea. > - Grid only appears on the contest panel if a new checkbox in > Contest Prefs is checked. (This is for VHF & up contesters). Yes, that's really important for VHF contests in UK. Can I get some feedback from US contesters about that please - don't take part in US VHF contests from over here, but what a lift that would be if I did :-) > - RSTS & RSTR are both default populated as 599 (if mode is CW) > or 59 (if mode is phone). Sent sn is maintained as self-incrementing > beginning at 001 (not zero) and displaying leading zeros as 3 figure > serials. The way MLDX does this is to start at the number you give it, this allows you to start with a number higher than 001. I think it will also continue from the number currently in the field, so if you needed to skip some numbers (perhaps you had a problem and logged some on paper while you rebooted), you can do. > - Return behaves like SPACE unless all fields are non-empty in > which case the QSO is logged and Call, Rcvd sn and Rcvd fields are > cleared ready for the next QSO. If this is a VHF contest, the RSTR is meaningful (at least in UK), so space should go to that first. We don't always require 'Rcvd sn field' > - Display the Sent sn at least double size (not shown in mockup > above) I'd like to be able to display the exchange I'm sending in large text, this would require a way to enter that in the prefers pane, but something like M0XDF xxx IO91PK where 'xxx' is the serial number I'm sending. This text could be on the RHS of the 'Contest' panel. On the log format, I think just logging this in the normal MLDX log and then producing an ADIF file is the way to go. Then we can use Cab-Converter to create the correct Cabrillo format based on the Contest-ID. I'd like to get CC producing REG1TEST for VHF+ contests too, but that's a different thread. I don't think we want to burden MLDX with calculating the score etc, since I think that involves too much work 'knowing' how thar is done and that's what CC does. I do think it might be worth providing some simple stats on QSOs per hour. **** I'd like to get more input from everyone on this list and especially from the Americas, I've only seen Rich'sd input from there (thank you Rich). 73 de M0XDF From M0XDF at Alphadene.co.uk Fri Nov 13 04:05:22 2009 From: M0XDF at Alphadene.co.uk (David Ferrington, M0XDF) Date: Fri, 13 Nov 2009 09:05:22 +0000 Subject: [MacLoggerContest] MacLoggerDX Contest panel In-Reply-To: References: <8EEFED4D-93C4-4904-969E-DE0B506AB0CB@dogparksoftware.com> <88ECBFCE-1A3A-4469-AD13-15AAD1806890@amsat.org> Message-ID: Chris, I completely agree with you, so do most of the people here. The intention is not to make MLDX into a full contest logger, that's not what we are trying to achieve or want. We are looking to see if we can improve the contest panel of MLDX and make it a little more suitable for casual contesting. for those that want to give contesting a go, have MLDX as their logger and don't want to have to do more to try it (let alone have to go to Wintel for it). So if you have some suggestions for improving MLDX Contest panel, for casual contesting, we love to hear them. 73 de M0XDF -- Ideas are like rabbits. You get a couple and learn how to handle them, and pretty soon you have a dozen. --John Steinbeck, novelist, Nobel laureate (1902-1968) On 13 Nov 2009, at 01:09, EZ Rhino wrote: > Well.... > > I'm afraid that what we all really want is a Mac OSX full blown > contest logger. Like N1MM for Mac. The problem is, MLDX will never > be that. [snip] MLDX when I contest casually, not caring about > scoring. -------------- next part -------------- An HTML attachment was scrubbed... URL: From g0dvj at amsat.org Fri Nov 13 04:56:52 2009 From: g0dvj at amsat.org (Jonathan G0DVJ) Date: Fri, 13 Nov 2009 09:56:52 +0000 Subject: [MacLoggerContest] MacLoggerDX Contest panel In-Reply-To: References: <8EEFED4D-93C4-4904-969E-DE0B506AB0CB@dogparksoftware.com> <88ECBFCE-1A3A-4469-AD13-15AAD1806890@amsat.org> Message-ID: Just a note on philosophy before I comment on David's posting below... Although I am too serious a contester (or not casual enough!!) for MLDX to be aimed at my main needs or the groups I contest with, I am contributing to this debate because I would like to improve how MLDX supports those casual contesters who might work me! I want them (to be as slick as possible! So I would encourage others who still need a dedicated contest logger to also offer ideas how we can improve support for the casual contester in MLDX. However I do use MLDX as a general logger which aggregates all my contest logs and other Qs from any group/software that I end up operating with. On 13 Nov 2009, at 00:58, David Ferrington, M0XDF wrote: >> - order the fields according to sent and received then other received > I would like to be able to reverse this order, the programs I've come across expect you to enter values in the order of an exchange if you were running (calling CQ), but I search & pounce a lot and generally want to enter values in a different order. If you answer me as a S&P station (as opposed to me answering your run) I still want you to give me the info in the 'accepted' order for the contest - in fact its really frustrating for a big gun to have someone making their own order up as they go. You may spend time before you call me filling in stuff that you can deduce from listening to me working the run of others, but SHIFT TAB still allows you to navigate the entry fields backwards and continuous TAB would allow you to circularly move from the last to the first field as well. The order in which you give your callsign and the whole exchange differs between S&P and run modes but the order of the info within the exchange shouldn't. (The only exception I am aware of is some sprint contests where, because you need to know whose frequency it was, some details are reversed). > So being able to specify the tab order of the fields would be very useful. however, it might result in people (myself included) getting confused as to where they are in the sequence - the jurys still out on this one - I'm leaning to your 'SPACE' idea. I didn't imagine a drag and drop to allow individuals to re-order fields was ever on the cards ... hence trying to use the keys we have available to allow improved navigation. >> - Grid only appears on the contest panel if a new checkbox in Contest Prefs is checked. (This is for VHF & up contesters). Furthermore if Grid is selected in Prefs, I would like the Contest Helper panel to do two additional things: - show the calculated distance (Km for Europe/Miles for NA?) between myGrid and the Grid entered at the time of each QSO - show a running status line of the 'ODX' i.e the furthest Q in this current contest in the form Call, HisGrid, Distance. >> - Return behaves like SPACE unless all fields are non-empty in which case the QSO is logged and Call, Rcvd sn and Rcvd fields are cleared ready for the next QSO. > > > If this is a VHF contest, the RSTR is meaningful (at least in UK), so space should go to that first. You mean RSTS and RSTR are both more meaningful (rather than being cue words for what follows) in higher band contesting ... yes I agree. So this is an additional tweak IF grid is selected in the Prefs. >> - Display the Sent sn at least double size (not shown in mockup above) > > I'd like to be able to display the exchange I'm sending in large text, this would require a way to enter that in the prefers pane, but something like > > M0XDF > xxx > IO91PK > > where 'xxx' is the serial number I'm sending. This text could be on the RHS of the 'Contest' panel. How many casual contesters are going to forget to give me their report if we do this? However I don't disagree with having your own exchange as a prompt card type thing displayed somewhere. Its the number that changes each Q that I was primarily concerned about .. especially if the operator gets distracted ... then a glance is all that's needed to have it leap out at them. > I'd like to get CC producing REG1TEST for VHF+ contests too, but that's a different thread. Maybe - I think someone in Region 1 might have to produce a R1T-Converter from ADIF ... I can't see our North American friends being very bothered about a format used for decades in a different IARU region of the world for VHF contests. > I do think it might be worth providing some simple stats on QSOs per hour. It already does this AFAIK .. its a feature in the Contest Helper window which Don added at my suggestion quite a while ago. 73, Jonathan G0DVJ -- From M0XDF at Alphadene.co.uk Fri Nov 13 08:27:21 2009 From: M0XDF at Alphadene.co.uk (David Ferrington, M0XDF) Date: Fri, 13 Nov 2009 13:27:21 +0000 Subject: [MacLoggerContest] MacLoggerDX Contest panel In-Reply-To: References: <8EEFED4D-93C4-4904-969E-DE0B506AB0CB@dogparksoftware.com> <88ECBFCE-1A3A-4469-AD13-15AAD1806890@amsat.org> Message-ID: my comments on Jonathan's comments :-) -- Study without desire spoils the memory, and it retains nothing that it takes in. -- Leonardo da Vinci On 13 Nov 2009, at 09:56, Jonathan G0DVJ wrote: >> I would like to be able to reverse this order, the programs I've >> come across expect you to enter values in the order of an exchange >> if you were running (calling CQ), but I search & pounce a lot and >> generally want to enter values in a different order. > > If you answer me as a S&P station (as opposed to me answering your > run) I still want you to give me the info in the 'accepted' order > for the contest - in fact its really frustrating for a big gun to > have someone making their own order up as they go. You may spend > time before you call me filling in stuff that you can deduce from > listening to me working the run of others, but SHIFT TAB still > allows you to navigate the entry fields backwards and continuous TAB > would allow you to circularly move from the last to the first field > as well. The order in which you give your callsign and the whole > exchange differs between S&P and run modes but the order of the info > within the exchange shouldn't. (The only exception I am aware of is > some sprint contests where, because you need to know whose frequency > it was, some details are reversed). > Oops, think you misunderstood me. I always give a standard exchange as you would expect, yes it annoys me when people don't, but that's casual contesting for you. Yes I was thinking of the order in which you fill fields and yes I agree that the tab/space/return method provides for that. > I didn't imagine a drag and drop to allow individuals to re-order > fields was ever on the cards ... hence trying to use the keys we > have available to allow improved navigation. Yes agreed and simple for Don to implement with no possibility of people getting confused in future. >>> - Grid only appears on the contest panel if a new checkbox in >>> Contest Prefs is checked. (This is for VHF & up contesters). > > Furthermore if Grid is selected in Prefs, I would like the Contest > Helper panel to do two additional things: > - show the calculated distance (Km for Europe/Miles for NA?) > between myGrid and the Grid entered at the time of each QSO > - show a running status line of the 'ODX' i.e the furthest Q in > this current contest in the form Call, HisGrid, Distance. Yes, that should be quite possible (is the same regardless of contest id) and easy to support. > You mean RSTS and RSTR are both more meaningful (rather than being > cue words for what follows) in higher band contesting ... yes I agree. > So this is an additional tweak IF grid is selected in the Prefs. Yes I did mean that > How many casual contesters are going to forget to give me their > report if we do this? However I don't disagree with having your own > exchange as a prompt card type thing displayed somewhere. Its the > number that changes each Q that I was primarily concerned about .. > especially if the operator gets distracted ... then a glance is all > that's needed to have it leap out at them. Agreed, the number we need to send in the most important >> I'd like to get CC producing REG1TEST for VHF+ contests too, but >> that's a different thread. > Maybe - I think someone in Region 1 might have to produce a R1T- > Converter from ADIF ... I can't see our North American friends being > very bothered about a format used for decades in a different IARU > region of the world for VHF contests. I believe NA use REG1TEST for their contest too, but may be mistaken. I will undertake to produce a REG1TEST format as part of Cab-Converter sometime, assume Scott agrees with that and if fits into our CC work. UK Contest committee will take Cabrillo for VHF contest now anyway, although they prefer REG1TEST. >> I do think it might be worth providing some simple stats on QSOs >> per hour. > It already does this AFAIK .. its a feature in the Contest Helper > window which Don added at my suggestion quite a while ago. Ah, I may have missed that. 73 de M0XDF From dagro at dogparksoftware.com Fri Nov 13 15:42:03 2009 From: dagro at dogparksoftware.com (Don Agro) Date: Fri, 13 Nov 2009 15:42:03 -0500 Subject: [MacLoggerContest] New Contest Panel Beta Message-ID: Thanks to the people who have contributed on this list, MacLoggerDX Version 5.19 beta 22 has just been released. Contest panel changes in Beta 22... ? The Log QSO and Clear Fields menu command allows quick field tabbing and logging from the Keyboard. ? The Call Sign field automatically upcases your typing and will do a lookup when you tab out of the field. Make sure to set your Call Book to None in the Lookup Prefs if you are contesting unassisted. ? You can show or hide Contest Panel Fields and Labels based on the Contest Prefs check boxes. ? The Map Rcvd popup in the Contest Prefs will automatically fill in some log fields based on the Rcvd field (SRX_STRING). ? The Call Sign field will flash red if the call is already in your log as you type. This is a Beta not a full release it is intended not as a final solution but as a prototype to encourage further discussion. 73 de VE3VRW Don Agro