From g0dvj at amsat.org Sun Feb 6 18:25:36 2005 From: g0dvj at amsat.org (Jonathan G0DVJ) Date: Sun Feb 6 18:25:39 2005 Subject: [MacLoggerContest] Welcome to the list Message-ID: <1e24c87c2b02c03a5e54abb47fd8bae0@amsat.org> Welcome to this list. The idea here is to spend a bit of time discussing important details of contest logging in general through the use of a number of separate mail threads. Then after we believe we have covered the main details, we should later attempt to focus on identifying the top key agreed features that initially someone like Don could begin with implementing in order to start the process of producing an insanely great contest logging program for Mac OSX. This mail summarises the 3 initial threads of discussion that I will be asking for your views and comments on in separate threads: 1) Contest exchange entry methods - learning from the best of what is around but also is there a better way ? 2) Contest type coverage - how to be as widely/internationally accommodating as possible in terms of supporting different contest events but in that Mac fashion of making it as simple for the user as possible to select XYZ contest and have it ready to use. 3) Contest operator support features: (aside from setup and logging) a) Info the operator needs to optimise his/her effectiveness - dupes, multiplier/bonuses, realtime scoring, rates of scoring, etc. as well as higher level features like: b) Interaction with other shack components (interfaces to Radios, Amplifiers, Rotors, TNCs, Internet, etc.) c) Post-contest entry files, statistics & learning, integration with main station log etc. Clearly there are other important aspects to discuss but let's try to address particular items one at a time so that we don't lose focus. These initial 3 cover a number of the bulleted features that I mentioned in my original "hallucinations" posting to the other list. I have reposted my original list of features below just for reference and information. After we do justice to some individual threads (e.g. the above) I suggest we come back to this original feature list to add/change/prioritise as a consensus. Looking forward to the discussions... 73, Jonathan G0DVJ -- Original post feature list ... > I was dreaming of something like MacLoggerDX but called > MacLoggerContest which had all these features ... > > - Fast entry (no multiple keystrokes) of only contest logging fields > (configurable for any contest requirements no matter what the exchange > required) > > - Real-time checking as callsign characters are typed without touching > other keys/buttons of duplicates, country/band/locator/other > multiplier analysis, beam headings, potential multiplier status, auto > data insertion (zones, area codes, reports, locators etc.) > > - Summary of scoring per band/mode/multipliers/etc. updated after > every entered QSO or edit. > > - Full log editing and re-scoring in real-time according to the > configurable scoring parameters set up in advance > > - Full support for all popular national and international contests in > the calendar (or the ability for users to set up such flexibility), > HF, VHF and UHF contests all supported. > > - Display of partial matches to the standard callsign contest > databases produced by K5ZD for many other contest software (CT, SD, > WriteLog etc.) > > - Import of standard CTY country prefix files used by other logging > software > > - Cabrillo log entry file generation and other post-contest processing > / statistics and integration with MacLoggerDX for your main station > log > > - A tailored contest CW memory keyer feature with very flexible speed > control, maybe even supporting data modes too like having MultiMode > built-in :) > > - A facility to connect to a public/private DX cluster (either on the > net or via RF/TNC) which highlights spots which are potential > multipliers. > > - Rig control functions for auto-logging frequency, allowing fast > changes from a run frequency to S&P VFO > > - SO2R support for 2 radio operation > > - Inbuilt contest voice "keyer" > > - Multi-operator support for logging and statistical analysis of rates > and mults etc. > > - Rendezvous support for Multi-multi operation over ethernet or > airport networks. > > - Integration with Apple's iChat for IM chat between operators in > multi-multi situations, spotting stations etc. > -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: text/enriched Size: 4180 bytes Desc: not available Url : http://seven.pairlist.net/pipermail/macloggercontest/attachments/20050206/707f3261/attachment-0001.bin From g0dvj at amsat.org Sun Feb 6 18:25:56 2005 From: g0dvj at amsat.org (Jonathan G0DVJ) Date: Sun Feb 6 18:26:00 2005 Subject: [MacLoggerContest] Exchange entry methods Message-ID: <5b47ef9ef09ff1eecac13d3dcebb65e0@amsat.org> So this thread is about achieving the best way to accommodate most people's preferred style of logging the contest QSOs in realtime as efficiently, accurately and easily as possible ... To start things off ... Most existing contest loggers approach this in one of 2 basic ways (with different variations) ... 1) The operator is faced with a logging line consisting of separate dedicated fields into which the various parts of the contest QSO exchange are entered and then provided with one or more ways of quickly moving between these fields (e.g. TAB, SPACE, ENTER etc.) When the operator is content that all required data has been logged the QSO is committed to the log. 2) The operator is faced with one single field into which he/she can enter any of part of the contest QSO exchange in any order followed by Enter (or some other key), and the software uses various methods to decipher which should go into which actual field in the log. When all required fields have had some data entered, the QSO can be committed to the log. I note a number of principles that various people have mentioned about this part of the process in other mails ... - for speed, the entry should be entirely keyboard based and no mouse/pointing required - again for speed reasons, as well as ease of thought, single keystrokes should be used (i.e. no sets of key combinations to learn for control functions). - for cases where corrections must be made - it must be easy to amend the right field contents quickly - for some data parts of the exchange (e.g. callsign) it is preferable to reflect information such as potential dupe, potential mult/score, partial matching from standard contest databases such as that maintained by K5ZD as individual characters are typed, not after the whole call has been entered. - for logged data items which the operator need not type, that data is automatically populated by the software from various lookup sources (or a best guess made when possible that can be easily overridden/overtyped) - for reliability and integrity, particularly realising that many contest efforts are from field locations perhaps using generators, QSOs should ideally be sent to disk after they are individually committed, so that if power is lost for example, only uncompleted/uncommitted QSOs might be lost when the system is restarted. - from a computing viewpoint, the application should be multi-threaded in the sense that entering a QSO exchange should not hold up other features happening in background or parallel (e.g. a cw or voice keyer could be running while the operator is entering data from the exchange that he/she has heard). I imagine that different individuals (even within the same team taking turns at operating) will favour one of the two basic ways listed above more than the other. Does it therefore make sense to offer both as alternative tabbed panes in the main window which can be toggled at will to offer the 2 ways to enter QSOs into the same log? Some of the principles listed are easier to uphold in the case of one of the ways than the other. Are there any other ways (existing or novel) that are not variations of one of the 2 described above, which would work? What other principles could we agree on as characteristics of this QSO entry process to add the 6 I have listed above? Please comment ... 73, Jonathan G0DVJ -- From g0dvj at amsat.org Sun Feb 6 18:26:08 2005 From: g0dvj at amsat.org (Jonathan G0DVJ) Date: Sun Feb 6 18:26:11 2005 Subject: [MacLoggerContest] Contest coverage and configuration Message-ID: <04fa210a85206ac5a222acffe063e0e9@amsat.org> So this thread is about achieving a really easy way to specify contest configuration which enables the widest scope of contests to be covered (since people don't want to have to use a different logger for particular events) but at the same time makes it simple for people to say I want to work XYZ contest and the set-up is done for them as far as possible... Again to start things off ... 1) Can we achieve an all-bands contest logger in one insanely great app? VHF/UHF/Microwave contesting is very different to HF contesting and AFAIK most existing software targets the two with separate applications. However there are a lot of common aspects between the two categories of events and although more complex to design, I would encourage us to at least initially aspire to cover the needs of both types of contester within one app. However I do think this is a classic area of where typical Mac software design philosophy can help to allow the things irrelevant to each category of event to be hidden from users as they use the other. If you only do one sort of contesting, you may not be too concerned about comment on this point but spare a thought for those who do both and perhaps would like to achieve consistency and seamlessness whichever weekend (hence event) it is! 2) International scope. It would be good to allow a new insanely great contesting app to cater for as many people as possible and that means providing the flexibility to cope with localisation - this has a number of related aspects ... a) Some contests are only popular in Europe or the USA but not both. Some are only applicable to some areas (e.g. VHF contests in USA or Europe!) By supplying reference files of data for as many different areas as possible (I think I can help here from a European perspective) we can make the appeal of the app as wide as possible. b) Some contests have different objectives and requirements on the operators logging according to where the entrant is located. e.g. in the ARRL DX contests I send a different set of information to that which I receive, being outside the USA and given the fact my objective in this case is different - to work only US stations - so the logging program should help me here by checking prefixes of stations I try to log for example. Whereas in other contests such as CQWW, everyone works everyone and exchanges the same information. By addressing both of these top level types we immediately cater for and support the operator in the best way possible. c) Some countries/areas have different bands (segments) available. For example, in the UK we have a whole series of contests on 4m (70MHz) which other countries don't. Similarly, I don't know if you guys over the Pond have contests on 220MHz ? - a band that we simply don't have over here. It would be nice to ensure that we at least allow logging on all the bands which people in different parts of the globe may need - although again maybe by asking the user one question about station location, the unnecessary/inapplicable options could be hidden. d) In different areas of the globe, within the same language, people use different terminology for the same concepts. This aspect is far less important in my view but mentioned briefly for completeness. One example would be that in North America you often use "Grid squares" (more important in VHF/UHF contesting) whereas over here in Europe people use "Locator" to mean the same thing! There are contests here for example which use grid squares (e.g. WAB - worked all britain) which are not the same as the international locator grid square system :) So just to be aware of these differences. 3) Configuring the exchange. Consider these examples ... One top level contest type is whether the location of the stations contacted is important. For some events, just a report and serial number is exchanged. There may be no multipliers/bonuses or other scoring complexities - simply a fixed number of points per accurately completed QSO logged. So no location or other information is important. This latter type of contest is important for the newer person to contesting or those who want to keep it very simple. Alternatively in other event types, there may be a whole number of ways that the location of the station worked affects the score. Typically sub types of this mean that the score is affected by (a) the call prefix of the station worked and/or (b) other information given in the exchange (such as ITU zone, CQ zone, province, state, county etc.) This scoring may be per band, per mode or per event as a whole. Some events allow for other additional data to be exchanged for points (e.g. fixed items such as name or age, complex QTC information in the WAE DX events) and in others (e.g. RSGB Rotating Postcode events) the information exchanged depends on the information received in the previous QSO! Doubtlessly, some of you will know of other events where additional schemes which can't be fitted at all into the types described here are required. Please comment. 4) Assuming we achieve the configuration of the contest in a typical Mac style user friendly way, is there any worth in using standards to specify and record these definitions of configurations? I have been discussing this aspect at length with Jack W6FB - and although something like XML is an option, we have virtually concluded that this would be overkill and of little value at this point in time. Most software currently uses its own file format. I see the more important aspect as how we make it easy for people to set up for XYZ contest (i.e. the config files are supplied but details hidden from user selection) and also allow new configurations to be defined and added to the distribution as time goes on to accommodate rule changes and new contest events. Maybe initially at least, as many existing contest loggers do, the latter aspect of changing and adding support for new event types could be left to the software author in order that we don't end up with lots of people all using some supplied config facility to create similar but slightly different and to varying degrees untested versions of the setup data files for the same contest :) What do others think? Please add other pre-contest aspects to this thread or new ones as necessary. 73, Jonathan G0DVJ -- From g0dvj at amsat.org Sun Feb 6 18:26:33 2005 From: g0dvj at amsat.org (Jonathan G0DVJ) Date: Sun Feb 6 18:26:35 2005 Subject: [MacLoggerContest] Contest Operator Support Features Message-ID: <1eab74c7de8ff2701fcd621083c6ed74@amsat.org> So this thread is about other support that a contest operator can be provided with from an insanely great contest logger application. To get things going I suggest comments under the following 3 headings ... 1. Information provided to the operator to increase his/her performance & effectiveness while logging ------------------------------------------------------------------------ ----------------------------------------------------------------- (a) Duplicate checking - Can we agree that this is the most essential? It's nice if the potential possibility of a dupe can be subtly signalled as the callsign is being entered and then if confirmed when completed the signal is totally unmissable! Providing look-up information about when the station was previously worked which is causing the dupe including the serial number he/she gave you (if applicable) is ideal. The logger should allow the operator to easily accept the duplicate contact if necessary and reflect the non-scoring aspect of this in the realtime score information presented (see below). What else to do with Duplicate Checking? (b) Multiplier/Bonus checking - This is about signalling that the current QSO being logged is potentially a new mult or bonus opportunity either on the current band/mode or potentially also on another band/mode (in the case of multi-band/multi-mode events). Obviously the realtime summary scores should be updated after the QSO is committed to the log if the mult/bonus totals per band/mode & overall are affected - i.e. the potential was confirmed. Something I have yet to see on other software but wonder if we could be the first, if others think its useful, related to this potential value of the stations you hear (when running a frequency) is to make an easy way to quickly log more than one partial call at a time - since you often get called by more than one station. If the potential value of each was flagged you could select on the basis of value if you desire. At a minimum it could provide a scratch pad of partial calls heard since my increasingly bad short term memory means I often forget what I have heard as a call after completing a QSO with another station. Any comments? What else on Mults? (c) Scoring rates - This gives the operator realtime feedback about his performance, and may imply changing propagation, tiredness and fatigue etc. The precise information should vary per type of contest event but usually include things like QSO's per minute (last 10, last 100 - not just instantaneous average), points per QSO (where this is variable), QSOs per Mult/bonus (how often are mults appearing), and in the case of VHF/UHF type contests where distances are more important, km/miles per QSO, best distance QSO - call, grid locator, distance. Comments? What else? (d) Real time scoring display - This are running totals applying to committed QSOs in the log for the current contest. Not just Total Points Score, but a table showing per band/mode (if applicable) breakdowns of QSOs, Points & Mults (if applicable). Has anyone seen display of time spent on each band/mode (if applicable) provided for reference by any other programs? Just occurred to me that timers running like this in background might help avoid reaching the end of the contest and then thinking - wow I should've spent more time on 40 or cw etc. which can be hard to do/remember while you are running. Comments ? What have I missed? (e) Currently worked station info - This is presenting as much helpful information about the station you are currently trying to work as possible to minimise the time required to complete for example. So if I don't have the full call of someone, but I have their locator (in a VHF event) or prefix (in HF) the software can present a suggested beam heading and distance to that square/country from my location so i (or the computer see below) can turn the antenna to make the signal better and get the rest for example - not something I am going to look at every QSO but when I am having problems etc. Country name look-up is also good based on prefix. A nice touch I have seen in some software is to allow the user to create simple text files which are also optionally looked-up against which match callsign to info like name or grid locator - name may only be an option within the CW keyer to auto insert it in the sent exchange after any greeting - and grid locator may be used as an auto insert in VHF/UHF events - although maybe we can do better than this in the provision of a dedicated locator database for gird locators? Comments? What else? 2. Interaction with other shack components (e.g. interfaces to Radios, Amplifiers, Rotors, TNCs, Internet etc.) ------------------------------------------------------------------------ ------------------------------------------------------------------------ -- - Radio should (if connected) provide frequency/band info to the log as a minimum. Quick QSY & back (remembering the original frequency) is a nice feature when working a station on one band who you realise is a multiplier on another band! Anything else? - Rotor control could act on the bearing info of the station being worked (as mentioned in 1(e) above). Low priority IMHO. - TNC could flag potential mults/bonuses to the operator as they appear as spots on a DX-cluster - similarly for internet connected clusters. Radio (frequency/mode) and/or rotor could act on spotted data if selected while remembering previous working frequency etc, Otherwise just the option of a passive cluster viewing window on might be enough for most people. Some sections of some contest rules (e.g. single operator unassisted) may prohibit cluster use so would we want any flag from the configuration process to govern if a cluster window can be displayed? - Other comments? Lets get details out on the table here - its very easy to invent ideas for making the app more complex but then we will eventually need to arrive at some consensus of what the initial top few priorities are. 3. Post-contest processing (e.g. entry files, statistics & learning by review, integration with main station log etc.) ------------------------------------------------------------------------ ------------------------------------------------------------------------ ----- - Cabrillo output format for log submission to the adjudicators. - ADIF export / integration with other main station logs (e.g. MLDX and others), possibly with some intelligent population of other fields for the main log (such as contest name in the notes field), site/location information, etc. - Export of scoring/mults/rates per hour, rates per operator (multi-op if applicable), lists of countries/grid squares worked per band, history of elapsed time spent on various bands/modes, to something that could be imported to Excel or similar so that the operator or team can learn from each contest effort and try to improve. Again this IMHO is lower priority. Discuss / add as appropriate please ? 73, Jonathan G0DVJ -- From jackbrindle at earthlink.net Sun Feb 6 19:47:00 2005 From: jackbrindle at earthlink.net (Jack Brindle) Date: Sun Feb 6 19:47:05 2005 Subject: [MacLoggerContest] Exchange entry methods In-Reply-To: <5b47ef9ef09ff1eecac13d3dcebb65e0@amsat.org> References: <5b47ef9ef09ff1eecac13d3dcebb65e0@amsat.org> Message-ID: <0f431f43583e4499eaa675f728002b35@earthlink.net> Jonathan and I have been having some rather interesting discussions about these topics for the last few weeks. First. let me thank Jonathan for kicking this off, and for Don hosting it. I think, and hope, that we will get some great ideas from these discussions. As I told Jonathan, I have been working on a carbon-based contest logging program for two years now. It has a LOT of code that works rather nicely. After all this time, it is NOT ready for use in a live contest. I have learned quite a bit along the way, and plan to add more as I move forward. It would not keep me from picking up someone else's program (Don?) if it is better than mine. It has given me quite an appreciation for the things that the PC logging authors have done in order to get to where they are. At this time I mostly use N1MM Logger for my contest logging. The reason? It's free and does the job. My most recent use was in the NA Sprint SSB on Saturday. There were things it pointed out (again) to me that I don't like, and things I do. in fact, all of the PC/Windows programs have features that are very good for contesting. But they all have one things I really don't like - they are not meant for my platform of choice... ;-) The most important area for the user in a contest program is exchange entry. As Jonathan has pointed out, there are two basic ways in current use. > 1) The operator is faced with a logging line consisting of separate > dedicated fields... > 2) The operator is faced with one single field into which he/she can > enter any of part of the contest QSO exchange... Both have plusses and minuses, and some PC programs use either or both methods. The first method has a big problem that at all times you have to know what field you are in. Typing a name into a serial number field gives strange results. Almost all programs use character checking for field entry, so that alphabetic characters are not allowed into numeric fields. Still, typing a name into a number field can be done, and results in no change to the number field, along with frustration after the user discovers that s/he typed the characters for nothing, and now has to re-type them The second is rather interesting, and very challenging to code. Trying to figure out what a piece of data is for requires some magic by the program and its author. Some are easy - the NCJ Sprint has only one numeric field which must be for a serial number. It also has two alphabetic fields, one for name and the other for state/province/country. It is possible that a name might actually look like a state, making it difficult to determine which is which. The ARRL Sweepstakes has two numeric fields - serial number and check. For serial numbers from 1-99, it is impossible to determine whether the numeric data is the serial number or check. PC authors have applied rather interesting logic to these areas, and we can learn from their efforts. There may be other ways of doing this, however. Typing data "blindly" (maybe into a hidden field), having it interpreted, then transferring it into the appropriate fields might be very useful. But there may be other ways that simply have not been considered. Data entry using a tablet and MacOS X's character recognition might produce interesting results - as long as the tablet is not troubled with RFI. There may be other methods that are just waiting for innovation. It should be noted that an area that is mentioned in another thread should also be considered here. Callsign dupe checking and "Super Check Partial" are very useful utilities that directly apply. Dupe checking is a must for contest programs. It must be VERY fast. Having to wait a considerable time for a database to complete an entry search is not acceptable. Unfortunately, some of the PC-based programs have this problem. It is very notable when your QSO count gets above 400 or 500 QSOs and is very aggravating. Super Check partial is something that should be included in any contest program at this point. It not only checks the callsign (and offers possible completions), but also can enter data into various fields. This data has been accumulated from past contests, and may be right or wrong for the current contest. It is very helpful, though, when you are trying to pull a station through QRM, or late in the contest when you have simply typed too many keystrokes. Note that it does not keep the operator from having to copy the entire exchange since the data shown might not be correct. > - for speed, the entry should be entirely keyboard based and no > mouse/pointing required This is the cry of the PC user - but is it really valid? As an example, most ops keep one hand on the transceiver VFO knob in order to QSY for S&P. It seems that an alternative would be (and in practice, is) to use a Powermate for this purpose. Tapping the PowerMate could cause it to perform some other function, like field movement or window selection. Again, this is a rule that came from a time when the PC had very few entry solutions. That no longer applies, and has never applied to our platform. > - again for speed reasons, as well as ease of thought, single > keystrokes should be used (i.e. no sets of key combinations to learn > for control functions). In the PC World, extensive use of multi-keystroke entry is required. We may be saying the same thing differently here, however. Multi-keystroke entry should include command/option + key entries. There are just too few 'F' keys to support the contester's needs. I agree that entries that use two separate keys to be pressed in sequence is definitely not the way to go. > - for cases where corrections must be made - it must be easy to amend > the right field contents quickly Yes! But getting to them quickly is not something that has been properly solved anywhere yet. > - for reliability and integrity, particularly realising that many > contest efforts are from field locations perhaps using generators, > QSOs should ideally be sent to disk after they are individually > committed, so that if power is lost for example, only > uncompleted/uncommitted QSOs might be lost when the system is > restarted. Yes, but in what format? I had an especially aggravating time with N1MM Logger last November when the program crashed and refused to restart. The program uses Microsoft Access database to keep all information, relying on database functions to quickly find the info. Getting at the data is not easy, and pretty much requires the database. I was eventually able to figure out some sequence of actions to get things going again (it still crashed periodically after that due to a flaw in the database info). I learned a very important lesson here - do NOT use a database for data storage. We may wish to discuss the QSO file format, leaving it open (even if the code is not). My own program uses a 128 byte binary format with both fixed and definable fields, depending on the contest. It is read and written very quickly, but because of its binary nature, I am no longer sure that it really is the way to go. For example it keeps the date and time in Unix binary format (number of seconds from Midnight, Jan 1, 1970). Easy for the Mac to use, but not easy for a human to read. Don has experience with this - what do you think? > - from a computing viewpoint, the application should be > multi-threaded in the sense that entering a QSO exchange should not > hold up other features happening in background or parallel (e.g. a cw > or voice keyer could be running while the operator is entering data > from the exchange that he/she has heard). I wouldn't even consider this at present. How the program does its thing should be left to the author, unless a proposal for an open-source project is being made. The Mac inherently gives us the resources we need to keep various tasks out of each other's way. For now, we need to define what the program needs to do, what the user sees, and what it does in reaction to inputs. Enough for my turn on the soapbox. Next... Thanks again, Jonathan. -Jack Brindle, W6FB, ex-WA4FIB ======================================================================= From jackbrindle at earthlink.net Sun Feb 6 19:59:26 2005 From: jackbrindle at earthlink.net (Jack Brindle) Date: Sun Feb 6 19:59:31 2005 Subject: [MacLoggerContest] Contest coverage and configuration In-Reply-To: <04fa210a85206ac5a222acffe063e0e9@amsat.org> References: <04fa210a85206ac5a222acffe063e0e9@amsat.org> Message-ID: <7e6ca35c21169f7e2f30b59001e74b5b@earthlink.net> I don't think I can pass this one up... On Feb 6, 2005, at 3:26 PM, Jonathan G0DVJ wrote: > 4) Assuming we achieve the configuration of the contest in a typical > Mac style user friendly way, is there any worth in using standards to > specify and record these definitions of configurations? I have been > discussing this aspect at length with Jack W6FB - and although > something like XML is an option, we have virtually concluded that this > would be overkill and of little value at this point in time. Actually, my viewpoint is that while XML might be useful, I believe that we need an application that allows the user to create and configure a contest, then write that info to a file (in _some_ format) that s/he or others might use. One such user might be the contest sponsor who would create a contest configuration file that I might import before the contest. The application would then interpret the data, setting thing up the way I wanted, but keeping the rules of the contest intact. In the absence of such a file, I could use the same application to create a configuration file for the contest (and being the nice guy I am, I would post it for others to use ;-) ). I'm not sure i care what the file's format actually is, as long as the contest application can use it. > Most software currently uses its own file format. I see the more > important aspect as how we make it easy for people to set up for XYZ > contest (i.e. the config files are supplied but details hidden from > user selection) and also allow new configurations to be defined and > added to the distribution as time goes on to accommodate rule changes > and new contest events. Maybe initially at least, as many existing > contest loggers do, the latter aspect of changing and adding support > for new event types could be left to the software author in order that > we don't end up with lots of people all using some supplied config > facility to create similar but slightly different and to varying > degrees untested versions of the setup data files for the same contest > :) > What do others think? One thing here of importance is that we do not wish to 're-invent the wheel." There are quite a few files that are commonly used in the PC world (cty.dta, etc) that we really _do_ want to use. Some of the formats are readily available, others require digging. But these are important, containing data we need. As for contest configuration files, perhaps this is an area we can help to standardize and give back to the PC folks. by the way, i find the PC authors to be helpful for our efforts. As long as we are not directly competing with them (different platform), then they are willing to help. Even then, there is a lot of cooperation between those folks. Amazingly friendly and helpful, these folks called hams! -Jack Brindle, W6FB ======================================================================= From jackbrindle at earthlink.net Sun Feb 6 20:40:41 2005 From: jackbrindle at earthlink.net (Jack Brindle) Date: Sun Feb 6 20:40:47 2005 Subject: [MacLoggerContest] Contest Operator Support Features In-Reply-To: <1eab74c7de8ff2701fcd621083c6ed74@amsat.org> References: <1eab74c7de8ff2701fcd621083c6ed74@amsat.org> Message-ID: <3a34af0e69315074fd6f88959aeb4adb@earthlink.net> On Feb 6, 2005, at 3:26 PM, Jonathan G0DVJ wrote: > (b) Multiplier/Bonus checking - This is about signalling that the > current QSO being logged is potentially a new mult or bonus > opportunity either on the current band/mode or potentially also on > another band/mode (in the case of multi-band/multi-mode events). > Obviously the realtime summary scores should be updated after the QSO > is committed to the log if the mult/bonus totals per band/mode & > overall are affected - i.e. the potential was confirmed. > Something I have yet to see on other software but wonder if we could > be the first, if others think its useful, related to this potential > value of the stations you hear (when running a frequency) is to make > an easy way to quickly log more than one partial call at a time - > since you often get called by more than one station. If the potential > value of each was flagged you could select on the basis of value if > you desire. At a minimum it could provide a scratch pad of partial > calls heard since my increasingly bad short term memory means I often > forget what I have heard as a call after completing a QSO with another > station. Interesting, but useful? This might come from an HF-only perspective, but I have been convinced by the local big guns that it is better to concentrate on getting as many QSOs as possible and not mults. Along the way mults will come. Yes, there are a few times that all caution should be thrown to the wind and you may go after that last mult. But in general it is a bad idea that ends up wasting time. Having said that, this is a case where packet spots come in very handy. With _valid_ information from that facility, it would be rather easy to note that a certain spot is a new multiplier. this _is_ commonly presented. Showing it from other data generally not reliable. An idea might be to allow the user to keep entries of stations heard, but not worked, just in case you come across them again. The computer could alert you when a spot shows up, for example. > - Radio should (if connected) provide frequency/band info to the log > as a minimum. I believe this is a must! I should not have to remember information that is very easily obtained from the radio. Also, this can provide a cross-check to make sure you are within the proper parameters (band edges, mode, etc). > - Rotor control could act on the bearing info of the station being > worked (as mentioned in 1(e) above). Low priority IMHO. One of the principal reasons that I recently changed calls (WA4FIB -> W6FB) is that in every contest I had at least one QSo where the other guy would have a great signal, only to fade into oblivion as he turned his antenna away from California and towards Florida. It can be useful, but also very harmful. Now I do believe that control of the rotor should be allowed through the contest program, just like control of everything having to do with the station should (antenna selection is a great one!). It should be user-selectable as to whether it is automatic or not. > - TNC could flag potential mults/bonuses to the operator as they > appear as spots on a DX-cluster - similarly for internet connected > clusters. Radio (frequency/mode) and/or rotor could act on spotted > data if selected while remembering previous working frequency etc, > Otherwise just the option of a passive cluster viewing window on might > be enough for most people. Some sections of some contest rules (e.g. > single operator unassisted) may prohibit cluster use so would we want > any flag from the configuration process to govern if a cluster window > can be displayed? Packet spotting is another mandatory feature in contest software these days. It must allow connections through the internet, and should also allow the use of a TNC. It is interesting that use of internet connected spotting has far overtaken the use of packet-radio based spotting. The two use the same data formats, but the internet has proven more reliable. Other equipment should be controlled as well. The next generation of amplifiers is/will provide a data interface for control. While accessories such as DVR are being moved into the contest program, there are other things that are beginning to be made available externally. > - ADIF export / integration with other main station logs (e.g. MLDX > and others), possibly with some intelligent population of other fields > for the main log (such as contest name in the notes field), > site/location information, etc. Support of ADIF is a pain for the programmer, but probably needed in the program. Should it support new ADIF definitions or even the XML-ADIF currently in the works? I would really like to hear Don's opinion on this. There is something very notably missing in Jonathan's writings - SO2R. In HF contesting these days, SO2R is rapidly becoming a must if you want to compete. Support for SO2R has ramifications in many areas, including rig control and information display, band maps, equipment (non-rig) control and user interface. Some of the PC-based programs have two exchange entry areas, one for each radio! Exactly how this all works and plays together is still an art and not a science, since the arena of SO2R is still developing. it would be interesting to hear from hams with SO2R experience for their ideas on how a station should work, and how it should be presented to the operator through the computer. I guess I might add that my view of contest /station software is that each piece of equipment is modeled in the program, and presented to the user in some fashion. An antenna rotor might be presented as an azimuthal map of the world with a pointer showing the direction. The radio could be a bandmap with a pointer indicating the current frequency. Spots would show up on the bandmap. The antenna system is an area ripe for modeling, with each antenna having some sort of indicator which shows the specific aspects of the antenna (direction, SWR, etc). Integrating all this and presenting a useful display to the operator that is not overpowering, even in the late stages of a contest when the op is very tired, is an interesting and challenging task for the developer. -Jack Brindle, W6FB ======================================================================= From K1GQ at kc1xx.com Sun Feb 6 22:51:00 2005 From: K1GQ at kc1xx.com (K1GQ) Date: Sun Feb 6 22:51:29 2005 Subject: [MacLoggerContest] Exchange entry methods In-Reply-To: <5b47ef9ef09ff1eecac13d3dcebb65e0@amsat.org> References: <5b47ef9ef09ff1eecac13d3dcebb65e0@amsat.org> Message-ID: On 2005 Feb 06, at 18:25, Jonathan G0DVJ wrote: > I note a number of principles that various people have mentioned about > this part of the process in other mails ... [snip of list of principles that omits this one:] - It must be possible to initiate sending a QSO exchange message that includes the other station's call sign without having completed entry of the call sign. That is, as long as I type (or edit) a character in the call sign before it is sent, it will be sent properly. Strictly speaking this isn't about exchange entry, but how exchange entry is implemented can impair this feature -- which is a show-stopper for me. K1GQ From jbastin at sssnet.com Mon Feb 7 08:23:27 2005 From: jbastin at sssnet.com (John Bastin) Date: Mon Feb 7 08:23:33 2005 Subject: [MacLoggerContest] Exchange entry methods In-Reply-To: References: <5b47ef9ef09ff1eecac13d3dcebb65e0@amsat.org> Message-ID: On Feb 6, 2005, at 10:51 PM, K1GQ wrote: > On 2005 Feb 06, at 18:25, Jonathan G0DVJ wrote: > >> I note a number of principles that various people have mentioned >> about this part of the process in other mails ... > > [snip of list of principles that omits this one:] > > - It must be possible to initiate sending a QSO exchange message that > includes the other station's call sign without having completed entry > of the call sign. That is, as long as I type (or edit) a character in > the call sign before it is sent, it will be sent properly. > > Strictly speaking this isn't about exchange entry, but how exchange > entry is implemented can impair this feature -- which is a > show-stopper for me. > > K1GQ I'll also want to see this feature. This is a fairly common feature in the DOS and Windows programs that I've used, allowing me to correct typos in the latter part of the callsign while the first part is already being transmitted. If I had to wait until the entire callsign was complete and correct in my log before the software started sending the exchange, it would be a significant slowdown. 73, John E Bastin, K8AJS jbastin@sssnet.com http://www.qsl.net/K8AJS From g0dvj at amsat.org Mon Feb 7 14:27:27 2005 From: g0dvj at amsat.org (Jonathan G0DVJ) Date: Mon Feb 7 14:27:35 2005 Subject: [MacLoggerContest] SO2R features In-Reply-To: <3a34af0e69315074fd6f88959aeb4adb@earthlink.net> References: <1eab74c7de8ff2701fcd621083c6ed74@amsat.org> <3a34af0e69315074fd6f88959aeb4adb@earthlink.net> Message-ID: <8a54695a9d5ca8fdbb918355f6bdb5da@amsat.org> Hi all Glad to see all the thread discussions taking place - I have some comments but want to leave space for others to give theirs first since I structured the initial topics and don't want to dominate the input. However, just one thing for now ... On Feb 7, 2005, at 1:40 am, Jack Brindle wrote: > There is something very notably missing in Jonathan's writings - SO2R. > In HF contesting these days, SO2R is rapidly becoming a must if you > want to compete. Support for SO2R has ramifications in many areas, > including rig control and information display, band maps, equipment > (non-rig) control and user interface. Some of the PC-based programs > have two exchange entry areas, one for each radio! Exactly how this > all works and plays together is still an art and not a science, since > the arena of SO2R is still developing. it would be interesting to hear > from hams with SO2R experience for their ideas on how a station should > work, and how it should be presented to the operator through the > computer. SO2R was in my original posting on the other list and I was leaving it for a future thread here. But over the weekend I saw an interesting post from CT1BOH on the CQ-Contest mailing list about SO2R on the PC and so I wanted to bring it to the table here and earlier now that Jack has raised the topic. In the same way that Don's other software often allows various add-on devices to be used to control things (e.g. SarTek rotor controller), we should consider when a contest feature would be best achieved by having a MacLoggerContest (MLC) that is compatible / designed to work with the best external units that are out there for things that us contest ops need that don't need to be directly implemented by the software itself. Maybe (?) one of these would be an SO2R controller like Jose describes experience of below. Either way I found reading his experiences interesting. It is quite a long posting to include but I didn't want to extract bits individually so hopefully you will stick with it. 73, Jonathan G0DVJ -- On Feb 5, 2005, at 5:18 pm, CT1BOH - Jos? Carlos Nunes wrote: > I am constantly thinking of ways to improve my final score, focusing > in the operating side of the game. > > Being a user of the main contest logging programs and an SO2R addicted > I always felt there was room for huge improvements, not only in what > the control of the SO2R equipment by the contest software is > concerned, but also in the information and statistics available to the > operator, to help him adjust his strategy, throughout the contest. > > I recently came across two products - a contest logging software > (www.win-test.com) and an all in one PC-Radio interface, SO2R and DVK > box - EZmaster (www.hamradiosolutions.com). Thanks to Win-Test > contest logging software authors, some exciting and new features were > recently developed and are now available to the contesting community. > I have no commercial interest in these products. I was offered a free > Win-Test version, the authors seem to like my ideas and I paid for my > EZmaster. > > PC USB CONTROL > > For the first time it is possible to control radios, antennas, SO2R > functions, etc, with only one cable going out of the PC into the all > in one PC-Radio interface box. With this USB cable, the contest > logging software will control the EZmaster and all the equipment > around connected to the EZmaster. Forget LPT or COM ports. If your > PC has one USB port, this is all you need. > > ADVANCED SO2R MANAGEMENT > Until now the contester would have to control the SO2R functions in an > external SO2R box. Not anymore. Now, with Win-Test and EZmaster, > the contester can control everything from the PC, but more > importantly, Win-Test will choose the receiving setting of the > headphones, automatically, depending of the moment of the QSO and > predefined contest scenarios. This is a great advancement. Forget > manual settings. Pre-define all the receiving and transmitting > settings, of both radios, according to each moment of a contest QSO. > > Although all SO2R products control the headset audio automatically to > listen to the second radio (R2R2) in both ears while the first radio > is transmitting, it is up to the user to decide and control when to > listen to the first radio (R1R1) or to both radios (R1R2) during > non-transmitting moments. This is a very tiring process in a 48-hour > event or in a very intense event like the Sprint contest. > > Win-Test introduces a new concept - Advanced SO2R mode. This mode will > control automatically everything according to: > The moment of the QSO > Pre-defined scenarios > Win-Test comes with five pre-defined scenarios: > "Small pile-up" > "Big-pile up" > "Work multiplier" on second radio while keeping a run > "Check band" for possible move to another band > "Alternate CQ" in two bands > > Apart from these pre-defined scenarios, the user can define and add > extra scenarios. It's up to his imagination, because Win-Test is very > flexible and easy to set-up. Take a look at the example below that > explains better this new concept, with a simulated QSO between P40E > using Advanced SO2R and CT1RB. > The chosen scenario is "big-pile up" mode. The moments of the QSO > are defined by P40E actions in the contest-logging program. > Moment 1 begins when P40E pushes F1 to broadcast his contest call. > Moment 3 begins when P40E pushes INSERT to start the QSO with CT1RB > Moment 5 begins when P40E pushes + to finish the QSO with CT1RB > > Note when CT1RB sends his call in the pile-up in moment 2, P40E is > listening with both ears in the run radio (R1R1), because there is a > big pile-up going on, and he does not want to miss part of a call. If > the mode would be "Small pile-up" the setting would be R1R2 instead of > R1R1, because the risk of loosing letters of the call in the pile-up > is small. > > Moment RX/TX P40E headphone > setting > Moment1: TEST P40E R2R2 > Moment2: ct1boh R1R1 > Moment3: CT1BOH 5999 R2R2 > Moment4: tu 59914 R1R2 > Moment5: TU P40E R2R2 > > Take notice that the user does not touch any button, or the external > SO2R box. It is Win-Test that automatically moves the headphones > settings of EZmaster from R2R2 to R1R1 to R1R2 according to the moment > of the QSO. Let's now check "work-multiplier mode". I will focus in > the part a station is working a multiplier spotted in the second > radio. This mode is a little bit more interesting because it involves > automatic transmitting: Imagine P40E is running his pile-up in radio1 > and spots ZD8Z with the second radio. While he calls and works ZD8Z, > he wants to make sure he keeps his running frequency busy and at the > same time, eventually copy another call for his run in radio1, in case > ZD8Z does not come back to his call in radio2. > > P40E spotted ZD8Z on the second radio and is ready to send his call to > ZD8Z pile-up. > P40E pushes SHIFT+F4 and this will send the content of F4 message into > the second radio plus his call into the first radio. (Just a note to > explain why the SHIFT key plus F4. In Win-Test, when a user pushes any > F1-F7 key this sends the content of F# key to radio 1. When the user > pushes SHIFT+F# key, this will send the content of the F# key to > radio2) > > Now if you are used to the old generation contest logging software you > would expect the content of F4 key to be just your call, F4=P40E, in > this example. Well not with this new generation contest logging > software. The content of F4 key, is the $F4 (P40E) plus audio control > (radio1 and radio2) and transmitting control (radio1 and radio2). > F4 setting key in Win-Test would be the following: > F4 = $R1R1 $F4 $R2R2 $TR2 $MSG1 $R1R2 > This means that P40E after pushing SHIFT+F4 to send his call in radio > 2 to ZD8Z pile-up, Win-Test will do the following: > > Move the audio setting of the headphone to both ears into radio1 > ($R1R1) and send P40E ($F4) in radio 2 > After $F4 (P40E) is sent, automatically, Win-Test moves the audio > setting to the second radio in both ears ($R2R2), so that P40E can > check if ZD8Z comes back to his call, and at the same time the content > of $MSG1 (in this case TEST P40E) will be sent into secondary radio > ($TR2 $MSG1) in this case radio1, and after this is done, Win-Test > will change the audio setting of the headphones to both radios > ($R1R2). At this time P40E will have one ear in radio1, to get a call, > to continue the pile-up, in radio1, if ZD8Z does not reply in radio2 > and another ear in radio2 to work ZD8Z, if ZD8Z replies to P40E call. > > What if you don't like these settings? Well changing it is as easy as > changing the content of F# keys in old generation logging software. > Just edit it and R#R#, $TR# whatever you want. Listen to the radios > as you like when you like according to the moment of the QSO. > As you see the user can program every transmitting and receiving > settings according to his scenarios, with full flexibility and > control. Also, in any moment, no matter what the automatic pre-defined > setting, he can manually change it. > > This is a very powerful and innovative way of operating, totally > automatic, only now possible with Win-Test and Ezmaster. > > Go to this address to view an example of the scenario configuration > window: http://ct1boh.no.sapo.pt/pics/scenarios.jpg > Go to this address to view an example of the SO2R (Primary radio - > the log, Secondary radio, Radio1 and Radio2) windows: > http://ct1boh.no.sapo.pt/pics/so2r.jpg > > CALLSIGN FEEDING and SO2R WINDOW > > Another interesting aspect of Win-Test is the way to feed calls into > radio1 and radio2. A big problem an SO2R operator has to face is the > fact he is running with 2 radios but only has one keyboard. Sometime > checking if a call is a multiplier or not is not very easy, especially > if there is a run going on at the same time. > TR users will push ALT and D keys write a call and then hit ENTER to > check if a call is a multiplier. > CT users can do this procedure in a more efficient way, because the > computer puts the radio 2 log entry field in front, automatically, > while radio 1 is transmitting. All the operator has to do is type a > call, saving ALT key , D key and ENTER key. Although this is very > efficient (I had the idea, and asked K1EA to implement it), the timing > takes a little to get used to and is dependent on the transmission of > radio1. > > Win-Test proposes two ways to solve the problem, dependent only of the > user will. While the user pushes the SHIFT key, this signals the > program that whatever is typed into the keyboard goes into the second > radio log entry field or while the user pushes a footswitch whatever > he types into the keyboard goes into the second radio log entry field. > Automatically, letter by letter of a callsign typed in the log field > entry, Win-Test tells the user if it is a new multiplier or not. > > Because Win-Test is a window based program there is a window with all > the information regarding the SO2R management and with the callsign > field of the secondary radio. In this window the user will check which > is the active radio, where he is listening (R1R1; R1R2; R2R2), where > he is transmitting (TX1; TX2). It is also in this window that the user > can, at any time of the moment of the QSO, change the audio setting > automatically defined by the moment of the QSO, and by the different > scenarios. This manual setting will be valid only during that moment. > When any transmission begins and a new QSO moment begins, Win-Test > automatic setting, take control. This way the user has total > flexibility to control the audio setting of his radios. > > > > STATISTICAL INFORMATION > Another aspect I always thought could be improved in contest logging > software is statistical information available to the operator. > Win-Test is very strong in this regard: > Rate Window > Apart from the normal "Last Hour", "Last 10", "Last 100", "Since > beginning of hour", rate information, Win-Test displays a moving graph > (15 column) of the rate. This moving graph can be computed in a 5, 10, > 15, 20 or 30 minute period. The rate itself can be displayed as > "QSO/Hour", "Points/QSO", "QSO points/hour" or "Points/hour". All this > can be changed with two clicks. > Go to this address to view an example of the rate window: > http://ct1boh.no.sapo.pt/pics/rate.jpg > > Real versus Objective Graph Window > Another interesting and for the first time available in a contest > logging software is Objective Tracking. Imagine you set goals for > your contest operation: > QSO goals > Multipliers goals > Score goals > > Win-Test will track real time information of your QSOs, Multipliers > and Score, comparing them, real time, every QSO, against the goals > defined in an objective file and will display a Real minus Objective > graph of the information. This way you can keep pushing for the record > or for your particular objective. > > You can even change at any given time during the contest, the > objective file. The user can define for example, three objective > files, and choose any, according to propagation, or his specific > performance. > > Go to this address to view an example of the objective window > http://ct1boh.no.sapo.pt/pics/objectives.jpg > In the picture you can see P40E 2003 real versus objective (SOAB world > record), at the end of the contest. > > Other Graph Windows > The user also has the possibility to plot real time, all sorts of > graphs: QSOs, Multipliers, points, Average points per QSOS, DXCC, > Zones, etc) > > MAP Window > There is world map window with grayline information, and under > development is a very interesting feature that will tell the user, > using a color intensity layer, the percentage of QSOs coming from the > different parts of the world. This will be very useful for the > decision making process, what band to operate, etc. > > Other Windows > There are many other windows available I just mention a few: > Solar Activity graph window (Solar Flux, A, K) > Ham Cap Propagation prediction interface window > > Anyway, there are so many other little things available, but I leave > that to you to explore. > Win-Test is definitely a next generation contest logging software, and > with an Ezmaster attached, advanced SO2R is possible, surely, a dream > come through, for the serious contester. > > Jos? Nunes CT1BOH > www.qsl.net/ct1boh From g0dvj at amsat.org Mon Feb 7 14:52:41 2005 From: g0dvj at amsat.org (Jonathan G0DVJ) Date: Mon Feb 7 14:52:45 2005 Subject: [MacLoggerContest] Fwd: Contest Logger for Macs Message-ID: On Feb 7, 2005, at 12:59 am, Jack Brindle wrote: > by the way, i find the PC authors to be helpful for our efforts. As > long as we are not directly competing with them (different platform), > then they are willing to help. Even then, there is a lot of > cooperation between those folks. Amazingly friendly and helpful, these > folks called hams! As an example of what Jack has said, I have been in contact with Paul O'Kane who writes the Super Duper (SD) contest software for Windows which has as large a following across Europe as some of the other PC software does in North America. Apart from offering to maybe comment on the threads here he has also sent me the following from his experience of SD... just for info. I think there is a useful comment about setting our sights, about new or distinctive features, and about the importance of the input routine. Begin forwarded message: > From: Paul O'Kane > Date: February 7, 2005 7:21:02 pm GMT > > Hello Jonathan, > > Are you going for the top-end of the market - with multi-multi and > SO2R support? It's getting very crowded up there, and fiendishly > difficult from the technical point of view. All I'm saying is don't > set your sights too high or your project will never be implemented. > Also, unless you introduce some really useful new features, you'll > not get any converts from PCs/Windows. > > I'd recommend that you pay attention to your data input routine. In > SD's routine, I have about 1500 lines of code, and that's one of the > reasons I can do some "neat" things while prefixes are being entered > - without the need to touch any other key. There's about 83,000 lines > of code in SD at present. > > 73, > Paul EI5DI > 73, Jonathan G0DVJ -- -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: text/enriched Size: 1867 bytes Desc: not available Url : http://seven.pairlist.net/pipermail/macloggercontest/attachments/20050207/82dcdfe0/attachment.bin From ted at hawaii.edu Mon Feb 7 15:30:59 2005 From: ted at hawaii.edu (Ted Brattstrom) Date: Mon Feb 7 15:31:57 2005 Subject: [MacLoggerContest] Contest Logger for Macs Message-ID: <103630100ea3.100ea3103630@hawaii.edu> Aloha - I checked in here a little late, so I didn't get the "list" of items :-) However, most of what I've seen is good- though I'd like to make 2 pleas :-) 1- in addition to the full on - does everything - contest logging system... have a nice, simple, contesting option :-) :-) no bells, no whistles :-) 2- as one of the "Contests" - please have a "DXpedition mode" - no dupe checking - all band - all mode... the style is similar - all you need to do is get the Call... and maybe write a signal report... :-) ease of entry, minimal key strokes, minimal mouse moovements!!! 73 and aloha - ted - nh6yk From jackbrindle at earthlink.net Mon Feb 7 16:22:35 2005 From: jackbrindle at earthlink.net (Jack Brindle) Date: Mon Feb 7 16:22:39 2005 Subject: [MacLoggerContest] SO2R features In-Reply-To: <8a54695a9d5ca8fdbb918355f6bdb5da@amsat.org> References: <1eab74c7de8ff2701fcd621083c6ed74@amsat.org> <3a34af0e69315074fd6f88959aeb4adb@earthlink.net> <8a54695a9d5ca8fdbb918355f6bdb5da@amsat.org> Message-ID: First - can the list "mom" change the reply setting so that replies automatically go to the list? At least that's my request. On Feb 7, 2005, at 11:27 AM, Jonathan G0DVJ wrote: > SO2R was in my original posting on the other list and I was leaving it > for a future thread here. But over the weekend I saw an interesting > post from CT1BOH on the CQ-Contest mailing list about SO2R on the PC > and so I wanted to bring it to the table here and earlier now that > Jack has raised the topic. In the same way that Don's other software > often allows various add-on devices to be used to control things (e.g. > SarTek rotor controller), we should consider when a contest feature > would be best achieved by having a MacLoggerContest (MLC) that is > compatible / designed to work with the best external units that are > out there for things that us contest ops need that don't need to be > directly implemented by the software itself. SO2R in a contest program is not just about working with external controllers but far more about how the radios are represented and handled. There are fundamental items such as how a radio's controls are displayed, its band map, etc. Even more, how exchange data is input and tagged to a specific radio (and thus its band/frequency). How this is presented to the user is something that needs to be understood up front and properly architected. The big problem with doing this is that it takes someone who is really comfortable with SO2R operation to be able to say how things should be done. Unfortunately different ops do things their own way, and there really is no commonly accepted way of handling and displaying SO2R information yet. Having said that, once a proper framework is in place, it actually becomes relatively easy to enhance the user experience with various additions and external controllers as well as making subtle changes in the UI. One other benefit is that a program architected for SO2R is very readily useful in SO1R operation. In fact going to SO2R really involves just plugging in a second radio. Is there anyone on the list who is deeply into SO2R and would like to comment on how they would like to have things done? While talking fundamentals, it would be interesting to hear Don's take on handling different radio types. I only have to worry about a K2, but that doesn't help the folks with other radios... ;-) Plug-in architecture, maybe? - Jack Brindle, W6FB ------------------------------------------------------------------------ --------------------- From dagro at dogparksoftware.com Mon Feb 7 16:51:12 2005 From: dagro at dogparksoftware.com (Don Agro) Date: Mon Feb 7 16:51:13 2005 Subject: [MacLoggerContest] List & Development issues - was- SO2R features In-Reply-To: References: <1eab74c7de8ff2701fcd621083c6ed74@amsat.org> <3a34af0e69315074fd6f88959aeb4adb@earthlink.net> <8a54695a9d5ca8fdbb918355f6bdb5da@amsat.org> Message-ID: <51d1bc706d82ca98a18475218ef66259@dogparksoftware.com> Hi Jack, On 7-Feb-05, at 4:22 PM, Jack Brindle wrote: > First - can the list "mom" change the reply setting so that replies > automatically go to the list? At least that's my request. The administrative interface to the list suggests... "Where are replies to list messages directed? Poster is strongly recommended for most mailing lists". A simple "Reply" will go to the poster, a "Reply All" will include the list as well. In my experience defaulting the "Reply" to the list results in a lot of accidental publication to the list of messages that the poster only intended to go to the originator, this can result in some embarrassing situations but if anyone feels strongly about this for any particular reason ? > While talking fundamentals, it would be interesting to hear Don's take > on handling different radio types. I only have to worry about a K2, > but that doesn't help the folks with other radios... ;-) Plug-in > architecture, maybe? MacLoggerDX handles over 60 radios and since I don't have them all - I put a lot of work into the debug logging so that if something goes wrong I can be there - without actually being there. On the plus side Plug-in architecture decreases the size of the download and allows incremental download of new drivers and 3rd party development to a published standard. On the negative side it makes support somewhat more complex since you need the driver version as well as the program version to reproduce the problem and in the case of a 3rd party driver can result in a finger pointing nightmare. 73 Don Agro VE3VRW D o g P a r k S o f t w a r e L t d . email: dagro@dogparksoftware.com www: http://www.dogparksoftware.com iChat AV:dogpark@mac.com From g0dvj at amsat.org Mon Feb 7 16:51:37 2005 From: g0dvj at amsat.org (Jonathan G0DVJ) Date: Mon Feb 7 16:51:42 2005 Subject: [MacLoggerContest] SO2R features In-Reply-To: References: <1eab74c7de8ff2701fcd621083c6ed74@amsat.org> <3a34af0e69315074fd6f88959aeb4adb@earthlink.net> <8a54695a9d5ca8fdbb918355f6bdb5da@amsat.org> Message-ID: On Feb 7, 2005, at 9:22 pm, Jack Brindle wrote: > While talking fundamentals, it would be interesting to hear Don's take > on handling different radio types. I only have to worry about a K2, > but that doesn't help the folks with other radios... ;-) Plug-in > architecture, maybe? I assumed Don would implement the same variety of radios in the same way he has in MLDX ! 73, Jonathan G0DVJ -- From JamesDuffey at comcast.net Mon Feb 7 20:38:46 2005 From: JamesDuffey at comcast.net (James R. Duffey) Date: Mon Feb 7 20:38:52 2005 Subject: [MacLoggerContest] Contest Logger for Macs In-Reply-To: <103630100ea3.100ea3103630@hawaii.edu> Message-ID: I agree, a simple no bells and whistles interface would be most useful. Such an interface is great in introducing beginners to computer contesting. And with a simplified interface, the program will get more use. I would also like the software to allow me to configure the logging for an arbitrary specific contest. I operate a lot of QRP contests and they are not always supported by big name software. There are some wierd exchanges as well, this weekend we had FYBO where one of the exchanges is temperature at the operating position. Many of us use hand me down Macs that are two or three generations old in the shack. It would be nice to have the software support the older machines as well. For example, I use a G3 400 MHz AIO running OSX 10.2.8 in the shack. Can you at least support the serial ports in legacy machines? When the kids get out of college I can afford a new computer for the shack. :^)= I use cocoaModem for RTTY/PSK31 and it is a stellar performer. I would like a contest program to link to it or use it as a plug in. And could it have a painless way to link to Logbook of the World? - Duffey -- James R. Duffey KK6MC/5 Cedar Crest NM 87008 DM65 From jbastin at sssnet.com Tue Feb 8 15:12:00 2005 From: jbastin at sssnet.com (John Bastin) Date: Tue Feb 8 15:12:05 2005 Subject: [MacLoggerContest] List & Development issues - was- SO2R features In-Reply-To: <51d1bc706d82ca98a18475218ef66259@dogparksoftware.com> References: <1eab74c7de8ff2701fcd621083c6ed74@amsat.org> <3a34af0e69315074fd6f88959aeb4adb@earthlink.net> <8a54695a9d5ca8fdbb918355f6bdb5da@amsat.org> <51d1bc706d82ca98a18475218ef66259@dogparksoftware.com> Message-ID: <2e1ba22918ef9c077b9b86ad3b51e30c@sssnet.com> On Feb 7, 2005, at 4:51 PM, Don Agro wrote: >> First - can the list "mom" change the reply setting so that replies >> automatically go to the list? At least that's my request. > > The administrative interface to the list suggests... > "Where are replies to list messages directed? Poster is strongly > recommended for most mailing lists". > > A simple "Reply" will go to the poster, a "Reply All" will include the > list as well. In my experience defaulting the "Reply" to the list > results in a lot of accidental publication to the list of messages > that the poster only intended to go to the originator, this can result > in some embarrassing situations but if anyone feels strongly about > this for any particular reason ? On this list, "Reply All" sends my reply to the poster, with a copy to the list. This can be a bit of a issue, because it results in the poster getting two replies, the list reply and the one directed to him (in this case, because Don's reply had gone both to Jack and to the list, my reply to that message would have had one copy to Don, one copy to Jack, and one copy to the list. I saw what was happening and removed everything but the list copy). On other lists I'm on, "Reply" goes only to the poster, "Reply All" goes only to the list. This seems to be a better situation, but in any rate, anyone replying to a message on the list, myself included, is perfectly capable of checking the addressee(s) before he sends the post, and making sure the destination is correct. For my own preference, I would prefer to see only one copy of each message on the list, not the list post plus one to me. YMMV. 73, John E Bastin, K8AJS jbastin@sssnet.com http://www.qsl.net/k8ajs/ From jbastin at sssnet.com Tue Feb 8 15:27:48 2005 From: jbastin at sssnet.com (John Bastin) Date: Tue Feb 8 15:27:56 2005 Subject: [MacLoggerContest] Contest Logger for Macs In-Reply-To: <103630100ea3.100ea3103630@hawaii.edu> References: <103630100ea3.100ea3103630@hawaii.edu> Message-ID: <88d2b33e839faee2e6bb3f2f56b5d58f@sssnet.com> On Feb 7, 2005, at 3:30 PM, Ted Brattstrom wrote: > > 2- as one of the "Contests" - please have a "DXpedition mode" - no dupe > checking - all band - all mode... the style is similar - all you need > to > do is get the Call... and maybe write a signal report... :-) Why no dupe checking? Nowadays, it seems that many DXpeditions are discouraging duplicate contacts on a band, with the objective of giving as many different stations as possible a chance to get in the log. When so many current DXpeditions are posting online logs while the DXpedition is still in process, the need for "insurance" contacts seems much less and they are right to discourage the practice. By all means provide dupe checking in the software; a DXpeditioner can disregard it if he desires. 73, John E Bastin, K8AJS jbastin@sssnet.com http://www.qsl.net/k8ajs/ From jackbrindle at earthlink.net Tue Feb 8 16:32:25 2005 From: jackbrindle at earthlink.net (Jack Brindle) Date: Tue Feb 8 16:32:30 2005 Subject: [MacLoggerContest] Contest Logger for Macs In-Reply-To: <88d2b33e839faee2e6bb3f2f56b5d58f@sssnet.com> References: <103630100ea3.100ea3103630@hawaii.edu> <88d2b33e839faee2e6bb3f2f56b5d58f@sssnet.com> Message-ID: <51f99660425f288033625ab2338829de@earthlink.net> Why not use MacLoggerDX for this mode of operation? Make the contest program excellent at handling contests, NOT general purpose logging. On Feb 8, 2005, at 12:27 PM, John Bastin wrote: > On Feb 7, 2005, at 3:30 PM, Ted Brattstrom wrote: > >> >> 2- as one of the "Contests" - please have a "DXpedition mode" - no >> dupe >> checking - all band - all mode... the style is similar - all you need >> to >> do is get the Call... and maybe write a signal report... :-) > > Why no dupe checking? Nowadays, it seems that many DXpeditions are > discouraging duplicate contacts on a band, with the objective of > giving as many different stations as possible a chance to get in the > log. When so many current DXpeditions are posting online logs while > the DXpedition is still in process, the need for "insurance" contacts > seems much less and they are right to discourage the practice. > > By all means provide dupe checking in the software; a DXpeditioner can > disregard it if he desires. > > 73, > > John E Bastin, K8AJS > jbastin@sssnet.com > http://www.qsl.net/k8ajs/ > > _______________________________________________ > MacLoggerContest mailing list > MacLoggerContest@dogparksoftware.com > http://seven.pairlist.net/mailman/listinfo/macloggercontest > > -Jack Brindle, W6FB ======================================================================= From ted at hawaii.edu Tue Feb 8 19:15:02 2005 From: ted at hawaii.edu (Ted Brattstrom) Date: Tue Feb 8 19:15:38 2005 Subject: [MacLoggerContest] Contest Logger for Macs Message-ID: <4b0ba14b1e30.4b1e304b0ba1@hawaii.edu> Aloha - Although I haven't tried MacLogger other than a quick download and trial - the logging of 1-3 QSOs/minute did not seem well supported. In addition, MacLogger has so many features that are not needed in this scenario - the busy-ness of the interface gets in the way. DXpedition format is very much like Contest format - how many QSOs can you get in the log in the minimum amount of time. So, you are clicking on a band (20M)/ mode (SSB) for that run, then type: VP8DHI 59 and it is logged... then the next call/signal report... To change bands - click on the next band (17M) ... Why? When I hand log - I put in date at the top of the page, time at the top - if I'm really cooking - the hour is at the top and only the minutes, and callsign get logged - If the default is 59, I can leave off writting that, so only the non-59 reports get into the paper log... Some DXpeditions are going for single contacts per band mode - so I've got no problem with putting in a dupe detector, as long as I can still log it :-) why? it never hurts, and they feel that they really are in the log. I'm up for it either way. When I'm out - sometimes I'm doing fast style (contest-ish) and sometimes I'm doing a little chatting along the way. (more standard log style). Thanks for all the thoughts - ted - nh6yk (and vp8dhi, v73yk, ce0y/nh6yk, nh4/nh6yk etc.) ----- Original Message ----- From: Jack Brindle Date: Tuesday, February 8, 2005 11:32 am Subject: Re: [MacLoggerContest] Contest Logger for Macs > Why not use MacLoggerDX for this mode of operation? Make the > contest > program excellent at handling contests, NOT general purpose logging. > > On Feb 8, 2005, at 12:27 PM, John Bastin wrote: > > > On Feb 7, 2005, at 3:30 PM, Ted Brattstrom wrote: > > > >> > >> 2- as one of the "Contests" - please have a "DXpedition mode" - > no > >> dupe > >> checking - all band - all mode... the style is similar - all > you need > >> to > >> do is get the Call... and maybe write a signal report... :-) > > > > Why no dupe checking? Nowadays, it seems that many DXpeditions > are > > discouraging duplicate contacts on a band, with the objective of > > giving as many different stations as possible a chance to get in > the > > log. When so many current DXpeditions are posting online logs > while > > the DXpedition is still in process, the need for "insurance" > contacts > > seems much less and they are right to discourage the practice. > > > > By all means provide dupe checking in the software; a > DXpeditioner can > > disregard it if he desires. > > > > 73, > > > > John E Bastin, K8AJS > > jbastin@sssnet.com > > http://www.qsl.net/k8ajs/ > > > > _______________________________________________ > > MacLoggerContest mailing list > > MacLoggerContest@dogparksoftware.com > > http://seven.pairlist.net/mailman/listinfo/macloggercontest > > > > > > -Jack Brindle, W6FB > ======================================================================= > > _______________________________________________ > MacLoggerContest mailing list > MacLoggerContest@dogparksoftware.com > http://seven.pairlist.net/mailman/listinfo/macloggercontest > From g0dvj at amsat.org Thu Feb 10 19:34:32 2005 From: g0dvj at amsat.org (Jonathan G0DVJ) Date: Thu Feb 10 19:34:41 2005 Subject: [MacLoggerContest] Exchange entry methods In-Reply-To: References: <5b47ef9ef09ff1eecac13d3dcebb65e0@amsat.org> Message-ID: <29f7ae1f4f491817c7bc828d5b1f8dd5@amsat.org> On Feb 7, 2005, at 1:23 pm, John Bastin wrote: > On Feb 6, 2005, at 10:51 PM, K1GQ wrote: > >> On 2005 Feb 06, at 18:25, Jonathan G0DVJ wrote: >> >>> I note a number of principles that various people have mentioned >>> about this part of the process in other mails ... >> >> [snip of list of principles that omits this one:] >> >> - It must be possible to initiate sending a QSO exchange message that >> includes the other station's call sign without having completed entry >> of the call sign. That is, as long as I type (or edit) a character >> in the call sign before it is sent, it will be sent properly. >> >> Strictly speaking this isn't about exchange entry, but how exchange >> entry is implemented can impair this feature -- which is a >> show-stopper for me. >> >> K1GQ > > I'll also want to see this feature. This is a fairly common feature in > the DOS and Windows programs that I've used, allowing me to correct > typos in the latter part of the callsign while the first part is > already being transmitted. If I had to wait until the entire callsign > was complete and correct in my log before the software started sending > the exchange, it would be a significant slowdown. I also join the consensus on this one - its a principle I missed in the original list. Thanks to K1GQ for adding it and K8AJS for re-enforcing it! Jonathan G0DVJ. -- From g0dvj at amsat.org Thu Feb 10 20:16:02 2005 From: g0dvj at amsat.org (Jonathan G0DVJ) Date: Thu Feb 10 20:16:05 2005 Subject: [MacLoggerContest] Exchange entry methods In-Reply-To: <0f431f43583e4499eaa675f728002b35@earthlink.net> References: <5b47ef9ef09ff1eecac13d3dcebb65e0@amsat.org> <0f431f43583e4499eaa675f728002b35@earthlink.net> Message-ID: <813d2102e0b72a353e1868c6cd46e7dc@amsat.org> My 2 cents on this topic - now others have had a chance ! ... On Feb 7, 2005, at 12:47 am, Jack Brindle wrote: > The most important area for the user in a contest program is exchange > entry. As Jonathan has pointed out, there are two basic ways in > current use. Great I think we all agree on this :) >> 1) The operator is faced with a logging line consisting of separate >> dedicated fields... >> 2) The operator is faced with one single field into which he/she can >> enter any of part of the contest QSO exchange... > > Both have plusses and minuses, and some PC programs use either or both > methods. Hence I still wonder if MLC should have an aim of trying to support either - maybe not both initially - we have to cut cloth to suit as an old english phrase goes - these 2 styles are so personal a choice that it would be good to offer either if/when possible. > The second is rather interesting, and very challenging to code. Trying > to figure out what a piece of data is for requires some magic by the > program and its author. The second can be made easier by various techniques - for example TAClog employs some interesting options for input within this style. prefixing a number where the semantics associated with it (its field) can be ambiguous with a letter seems cunbersome but can work well so S103 means Sent serial 103 as opposed to a different numeric field. The other option allowed within this second style is the entry of more than one field's contents at once - again TAClog is an example of this where if you type 599 001 JO01MX - this is split up into parts and the various fields populated - with default ordering being an option if desired. So the "normal order" you might expect can be taken into account. Also the problem of easy corrections to fields before committing is slicker with this second method - typing another match for a field's contents that already matched replaces the previous entry for that field. > But there may be other ways that simply have not been considered. Data > entry using a tablet and MacOS X's character recognition might produce > interesting results - as long as the tablet is not troubled with RFI. > There may be other methods that are just waiting for innovation. True - I have a tablet - many won't however - and given the experience I have of Apple "INK" so far I wouldn't want to rely on it for contest QSO entry! > Callsign dupe checking and "Super Check Partial" are very useful > utilities that directly apply. Dupe checking is a must for contest > programs. It must be VERY fast. Having to wait a considerable time for > a database to complete an entry search is not acceptable. > Unfortunately, some of the PC-based programs have this problem. It is > very notable when your QSO count gets above 400 or 500 QSOs and is > very aggravating. Agreed totally. > Super Check partial is something that should be included in any > contest program at this point. It not only checks the callsign (and > offers possible completions), but also can enter data into various > fields. Good point - agreed! >> - for speed, the entry should be entirely keyboard based and no >> mouse/pointing required > This is the cry of the PC user - but is it really valid? As an > example, most ops keep one hand on the transceiver VFO knob in order > to QSY for S&P. It seems that an alternative would be (and in > practice, is) to use a Powermate for this purpose. Tapping the > PowerMate could cause it to perform some other function, like field > movement or window selection. Again, this is a rule that came from a > time when the PC had very few entry solutions. That no longer applies, > and has never applied to our platform. Hmmm i would have to be convinced - Also although I have a PowerMate - again many people don't. We need to make this a generally usable program without people needing to get extra hardware - although I have no problem with adding extras to use additional stuff later. I have most of the AppleStore's contents here but I am not typical :) I would go with an analogy of Don's other software ... where in MacDoppler you can tune by using a PowerMate but there are other ways to tune without the extra hardware. >> - again for speed reasons, as well as ease of thought, single >> keystrokes should be used (i.e. no sets of key combinations to learn >> for control functions). > In the PC World, extensive use of multi-keystroke entry is required. > We may be saying the same thing differently here, however. > Multi-keystroke entry should include command/option + key entries. > There are just too few 'F' keys to support the contester's needs. I > agree that entries that use two separate keys to be pressed in > sequence is definitely not the way to go. F keys are good for Keyer message stores etc. Other punctuation keys etc which have no use in contests can be used as singles to great effect - SD is a very good exponent of this. > Yes, but in what format? I learned a very important lesson here - do > NOT use a database for data storage. Agreed again. And certainly not a Microsoft database LOL ! 73 Jonathan G0DVJ -- From g0dvj at amsat.org Fri Feb 11 15:39:12 2005 From: g0dvj at amsat.org (Jonathan G0DVJ) Date: Fri Feb 11 15:39:18 2005 Subject: [MacLoggerContest] MLC compared to MLDX In-Reply-To: <932016020d4e8d854fca284c866042aa@dogparksoftware.com> References: <53429265c26ba518a443da7ec29949d9@amsat.org> <7462a427e2435b614d2daf708ba7c65f@dogparksoftware.com> <28dbc9c47ab037321f1df461a9ebc238@dogparksoftware.com> <9f05d79baf1db6b5a944073a6841f157@dogparksoftware.com> <3e242e82f3104b0afc11378b0a3d1c0c@dogparksoftware.com> <14f89e1736097cd356857816a827bcc0@dogparksoftware.com> <44e423cce18c334390c2c744de7d36f9@earthlink.net> <918c7f443b9406046b53efc4d5bd6300@dogparksoftware.com> <1e0259a35a782cdd0c1055c8e946496e@amsat.org> <932016020d4e8d854fca284c866042aa@dogparksoftware.com> Message-ID: Hi all, (sorry for the burst of activity from me on the list at weekends but work is giving me little chance during the week at present!) One of the minor points Don and I were discussing before this list was created was: On Feb 3, 2005, at 8:08 am, Don Agro wrote: >> One interesting thing for next time would be to discuss what features >> for contest are in common with MLDX and where the differences and >> similarities lie - if that would help. > > Yes, I think it would, as long as we don't let it limit where we are > going, but a "MLDX feature good for MLC" and a MLDX feature NOT good > for MLC" would be a good place to start. Note this is not to say that MLC is a version of MLDX - it is clear that the two loggers are entirely different applications - nor are we looking at the detail of appearance and design of the user experience - this is merely to assist Don in terms of some high level features that have already been coded in some sense ! (Analogous to the way that some features (e.g. Map) are shared between MLDX and MacDopplerPro for example). So now I think is a good time to have a new thread looking at this. I have attempted a "starter for 10" below - let's add/correct etc. as appropriate... MLDX good for MLC: - DX Clusters Pane and functions (with added links to scoring potential etc. as per separate thread - e.g. identifying new mults that have been spotted) - Map Pane (should concentrate of what has been worked as an indicator of propagation etc. maybe coloured by band etc. but secondary nice-if rather than essential) - also only really of use when HF contest selected unless we can have loadable more localised maps - Beam rotor support - Rig control support for such a wide range of radios. (Again maybe linked to specific quick QSY for different band/mode button functions) - MicroBand decoder support - Keyer support (adapted specifically for contesting needs) - Cabrillo support (need export instead of import !) - ADIF support (only need export) MLDX not good/not needed for MLC: - QSL pane and functions - Labels pane and functions - Awards pane and functions - Schedules pane and functions (Could imagine a different but analogous sked/band change/other (e.g. fill genny!) reminder system) - Memories pane and functions (Could imagine a different but analogous Memory map of what you have heard/logged per band e.g. on S&P mode) - UCB pane and functions - Previous (only implemented by the Super Check Partial support as well as Dupe Checks in the same current contest). - Support for WARC bands - no contests happen here. - Log pane - fields never needed such as address related, power, contact details, plus others only displayed according to contest configuration. - Different pane/layout completely needed - some common info/fields but emphasis completely different. Comments from any others who are familiar with MLDX? 73, Jonathan G0DVJ -- From ted at hawaii.edu Sat Feb 12 14:45:28 2005 From: ted at hawaii.edu (Ted Brattstrom) Date: Sat Feb 12 14:45:31 2005 Subject: [MacLoggerContest] MLC compared to MLDX Message-ID: Drat - I'm doing this each time - hitting reply like a normal list, and forgetting it doesn't go to the list... cheers - ted - nh6yk ----- Original Message ----- From: Ted Brattstrom Date: Saturday, February 12, 2005 9:42 am Subject: Re: [MacLoggerContest] MLC compared to MLDX > Aloha - > > Just a few comments :-) > > ----- Original Message ----- > From: Jonathan G0DVJ > Date: Friday, February 11, 2005 10:39 am > Subject: [MacLoggerContest] MLC compared to MLDX > > > > > Hi all, (sorry for the burst of activity from me on the list at > > weekends but work is giving me little chance during the week at > > present!) > > Work does get in the way of fun :-) :-) weekends are the time to catch > up on all the other stuff (of course, I'm a teacher, so it's also the > time to catch up on work :-) ) > > > > MLDX good for MLC: > > > > - DX Clusters Pane and functions (with added links to scoring > > potential etc. as per separate thread - e.g. identifying new > mults > > that have been spotted) > > Note - if implemented, this should be able to be turned off - or made > one way... (I'd leave it out, personally :-) ) > > The reason, using any cluster changes you from Single Op to > Assisted - > there are enough people who are "assisted" who are submitting as > Single Op. > > > - Map Pane (should concentrate of what has been worked as an > > indicator > > of propagation etc. maybe coloured by band etc. but secondary > nice- > > if > > rather than essential) - also only really of use when HF contest > > selected unless we can have loadable more localised maps > > Cute, but how needed is it --- if I hear a lot of African stations > on,I can guess that propagation supports that direction :-) and, > knowingthe bands from my QTH, and the like - it's not particularly > needed.Unless you put something like the SFI/A/K in to make band > predictions in > real time. (that's a separate program) > > > - Beam rotor support > > - Rig control support for such a wide range of radios. (Again > > maybe > > linked to specific quick QSY for different band/mode button > functions)> - MicroBand decoder support > > - Keyer support (adapted specifically for contesting needs) > > - Cabrillo support (need export instead of import !) > > - ADIF support (only need export) > > > I'd add - the ability to do a quick edit on a QSO - How many times > haveI entered the info quickly, hit return twice, then noticed that I > mis-typed the call - Post contest editing is fine - (and > important), as > long as you keep a pad of note paper next to you (which I do) > > > > MLDX not good/not needed for MLC: > > > > - QSL pane and functions > > - Labels pane and functions > > - Awards pane and functions > > - Schedules pane and functions (Could imagine a different but > > analogous sked/band change/other (e.g. fill genny!) reminder system) > > - Memories pane and functions (Could imagine a different but > > analogous > > > Memory map of what you have heard/logged per band e.g. on S&P mode) > > I don't know how this is implemented - but, the ability to enter a > calland band that you can come back to... because you didn't get > through > I envision something like entering the call, trying to call for a > minuteor 20 - then hitting a function key to put it over on the > side with the > freq and call... it can be gone back to later. > > (I spent about 30 minutes + trying to get to FP/VE7SV on 10M since it > was an all time new one - and that ends up being a higher priority > thanthe contest :-) ) > > > > > - UCB pane and functions > > - Previous (only implemented by the Super Check Partial support > as > > well as Dupe Checks in the same current contest). > > - Support for WARC bands - no contests happen here. > > (yeah, I know I keep saying it :-) keep the WARC bands in there - no > need to take them out :-) then it's still ok for DXpeditions - part of > why a number of WIN contest programs are used on DXpeditions, same > fastentry speed - DXpeditioners are often Contestors and want the same > interface in both scenarios. (same networking for network > backups!!!)) > > - Log pane - fields never needed such as address related, power, > > contact details, plus others only displayed according to contest > > configuration. > > - Different pane/layout completely needed - some common > > info/fields > > but emphasis completely different. > > > > > > Comments from any others who are familiar with MLDX? > > Sorry to be not familiar with MLDX - My experience has been with: > Paperlogs, Excel, LogEQF (win/dos), MacContest 3.5 (mac), CT (win - > networked), and (drat, and I'm sorry I forgot your name...) the > contestspecific logger worked up by a list member.... > > Aloha - ted - nh6yk > > > 73, > > Jonathan G0DVJ > From g0dvj at amsat.org Sun Feb 13 13:54:11 2005 From: g0dvj at amsat.org (Jonathan G0DVJ) Date: Sun Feb 13 13:54:17 2005 Subject: [MacLoggerContest] MLC compared to MLDX In-Reply-To: References: Message-ID: <1ed2627956023208ea0477f1bb4598db@amsat.org> Hi all, Wanted to just comment on a few things Ted brought to the table (thanks Ted). My original posting in this thread was intended to be a straight high level feature comparison not a list of priorities! I do concur with Ted's noting of priorities of some of the points. I hope we can have a specific thread about the actual priorities soon - perhaps after any other more detailed debates. On Feb 12, 2005, at 7:42 pm, Ted Brattstrom wrote: >> MLDX good for MLC: >> >> - DX Clusters Pane and functions (with added links to scoring >> potential etc. as per separate thread - e.g. identifying new mults >> that have been spotted) > > Note - if implemented, this should be able to be turned off - or made > one way... (I'd leave it out, personally :-) ) > The reason, using any cluster changes you from Single Op to Assisted - > there are enough people who are "assisted" who are submitting as > Single Op. Agreed ! >> - Map Pane (should concentrate of what has been worked as an >> indicator of propagation etc. maybe coloured by band etc. but >> secondary nice- >> if rather than essential) - also only really of use when HF contest >> selected unless we can have loadable more localised maps Yes hence I regarded this as a nice-if! > I'd add - the ability to do a quick edit on a QSO - How many times have > I entered the info quickly, hit return twice, then noticed that I > mis-typed the call - Post contest editing is fine - (and important), as > long as you keep a pad of note paper next to you (which I do) Again absolutely agree - the ability to quickly edit QSOs in mid contest was highlighted in another mail thread. I am coming to the conclusion that perhaps two mechanisms are needed - one which easily pulls back the previous QSO for editing when you have committed it and then realise something needs changing and then a more general way of editing any QSO in the log. >> Memory map of what you have heard/logged per band e.g. on S&P mode) > > I don't know how this is implemented - but, the ability to enter a call > and band that you can come back to... because you didn't get through > > I envision something like entering the call, trying to call for a > minute > or 20 - then hitting a function key to put it over on the side with the > freq and call... it can be gone back to later. I have seen this scratchpad/recall type facility within loggers such as SD and it is very useful. Thanks for saying so too! >> - Support for WARC bands - no contests happen here. > > (yeah, I know I keep saying it :-) keep the WARC bands in there - no > need to take them out :-) then it's still ok for DXpeditions - Yeah - a mistake in hindsight on my part - I agreed with your comment about secondary use for DX-peditions in another thread and then wrote this daft contradictory thing in the comparison of MLC & MLDX thread ! Ooopss. Brain not in gear. > Aloha - ted - nh6yk > BTW - Had a great time a couple of years ago staying in Hawaii a few days on a round the world trip! 73, Jonathan G0DVJ -- From jackbrindle at earthlink.net Sun Feb 13 15:07:11 2005 From: jackbrindle at earthlink.net (Jack Brindle) Date: Sun Feb 13 15:07:16 2005 Subject: [MacLoggerContest] MLC compared to MLDX In-Reply-To: <1ed2627956023208ea0477f1bb4598db@amsat.org> References: <1ed2627956023208ea0477f1bb4598db@amsat.org> Message-ID: <404c6891acd49f4a30290a71bd2d1a4f@earthlink.net> On Feb 13, 2005, at 10:54 AM, Jonathan G0DVJ wrote: >>> - DX Clusters Pane and functions (with added links to scoring >>> potential etc. as per separate thread - e.g. identifying new mults >>> that have been spotted) >> >> Note - if implemented, this should be able to be turned off - or made >> one way... (I'd leave it out, personally :-) ) >> The reason, using any cluster changes you from Single Op to Assisted - >> there are enough people who are "assisted" who are submitting as >> Single Op. This is very important for contest club ops. In very competitive areas stations may not be able to compete, but they can help their fellow club members to do so. The ability to feed spots into the local club cluster can mean a lot of points to the club itself. Spots can also mean the difference between a sweep in some contests and being down in the mult count. I put cluster capability in the "must have" category. >>> - Map Pane (should concentrate of what has been worked as an >>> indicator of propagation etc. maybe coloured by band etc. but >>> secondary nice- >>> if rather than essential) - also only really of use when HF contest >>> selected unless we can have loadable more localised maps I go the opposite for this - I'd rather use my screen real-estate for more important things. This is more of a distraction than anything else. Why? It puts the op into the mode of going after multipliers instead of getting more QSOs. Mults come with QSOs, searching for mults keeps you from getting Qs and ends up lowering your score. This is one I have learned the hard way from my fellow club members. If the feature is there, make sure it can be turned off. >>> Memory map of what you have heard/logged per band e.g. on S&P mode) >> >> I don't know how this is implemented - but, the ability to enter a >> call >> and band that you can come back to... because you didn't get through >> >> I envision something like entering the call, trying to call for a >> minute >> or 20 - then hitting a function key to put it over on the side with >> the >> freq and call... it can be gone back to later. This actually can be part of the spotting system. Just because you don't have a connection to the cluster enabled doesn't mean you cannot add spots for your own operation (that don't go to anyone else). Features in the program need to be useful not just for the casual contester but also for the more serious ones. Please do not leave out features that the serious guys will need (like spotting). It would seriously cripple the program. - Jack Brindle, W6FB ------------------------------------------------------------------------ --------------------- From g0dvj at amsat.org Sun Feb 13 15:11:44 2005 From: g0dvj at amsat.org (Jonathan G0DVJ) Date: Sun Feb 13 15:11:46 2005 Subject: [MacLoggerContest] Types of Contest to support? Message-ID: <017a222aad6316096e832d0b39d526ce@amsat.org> Hi all, We discussed general flexibility required to support as many contest events as possible in an earlier thread. I thought it maybe worth having a cross-continents check of what contest types in detail need supporting at least initially - so hence this thread following on from the general one on contest configuration. The sorts of contest scoring arrangements that come to mind from this side of the Pond are: HF types: (can be x points per QSO optionally varying per Band, Mode or Continent or any combination of these, with optionally own country/continent may not score for points [but may still optionally be a multiplier]) - No Multipliers With Multipliers (the info for these may come from the call prefix OR as a separate part of the Exchanged info OR both): - Country Multipliers (various country reference lists required for this since some variations from the DXCC list exist for contesting*) - Zone Multipliers (CQ zone, ITU Zone - note in some ITU zones 76-89 are not included since sea areas only, etc.) - Area Multipliers (Country specific lists - States, Provinces, Counties, Districts, Call Areas, Administrative areas etc.) - Call prefix Multipliers (e.g. CQ WPX - where G3xxx, G4xxx, M4x etc. are all UK mults.) - HQ national society initials (e.g. IARU) - QTC info (WAE events - needs specific support when logging not detailed here) - others? * The DXCC list is used with variation in different events for example, in some, DXCC mults are supplemented by Call Areas in large countries such as W, VE, VK, JA etc.) VHF types: (either x points per QSO or y points per km/mile) then: - No multiplers - Grid Square Multipliers (may be 4 or 6 character grids used) - Country Multipliers (from Prefix of Calls worked) - Area Multipliers (in the UK Districts worked - but could be various other area data sets e.g. Counties, States, Provinces etc.) - Any combination of the last 3 above! Of course multipliers may be counted per Band, per Mode, OR both! Aside from scoring, and in addition to the information already mentioned above for the purposes of scoring, what other information may optionally form part of the exchange in a contest? (some of these may need to just be provided by a free format text field rather than customised fields?) My starter list is: - serial number - report RS(T) length dependent on mode used (yes some events dont use this like European Sprints!) - name - age - club name that person is a member of - membership number ? (this really sounds like train-spotting lol) - year first licensed - grid square (only 4 chars on HF? - e.g. Stew Perry Trophy event) What have I omitted that wouldn't allow your fave contest ? Please add/comment as necessary. BTW I though Jack's earlier posting on the other thread was very useful in terms of how these various options might be selected, saved as a template for easy selection and sharing and quick'n'easy get going with the contest operation ! 73, Jonathan G0DVJ -- -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: text/enriched Size: 3061 bytes Desc: not available Url : http://seven.pairlist.net/pipermail/macloggercontest/attachments/20050213/9bc96467/attachment.bin From ted at hawaii.edu Sun Feb 13 21:32:20 2005 From: ted at hawaii.edu (Ted Brattstrom) Date: Sun Feb 13 21:32:22 2005 Subject: [MacLoggerContest] MLC compared to MLDX Message-ID: <181f717b86.17b86181f7@hawaii.edu> Aloha - Good point raised by Jack! I haven't worked in club competitions :-) so I hadn't thought of this. Which leads to the issue - allow for toggle ON/OFF of Spots going OUT and ON/OFF Spots coming IN (default to OFF and OFF :-) :-) ) 73 - ted - nh6yk ----- Original Message ----- From: Jack Brindle Date: Sunday, February 13, 2005 10:07 am Subject: Re: [MacLoggerContest] MLC compared to MLDX > >>> - DX Clusters Pane and functions (with added links to scoring > >>> potential etc. as per separate thread - e.g. identifying new mults > >>> that have been spotted) > >> > >> Note - if implemented, this should be able to be turned off - or > made>> one way... (I'd leave it out, personally :-) ) > >> The reason, using any cluster changes you from Single Op to > Assisted - > >> there are enough people who are "assisted" who are submitting as > > >> Single Op. > > This is very important for contest club ops. In very competitive > areas > stations may not be able to compete, but they can help their fellow > > club members to do so. The ability to feed spots into the local > club > cluster can mean a lot of points to the club itself. Spots can also > > mean the difference between a sweep in some contests and being down > in > the mult count. I put cluster capability in the "must have" category. From jbastin at sssnet.com Wed Feb 16 12:29:08 2005 From: jbastin at sssnet.com (John Bastin) Date: Wed Feb 16 12:29:13 2005 Subject: [MacLoggerContest] MLC compared to MLDX In-Reply-To: <1ed2627956023208ea0477f1bb4598db@amsat.org> References: <1ed2627956023208ea0477f1bb4598db@amsat.org> Message-ID: On Feb 13, 2005, at 1:54 PM, Jonathan G0DVJ wrote: > Hi all, > > Wanted to just comment on a few things Ted brought to the table > (thanks Ted). > My original posting in this thread was intended to be a straight high > level feature comparison not a list of priorities! > I do concur with Ted's noting of priorities of some of the points. > > I hope we can have a specific thread about the actual priorities soon > - perhaps after any other more detailed debates. > > > On Feb 12, 2005, at 7:42 pm, Ted Brattstrom wrote: > >>> MLDX good for MLC: >>> >>> - DX Clusters Pane and functions (with added links to scoring >>> potential etc. as per separate thread - e.g. identifying new mults >>> that have been spotted) >> >> Note - if implemented, this should be able to be turned off - or made >> one way... (I'd leave it out, personally :-) ) >> The reason, using any cluster changes you from Single Op to Assisted - >> there are enough people who are "assisted" who are submitting as >> Single Op. It depends on the contest. Some contests put you in a different class if you use a packet cluster, others just don't allow it. On the other hand, many contests in which I participate _encourage_ the use of packet (RTTY contests frequently do this) because they believe it helps increase participation. > >>> - Map Pane (should concentrate of what has been worked as an >>> indicator of propagation etc. maybe coloured by band etc. but >>> secondary nice- >>> if rather than essential) - also only really of use when HF contest >>> selected unless we can have loadable more localised maps I would regard this as a waste of precious display real estate and processor cycles. Give me a small box showing short path and long path beam headings, and possibly sunrise and sunset times (in UTC) based on the prefix currently in the log field. > >> I'd add - the ability to do a quick edit on a QSO - How many times >> have >> I entered the info quickly, hit return twice, then noticed that I >> mis-typed the call - Post contest editing is fine - (and important), >> as >> long as you keep a pad of note paper next to you (which I do) The ability to edit QSO info at any time, during the QSO, after the QSO is logged, or after the contest, is a must-have for me. >>> Memory map of what you have heard/logged per band e.g. on S&P mode) >> Since I'm not a "big gun" and so spend a lot of my contest time S&P'ing, it's nice to have a place where one mouse click will store the current callsign, frequency, mode, filters, etc. so I can leave it and with one click a few minutes later immediately come back to it to give the pileup another try. >> I don't know how this is implemented - but, the ability to enter a >> call >> and band that you can come back to... because you didn't get through >> >> I envision something like entering the call, trying to call for a >> minute >> or 20 - then hitting a function key to put it over on the side with >> the >> freq and call... it can be gone back to later. > > I have seen this scratchpad/recall type facility within loggers such > as SD and it is very useful. Thanks for saying so too! 73, John E Bastin, K8AJS jbastin@sssnet.com http://www.qsl.net/k8ajs/ From g0dvj at amsat.org Sun Feb 20 10:57:25 2005 From: g0dvj at amsat.org (Jonathan G0DVJ) Date: Sun Feb 20 10:57:29 2005 Subject: [MacLoggerContest] Keyers Message-ID: <0a5d776f55d0e04f84648385746ea0f4@amsat.org> Hi all, Next discussion ... Keyer functions ... by this I include CW and Voice "keyers". For those of us that do both CW and Phone contests, I postulate that CW keying is a higher priority than a voice recorder/parrot function. The CW keyer for contesting needs to allow a number of key strings to be easily sent and potentially seamlessly concatenated together. Some of the contents of what is sent by the keyer should enable the exchange entered in the current logging line to be inserted automatically - such as serial number, RST report etc. Some parts may be optionally included from info in the contest/operator set-up (e.g. grid/zone etc.) It should be very easy to adjust the speed of the keyer since different operators respond at different speeds in quick succession and its nice to go respond at a matching rate. Maybe this is an application where something like the Griffin PowerMate could be optionally employed? Some guys seem to like to send some parts of the exchange (e.g. RST) faster than other parts (e.g. serial) although I have never been a great fan of this personally - but some contest loggers do allow you to specify speed changes in the programmable text exchange. Anyone in favour of this ? ESC to cancel in mid keying is a nice feature in case you initiate the keyer in error! On the phone keyer side, I consider this rather a bell & whistle - assuming we are initially at least not talking SO2R operation. Also there are many other boxes that people use for voice keying which can seamlessly fit into the set-up of the station. But if we did have such a feature in MLC ... It would allow sound file snippets to be sent by hitting a key - specifically for repetitive audio clips such as CQ calls. Again an ESC to cancel immediately is probably a useful option. Any comments on either of these ? Anything I have forgotten ? 73, Jonathan G0DVJ -- From jbastin at sssnet.com Sun Feb 20 11:26:55 2005 From: jbastin at sssnet.com (John Bastin) Date: Sun Feb 20 11:27:02 2005 Subject: [MacLoggerContest] Keyers In-Reply-To: <0a5d776f55d0e04f84648385746ea0f4@amsat.org> References: <0a5d776f55d0e04f84648385746ea0f4@amsat.org> Message-ID: <01aed52cac40090585e36baaab82c703@sssnet.com> On Feb 20, 2005, at 10:57 AM, Jonathan G0DVJ wrote: > > Some guys seem to like to send some parts of the exchange (e.g. RST) > faster than other parts (e.g. serial) although I have never been a > great fan of this personally - but some contest loggers do allow you > to specify speed changes in the programmable text exchange. Anyone in > favour of this ? I like this feature and use it in most contests. It's not a deal-breaker either way, though. > > ESC to cancel in mid keying is a nice feature in case you initiate the > keyer in error! This is an absolute necessity. Another feature which I use a lot in my current contest logging program is the ability to set up an automatic repeat of a message, after an adjustable time delay. I use this to set up an automatic CQ Contest message repetition. In that case, the timer is shut off as soon as ANY key is pressed, so that the auto-CQ function quits as soon as someone answers and I start typing his callsign into the log. 73, John E Bastin, K8AJS jbastin@sssnet.com http://www.qsl.net/k8ajs/ From aa4lr at arrl.net Sun Feb 20 12:15:16 2005 From: aa4lr at arrl.net (Bill Coleman) Date: Sun Feb 20 12:15:24 2005 Subject: [MacLoggerContest] Keyers In-Reply-To: <0a5d776f55d0e04f84648385746ea0f4@amsat.org> References: <0a5d776f55d0e04f84648385746ea0f4@amsat.org> Message-ID: <1434f3fd14815a5c40cb46f970f1f294@arrl.net> On Feb 20, 2005, at 10:57 AM, Jonathan G0DVJ wrote: > For those of us that do both CW and Phone contests, I postulate that > CW keying is a higher priority than a voice recorder/parrot function. It's hard to imagine contest software that does not support CW keying. Although I certainly used various DOS and Windows software for years, keying things manually. Many of the older ops I've worked with at a M/M tend to grab for the keyer paddles. Voice keying isn't so common. I've had good success for several years now (6-7, can't remember) using a 1 message voice keyer. I program it with a CQ message. I can easily do the rest of the exchange with my voice and not get fatigued, even after 20 or more hours of contesting. > The CW keyer for contesting needs to allow a number of key strings to > be easily sent and potentially seamlessly concatenated together. Some of these strings are context-sensitive. I think it is TRlog that usually figures out what to send based on what's on the logging line. In my experience, there's only about a half-dozen messages I use in CW keying: CQ message My call Exchange His call TU message (TU AA4LR TEST, for example) QRZ message Specific repeat mesage (NR? QTH? PWR? -- these depend on the contest exchange) > It should be very easy to adjust the speed of the keyer since > different operators respond at different speeds in quick succession > and its nice to go respond at a matching rate. I head one guy last night on 80m answer a 20 wpm CQ with 32 wpm CW. It was a struggle for the operator to answer him and took several repeats. When CQing, I generally don't adjust the CW speed when I'm being called unless asked (QRS or PSE QRS). I figure the other operator can copy me, or has hung around long enough to get the info. (A trick I used to do when I couldn't copy contest-speed CW) Of course, I'm a relative slow-poke at 25 wpm. When answering a CQ, though, I'll often call first at full speed (again 25 wpm isn't too fast), then slow down if the op appears to be having difficulty. Speed changing doesn't happen too frequently -- it should be accessible, but doesn't require a special controller. > Some guys seem to like to send some parts of the exchange (e.g. RST) > faster than other parts (e.g. serial) although I have never been a > great fan of this personally - but some contest loggers do allow you > to specify speed changes in the programmable text exchange. The idea behind this is to allow common parts of the transmission to be sped up to save time. Frankly, I think it is counterproductive. While a small shift (2 wpm or so) isn't objectionable, large shifts in CW speed tend to throw off my timing. This often causes me to ask for repeats. Frankly, I'd rather hear cut numbers than a bunch of speed shifts. > ESC to cancel in mid keying is a nice feature in case you initiate the > keyer in error! This happens FREQUENTLY! Bill Coleman, AA4LR, PP-ASEL Mail: aa4lr@arrl.net Quote: "Not within a thousand years will man ever fly!" -- Wilbur Wright, 1901 From g0dvj at amsat.org Sun Feb 20 12:48:45 2005 From: g0dvj at amsat.org (Jonathan G0DVJ) Date: Sun Feb 20 12:48:51 2005 Subject: [MacLoggerContest] Post-contest support Message-ID: <39e2575054e7f775b9b9f32c98489481@amsat.org> Thanks for the replies/comments on the previous keyer thread - I agree completely with both John & Bill on all their points. Another aspect we haven't yet covered much is post-contest support... Again I will kick off with some comments about this and perhaps people will comment/correct as they wish. So after the hard work of the contest it would be nice to have : 1) an easy way to submit the entry [Essential] 2) an easy way to aggregate the contest log into a main station log (either MLDX or something else) [Essential] 3) a way to analyse the performance of the contest effort [Bell & Whistle?] 4) anything else I have forgotten?? For (1) I guess we are talking about Cabrillo export but with some parts of the header completed from info the software already has about the operator (e.g. contact info) and the station (maybe radios & antennas - see about locations below) etc. This links the post-contest facilities with the contest set-up part as well as user preferences. For (2) I guess we are talking about an intelligent ADIF export, which most other station loggers can handle - it would be excellent IMHO if we could crack the problem I have often had which is conveying the contest name, year & my contest location over to the comments or notes field of the station log so that this information can be added to any QSLs I create (e.g. in the MLDX QSL facility). In (3) I would like to be able to analyse the QSOs, Points, Mults (if applicable) per hour of the contest. Also Mults per band/mode would be interesting. This is an area that like with MLDX awards facility could be enhanced as time goes on IMHO. What else have I missed - what are others' views? Oh and on contest location (which I mentioned under (2) above) - it would be great if I could set-up and then select from a number of different contest locations known to the program. As well as operation from home, I typically have a few other locations I use (different with various groups and for HF/VHF events.) These stored locations would then be able to pre-populate and hence simplify the set-up for many contest events including my grid locator, zones (ITU & CQ), Lat/Long, station equipment, etc. What say others? 73, Jonathan G0DVJ -- From ted at hawaii.edu Sun Feb 20 13:07:31 2005 From: ted at hawaii.edu (Ted Brattstrom) Date: Sun Feb 20 13:07:33 2005 Subject: [MacLoggerContest] Keyers Message-ID: <14f98115296c.15296c14f981@hawaii.edu> Aloha Jonnathan and all - Not being cw op - I'll limit myself to phone comments :-) Minor contests, the voice keyer isn't needed - major efforts - it really helps a lot - At a minimum - the CQ string should be playable. I can usually hold out for a contest on the rest on regular voice :-) there ARE a lot of boxes out there that do this, the question of letting the software do this boils down to a couple of issues - how many more wires / interfaces are we going to have from the computer to the radio - remembering that the microphone has to get in there someway too :-) (yes, there are interface boxes for that too...) side thought: (I'm seeing the need for a box that has USB on one side, Mic in, Key in (straight and otherwise) Radio audio in, - then outputs Audio to radio (voice, PSK, JT, RTTY, SSTV), cw keying to radio, Amplifier keying, and band/mode data both ways... and the like - all for under $29.95 :-) :-) ) However, the voice side of things can be done in the same format as the CW side of things - prepared sound files - and synthesized sound files for number increments. (with the option for all synthesized - which helps out some hams who have a hard time talking... I remember one (non contest) qso with a ham who was clearly running a speech sythesizer - it worked) I haven't played a lot with the text to speech parts of the mac - but it seems all there :-) Just a few more thoughts from the mid-pacific... 73 and aloha - ted - nh6yk ----- Original Message ----- From: Jonathan G0DVJ Date: Sunday, February 20, 2005 5:57 am Subject: [MacLoggerContest] Keyers > Next discussion ... Keyer functions ... by this I include CW and > Voice > "keyers". > For those of us that do both CW and Phone contests, I postulate > that CW > keying is a higher priority than a voice recorder/parrot function. > On the phone keyer side, I consider this rather a bell & whistle - > assuming we are initially at least not talking SO2R operation. > Also > there are many other boxes that people use for voice keying which > can > seamlessly fit into the set-up of the station. But if we did have > such > a feature in MLC ... > > It would allow sound file snippets to be sent by hitting a key - > specifically for repetitive audio clips such as CQ calls. > > Again an ESC to cancel immediately is probably a useful option. From aa4lr at arrl.net Sun Feb 20 13:47:45 2005 From: aa4lr at arrl.net (Bill Coleman) Date: Sun Feb 20 13:47:49 2005 Subject: [MacLoggerContest] Keyers In-Reply-To: <14f98115296c.15296c14f981@hawaii.edu> References: <14f98115296c.15296c14f981@hawaii.edu> Message-ID: On Feb 20, 2005, at 1:07 PM, Ted Brattstrom wrote: > side thought: > (I'm seeing the need for a box that has USB on one side, > Mic in, Key in (straight and otherwise) Radio audio in, > - then outputs Audio to radio (voice, PSK, JT, RTTY, > SSTV), cw keying to radio, Amplifier keying, and > band/mode data both ways... and the like - all > for under $29.95 :-) :-) ) You mean, like this: (Warning! Macintosh compatibility unknown) The prices range all over, but they certainly seem to have a number of interesting gadgets. Bill Coleman, AA4LR, PP-ASEL Mail: aa4lr@arrl.net Quote: "Boot, you transistorized tormentor! Boot!" -- Archibald Asparagus, VeggieTales From ted at hawaii.edu Sun Feb 20 15:16:18 2005 From: ted at hawaii.edu (Ted Brattstrom) Date: Sun Feb 20 15:16:20 2005 Subject: [MacLoggerContest] Keyers Message-ID: <1690d916ba55.16ba551690d9@hawaii.edu> Oops = it figures it was already done :-) so, the contest logger should support this (or similar) box (USB MicroKeyer) though $179 Plus some additional cables seems a bit steep - or maybe I'm just cheap :-) :-) thanks - ted - nh6yk ----- Original Message ----- From: Bill Coleman Date: Sunday, February 20, 2005 8:47 am Subject: Re: [MacLoggerContest] Keyers > > On Feb 20, 2005, at 1:07 PM, Ted Brattstrom wrote: > > > side thought: > > (I'm seeing the need for a box that has USB on one side, > > Mic in, Key in (straight and otherwise) Radio audio in, > > - then outputs Audio to radio (voice, PSK, JT, RTTY, > > SSTV), cw keying to radio, Amplifier keying, and > > band/mode data both ways... and the like - all > > for under $29.95 :-) :-) ) > > You mean, like this: > > (Warning! Macintosh compatibility unknown) > > The prices range all over, but they certainly seem to have a number > of > interesting gadgets. > > Bill Coleman, AA4LR, PP-ASEL Mail: aa4lr@arrl.net > Quote: "Boot, you transistorized tormentor! Boot!" > -- Archibald Asparagus, VeggieTales > > From jbastin at sssnet.com Sun Feb 20 21:28:33 2005 From: jbastin at sssnet.com (John E Bastin) Date: Sun Feb 20 21:28:38 2005 Subject: [MacLoggerContest] Post-contest support In-Reply-To: <39e2575054e7f775b9b9f32c98489481@amsat.org> References: <39e2575054e7f775b9b9f32c98489481@amsat.org> Message-ID: On Feb 20, 2005, at 12:48 PM, Jonathan G0DVJ wrote: > Thanks for the replies/comments on the previous keyer thread - I agree > completely with both John & Bill on all their points. > > > Another aspect we haven't yet covered much is post-contest support... > Again I will kick off with some comments about this and perhaps people > will comment/correct as they wish. > > > So after the hard work of the contest it would be nice to have : > > 1) an easy way to submit the entry [Essential] > > 2) an easy way to aggregate the contest log into a main station log > (either MLDX or something else) [Essential] > > 3) a way to analyse the performance of the contest effort [Bell & > Whistle?] > > 4) anything else I have forgotten?? > > > For (1) I guess we are talking about Cabrillo export but with some > parts of the header completed from info the software already has about > the operator (e.g. contact info) and the station (maybe radios & > antennas - see about locations below) etc. This links the > post-contest facilities with the contest set-up part as well as user > preferences. Cabrillo export if the contest organizer wants the scores submitted that way. Not all contests ask for Cabrillo; many times with my present contest logging software I see people complaining that there is no Cabrillo export for a contest _where Cabrillo isn't wanted_. If the software is going to attempt to export files suitable for contest entry, then it MUST have accurate information on what is required for each contest, and provide what is needed, whether it be Cabrillo or something else. > > For (2) I guess we are talking about an intelligent ADIF export, which > most other station loggers can handle - it would be excellent IMHO if > we could crack the problem I have often had which is conveying the > contest name, year & my contest location over to the comments or notes > field of the station log so that this information can be added to any > QSLs I create (e.g. in the MLDX QSL facility). IMO this problem is much more easily solved at the receiving end. The logging software can have a provision to enter additional fields such as contest name and the like and have them included in each record of the imported file. That easily handles the object of having things in the proper format for whatever program is receiving the data. > > In (3) I would like to be able to analyse the QSOs, Points, Mults (if > applicable) per hour of the contest. Also Mults per band/mode would > be interesting. This is an area that like with MLDX awards facility > could be enhanced as time goes on IMHO. Analysis functions are very useful. 73, J o h n B a s t i n K 8 A J S jbastin@sssnet.com http://www.qsl.net/k8ajs -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: text/enriched Size: 2819 bytes Desc: not available Url : http://seven.pairlist.net/pipermail/macloggercontest/attachments/20050220/d593d161/attachment-0001.bin From g0dvj at amsat.org Sat Feb 26 17:22:13 2005 From: g0dvj at amsat.org (Jonathan G0DVJ) Date: Sat Feb 26 17:22:15 2005 Subject: [MacLoggerContest] Any other topics? Message-ID: <9999ee07d959f63d2411cbccb59eeed4@amsat.org> So have we exhausted the debate on this list now ? Covered everything? I propose that next I repost the original list of features, re-ordered and modified based on the ideas people have put forward in the various threads so far. This was what Don originally suggested - it would be good if we could try and agree some sort of consensus on the top five priorities. The main point of debate so far that I have detected is whether MLC should be aimed at single station, SO2R, or Multi-multi. I would hope that we could at least aim for the first with bells and whistles following, and SO2R as a longer term goal ? I think as someone observed, big multi-multi groups are relatively small in number and have existing systems that they employ already - hence the market there is probably too small to warrant consideration. I will re-post the original list and and canvass your support soon. Thanks, Jonathan G0DVJ -- From K1GQ at kc1xx.com Sat Feb 26 17:36:58 2005 From: K1GQ at kc1xx.com (K1GQ) Date: Sat Feb 26 17:37:04 2005 Subject: [MacLoggerContest] Any other topics? In-Reply-To: <9999ee07d959f63d2411cbccb59eeed4@amsat.org> References: <9999ee07d959f63d2411cbccb59eeed4@amsat.org> Message-ID: On 2005 Feb 26, at 17:22, Jonathan G0DVJ wrote: > I think as someone observed, big multi-multi groups are relatively > small in number and have existing systems that they employ already - > hence the market there is probably too small to warrant consideration. I must have missed that observation. It's wrong in that the "market" is no smaller than in any other category -- with one caveat: it can't be an all-or-nothing choice. I want to be able to take my Powerbook loaded with MLC to KC1XX, plug in an ethernet cable, and have it Just Work with the CT messaging protocol. I wouldn't be interested in an MLC design that fails to consider networks of computers running MLC and/or other contest logging programs. Bill, K1GQ From w2wjo at earthlink.net Sat Feb 26 17:50:33 2005 From: w2wjo at earthlink.net (Walter O'Brien, W2WJO) Date: Sat Feb 26 17:54:22 2005 Subject: [MacLoggerContest] Any other topics? In-Reply-To: References: <9999ee07d959f63d2411cbccb59eeed4@amsat.org> Message-ID: wouldn't having import/export of .adif and/or cabrillo solve that problem for the most part? Not everybody uses CT... I think an MLC for every possible network PC contest is raising the bar pretty high. Of course, if that's your requirement, then that's what you need. But just a great contesting package with flexibility for the various major contests is sure a great start. It can always be tweaked and added on as it goes.. start with single user, work your way up to multi and SO2R, etc. IMHO 73 Walter W2WJO On Feb 26, 2005, at 5:36 PM, K1GQ wrote: > On 2005 Feb 26, at 17:22, Jonathan G0DVJ wrote: > >> I think as someone observed, big multi-multi groups are relatively >> small in number and have existing systems that they employ already - >> hence the market there is probably too small to warrant >> consideration. > > I must have missed that observation. It's wrong in that the "market" > is no smaller than in any other category -- with one caveat: it can't > be an all-or-nothing choice. I want to be able to take my Powerbook > loaded with MLC to KC1XX, plug in an ethernet cable, and have it Just > Work with the CT messaging protocol. I wouldn't be interested in an > MLC design that fails to consider networks of computers running MLC > and/or other contest logging programs. > > Bill, K1GQ > > _______________________________________________ > MacLoggerContest mailing list > MacLoggerContest@dogparksoftware.com > http://seven.pairlist.net/mailman/listinfo/macloggercontest > From K1GQ at kc1xx.com Sat Feb 26 18:00:13 2005 From: K1GQ at kc1xx.com (K1GQ) Date: Sat Feb 26 18:00:17 2005 Subject: [MacLoggerContest] Any other topics? In-Reply-To: References: <9999ee07d959f63d2411cbccb59eeed4@amsat.org> Message-ID: <1d6a0e20ed32fdd5463339ababf6af9a@kc1xx.com> On 2005 Feb 26, at 17:50, Walter O'Brien, W2WJO wrote: > wouldn't having import/export of .adif and/or cabrillo solve that > problem for the most part? Not everybody uses CT... No, that would be completely inadequate. I'm aiming to use MLC *during* the contests. *I* use CT. If somebody else wants to interface with some other contest program, speak up -- I only inject requirements that matter to me :-) Bill From dagro at dogparksoftware.com Sat Feb 26 18:07:34 2005 From: dagro at dogparksoftware.com (Don Agro) Date: Sat Feb 26 18:07:37 2005 Subject: [MacLoggerContest] Any other topics? In-Reply-To: <1d6a0e20ed32fdd5463339ababf6af9a@kc1xx.com> References: <9999ee07d959f63d2411cbccb59eeed4@amsat.org> <1d6a0e20ed32fdd5463339ababf6af9a@kc1xx.com> Message-ID: Hi Bill, On 26-Feb-05, at 6:00 PM, K1GQ wrote: > On 2005 Feb 26, at 17:50, Walter O'Brien, W2WJO wrote: > >> wouldn't having import/export of .adif and/or cabrillo solve that >> problem for the most part? Not everybody uses CT... > > No, that would be completely inadequate. I'm aiming to use MLC > *during* the contests. > > *I* use CT. If somebody else wants to interface with some other > contest program, speak up -- I only inject requirements that matter to > me :-) > > Bill To the best of my knowledge the CT messaging protocol is private and unpublished. On 1-Feb-05, at 7:33 AM, Brian Short wrote: > Well, multi-op, multi-transmitter is a subset, obviously. > > The inter-computer networking is important to those who do > this type of thing, but any look at the results will show that > the number of entries in this class is fairly small compared > to the single-op or multi-op/single transmitter. > > Not that they are not important, but... > > Also, Writelog as far as I know does not inter-operate with > TrLog or CT. CT does not inter-operate with TrLog, etc. > > In the past, the networking has been between like "programs" > only, never mind platforms, operating systems, etc. > > I don't even know, myself, if the WriteLog has an open protocol > for the networking - the documentation is sparse is some senses > and largely provided by volunteers as far as I can tell. 73 Don Agro VE3VRW D o g P a r k S o f t w a r e L t d . email: dagro@dogparksoftware.com www: http://www.dogparksoftware.com iChat AV:dogpark@mac.com From mikel at oreilly.com Sat Feb 26 18:53:05 2005 From: mikel at oreilly.com (Michael K. Loukides) Date: Sat Feb 26 18:53:07 2005 Subject: [MacLoggerContest] another contest logger for the mac In-Reply-To: <20050226230018.944815722B@seven.pairlist.net> References: <20050226230018.944815722B@seven.pairlist.net> Message-ID: I just joined the list; haven't seen loads of activity, though. If someone wants to look at a contest logger that runs on the mac, try my JL (www.qsl.net/w1jq). It's free, it's written in Java. I haven't looked seriously at contest loggers for the UNIX world since I started the JL project, so I don't know how it compares with the competition. But it's nice, and it's fairly easy to use. I've used in top-10 finishes in ARRL DX Phone '04 and (based on preliminary scores) CQWW DX Phone '04, both SOAB LP. It supports a fairly large number of contests and can be coerced into working for most state QSO parties. It incorporates a CW keyer and a DVK (CW depends on the serial port, see below). It also supports rig control for Icom radios, also depending on the serial port. I haven't yet tried to figure out serial port support on OS X. I'd appreciate someone who wants to give it a shot, though, and save me the effort. I think it can be done with a USB-serial interface (many products available, including one from Microham) and the rxtx implementation of the javax.comm interfaces (www.rxtx.org). The rxtx package has been compiled for OS X, and I've traded email with someon who's used it successfully, but I haven't tried yet. And I admit I'd appreciate it if someone would do the work for me. There are a lot of things it doesn't support yet: * It doesn't support M-M at this point. * It doesn't support DX clusters. * It doesn't support SO2R MM support is something I'd very much like to add... though I've spent a couple of years trying to think it through, and haven't decided how to do it. DX cluster support is something I'll probably add fairly soon. I'm inching my way towards SO2R--I now have the 2R, but I don't have the 2Ant--and I have no idea what sort of software support this would require. Anyway, take a look, see if you like it. Again, www.qsl.net/w1jq. Mike Loukides, W1JQ From jbastin at sssnet.com Mon Feb 28 09:29:39 2005 From: jbastin at sssnet.com (John Bastin) Date: Mon Feb 28 09:29:45 2005 Subject: [MacLoggerContest] Any other topics? In-Reply-To: References: <9999ee07d959f63d2411cbccb59eeed4@amsat.org> Message-ID: <0a5f1d44efa6e452e682aa6a99d8c861@sssnet.com> On Feb 26, 2005, at 5:36 PM, K1GQ wrote: > On 2005 Feb 26, at 17:22, Jonathan G0DVJ wrote: > >> I think as someone observed, big multi-multi groups are relatively >> small in number and have existing systems that they employ already - >> hence the market there is probably too small to warrant >> consideration. > > I must have missed that observation. It's wrong in that the "market" > is no smaller than in any other category -- with one caveat: it can't > be an all-or-nothing choice. I want to be able to take my Powerbook > loaded with MLC to KC1XX, plug in an ethernet cable, and have it Just > Work with the CT messaging protocol. I wouldn't be interested in an > MLC design that fails to consider networks of computers running MLC > and/or other contest logging programs. > > Bill, K1GQ I'll put in a second to that request. For maximum usefulness, we need to be compatible in data formats and transfer protocols with what's already out there. 73, John E Bastin, K8AJS jbastin@sssnet.com http://www.qsl.net/k8ajs/ From jbastin at sssnet.com Mon Feb 28 09:32:43 2005 From: jbastin at sssnet.com (John Bastin) Date: Mon Feb 28 09:32:47 2005 Subject: [MacLoggerContest] Any other topics? In-Reply-To: <1d6a0e20ed32fdd5463339ababf6af9a@kc1xx.com> References: <9999ee07d959f63d2411cbccb59eeed4@amsat.org> <1d6a0e20ed32fdd5463339ababf6af9a@kc1xx.com> Message-ID: On Feb 26, 2005, at 6:00 PM, K1GQ wrote: > On 2005 Feb 26, at 17:50, Walter O'Brien, W2WJO wrote: > >> wouldn't having import/export of .adif and/or cabrillo solve that >> problem for the most part? Not everybody uses CT... > > No, that would be completely inadequate. I'm aiming to use MLC > *during* the contests. > > *I* use CT. If somebody else wants to interface with some other > contest program, speak up -- I only inject requirements that matter to > me :-) A multi- station where I frequently contest uses NA. However, he also uses DOS networking via serial ports, and I wouldn't ask ANYBODY to go there...:-) 73, John E Bastin, K8AJS jbastin@sssnet.com http://www.qsl.net/k8ajs/ From dagro at dogparksoftware.com Mon Feb 28 09:47:31 2005 From: dagro at dogparksoftware.com (Don Agro) Date: Mon Feb 28 09:47:33 2005 Subject: [MacLoggerContest] Any other topics? In-Reply-To: <0a5f1d44efa6e452e682aa6a99d8c861@sssnet.com> References: <9999ee07d959f63d2411cbccb59eeed4@amsat.org> <0a5f1d44efa6e452e682aa6a99d8c861@sssnet.com> Message-ID: <085a9ab6a6135a3b2826b7075851b301@dogparksoftware.com> Hi John, On 28-Feb-05, at 9:29 AM, John Bastin wrote: > I'll put in a second to that request. For maximum usefulness, we need > to be compatible in data formats and transfer protocols with what's > already out there. If compatibility with multiple existing undocumented data transfer protocols is a show stopper - well then consider the show stopped - at this end anyway. This is just so far from reasonable that I am (almost) speechless. Cabrillo, ADIF fine - but interoperability with PC network loggers when THEY don't even interoperate ? 73 Don Agro VE3VRW D o g P a r k S o f t w a r e L t d . email: dagro@dogparksoftware.com www: http://www.dogparksoftware.com iChat AV:dogpark@mac.com From jackbrindle at earthlink.net Mon Feb 28 11:52:49 2005 From: jackbrindle at earthlink.net (Jack Brindle) Date: Mon Feb 28 11:52:53 2005 Subject: [MacLoggerContest] Any other topics? In-Reply-To: <085a9ab6a6135a3b2826b7075851b301@dogparksoftware.com> References: <9999ee07d959f63d2411cbccb59eeed4@amsat.org> <0a5f1d44efa6e452e682aa6a99d8c861@sssnet.com> <085a9ab6a6135a3b2826b7075851b301@dogparksoftware.com> Message-ID: I'll second what Don says here. The formats, protocols and network communications for the various PC-based programs are closely-held secrets. With few exceptions, the authors have not collaborated to share this information, instead choosing to reinvent the formats so that users are locked in to their own programs. To be fair, testing with everyone else's program would be a bear, especially since those programs tend to change very often. Also, in some cases the information changes with every release since it is extremely closely related to the internal data format of the program (for those cases). While there may be some cracks in the information wall, don't expect these authors to open up their network formats. The cracks? TLF is a Linux-based open-source program. There may be a couple of others in this vein as well. I believe there are several common areas where we may lead the way with standard, open methods. M/M network data formats and protocols is certainly one, as well as a common contest definition format. Any others? On Feb 28, 2005, at 6:47 AM, Don Agro wrote: > On 28-Feb-05, at 9:29 AM, John Bastin wrote: > >> I'll put in a second to that request. For maximum usefulness, we need >> to be compatible in data formats and transfer protocols with what's >> already out there. > > If compatibility with multiple existing undocumented data transfer > protocols is a show stopper - well then consider the show stopped - at > this end anyway. > > This is just so far from reasonable that I am (almost) speechless. > > Cabrillo, ADIF fine - but interoperability with PC network loggers > when THEY don't even interoperate ? - Jack Brindle, W6FB ------------------------------------------------------------------------ --------------------- From K1GQ at kc1xx.com Mon Feb 28 12:19:45 2005 From: K1GQ at kc1xx.com (K1GQ) Date: Mon Feb 28 12:19:48 2005 Subject: [MacLoggerContest] Any other topics? In-Reply-To: References: <9999ee07d959f63d2411cbccb59eeed4@amsat.org> <0a5f1d44efa6e452e682aa6a99d8c861@sssnet.com> <085a9ab6a6135a3b2826b7075851b301@dogparksoftware.com> Message-ID: <8294bf6236d1c10bb2e3eb8012354a08@kc1xx.com> On 2005 Feb 28, at 11:52, Jack Brindle wrote: There is a lot of disinformation here, which I can't let pass. > I'll second what Don says here. The formats, protocols and network > communications for the various PC-based programs are closely-held > secrets. In the case that I care about, there are *no* secrets, closely-held or otherwise. > With few exceptions, the authors have not collaborated to share this > information, instead choosing to reinvent the formats so that users > are locked in to their own programs. Nor is there any lock-in motive; the software is free. It is true that there has been little incentive for existing software to interoperate at the network level, and none does that I am aware of. As Apple computer enthusiasts, we're painfully aware that pretty much all of the work needed to implement interoperability will rest on our shoulders. > To be fair, testing with everyone else's program would be a bear, > especially since those programs tend to change very often. Also, in > some cases the information changes with every release since it is > extremely closely related to the internal data format of the program > (for those cases). Wrong again. The information exchanged across the CT network has not changed in format or content for years. > While there may be some cracks in the information wall, don't expect > these authors to open up their network formats. The cracks? TLF is a > Linux-based open-source program. There may be a couple of others in > this vein as well. Have you asked any authors? > I believe there are several common areas where we may lead the way > with standard, open methods. M/M network data formats and protocols is > certainly one, as well as a common contest definition format. Any > others? This is right on! My original posting had two motives: (1) I'd like to sneak up on the team that I operate with by bringing in one superb Mac OS X contest program that Just Works in the existing ethernet-based network of DOS logging programs (currently 11 computers). (2) I'd like the designers of MLC to not overlook the features implied by this configuration that do not apply at all in the single-computer situation, such as Gab and Partner mode, not to mention the fundamental database issues surrounding managing a consistent log with multiple asynchronous writers. And then there are the serial number contests... Ooops, I've probably convinced y'all that this is too hard :-) Bill From dagro at dogparksoftware.com Mon Feb 28 12:31:11 2005 From: dagro at dogparksoftware.com (Don Agro) Date: Mon Feb 28 12:31:14 2005 Subject: [MacLoggerContest] Any other topics? In-Reply-To: <8294bf6236d1c10bb2e3eb8012354a08@kc1xx.com> References: <9999ee07d959f63d2411cbccb59eeed4@amsat.org> <0a5f1d44efa6e452e682aa6a99d8c861@sssnet.com> <085a9ab6a6135a3b2826b7075851b301@dogparksoftware.com> <8294bf6236d1c10bb2e3eb8012354a08@kc1xx.com> Message-ID: <1cb10fcc6f856ac9d7ab6a6c8165896d@dogparksoftware.com> Hi Bill, On 28-Feb-05, at 12:19 PM, K1GQ wrote: > (2) I'd like the designers of MLC to not overlook the features implied > by this configuration that do not apply at all in the single-computer > situation, such as Gab and Partner mode, not to mention the > fundamental database issues surrounding managing a consistent log with > multiple asynchronous writers. And then there are the serial number > contests... Ummm - actually, what you said was : On 26-Feb-05, at 5:36 PM, K1GQ wrote: > I wouldn't be interested in an MLC design that fails to consider > networks of computers running MLC and/or other contest logging > programs. 73 Don Agro VE3VRW D o g P a r k S o f t w a r e L t d . email: dagro@dogparksoftware.com www: http://www.dogparksoftware.com iChat AV:dogpark@mac.com From dagro at dogparksoftware.com Mon Feb 28 12:48:28 2005 From: dagro at dogparksoftware.com (Don Agro) Date: Mon Feb 28 12:48:31 2005 Subject: [MacLoggerContest] Any other topics? In-Reply-To: <1cb10fcc6f856ac9d7ab6a6c8165896d@dogparksoftware.com> References: <9999ee07d959f63d2411cbccb59eeed4@amsat.org> <0a5f1d44efa6e452e682aa6a99d8c861@sssnet.com> <085a9ab6a6135a3b2826b7075851b301@dogparksoftware.com> <8294bf6236d1c10bb2e3eb8012354a08@kc1xx.com> <1cb10fcc6f856ac9d7ab6a6c8165896d@dogparksoftware.com> Message-ID: <3aa5d80dfc6955f14ccd0869b8a506e0@dogparksoftware.com> Hi Bill, On 28-Feb-05, at 12:31 PM, Don Agro wrote: > Ummm - actually, what you said was : Not trying to be argumentative here, just pointing out that there seems to be a big difference between the single ops who work contests from home, and the club contesters. Aside from the obvious networking and shared database issues do you think the differences run deeper ? Do the PC programs handle the difference well or would it be better to have a single and multi version of MLC ? 73 Don Agro VE3VRW D o g P a r k S o f t w a r e L t d . email: dagro@dogparksoftware.com www: http://www.dogparksoftware.com iChat AV:dogpark@mac.com From g0dvj at amsat.org Mon Feb 28 12:55:16 2005 From: g0dvj at amsat.org (Jonathan G0DVJ) Date: Mon Feb 28 12:55:18 2005 Subject: [MacLoggerContest] Any other topics? In-Reply-To: <3aa5d80dfc6955f14ccd0869b8a506e0@dogparksoftware.com> References: <9999ee07d959f63d2411cbccb59eeed4@amsat.org> <0a5f1d44efa6e452e682aa6a99d8c861@sssnet.com> <085a9ab6a6135a3b2826b7075851b301@dogparksoftware.com> <8294bf6236d1c10bb2e3eb8012354a08@kc1xx.com> <1cb10fcc6f856ac9d7ab6a6c8165896d@dogparksoftware.com> <3aa5d80dfc6955f14ccd0869b8a506e0@dogparksoftware.com> Message-ID: On Feb 28, 2005, at 5:48 pm, Don Agro wrote: > Not trying to be argumentative here, just pointing out that there > seems to be a big difference between the single ops who work contests > from home, and the club contesters. > > Aside from the obvious networking and shared database issues do you > think the differences run deeper ? Don, My take on this would be to classify the difference between Multi-Multi operations & others. For example the software I would hope to replace with something like MLC would work equally well if i am a single op at home or when i am out with one of my multi-op but single station clubs out in the field. Will reply with more on this thread later. Pushed for time now - sorry. 73, Jonathan G0DVJ -- From K1GQ at kc1xx.com Mon Feb 28 13:10:41 2005 From: K1GQ at kc1xx.com (K1GQ) Date: Mon Feb 28 13:10:48 2005 Subject: [MacLoggerContest] Any other topics? In-Reply-To: <3aa5d80dfc6955f14ccd0869b8a506e0@dogparksoftware.com> References: <9999ee07d959f63d2411cbccb59eeed4@amsat.org> <0a5f1d44efa6e452e682aa6a99d8c861@sssnet.com> <085a9ab6a6135a3b2826b7075851b301@dogparksoftware.com> <8294bf6236d1c10bb2e3eb8012354a08@kc1xx.com> <1cb10fcc6f856ac9d7ab6a6c8165896d@dogparksoftware.com> <3aa5d80dfc6955f14ccd0869b8a506e0@dogparksoftware.com> Message-ID: <0fead9e901fdefc660877f17ccdfabc8@kc1xx.com> Hi Don, On 2005 Feb 28, at 12:48, Don Agro wrote: > Hi Bill, > > On 28-Feb-05, at 12:31 PM, Don Agro wrote: > >> Ummm - actually, what you said was : > > Not trying to be argumentative here, just pointing out that there > seems to be a big difference between the single ops who work contests > from home, and the club contesters. Yes, big difference, in that the multi-ops need everything that the single-ops need (except perhaps SO2R), and a lot more. At the same time, the larger multi-ops need so many computers, and their software is so unstable, that they tend to use very old hardware and fear to modify "working" configurations. > Aside from the obvious networking and shared database issues do you > think the differences run deeper ? From the user's perspective I think that there is little difference. > Do the PC programs handle the difference well or would it be better to > have a single and multi version of MLC ? I am very familiar with one PC program, CT, and not at all with any others. CT has one version that supports all the entry categories, and from what I know of the program's architecture there would be little reason to split it into more than one version. Ummm, here's one thought: CT is entirely the work of one individual -- K1EA. If it were more modular, others could perhaps help Ken maintain and extend the software; that is not possible as it stands (we've tried). I'd love to participate in developing MLC, but modularity is hard to do well. [In Real Life I develop data analysis software for USAF customers using C++ and Python.] Bill From jackbrindle at earthlink.net Mon Feb 28 13:59:29 2005 From: jackbrindle at earthlink.net (Jack Brindle) Date: Mon Feb 28 13:59:35 2005 Subject: [MacLoggerContest] Any other topics? In-Reply-To: <8294bf6236d1c10bb2e3eb8012354a08@kc1xx.com> References: <9999ee07d959f63d2411cbccb59eeed4@amsat.org> <0a5f1d44efa6e452e682aa6a99d8c861@sssnet.com> <085a9ab6a6135a3b2826b7075851b301@dogparksoftware.com> <8294bf6236d1c10bb2e3eb8012354a08@kc1xx.com> Message-ID: <9b710beef2f8c7b31d3b6e56b3d11d22@earthlink.net> On Feb 28, 2005, at 9:19 AM, K1GQ wrote: > On 2005 Feb 28, at 11:52, Jack Brindle wrote: >> I'll second what Don says here. The formats, protocols and network >> communications for the various PC-based programs are closely-held >> secrets. > > In the case that I care about, there are *no* secrets, closely-held or > otherwise. If something is not published, then it is legally held as trade secret. None of the PC-based programs have published their protocols. >> With few exceptions, the authors have not collaborated to share this >> information, instead choosing to reinvent the formats so that users >> are locked in to their own programs. > > Nor is there any lock-in motive; the software is free. Only in a few cases. TRLog and WriteLog, the two biggest contenders in the PC world are definitely not free. N1MM is making inroads, but not so much yet with the "big boys." >> To be fair, testing with everyone else's program would be a bear, >> especially since those programs tend to change very often. Also, in >> some cases the information changes with every release since it is >> extremely closely related to the internal data format of the program >> (for those cases). > > Wrong again. The information exchanged across the CT network has not > changed in format or content for years. There is a major fundamental problem here. It is not feasible to implement the protocols and formats for every PC program. If _I_ were making the decision, I would try for TRLog and WriteLog, and maybe N1MM compatibility. The information for those three programs is definitely not available. Yes, in fact, I have asked. In the case of N1MM I was very specifically told that the information is still changing, and that since its stability is problematic for Tom, he was not interested in adding troubles by letting someone else play. I would not suggest reverse-engineering the protocols and expecting that to work. One slight change and we have to reinvest the time for reverse engineering. There is a very slight possibility for working with CT in that parts of the protocol _may_ be available. With the small user-base CTLog commands at this time with respect to the other programs, and expecting that MLC would be a commercial venture, I seriously question whether it is worth while to make this effort. But then _I_ am not making the decisions here, right? > (2) I'd like the designers of MLC to not overlook the features implied > by this configuration that do not apply at all in the single-computer > situation, such as Gab and Partner mode, not to mention the > fundamental database issues surrounding managing a consistent log with > multiple asynchronous writers. And then there are the serial number > contests... > > Ooops, I've probably convinced y'all that this is too hard :-) I agree that this is an admirable goal, and one that should be in the desired features set. Again having it there will have an effect on the programs architecture, although not quite as much as an SO2R requirement. I believe there is a LOT of work to be done just to get the program up to a level for a single operator without having the author reverse engineer other folks protocols. I strongly agree that creating and publishing the protocols and formats would be a great thing. But the effort cannot stop there. Evangelizing the standards and getting other authors to use them would be a monumental task. Trey and friends had a big carrot when introducing the Cabrillo format - use it or get pushed out of the contest market. We don't have that carrot. The PC authors will simply say "Sorry, I'll keep doing things MY way." How do I know? From conversations with them. To a person, they are very friendly and great guys. But they want to do things their way. This is a place where enlisting the help of various individuals in the contesting community would be of great help. Having a single application that would create a contest template for every platform would be of great use for contest sponsors. They could simply publish the template (on a web page, say) have the contesters download it, and be ready to go. Just the effort saved in answering user questions would be a big help for not only the contest sponsors, but the software providers as well. Anyone wish to go try evangelizing these things? Let's get a good, solid contest program for the Mac going, with the proper hooks to add whatever we want in the future. I think we agree, we really need that. - Jack Brindle, W6FB ------------------------------------------------------------------------ --------------------- From g0dvj at amsat.org Mon Feb 28 16:02:54 2005 From: g0dvj at amsat.org (Jonathan G0DVJ) Date: Mon Feb 28 16:02:56 2005 Subject: [MacLoggerContest] Any other topics? In-Reply-To: <9999ee07d959f63d2411cbccb59eeed4@amsat.org> References: <9999ee07d959f63d2411cbccb59eeed4@amsat.org> Message-ID: <5576f9eff2b738cfae7426bea094daf5@amsat.org> On Feb 26, 2005, at 10:22 pm, I wrote: > So have we exhausted the debate on this list now ? Covered > everything? LOL - Clearly there was more to say ! Nice to see renewed activity on the list ! I am going to try to pull together bits from the various inputs to the thread in this mail... On Feb 26, 2005, at 10:50 pm, Walter O'Brien, W2WJO wrote: > Not everybody uses CT... true - and although I have (in fact I have used most of them for something LOL), many people especially this side of the Pond do not use CT unless they are one of the big multi-multi groups - but I think picking out compatibility with any one or two or three of existing programs is problematic as an approach in any case. > I think an MLC for every possible network PC contest is raising the > bar pretty high. Of course, if that's your requirement, then that's > what you need. But just a great contesting package with flexibility > for the various major contests is sure a great start. It can always be > tweaked and added on as it goes.. start with single user, work your > way up to multi and SO2R, etc. I agree about this raising the bar very (too) high and as Don said: On Feb 28, 2005, at 2:47 pm, Don Agro wrote: > If compatibility with multiple existing undocumented data transfer > protocols is a show stopper - well then consider the show stopped - at > this end anyway. > This is just so far from reasonable that I am (almost) speechless. > Cabrillo, ADIF fine - but interoperability with PC network loggers > when THEY don't even interoperate ? On Feb 28, 2005, at 2:29 pm, John Bastin wrote: > I'll put in a second to that request. For maximum usefulness, we need > to be compatible in data formats and transfer protocols with what's > already out there. I sympathise with the vision that John and Bill paint, but for now at least I think this amounts to trying to "boil the ocean" in terms of sorting out the general problem of non-interworking software for multi-multi networked set-ups! What Don says about show stopping is good enough for me! And I do not want to stop the show after we have edged towards so much general agreement in other areas. On Feb 28, 2005, at 5:19 pm, K1GQ wrote: > It is true that there has been little incentive for existing software > to interoperate at the network level, and none does that I am aware > of. As Apple computer enthusiasts, we're painfully aware that pretty > much all of the work needed to implement interoperability will rest on > our shoulders. This is the bit I have trouble subscribing to! Why should it rest with Mac developers? If we can develop an insanely great contest logger for Mac OSX then ... [putting tongue firmly in cheek and bullet-proof vest on!] ... those that can afford to have the best station (aka KC1XX et al.) will also want to have the best computing platform and logging software and so invest in 11 Mac Mini's & MLC version n (where n is not too small a number !!) LOL ? I am attempting to inject a little light-heartedness into the debate in case anyone missed it! But there is a case for making contest logging for the single op (including multi-op SINGLE station - i.e. one op at a time!) so pleasant and easy with MLC that it encourages all those smaller contest stations to get on and give more points away to the bigger guns! I believe that those of us who are dedicated enough to do multi-multi, have already proved that we will use all sorts of D(r)OS and Windoze systems with all their peculiarities and imperfections to get the logging done - those who don't and won't ever do M-M are the prime customers for an OSX solution which is a breeze to use (like hardware like software! c.f. father - son). On Feb 28, 2005, at 5:19 pm, K1GQ wrote: > (2) I'd like the designers of MLC to not overlook the features implied > by this configuration that do not apply at all in the single-computer > situation, such as Gab and Partner mode, not to mention the > fundamental database issues surrounding managing a consistent log with > multiple asynchronous writers. And then there are the serial number > contests... These are the features that I would love to be borne in mind when designing MLC so that if it is possible to extend it for M-M after the initial versions that it is not such a problem. I do agree with Bill on this. On Feb 28, 2005, at 6:59 pm, Jack Brindle wrote: > Let's get a good, solid contest program for the Mac going, with the > proper hooks to add whatever we want in the future. I think we agree, > we really need that. Yes so that is the first agreed over-riding point we have reached consensus on then ? :) But it may turn out that design-wise as well as focus-on-market-segment-wise, there is a case for only using this knowledge of the extra hooks that would be required to decide that 2 programs are required (in the fullness of time) as with Doppler and DopplerPro, Maybe MLC and MLC-Multi ? *IF* this was the conclusion then maybe MLC design should be done with SO2R hooks for later in mind thereby re-enforcing the idea of Single Station (single or multi-op, one or two radios) for MLC and Multiple Station support for MLC-Multi ? Note I am not trying to seemingly double the work of Don here - rather catalysing the discussion about how wide to make the scope of what we can do in one insanely great piece of contest software! In fact I was surprised and rather encouraged that no-one squealed when I suggested in an early thread here that MLC could support both HF and VHF contesters, which I don't think is attempted by very many other solutions around. It's not that i don't appreciate the differences between these categories as in the same way that there are differences for Multi-Single & Multi-Multi - just which categories can be brought together for the benefit of the users. On with the debate ... I will hold off a bit more before offering the top 5 feature list that we are looking to get support from 20 of us to achieve a level of consensus on :) For those that don't know what I mean by this, let me re-quote what Don expressed to me at the outset of the formation of this list ... I want everyone here to be absolutely clear about why I am putting so much effort into the consensus building ! :) On 2-Feb-05, at 10:28 AM, Don Agro wrote: > I would really appreciate seeing your original email posted back to > the Ham-Mac list re-written in order of priority - If 20 people on the > Ham-Mac list can agree on the top 5 priorities I will jump into the > fray with MacLoggerContest. The reason I am asking for that level of > detail is not just to get a consensus amongst the enthusiasts, but to > make sure I (a non-contester) get a firm grip on what it would take to > make an insanely great contesting program. We need the debate on any topics - they are all valid! But I could also simply produce a spec for MLC which suits just me and what I do and which I state is non-negotiable - however I don't feel that would be helpful :) Oh and there are 41 people subscribed to this list - so if some of you would prefer to give opinions direct to Don or via myself instead of on the list (I know that some may have been "flamed" when giving views on other lists before in their Internet lives which may leave them less comfy about posting to the whole list), then please do reply directly. All opinions are welcomed. 73, Jonathan G0DVJ -- From jbastin at sssnet.com Mon Feb 28 16:56:21 2005 From: jbastin at sssnet.com (John Bastin) Date: Mon Feb 28 16:56:28 2005 Subject: [MacLoggerContest] Any other topics? In-Reply-To: <5576f9eff2b738cfae7426bea094daf5@amsat.org> References: <9999ee07d959f63d2411cbccb59eeed4@amsat.org> <5576f9eff2b738cfae7426bea094daf5@amsat.org> Message-ID: On Feb 28, 2005, at 4:02 PM, Jonathan G0DVJ wrote: > > On Feb 28, 2005, at 5:19 pm, K1GQ wrote: >> It is true that there has been little incentive for existing software >> to interoperate at the network level, and none does that I am aware >> of. As Apple computer enthusiasts, we're painfully aware that pretty >> much all of the work needed to implement interoperability will rest >> on our shoulders. > > This is the bit I have trouble subscribing to! Why should it rest > with Mac developers? Well, unfortunately, because we're trying to get our foot in the doorway to an entrenched status quo. The developers of other software really have no incentive to spend uncompensated time writing in compatibility with a platform that none of their customers use. > If we can develop an insanely great contest logger for Mac OSX then > ... [putting tongue firmly in cheek and bullet-proof vest on!] ... > those that can afford to have the best station (aka KC1XX et al.) will > also want to have the best computing platform and logging software and > so invest in 11 Mac Mini's & MLC version n (where n is not too small a > number !!) Realistically, KC1XX et al. have priorities for their "big gun" stations and those priorities are the best radios, the best antennas and the best operators. Computers and software are far down the list of investment items. CT and NA are attractive and widely-used programs that have one VERY big quality - they run in DOS, which means the contesters can have very good software running on the cheapest, salvage and refurbished hardware available. WriteLog is a popular program for the newer users who already have hardware that came running Windows, but the old-timers are still DOS people. Despite my earlier comment, probably the main thing that would be nice for our software is that it be able to handle data in currently-used amateur radio formats, meaning Cabrillo and ADIF, for purposes of moving data from one machine to another or even from platform to platform. Let's face it, despite what Bill dreamed about, I'm not going into an established multi-multi setup with my PowerBook to sit down and operate; that multi-multi already has computers at every radio and a couple of spares if needed. Even if the software could converse, the hardware nightmare of going in there with a 'strange' computer and trying to wire it up would only be counter-productive for the contest operation. And in the end, that's the bottom line: does it help the score? If not, it's not getting in the door. So in the beginning, let's have contesting software that works for the single-operator and multi-single operations, where the guy (or gal) who wants to enter the contest just happens to already be a Mac user. If he's a single-op, he wants to use the platform he's comfortable with, and if he's hosting a multi-single, the ops coming in will use whatever is there. They don't care, as long as it helps the score. Important points? Here's my vote: Radio control CW/FSK generation (copy is necessary for FSK, not for CW) Fast dupe checking, whether there are 5 contacts in the log or 5000 Automatic journaling, so even if you have a power failure, NOTHING is lost. Native coverage of a wide range of contests, with the ability to change the entry format to whatever is required for a particular 'test, and to accurately compute the score at the end. An ongoing display of the current score isn't really necessary, but a display of multipliers/bands needed would be a plus. 73, John E Bastin, K8AJS jbastin@sssnet.com http://www.qsl.net/k8ajs/ From aa4lr at arrl.net Mon Feb 28 21:38:38 2005 From: aa4lr at arrl.net (Bill Coleman) Date: Mon Feb 28 22:10:37 2005 Subject: [MacLoggerContest] Any other topics? In-Reply-To: <8294bf6236d1c10bb2e3eb8012354a08@kc1xx.com> References: <9999ee07d959f63d2411cbccb59eeed4@amsat.org> <0a5f1d44efa6e452e682aa6a99d8c861@sssnet.com> <085a9ab6a6135a3b2826b7075851b301@dogparksoftware.com> <8294bf6236d1c10bb2e3eb8012354a08@kc1xx.com> Message-ID: <6cb51a8ad26d509c146a966f62e77afd@arrl.net> On Feb 28, 2005, at 12:19 PM, K1GQ wrote: >> I'll second what Don says here. The formats, protocols and network >> communications for the various PC-based programs are closely-held >> secrets. > > In the case that I care about, there are *no* secrets, closely-held or > otherwise. Where can I find the specification of the CT network protocols? Bill Coleman, AA4LR, PP-ASEL Mail: aa4lr@arrl.net Quote: "Not within a thousand years will man ever fly!" -- Wilbur Wright, 1901 From g0dvj at amsat.org Tue Mar 1 17:10:54 2005 From: g0dvj at amsat.org (Jonathan G0DVJ) Date: Tue Mar 1 17:10:58 2005 Subject: [MacLoggerContest] Any other topics? In-Reply-To: References: <9999ee07d959f63d2411cbccb59eeed4@amsat.org> <5576f9eff2b738cfae7426bea094daf5@amsat.org> Message-ID: On Feb 28, 2005, at 9:56 pm, John Bastin wrote: > Realistically, KC1XX et al. have priorities for their "big gun" > stations and those priorities are the best radios, the best antennas > and the best operators. Computers and software are far down the list > of investment items. CT and NA are attractive and widely-used programs > that have one VERY big quality - they run in DOS, which means the > contesters can have very good software running on the cheapest, > salvage and refurbished hardware available. WriteLog is a popular > program for the newer users who already have hardware that came > running Windows, but the old-timers are still DOS people. Exactly - same as the big guns this side of the Pond! > Despite my earlier comment, probably the main thing that would be nice > for our software is that it be able to handle data in currently-used > amateur radio formats, meaning Cabrillo and ADIF, for purposes of > moving data from one machine to another or even from platform to > platform. Let's face it, despite what Bill dreamed about, I'm not > going into an established multi-multi setup with my PowerBook to sit > down and operate; that multi-multi already has computers at every > radio and a couple of spares if needed. Even if the software could > converse, the hardware nightmare of going in there with a 'strange' > computer and trying to wire it up would only be counter-productive for > the contest operation. And in the end, that's the bottom line: does it > help the score? If not, it's not getting in the door. > > So in the beginning, let's have contesting software that works for the > single-operator and multi-single operations, where the guy (or gal) > who wants to enter the contest just happens to already be a Mac user. > If he's a single-op, he wants to use the platform he's comfortable > with, and if he's hosting a multi-single, the ops coming in will use > whatever is there. They don't care, as long as it helps the score. I couldn't agree more. > Important points? Here's my vote: > > Radio control > CW/FSK generation (copy is necessary for FSK, not for CW) > Fast dupe checking, whether there are 5 contacts in the log or 5000 > Automatic journaling, so even if you have a power failure, NOTHING is > lost. > Native coverage of a wide range of contests, with the ability to > change the entry format to whatever is required for a particular > 'test, and to accurately compute the score at the end. An ongoing > display of the current score isn't really necessary, but a display of > multipliers/bands needed would be a plus. Thanks for the input John - I don't think I would have to compromise much to agree with you :) It's pretty much what others have said too - taking your previous paragraphs into account too. 73, Jonathan G0DVJ -- From jackbrindle at earthlink.net Wed Mar 2 01:44:07 2005 From: jackbrindle at earthlink.net (Jack Brindle) Date: Wed Mar 2 01:44:12 2005 Subject: [MacLoggerContest] Any other topics? In-Reply-To: References: <9999ee07d959f63d2411cbccb59eeed4@amsat.org> <5576f9eff2b738cfae7426bea094daf5@amsat.org> Message-ID: <9bf2d2a99990af601be06a1c4bf81ea7@earthlink.net> On Feb 28, 2005, at 1:56 PM, John Bastin wrote: > Automatic journaling, so even if you have a power failure, NOTHING is > lost. This grabbed my attention - I'd like to drill into it a bit to understand exactly what is being asked for and why. More importantly, I want to understand the current need for journalling, because I don't think I understand it properly now. Under MacOS X information written to files may be immediately flushed to disk. When writing a log file, the data may be appended to the log file and saved to disk immediately. As I understand journalling, the information is written to the journal file, then to the log file. In this case a power failure before the journal write would lose the entry, while one in-between the two writes will simply cause a journal-to-log file update on restart. But, the information that would be appended to the log file could have been handled in place of the journal write, taking care of the whole thing at once. In both cases, power failures before the first write completes causes the entire entry to be lost, while a failure after the first write completes just causes the operator to be rather unhappy. It seems that the simplest way to handle things would be to write the log entry to the file and immediately flush the file to disk. Is this too simple? What am I missing? - Jack Brindle, W6FB ------------------------------------------------------------------------ --------------------- From g0dvj at amsat.org Wed Mar 2 13:46:01 2005 From: g0dvj at amsat.org (Jonathan G0DVJ) Date: Wed Mar 2 13:47:45 2005 Subject: [MacLoggerContest] Journalling In-Reply-To: <9bf2d2a99990af601be06a1c4bf81ea7@earthlink.net> References: <9999ee07d959f63d2411cbccb59eeed4@amsat.org> <5576f9eff2b738cfae7426bea094daf5@amsat.org> <9bf2d2a99990af601be06a1c4bf81ea7@earthlink.net> Message-ID: <5cb17cb36a14fd6d89c6c65df7da2ea3@amsat.org> Interesting discussion ... Are we mixing up two meanings of Journalling? Maybe John mentioned it in the general sense of keeping a journal record of QSO data so that nothing is lost. i.e. at the application level. There is also the OSX specific meaning of Journalling which was introduced in Panther and which is a system-wide volume configuration aspect under admin user control at disk set-up time, and not the application. Not sure if Jack is alluding to this in his posting? I agree that the simplest way seems to be to write then flush from the application's viewpoint. However maybe this is another area where we should just state what the user experience should be and leave it to Don to decide how best to implement things to achieve it, like Jack rightly pointed out when I mentioned multi-threading in an earlier post! I think we all agree with John's original point about losing nothing from the committed log - Most other systems I have used cannot guarantee that the current QSO still being entered (i.e. not completed/committed) won't be lost, but that is the most one can lose. 73, Jonathan. -- On Mar 2, 2005, at 6:44 am, Jack Brindle wrote: > > On Feb 28, 2005, at 1:56 PM, John Bastin wrote: > >> Automatic journaling, so even if you have a power failure, NOTHING is >> lost. > > This grabbed my attention - I'd like to drill into it a bit to > understand exactly what is being asked for and why. More importantly, > I want to understand the current need for journalling, because I don't > think I understand it properly now. > > Under MacOS X information written to files may be immediately flushed > to disk. When writing a log file, the data may be appended to the log > file and saved to disk immediately. As I understand journalling, the > information is written to the journal file, then to the log file. In > this case a power failure before the journal write would lose the > entry, while one in-between the two writes will simply cause a > journal-to-log file update on restart. But, the information that would > be appended to the log file could have been handled in place of the > journal write, taking care of the whole thing at once. In both cases, > power failures before the first write completes causes the entire > entry to be lost, while a failure after the first write completes just > causes the operator to be rather unhappy. > > It seems that the simplest way to handle things would be to write the > log entry to the file and immediately flush the file to disk. Is this > too simple? What am I missing? From jackbrindle at earthlink.net Wed Mar 2 14:41:06 2005 From: jackbrindle at earthlink.net (Jack Brindle) Date: Wed Mar 2 14:41:09 2005 Subject: [MacLoggerContest] Journalling In-Reply-To: <5cb17cb36a14fd6d89c6c65df7da2ea3@amsat.org> References: <9999ee07d959f63d2411cbccb59eeed4@amsat.org> <5576f9eff2b738cfae7426bea094daf5@amsat.org> <9bf2d2a99990af601be06a1c4bf81ea7@earthlink.net> <5cb17cb36a14fd6d89c6c65df7da2ea3@amsat.org> Message-ID: A short bit of clarification, then. Make no assumptions as to what I may be referring. I won't claim to know what problem journalling may be solving. I won't claim to know how it may be solving that problem. I won't even claim to know why Apple added journalling to the Mac's file system! I simply want to know what the problem is that needs to be solved, and apparently has been solved in the past with journalling. On Mar 2, 2005, at 10:46 AM, Jonathan G0DVJ wrote: > > Interesting discussion ... > > Are we mixing up two meanings of Journalling? Maybe John mentioned it > in the general sense of keeping a journal record of QSO data so that > nothing is lost. i.e. at the application level. There is also the > OSX specific meaning of Journalling which was introduced in Panther > and which is a system-wide volume configuration aspect under admin > user control at disk set-up time, and not the application. Not sure > if Jack is alluding to this in his posting? > > I agree that the simplest way seems to be to write then flush from the > application's viewpoint. However maybe this is another area where we > should just state what the user experience should be and leave it to > Don to decide how best to implement things to achieve it, like Jack > rightly pointed out when I mentioned multi-threading in an earlier > post! > > I think we all agree with John's original point about losing nothing > from the committed log - Most other systems I have used cannot > guarantee that the current QSO still being entered (i.e. not > completed/committed) won't be lost, but that is the most one can lose. > > 73, > Jonathan. > -- > > On Mar 2, 2005, at 6:44 am, Jack Brindle wrote: > >> >> On Feb 28, 2005, at 1:56 PM, John Bastin wrote: >> >>> Automatic journaling, so even if you have a power failure, NOTHING >>> is lost. >> >> This grabbed my attention - I'd like to drill into it a bit to >> understand exactly what is being asked for and why. More importantly, >> I want to understand the current need for journalling, because I >> don't think I understand it properly now. >> >> Under MacOS X information written to files may be immediately flushed >> to disk. When writing a log file, the data may be appended to the log >> file and saved to disk immediately. As I understand journalling, the >> information is written to the journal file, then to the log file. In >> this case a power failure before the journal write would lose the >> entry, while one in-between the two writes will simply cause a >> journal-to-log file update on restart. But, the information that >> would be appended to the log file could have been handled in place of >> the journal write, taking care of the whole thing at once. In both >> cases, power failures before the first write completes causes the >> entire entry to be lost, while a failure after the first write >> completes just causes the operator to be rather unhappy. >> >> It seems that the simplest way to handle things would be to write the >> log entry to the file and immediately flush the file to disk. Is this >> too simple? What am I missing? > > _______________________________________________ > MacLoggerContest mailing list > MacLoggerContest@dogparksoftware.com > http://seven.pairlist.net/mailman/listinfo/macloggercontest > > -Jack Brindle, W6FB ======================================================================= From VA3SPH at rac.ca Wed Mar 2 19:06:16 2005 From: VA3SPH at rac.ca (Steve Hellyer) Date: Wed Mar 2 19:06:18 2005 Subject: [MacLoggerContest] Journalling In-Reply-To: References: <9999ee07d959f63d2411cbccb59eeed4@amsat.org> <5576f9eff2b738cfae7426bea094daf5@amsat.org> <9bf2d2a99990af601be06a1c4bf81ea7@earthlink.net> <5cb17cb36a14fd6d89c6c65df7da2ea3@amsat.org> Message-ID: I think I can help here... Journalling on Mac OS X 10.3.x was introduced for two reasons. 1) It provides a more reliable way to recover from a unplanned computer shutdown (ie power was removed). 2) It greatly speeds the recovery process on reboot when this event occurs. Previous to journaling the OS would have to scan the entire disk looking for and cleaning up directory structure on the disk(s) often called by UNIX name FSCK (File System Check). This might be ok if your drive(s) are not very big, but now we have single ATA HDs that can be as big as 400 GB. That could take a very long time (hours) to scan. Also recall Apple makes very large RAID drives called Xserve RAID. It can store up to about 5 TB (5,000 GB) in a single volume. I am guessing but running a normal scan disk would take a few days on a volume this large and full of files. http://www.apple.com/xserve/raid/ Related .... Don't even think about defragmenting one of these at it would take a very very long time. Which is also why Mac OS X and UNIX in general is designed to overcome many file fragmentation issues and why background defrag is also built in (Only active when system thinks it really necessary and on file small subset if files). As the name implies a journal is kept by the OS on when and where files where manipulated. Instead of scanning the disk after an improper shutdown it just checks the journal for what it was last doing and check those files. It is not intended to actually save your files you were working on. Much more reliable than having a program scanning everything and make best guess as what it suppose to look like. And your back up and running in seconds rather than minutes/hours/days depending on size and number of drives. My suggestion is to avoid situation this if at all possible. How? Use Laptops as they have built in UPS (battery). or get a UPS for Desktop with USB connection to communicate to your computer. This way if you have a power out you can shut the system down cleanly. A journalised database performs similar function, but specifically on the database records. Many relational and SQL databases have this feature built in so it possible to get that function without really knowing about it as an operator. I am not a contester myself yet but enjoy making contact with contesters! Enjoying the thoughts and conversations here too. Hope this is of some help! Steve - VA3SPH On 2-Mar-05, at 2:41 PM, Jack Brindle wrote: > A short bit of clarification, then. Make no assumptions as to what I > may be referring. I won't claim to know what problem journalling may > be solving. I won't claim to know how it may be solving that problem. > I won't even claim to know why Apple added journalling to the Mac's > file system! > > I simply want to know what the problem is that needs to be solved, and > apparently has been solved in the past with journalling. > > On Mar 2, 2005, at 10:46 AM, Jonathan G0DVJ wrote: > >> >> Interesting discussion ... >> >> Are we mixing up two meanings of Journalling? Maybe John mentioned >> it in the general sense of keeping a journal record of QSO data so >> that nothing is lost. i.e. at the application level. There is also >> the OSX specific meaning of Journalling which was introduced in >> Panther and which is a system-wide volume configuration aspect under >> admin user control at disk set-up time, and not the application. >> Not sure if Jack is alluding to this in his posting? >> >> I agree that the simplest way seems to be to write then flush from >> the application's viewpoint. However maybe this is another area >> where we should just state what the user experience should be and >> leave it to Don to decide how best to implement things to achieve it, >> like Jack rightly pointed out when I mentioned multi-threading in an >> earlier post! >> >> I think we all agree with John's original point about losing nothing >> from the committed log - Most other systems I have used cannot >> guarantee that the current QSO still being entered (i.e. not >> completed/committed) won't be lost, but that is the most one can >> lose. >> >> 73, >> Jonathan. >> -- >> >> On Mar 2, 2005, at 6:44 am, Jack Brindle wrote: >> >>> >>> On Feb 28, 2005, at 1:56 PM, John Bastin wrote: >>> >>>> Automatic journaling, so even if you have a power failure, NOTHING >>>> is lost. >>> >>> This grabbed my attention - I'd like to drill into it a bit to >>> understand exactly what is being asked for and why. More >>> importantly, I want to understand the current need for journalling, >>> because I don't think I understand it properly now. >>> >>> Under MacOS X information written to files may be immediately >>> flushed to disk. When writing a log file, the data may be appended >>> to the log file and saved to disk immediately. As I understand >>> journalling, the information is written to the journal file, then to >>> the log file. In this case a power failure before the journal write >>> would lose the entry, while one in-between the two writes will >>> simply cause a journal-to-log file update on restart. But, the >>> information that would be appended to the log file could have been >>> handled in place of the journal write, taking care of the whole >>> thing at once. In both cases, power failures before the first write >>> completes causes the entire entry to be lost, while a failure after >>> the first write completes just causes the operator to be rather >>> unhappy. >>> >>> It seems that the simplest way to handle things would be to write >>> the log entry to the file and immediately flush the file to disk. Is >>> this too simple? What am I missing? >> >> _______________________________________________ >> MacLoggerContest mailing list >> MacLoggerContest@dogparksoftware.com >> http://seven.pairlist.net/mailman/listinfo/macloggercontest >> >> > > -Jack Brindle, W6FB > ======================================================================= > > _______________________________________________ > MacLoggerContest mailing list > MacLoggerContest@dogparksoftware.com > http://seven.pairlist.net/mailman/listinfo/macloggercontest > > 73 Steve VA3SPH From jbastin at sssnet.com Wed Mar 2 22:50:35 2005 From: jbastin at sssnet.com (John E Bastin) Date: Wed Mar 2 22:50:37 2005 Subject: [MacLoggerContest] Journalling In-Reply-To: <5cb17cb36a14fd6d89c6c65df7da2ea3@amsat.org> References: <9999ee07d959f63d2411cbccb59eeed4@amsat.org> <5576f9eff2b738cfae7426bea094daf5@amsat.org> <9bf2d2a99990af601be06a1c4bf81ea7@earthlink.net> <5cb17cb36a14fd6d89c6c65df7da2ea3@amsat.org> Message-ID: <60b89a553b29ab9c0ffa7f8b1068d704@sssnet.com> On Mar 2, 2005, at 1:46 PM, Jonathan G0DVJ wrote: > > Are we mixing up two meanings of Journalling? Probably. Perhaps it was a bad choice of words. > Maybe John mentioned it in the general sense of keeping a journal > record of QSO data so that nothing is lost. i.e. at the application > level. There is also the OSX specific meaning of Journalling which > was introduced in Panther and which is a system-wide volume > configuration aspect under admin user control at disk set-up time, and > not the application. Not sure if Jack is alluding to this in his > posting? I'm not going into the Mac OS X journaling. I merely desire that the software, in some manner, provide ongoing protection against data loss, and one common way of addressing this is to write the data continuously to a small "journal" file, so that any catastrophe, be it a power failure or a program crash, does not result in loss of data. I think the reason for the separate file may be that it is small, and so read/write access is very fast. Periodically, it could automatically be flushed to the full log file, or the user could be prompted to do so manually. 73, J o h n B a s t i n K8AJS jbastin@sssnet.com http://www.qsl.net/k8ajs/ From jackbrindle at earthlink.net Thu Mar 10 03:16:11 2005 From: jackbrindle at earthlink.net (Jack Brindle) Date: Thu Mar 10 03:16:15 2005 Subject: [MacLoggerContest] Test In-Reply-To: References: <20050226230018.944815722B@seven.pairlist.net> Message-ID: Just testing to see if the list is still alive. - Jack Brindle, W6FB ------------------------------------------------------------------------ --------------------- From g0dvj at amsat.org Fri Mar 11 17:30:19 2005 From: g0dvj at amsat.org (Jonathan G0DVJ) Date: Fri Mar 11 17:30:18 2005 Subject: [MacLoggerContest] 1st draft at consensus of top 5 MLC feature list priorities Message-ID: <4674f22b5fcd4360ca6667d90d95d88a@amsat.org> Hi all, Sorry for the silence on the list from me for the last week or so. I have just been very busy with work here and not so much time to think about radio. Don't expect much from me next week either as I fly to Germany on business on Sunday ... We have had some good debates on this list over the last couple of months - about a lot of detail and some philosophy regarding a potential MacLoggerContest (MLC) program which would in Don's words aim to be "an insanely great contest logger"! Hopefully we have also had time to deliberate and think through what we believe is important. Just to remind you why I am putting effort into getting a consensus ... a quote from a direct email (with permission) from Don ... On Feb 2, 2005, at 3:28 pm, Don Agro wrote: > I would really appreciate seeing your original email posted back to > the Ham-Mac list re-written in order of priority - If 20 people on the > Ham-Mac list can agree on the top 5 priorities I will jump into the > fray with MacLoggerContest. The reason I am asking for that level of > detail is not just to get a consensus amongst the enthusiasts, but to > make sure I get a firm grip on what it would take to make an insanely > great contesting program. Let's not rush into this - it takes time to gain consensus, it means we all have to evaluate what we can live with as opposed to what we can't, and I think we have to take the size of the task into account and look at this as a starter top 5 rather than an end-game. It would be good to try and arrive at some support on this specialist list we set up for the purpose initially - however I promised at the outset that we would copy back a summary to the ham-mac general list and look for support there too and so subsequently we will do that. Having looked at the original feature list from my mail that originally set this discussion off (available from the archive of this list in the first welcome message I posted), and trying to take into account the discussions that have been had since then on this list, I offer a draft top 5 features/characteristics of a possible initial MLC. Please note I am not trying to rank these 5 at this stage - this is not required - rather we are prioritising these things against the other features that are derived from the original list. I have re-worded some of the points where the discussions we have had clarified different items from the original list. You will see I have tried to categorise the top 5 by 4 essential areas of discussion too as I have read them. I have allowed ourselves one initial "bell & whistle" feature at this stage. Each of these contains a certain amount of detail based on the discussions we have had. I felt I had to bulk some related items together given that there are just a certain number (>5) features that all contest loggers need! The remainder of the items from the original list I posted are listed again in no order of importance for reference afterwards. I hope I have managed to achieve a very difficult task at least to some extent. Please consider this initial attempt at a consensus and if you can give it some support at this early stage, please either post a note to that effect to this list or direct to Don or via myself if you prefer. I will subsequently canvass further support from the ham-mac general list if this stage proceeds well. Thanks & 73, Jonathan G0DVJ -- Top 5 : (in categories but NO order of importance) - 1st draft: --------- SETUP: - Easy but flexible configurable set-up for any contest requirements no matter what the exchange required and the scoring schemes defined. Full support for all popular national and international contests in the calendar (or the ability for users to set up such flexibility), HF, VHF and UHF contests all supported. ENTRY/EDITING OF QSOs: - Fast entry of required contest logging fields through a "bullet-proof" data entry routine. Auto insertion of relevant data from radio connection (such as Band/Mode) but also enabling other radio communication features as and when. Auto suggested data insertion (zones, area codes, reports, locators etc. as appropriate). Entry includes the important aspect of editing a QSO easily and quickly. CHECKING & INFO FOR OPERATORS: - Real-time checking (preferably as callsign characters are typed without touching other keys/buttons) of DUPLICATES, but also country/band/locator/other multiplier analysis, beam headings, potential multiplier status ) plus re-scoring in real-time & continuous summary of scoring per band/mode/multipliers/etc. INTERFACES & STANDARDS: - Use of all existing "standard" file formats used by other similar software such as: - Partial matches to the standard callsign contest databases produced by K5ZD, - Use of standard CTY country prefix files - optional Cabrillo log entry file generation - ADIF generation for integration with MacLoggerDX and other loggers for your main station log INITIAL BELL & WHISTLE: - A contest CW memory keyer Other outside top 5: (not in any order). -------------------------- - A facility to connect to a public/private DX cluster (either on the net or via RF/TNC) which highlights spots which are potential multipliers. - SO2R support for 2 radio operation - Inbuilt contest voice "keyer" for CQ parrot calling. - Multi-operator support for logging and statistical analysis of rates and mults etc. - Rendezvous support for Multi-multi operation over ethernet or airport networks. - Integration with Apple's iChat for IM chat between operators in multi-multi situations, spotting stations etc. -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: text/enriched Size: 5709 bytes Desc: not available Url : http://seven.pairlist.net/pipermail/macloggercontest/attachments/20050311/bffb3067/attachment-0001.bin From ccc at space.mit.edu Sat Mar 12 12:25:48 2005 From: ccc at space.mit.edu (Chuck Counselman) Date: Sat Mar 12 12:25:58 2005 Subject: [MacLoggerContest] Top 5 features for MLC In-Reply-To: <4674f22b5fcd4360ca6667d90d95d88a@amsat.org> References: <4674f22b5fcd4360ca6667d90d95d88a@amsat.org> Message-ID: At 10:30 PM +0000 3/11/05, Jonathan G0DVJ wrote: >...I offer a draft top 5 features/characteristics of a possible >initial MLC.... Please consider this initial attempt at a consensus My humble comments: >SETUP: >...configurable...for any contest.... Full support for all popular >national and international contests..., HF, VHF and UHF.... Sure. Sine qua non, IMO. >ENTRY/EDITING OF QSOs: >- Fast entry of required contest logging fields through a >"bullet-proof" data entry routine. Auto insertion of relevant data >from radio connection (such as Band/Mode).... Auto suggested data >insertion (zones, area codes, reports, locators etc. as >appropriate). Entry includes the important aspect of editing a QSO >easily and quickly. Sure. Sine qua non, IMO. >CHECKING & INFO FOR OPERATORS: >- Real-time checking (preferably as callsign characters are typed >without touching other keys/buttons) of DUPLICATES... Sure. Sine qua non, IMO. >...also country/band/locator/other multiplier analysis, beam >headings, potential multiplier status)... Sure. Sine qua non, IMO. >...plus re-scoring in real-time & continuous summary of scoring per >band/mode/multipliers/etc. IMO, real-time scoring (as opposed to accounting for multipliers) is not essential in the initial MLC. I could wait until a later release for this. >INTERFACES & STANDARDS: >- Use of all existing "standard" file formats... Sure. Sine qua non, IMO. >INITIAL BELL & WHISTLE: >- A contest CW memory keyer IMO this is a high priority and should be in the initial release. >Other outside top 5: (not in any order). > >- A facility to connect to a public/private DX cluster (either on >the net or via RF/TNC) which highlights spots which are potential >multipliers. IMO this is a high priority and should be in the initial release, especially as DX "cluster" connection is already a feature of MLDX. <<<============[WHERE I'D DRAW THE LINE FOR THE INITIAL MLC]===========>>> >- SO2R support for 2 radio operation Defer. >- Inbuilt contest voice "keyer" for CQ parrot calling. Defer. >- Multi-operator support for logging and statistical analysis of >rates and mults etc. Defer even further. The market is smaller, first because there are fewer multi-op stations, second because practically none of them use Macintosh computers, and third because a multi-op station is much less likely than an individual to switch to Macintosh. >- Rendezvous support for Multi-multi operation over ethernet or >airport networks. Defer still further. The market is still smaller. I doubt that you'll ever see a Multi-multi operation using Macintosh s/w. >- Integration with Apple's iChat for IM chat between operators in >multi-multi situations, spotting stations etc. Defer further yet. The market is still smaller. The best is the enemy of the good. A good plan today is better than a perfect plan tomorrow. Let's define a feature set that is enough for most of us, and to which Don will commit. Don Agro and we users are in this boat together. He needs a market and we need his product. To get past the chicken-and-egg problem, perhaps Don and we can devise a way of sharing risk and working together. 73 de Chuck W1HIS -------------- next part -------------- An HTML attachment was scrubbed... URL: http://seven.pairlist.net/pipermail/macloggercontest/attachments/20050312/91a5f88c/attachment.htm From jackbrindle at earthlink.net Sat Mar 12 14:25:27 2005 From: jackbrindle at earthlink.net (Jack Brindle) Date: Sat Mar 12 14:25:30 2005 Subject: [MacLoggerContest] Journalling In-Reply-To: <60b89a553b29ab9c0ffa7f8b1068d704@sssnet.com> References: <9999ee07d959f63d2411cbccb59eeed4@amsat.org> <5576f9eff2b738cfae7426bea094daf5@amsat.org> <9bf2d2a99990af601be06a1c4bf81ea7@earthlink.net> <5cb17cb36a14fd6d89c6c65df7da2ea3@amsat.org> <60b89a553b29ab9c0ffa7f8b1068d704@sssnet.com> Message-ID: <953d9f7778b7c68c33708f4895addb32@earthlink.net> Before I go on to the next topic, let me report my research on the journalling issue. I sent a previous email on this, but it somehow got lost. I spent some time going over the operation of several PC-based contest programs, including TRLog, WriteLog and N1MM. Several of the programs (very notably WriteLog) keep their log information in RAM, writing it to storage only when requested. This provides for fast access to all data, but also leaves that data open to loss on a power failure or other computer calamity (faulty pointers, etc). The reason for this is that in the early days of PCs, especially under DOS, mass storage consisted of some hard disks, but mainly floppies. Neither were that reliable, and all were very slow (especially floppies). Thus for fast access to data, you really needed to have that data in RAM. The solution was to keep a journal file for all data written into the log, and only write out the entire log when needed (or requested by the user). If there was a problem, the log could be rebuilt with the journal file. Of course, since the media was slow, the journal file writes were also slow, but at least you didn't have to write the entire log. The authors went to a lot of trouble to make this system work in light of the hardware/OS facilities at hand. Newer programs have tended to require more reliable hardware / OS, and have moved to different techniques to handle reliability issues. It is interesting that N1MM does not use an explicit journal file, although it may be built in to the Access database. At the risk of getting into implementation, I would suggest a better scenario is to keep the log on disk, with an in-memory log tree maintaining rudimentary information (callsign) along with an index into the log file for the QSO entry. You then get the best of both worlds, with the immediately-written log file eliminating the need for a journal and fast access to commonly needed information. There are some problems with this scenario, such as how to handle multiple QSOs with a single station for contests that allow it, but those can easily be taken care of by intelligent software design. There are big advantages to using contemporary MacOS X systems. Not having to pull tricks to help out old, slow systems is definitely a plus! -Jack Brindle, W6FB ======================================================================= From JamesDuffey at comcast.net Sat Mar 12 17:26:04 2005 From: JamesDuffey at comcast.net (James R. Duffey) Date: Sat Mar 12 17:26:08 2005 Subject: [MacLoggerContest] Top 5 features for MLC In-Reply-To: Message-ID: One feature that I would like to see as essential or a high priority bell and whistle is a band map or stack for us lowly S&Pers. After you call a station 3 times and they don't come back hit a button and the program stores the frequency and (possibley) the exchange information it for you. Then, after you have swept the band up or down you can go back and click on those stations again and try to work them. I use the 5 stack register on my 850 for this function now, something similar in the contest program would be a big help to those of us who primarily S&P rather than run. I also operate a lot of QRP contests that often have unusual exchanges. Hence, the ability to configure a custom contest would be nice. - Duffey -- James R. Duffey KK6MC/5 Cedar Crest NM 87008 DM65 From jackbrindle at earthlink.net Sun Mar 13 00:24:52 2005 From: jackbrindle at earthlink.net (Jack Brindle) Date: Sun Mar 13 00:24:56 2005 Subject: [MacLoggerContest] 1st draft at consensus of top 5 MLC feature list priorities In-Reply-To: <4674f22b5fcd4360ca6667d90d95d88a@amsat.org> References: <4674f22b5fcd4360ca6667d90d95d88a@amsat.org> Message-ID: We seem to be making feature selections by the perceived difficulty in implementation. Many might be amazed that some features, such as voice playback are very easy to implement, and others far more difficult. I would suggest that implementation difficulty might be scored by the developers, then a fresh look at priority be made. Examples in my discussion below. By far the most difficult part of a contest program is user interface. Getting it right, with needed information displayed where it gets the operators attention, and lesser, but still import info also being displayed is rather difficult. Things that seem important may not be to the experienced contester. Things that don't seem important to the casual user, such as rate charts, are actually paramount to making tactical decisions. Compared to UI, pretty much everything else is easy to implement. I believe we will need to pursue a UI discussion in order to nail down many features. For now, though, we continue... On Mar 11, 2005, at 2:30 PM, Jonathan G0DVJ wrote: > CHECKING & INFO FOR OPERATORS: > - Real-time checking (preferably as callsign characters are typed > without touching other keys/buttons) of DUPLICATES, but also > country/band/locator/other multiplier analysis, beam headings, > potential multiplier status ) plus re-scoring in real-time & > continuous summary of scoring per band/mode/multipliers/etc. Scoring is pretty easy to do. I believe that real-time scoring and statistics (rates, etc) are an important part of the contest data and should be displayed. It would be nice to have rate charts and graphs, but being a UI item, it is more difficult to do... > INTERFACES & STANDARDS: > - Use of all existing "standard" file formats used by other similar > software such as: > - Partial matches to the standard callsign contest databases > produced by K5ZD, > - Use of standard CTY country prefix files > - optional Cabrillo log entry file generation > - ADIF generation for integration with MacLoggerDX and other loggers > for your main station log Decoding the standard files can be difficult because of a lack of documentation. However, this information can be uncovered, and their use should be a requirement. Cabrillo is not optional. It is required for submission of contest entries for pretty much all major contests on this side of the pond. Without it a contest program is useless. I would put ADIF in the optional category, but it may be easy to drop it in from some other code piece. Developer? > INITIAL BELL & WHISTLE: > - A contest CW memory keyer There are two ways to do this. The first is to output a CW digital open collector/drain signal to key rigs. This requires rather precise timing within the Mac, something not very easy in a non-real time environment. Still, it can be done. Perhaps an existing drop-in facility can be used? The second method is to make use of the ASCII CW facility in many contemporary rigs. I would strongly urge the support of this - text to be transmitted is simply sent out the RS-232 port to the rig for it to encode and transmit. An alternative to this is to adopt one or more of the various keyer systems, such as that from K1EL, which also provide the same service. Probably both should be implemented in the long run. I would also move the SSB audio play system to this level. It is amazingly easy to implement. Creation of the audio files can be done with external applications such as Peak LE or the freeware Audacity. I would NOT add audio recording at this time unless the author understands the part of the QuickTime system. When audio recording is added, it should allow for the creation of contest exchange files as well as recording of contest audio from the radio(s). Also long-run should be a facility to insert numbers and letters for the exchange. Concatenating sound so that it sounds natural is not easy, and will require quite a bit of work in both the sound recording and playback facilities. I don't believe this facility is required in the first round. > - A facility to connect to a public/private DX cluster (either on the > net or via RF/TNC) which highlights spots which are potential > multipliers. I also believe this is mandatory, at least for internet access. This is more important than access through the packet system. In the US, the packet system has decayed tremendously, and has been surpassed by the far more reliable internet. > - SO2R support for 2 radio operation I agree with moving this to the future, but not too far. The foundation for it should be placed in the initial code, though, or a complete rewrite will be required for implementation. When it is added, the UI _will_ be modified extensively to properly display roles and operations. How much it needs to be changed will be determined by the up-front UI design. > - Inbuilt contest voice "keyer" for CQ parrot calling. See above. No reason not to do it now. > - Multi-operator support for logging and statistical analysis of rates > and mults etc. > > - Rendezvous support for Multi-multi operation over ethernet or > airport networks. > > - Integration with Apple's iChat for IM chat between operators in > multi-multi situations, spotting stations etc. M/M support is very argumentative. It is in a major state of evolution in the PC world at this point. I agree that it should be moved back to a later version. - Jack Brindle, W6FB ------------------------------------------------------------------------ --------------------- From dagro at dogparksoftware.com Sun Mar 13 04:15:44 2005 From: dagro at dogparksoftware.com (Don Agro) Date: Sun Mar 13 04:15:48 2005 Subject: [MacLoggerContest] 1st draft at consensus of top 5 MLC feature list priorities In-Reply-To: References: <4674f22b5fcd4360ca6667d90d95d88a@amsat.org> Message-ID: Hi Jack, On 13-Mar-05, at 12:24 AM, Jack Brindle wrote: > We seem to be making feature selections by the perceived difficulty in > implementation. There have been some comments concerning features already existing in MLDX etc. but this is not the way we should be selecting features. > Many might be amazed that some features, such as voice playback are > very easy to implement, and others far more difficult. I would suggest > that implementation difficulty might be scored by the developers, then > a fresh look at priority be made. Examples in my discussion below. It's a bit early for that. At this point, I think only the impossible should be ruled out - for example reverse engineering closed file and packet formats and standards is just not reasonable (or dependable) for the initial release - but 'difficult' is not a problem. > Cabrillo is not optional. It is required for submission of contest > entries for pretty much all major contests on this side of the pond. > Without it a contest program is useless. I would put ADIF in the > optional category, but it may be easy to drop it in from some other > code piece. Developer? Cabrillo and ADIF are open standards and well documented - and well supported within MLDX. >> INITIAL BELL & WHISTLE: >> - A contest CW memory keyer > > There are two ways to do this. The first is to output a CW digital > open collector/drain signal to key rigs. This requires rather precise > timing within the Mac, something not very easy in a non-real time > environment. Still, it can be done. Perhaps an existing drop-in > facility can be used? This is already done in MacLoggerDX - and Unix is Real Time within reason - not really a problem. At 32 wpm and assuming an average of 48 dit durations in a word a 'dit' would be 1250 / 32 = 39.0625 milliseconds - not a difficult interval to handle. > The second method is to make use of the ASCII CW facility in many > contemporary rigs. I would strongly urge the support of this - text to > be transmitted is simply sent out the RS-232 port to the rig for it to > encode and transmit. Not all rigs support this and all in a different way - driver dependent and impossible to fix if it's 'broken' in the radio. Now that is a whole other discussion - what is an appropriate contest rig ? Do we support them all ? > An alternative to this is to adopt one or more of the various keyer > systems, such as that from K1EL, which also provide the same service. > Probably both should be implemented in the long run. Within the MacLoggerDX user community - based on what I am hearing from those that are using CW keying - most are using the software CW within MLDX and the microHAM interfaces to their rigs - but these are implementation details and to some extend driver dependent. But we are getting ahead of ourselves - at this stage we just want to know if CW and/or voice keying are essential in most contests. > I would also move the SSB audio play system to this level. It is > amazingly easy to implement. Creation of the audio files can be done > with external applications such as Peak LE or the freeware Audacity. I > would NOT add audio recording at this time unless the author > understands the part of the QuickTime system. When audio recording is > added, it should allow for the creation of contest exchange files as > well as recording of contest audio from the radio(s). Once again this is a much lower level implementation level issue - the real question at this stage is how important is audio recording/playback in a contest situation ? The playback/keying part is already in MacLoggerDX and serves as an example for discussion. If the consensus is that voice and CW keyers are essential, then at a later time it might be useful to evaluate what is already in MLDX to see if it is appropriate or not for the contest situation. I would think that this would be a 2 part discussion - low level functionality and UI/usability. I realize that you are not a MLDX user Jack, and this is not a problem - but you might want to take a look at the online documentation for the purpose of discussion... Here is the page on the MacLoggerDX keyers... There will be some code re-use between MLDX and MLC - but not a lot since MLDX is PowerPlant-Carbon and MLC will be XCode Cocoa-Objective C. 73 Don Agro VE3VRW D o g P a r k S o f t w a r e L t d . email: dagro@dogparksoftware.com www: http://www.dogparksoftware.com iChat AV:dogpark@mac.com From bsandersen at mac.com Sun Mar 13 08:48:28 2005 From: bsandersen at mac.com (B. Scott Andersen) Date: Sun Mar 13 08:48:46 2005 Subject: [MacLoggerContest] CabConverter In-Reply-To: <20050313052555.A68B4570D8@seven.pairlist.net> References: <20050313052555.A68B4570D8@seven.pairlist.net> Message-ID: <13ca8b9c64348c5e7e8d2b74f98dda47@mac.com> Fellow MacLogger DX users: I have been lurking on the list for some time and thought this might be the right time to jump in. I have been quietly working on an add-on for MacLogger DX called CabConverter that allows MLDX using contesters to generate appropriate Cabrillo files. I am announcing this effort with this message. CabConverter is a stand-alone program and accepts an ADIF file generated by MLDX as input and generates a Cabrillo file. Users must supply information within CabConverter's GUI for things like, name, call, email address, etc. These general things are retained as preferences. Additionally, users will need to specify the contest, operating category, additional category overlay (tri-bander, rookie, etc.), along with power category and other things for a particular contest. Once you've done that, there's little left to do but select the ADIF file holding your QSOs, give them a quick look within the log browsing window, and generate your Cabrillo file for submission. There are a couple of things to note: 1. There is no such thing as a Cabrillo file standard. There are several file formats with different information captured in different columns. Each contest is a little different. Certainly, the scoring is different for each contest which leads us to point 2. 2. The assertion that "Scoring is pretty easy to do" (seen recently) has not matched my experience. Scoring is tedious and different for each contest. Take the upcoming CQ WPX contest as an example. The value of a QSO depends on the country you're in, the country they're in, the continent you're on, the continent their on, and the band. Take it from me, there is a lot of typing to get a program to understand all that... especially when you're given nothing more than a call sign of variable forms such as AB1BL, AB1BL/4, AB1BL/J4, J4/AB1BL, and AB1BL/MM for AB1BL at home, in Georgia, in Aruba, also in Aruba, and marine mobile respectively. I've not even gotten to the point of talking about multipliers! 3. In order for CabConverter to work, the proper contest-specific information needs to be captured in some set form within each logged QSO entry. So, CabConverter users will need to see what CabConverter will need _before_ the contest begins. 4. Contests will be added one-at-a-time for a while. Corresponding PC programs that support 50 or 100 or 200 contest forms most likely didn't start that way on day-one. They probably grew one or two at a time, also. Now, the important bits: * How much will it cost? I'm not sure yet. * When can I try it? I'm planning on having a very early snapshot version available this week so people can get used to it. I'm finishing off the logic to support the CQ WPX SSB contest now. Other recent contests are also supported (in case you've not submitted your Cabrillo file for those yet). * What contests will it support? I do not have a concrete list yet but most of the HF contests supported by the ARRL and CQ folks will be included plus the other contests that I happen to be interested in such as New England QSO party, etc. I'll try to have a version of CabConverter done that supports a particular contest at least a week before that contest begins. * Who can use it? The software will assume that you are in the continental US. For Canadian, Alaskan, and Hawaiian comrades, I can only give you my sincerest apology. Scoring in particular and the expected exchange is often different for "DX" stations and I'm currently concentrating on getting the software working for one class of user (CONUS). I have had one very helpful and productive beta tester thus far but could use a couple more. Volunteers may contact me directly. Finally, this is a background effort for me. I'm a ham. I also have a job (a fairly demanding one, by the way!). Don Argo has spoiled all of us with his world-class support, and nearly dizzying ability to crank out high-quality software quickly and repeatedly. Let me say this for the record: I'm not Don. :-) That said, I believe that you'll find CabConverter makes contesting more fun. It has for me. Thank you. -- Scott (NE1RD) B. Scott Andersen | "Magic is real, unless declared integer." bsandersen@mac.com | -- The collected sayings of Wiz Zumwalt Acton, Massachusetts | Ham: NE1RD, QRP ARCI#11588, FP#-910 From dagro at dogparksoftware.com Sun Mar 13 09:24:39 2005 From: dagro at dogparksoftware.com (Don Agro) Date: Sun Mar 13 09:24:42 2005 Subject: [MacLoggerContest] CabConverter In-Reply-To: <13ca8b9c64348c5e7e8d2b74f98dda47@mac.com> References: <20050313052555.A68B4570D8@seven.pairlist.net> <13ca8b9c64348c5e7e8d2b74f98dda47@mac.com> Message-ID: <8111b9b93c65d9337d096c71e39cdd89@dogparksoftware.com> Hi Scott, On 13-Mar-05, at 8:48 AM, B. Scott Andersen wrote: > CabConverter is a stand-alone program and accepts an ADIF file > generated by MLDX as input and generates a Cabrillo file. Users > must supply information within CabConverter's GUI for things > like, name, call, email address, etc. These general things are > retained as preferences. Additionally, users will need to specify > the contest, operating category, additional category overlay > (tri-bander, rookie, etc.), along with power category and other > things for a particular contest. Fantastic ! Please keep us posted on your progress. 73 Don Agro VE3VRW D o g P a r k S o f t w a r e L t d . email: dagro@dogparksoftware.com www: http://www.dogparksoftware.com iChat AV:dogpark@mac.com From ccc at space.mit.edu Sun Mar 13 15:12:42 2005 From: ccc at space.mit.edu (Chuck Counselman) Date: Sun Mar 13 15:12:55 2005 Subject: [MacLoggerContest] The number of dit durations in a word In-Reply-To: References: <4674f22b5fcd4360ca6667d90d95d88a@amsat.org> Message-ID: At 4:15 AM -0500 3/13/05, Don Agro wrote: >...assuming an average of 48 dit durations in a word.... This off-topic and trivial, but perhaps others are interested as I am. I don't know where I learned it, much less whether it's correct, but for about 35 years I've thought that the canonical "word" for measuring the speed of sending Morse code in words per minute was "PARIS_" where I've typed an underline character to represent the space between words. Assuming that the duration of a dah is equal to three dit-durations; one dit-duration between each dit or dah within a letter; one dah-duration between letters; and three dah durations between words, I calculate that the duration of "PARIS_" is 52 dit-durations. So, I wonder, whence comes the value 48? 73 de Chuck, W1HIS From dagro at dogparksoftware.com Sun Mar 13 15:29:13 2005 From: dagro at dogparksoftware.com (Don Agro) Date: Sun Mar 13 15:29:16 2005 Subject: [MacLoggerContest] The number of dit durations in a word In-Reply-To: References: <4674f22b5fcd4360ca6667d90d95d88a@amsat.org> Message-ID: Hi Chuck, On 13-Mar-05, at 3:12 PM, Chuck Counselman wrote: > At 4:15 AM -0500 3/13/05, Don Agro wrote: >> ...assuming an average of 48 dit durations in a word.... > > This off-topic and trivial, but perhaps others are interested as I am. > > I don't know where I learned it, much less whether it's correct, but > for about 35 years I've thought that the canonical "word" for > measuring the speed of sending Morse code in words per minute was > "PARIS_" where I've typed an underline character to represent the > space between words. Assuming that the duration of a dah is equal to > three dit-durations; one dit-duration between each dit or dah within a > letter; http://users.erols.com/k3mt/morse/cw.htm the dit - two dit spaces long the dah - four dit spaces long the letter space - two dit spaces long the word space - four dit spaces long. > one dah-duration between letters; and three dah durations between > words, I calculate that the duration of "PARIS_" is 52 dit-durations. > > So, I wonder, whence comes the value 48? PARIS - the standard word - takes 48 dit spaces of time. 73 Don Agro VE3VRW D o g P a r k S o f t w a r e L t d . email: dagro@dogparksoftware.com www: http://www.dogparksoftware.com iChat AV:dogpark@mac.com From ccc at space.mit.edu Sun Mar 13 20:58:00 2005 From: ccc at space.mit.edu (Chuck Counselman) Date: Sun Mar 13 20:58:09 2005 Subject: [MacLoggerContest] Fun with theology In-Reply-To: References: <4674f22b5fcd4360ca6667d90d95d88a@amsat.org> Message-ID: Bill Coleman wrote: >... the standard word is 50 elements long.... Thanks. I'm beginning to understand why theology was so popular in the Middle Ages. You know -- when they worried about how many angels could dance on the head of a pin. Don says 48. I said 52. You say 50. Answers.com says "up to" 49. I bet Google can find me a statement that it's "at least" 49. :-) No wonder the World Radiocommunication Conference of 2003 decided to throw the whole thing out. BTW, a nice history of Morse code appears at . (Scroll way down to get to it.) 73 de Chuck W1HIS From dagro at dogparksoftware.com Sun Mar 13 21:19:16 2005 From: dagro at dogparksoftware.com (Don Agro) Date: Sun Mar 13 21:19:20 2005 Subject: [MacLoggerContest] Fun with theology In-Reply-To: References: <4674f22b5fcd4360ca6667d90d95d88a@amsat.org> Message-ID: <6aaca8c5f0feefb77d999d21f5085870@dogparksoftware.com> On 13-Mar-05, at 8:58 PM, Chuck Counselman wrote: > Bill Coleman wrote: >> ... the standard word is 50 elements long.... > Thanks. I'm beginning to understand why theology was so popular in > the Middle Ages. You know -- when they worried about how many angels > could dance on the head of a pin. > Don says 48. > I said 52. > You say 50. > Answers.com says "up to" 49. > I bet Google can find me a statement that it's "at least" 49. :-) And MacLoggerDX actually does 48 - that's not theology - that's the actual angels actually dancing :) 73 Don Agro VE3VRW D o g P a r k S o f t w a r e L t d . email: dagro@dogparksoftware.com www: http://www.dogparksoftware.com iChat AV:dogpark@mac.com From dagro at dogparksoftware.com Mon Mar 14 07:29:40 2005 From: dagro at dogparksoftware.com (Don Agro) Date: Mon Mar 14 07:29:42 2005 Subject: [MacLoggerContest] Fun with theology In-Reply-To: References: <4674f22b5fcd4360ca6667d90d95d88a@amsat.org> Message-ID: <2e702d3f9b8f6c0eb7b81e65a384290c@dogparksoftware.com> Hi Chuck, Bill, On 14-Mar-05, at 6:37 AM, Chuck Counselman wrote: > Don:? I am taking the liberty of forwarding Bill Coleman's message to > you.? IMO, he is correct. > > The importance of this is not for calculating the number of > milliseconds in a dit; it's for generating code that's legible. > > -Chuck, W1HIS MacLoggerDX does in fact pause 2 dit intervals between characters PLUS 4 dit intervals between words resulting in a total of 6 dit intervals. The people who tested this found it perfectly copyable. This tangent arose because of the (incorrect I feel) assertion that accurately timed CW could not be generated in software on a Mac. I was merely using K3MT's reference to show the approximate operating system granularity required to generate accurate CW at 32 WPM. Now if I base my calculations on an average word size of 48 dit spaces and someone else says that the average word size is 50 dit spaces it really doesn't matter - except that our words per minute may vary by around 4% - but the relationship between MacLoggerDX's dits, dahs and spaces is still fixed at an accurate and copyable ratio timed to the fraction of a millisecond. > At 11:44 PM -0500 3/13/05, Bill Coleman wrote: > On Mar 13, 2005, at 11:14 PM, Chuck Counselman wrote: > Don Agro got 48 as follows: > http://users.erols.com/k3mt/morse/cw.htm > ?the dit - two dit spaces long > ?the dah - four dit spaces long > ?the letter space - two dit spaces long > ?the word space - four dit spaces long. > > AH! I see the error -- the Word space is 4 dit spaces long -- IN > ADDITION TO the character space.? The total off time should be 7 > elements long. > > If you send morse with a word space only 5 elements long, your words > will run together and copy will be harder. > > In your case, the word space is 9 elements long, which is a bit too > long, but too long is far better than too short. > > I have in my hands the twelfth edition of "Learning the > Radiotelegraph Code", as published by the ARRL in 1970. (Old enough > not to have an ISBN, but it is Library of Congress catalog number > 55-8967) > > In chapter 2 - Learning to Send, it has a chart on Page 17, which > lists the relative sizes of the components of code: > > Dit = 1 > Dah = 3 > Element space = 1 > Character space = 3 > Word space = 7 > > It then gives an example -- the text "IN ALL" charted according to > these rules. There are clearly 7 element intervals between the end of > the last element in a word, and the first element of the next word. > > Bill Coleman, AA4LR, PP-ASEL??????? Mail: aa4lr@mac.com > Quote: "We invented personal computing." > ??????????? -- Bill Gates @ TechNet / MSDN 2003 > > 73 Don Agro VE3VRW D o g P a r k S o f t w a r e L t d . email: dagro@dogparksoftware.com www: http://www.dogparksoftware.com iChat AV:dogpark@mac.com From dagro at dogparksoftware.com Wed Mar 16 07:16:47 2005 From: dagro at dogparksoftware.com (Don Agro) Date: Wed Mar 16 07:16:49 2005 Subject: [MacLoggerContest] Fun with theology In-Reply-To: References: <4674f22b5fcd4360ca6667d90d95d88a@amsat.org> <2e702d3f9b8f6c0eb7b81e65a384290c@dogparksoftware.com> Message-ID: <78830447fa59e8da1c89f75f9dc4397b@dogparksoftware.com> Hi Bill, On 15-Mar-05, at 11:06 PM, Bill Coleman wrote: > There are several programs in the PC world that use a "short" space. > For example, CQPWin (yeah, I know) allows you to insert a "*" instead > of a space character. I don't know how many dit intervals this is > precisely, but it does result in faster sending. > > 2 dit intervals between characters seems somewhat too short to me. When you say "seems" is this from actually listening to the CW that MacLoggerDX produces or just a theoretical concern ? MacLoggerDX version 4.0.7b7 features a user-selectable number of dit intervals between words. I suppose we could further complicate the user interface by making the number of dit intervals between characters variable as well (maybe include fractional dit intervals ?), but to be honest you are the first one to mention this. > For all those generating CW on the serial port RTS line -- I wonder > how much fixed and variable latency there is on these USB / serial > adapters. In the adapters - little to none. In the whole bus - it depends. I think this is a theoretical concern with little bearing on practice. USB 1.1 supports four basic types of data transfers which are Control, Bulk, Interrupt and Isochronous. Control transfers are for configuring a device and also control of other?Pipes?on the device. Bulk transfers are used for relatively large and bursty data and have variable latency constraints. An example is printer data from PC to an USB printer. Interrupt transfers are for timely and reliably delivery of small data like mouse co-ordinates or key characters. Isochronous, also called real time transfers occupy a prenegotiated amount of USB bandwidth with pre-negotiated delivery latency. However, for lost data there is no retransmission and hence cannot have reliable delivery. An example is audio and video capture or playback devices. Typical data rates are 1.5 Mbit/s (Low speed) and 12 Mbit/s (Full speed). Currently the new version of the standard ver 2.0 addresses a facility of High speed (480 Mbit/s). The lowest data rate (1.5 Mbits/s) is many times faster than required to handle the nyquist frequency implied by the duration of a dit pause. > I suppose it would depend on the other activity on the USB port as > well, since USB, unlike Firewire, doesn't have a guaranteed level of > service. The whole bus bandwidth would of course depend on the CPU controlling it and the controller chip used but I find it hard to believe that normal bus load would introduce any measurable or perceptible variation in the relatively glacial time frame of the dit pause. I suppose if you were trying to send CW while you were simultaneously streaming audio and video from a USB web cam you might run into trouble (I haven't tried it) - but in any real practical useful sense - there is no problem. But rather than spending all this time on theoretical conjecture (amateur radio is based on empirical science after all) why not listen to the CW that MacLoggerDX actually generates and base your recommendations on that ? Auditory perceptions will introduce their own subjective errors but at least we will be judging the engineering rather than the theory :) 73 Don Agro VE3VRW D o g P a r k S o f t w a r e L t d . email: dagro@dogparksoftware.com www: http://www.dogparksoftware.com iChat AV:dogpark@mac.com From aa4lr at arrl.net Wed Mar 16 16:17:06 2005 From: aa4lr at arrl.net (Bill Coleman) Date: Wed Mar 16 19:11:22 2005 Subject: [MacLoggerContest] Fun with theology In-Reply-To: <2e702d3f9b8f6c0eb7b81e65a384290c@dogparksoftware.com> References: <4674f22b5fcd4360ca6667d90d95d88a@amsat.org> <2e702d3f9b8f6c0eb7b81e65a384290c@dogparksoftware.com> Message-ID: <89ba99e5681e3dfa0f771d1fdad62124@arrl.net> On Mar 14, 2005, at 7:29 AM, Don Agro wrote: > Hi Chuck, Bill, > MacLoggerDX does in fact pause 2 dit intervals between characters PLUS > 4 dit intervals between words resulting in a total of 6 dit intervals. There are several programs in the PC world that use a "short" space. For example, CQPWin (yeah, I know) allows you to insert a "*" instead of a space character. I don't know how many dit intervals this is precisely, but it does result in faster sending. 2 dit intervals between characters seems somewhat too short to me. > The people who tested this found it perfectly copyable. > > This tangent arose because of the (incorrect I feel) assertion that > accurately timed CW could not be generated in software on a Mac. If nothing else, the ancient Sound Manager is capable of generating very precise timings down to less than a millisecond. MacOS X has more modern (and more accurate) replacements. > I was merely using K3MT's reference to show the approximate operating > system granularity required to generate accurate CW at 32 WPM. > > Now if I base my calculations on an average word size of 48 dit spaces > and someone else says that the average word size is 50 dit spaces it > really doesn't matter - except that our words per minute may vary by > around 4% - but the relationship between MacLoggerDX's dits, dahs and > spaces is still fixed at an accurate and copyable ratio timed to the > fraction of a millisecond. For all those generating CW on the serial port RTS line -- I wonder how much fixed and variable latency there is on these USB / serial adapters. I suppose it would depend on the other activity on the USB port as well, since USB, unlike Firewire, doesn't have a guaranteed level of service. Bill Coleman, AA4LR, PP-ASEL Mail: aa4lr@arrl.net Quote: "Not within a thousand years will man ever fly!" -- Wilbur Wright, 1901 From aa4lr at arrl.net Wed Mar 16 20:02:49 2005 From: aa4lr at arrl.net (Bill Coleman) Date: Wed Mar 16 21:00:34 2005 Subject: [MacLoggerContest] Fun with theology In-Reply-To: <78830447fa59e8da1c89f75f9dc4397b@dogparksoftware.com> References: <4674f22b5fcd4360ca6667d90d95d88a@amsat.org> <2e702d3f9b8f6c0eb7b81e65a384290c@dogparksoftware.com> <78830447fa59e8da1c89f75f9dc4397b@dogparksoftware.com> Message-ID: <4d209ea75027a0aaac01d4391ab01d71@arrl.net> On Mar 16, 2005, at 7:16 AM, Don Agro wrote: > Hi Bill, > > On 15-Mar-05, at 11:06 PM, Bill Coleman wrote: > >> There are several programs in the PC world that use a "short" space. >> For example, CQPWin (yeah, I know) allows you to insert a "*" instead >> of a space character. I don't know how many dit intervals this is >> precisely, but it does result in faster sending. >> >> 2 dit intervals between characters seems somewhat too short to me. > > When you say "seems" is this from actually listening to the CW that > MacLoggerDX produces or just a theoretical concern ? Theoretical, as I haven't heard the particular CW generated by MacLoggerDX. > I suppose we could further complicate the user interface by making the > number of dit intervals between characters variable as well (maybe > include fractional dit intervals ?), but to be honest you are the > first one to mention this. We may just have a definition problem. So, if you send "IS", do you send: ". . . . ." or ". . . . ." The first has three dit intervals between the two characters, the latter has only two. It's only one dit element removed from sending "5". > But rather than spending all this time on theoretical conjecture > (amateur radio is based on empirical science after all) why not listen > to the CW that MacLoggerDX actually generates and base your > recommendations on that ? OK. > Auditory perceptions will introduce their own subjective errors but at > least we will be judging the engineering rather than the theory :) But, I *like* theory.... Bill Coleman, AA4LR, PP-ASEL Mail: aa4lr@arrl.net Quote: "Not within a thousand years will man ever fly!" -- Wilbur Wright, 1901 From dagro at dogparksoftware.com Wed Mar 16 21:26:47 2005 From: dagro at dogparksoftware.com (Don Agro) Date: Wed Mar 16 21:26:51 2005 Subject: [MacLoggerContest] Fun with theology In-Reply-To: <4d209ea75027a0aaac01d4391ab01d71@arrl.net> References: <4674f22b5fcd4360ca6667d90d95d88a@amsat.org> <2e702d3f9b8f6c0eb7b81e65a384290c@dogparksoftware.com> <78830447fa59e8da1c89f75f9dc4397b@dogparksoftware.com> <4d209ea75027a0aaac01d4391ab01d71@arrl.net> Message-ID: <0f400847c475cc83abd3f1943d555e23@dogparksoftware.com> Hi Bill, On 16-Mar-05, at 8:02 PM, Bill Coleman wrote: > We may just have a definition problem. So, if you send "IS", do you > send: > > ". . . . ." or > ". . . . ." The former. Each dit or dah implies a following dit interval - this in addition to the 2 dit intervals following a character - and this in addition to the user chosen number of dit intervals following a word (used to be fixed at 4). This is why 4 dit intervals between words worked so well - it already implied an additional dit interval after the last dit or dah in the word plus 2 dit intervals after the last character in the word which would really translate into a grand total of 7 dit intervals after the last key up in the word. > The first has three dit intervals between the two characters, the > latter has only two. It's only one dit element removed from sending > "5". We send the dit interval following the second dit in 'I' plus the 2 dit intervals between the two characters which totals 3 dit intervals between "I" and "S". >> But rather than spending all this time on theoretical conjecture >> (amateur radio is based on empirical science after all) why not >> listen to the CW that MacLoggerDX actually generates and base your >> recommendations on that ? > > OK. Have a listen - the free demo will generate CW with a variety of hardware/software keying options so it shouldn't be too difficult to set up with your particular rig/interface. >> Auditory perceptions will introduce their own subjective errors but >> at least we will be judging the engineering rather than the theory :) > > But, I *like* theory.... So do I, but my customers have come to expect that the theory actually gets turned into something that they can use :) 73 Don Agro VE3VRW D o g P a r k S o f t w a r e L t d . email: dagro@dogparksoftware.com www: http://www.dogparksoftware.com iChat AV:dogpark@mac.com From JamesDuffey at comcast.net Wed Mar 16 22:08:51 2005 From: JamesDuffey at comcast.net (James R. Duffey) Date: Wed Mar 16 22:08:56 2005 Subject: [MacLoggerContest] Spaces - Theological and Otherwise In-Reply-To: <0f400847c475cc83abd3f1943d555e23@dogparksoftware.com> Message-ID: There are times when an extra pause (space) is useful in sending a contest exchange. For instance when I (or my keyer or computer) send my section, NM, with normal spacing, that is a letter space between the letters, it is often copieed as Y and I get a ? or agn. If I insert an extra space or two between the N and M I seldom get a request for repeat. I suppose this is not a problem when I generate my own exchange with the spaces inserted by me and not the machine. However, it could be a problem when the program compiles the exchange from a preferences panel. It will generate a single space between the N and M automatically, but if I try to put N M into the sec space instead of NM it tells me it is an invalid section or state. Now that I have posted it, I realise now that this is a nit, so I apoligize. But it is a feature that someone should put on a postit note where they can see it in when it is time for REV 2. Angels don't dance on the head of a pin, they dance at Studio 54. - Duffey -- James R. Duffey KK6MC/5 Cedar Crest NM 87008 DM65 From dagro at dogparksoftware.com Thu Mar 17 09:03:10 2005 From: dagro at dogparksoftware.com (Don Agro) Date: Thu Mar 17 09:03:15 2005 Subject: [MacLoggerContest] Re: Spaces - Theological and Otherwise In-Reply-To: References: Message-ID: <4344a93fae849dcad71e11cec334c87d@dogparksoftware.com> Hi James, On 16-Mar-05, at 10:08 PM, James R. Duffey wrote: > There are times when an extra pause (space) is useful in sending a > contest > exchange. > > For instance when I (or my keyer or computer) send my section, NM, with > normal spacing, that is a letter space between the letters, it is often > copieed as Y and I get a ? or agn. If I insert an extra space or two > between the N and M I seldom get a request for repeat. > > I suppose this is not a problem when I generate my own exchange with > the > spaces inserted by me and not the machine. However, it could be a > problem > when the program compiles the exchange from a preferences panel. It > will > generate a single space between the N and M automatically, but if I > try to > put N M into the sec space instead of NM it tells me it is an invalid > section or state. Good point. > Now that I have posted it, I realise now that this is a nit, so I > apoligize. No apology necessary - as they say "The devil is in the details" - Hmmm this is getting theological :) > But it is a feature that someone should put on a postit note where > they can > see it in when it is time for REV 2. 73 Don Agro VE3VRW D o g P a r k S o f t w a r e L t d . email: dagro@dogparksoftware.com www: http://www.dogparksoftware.com iChat AV:dogpark@mac.com From bsandersen at mac.com Tue Mar 22 22:25:04 2005 From: bsandersen at mac.com (B. Scott Andersen) Date: Tue Mar 22 22:25:09 2005 Subject: [MacLoggerContest] Cab-converter(TM) version 1.00 available Message-ID: <6ce60d5dd1fbe04a850d627b7c979412@mac.com> Fellow contesters, Version 1.00 of Cab-converter(TM) is now available. This is a utility that may be used for FREE as per the legal section in the manual. You may access a Stuff-it archive of the distribution from the public area of my iDisk. From the Finder, Go->Other User's Public Folder...-> and in the member name dialog box enter "bsandersen". Unstuff the archive and READ THE DOCUMENTATION. Begin with "index.html" in the manual folder. (I'll likely make this all much nicer as I go but I wanted to get this out before the CQ WPX SSB contest this weekend.) This is the first generally available version. It has not been tested much. Please check for updates immediately after this weekend's contest. This software is presented AS-IS and for FREE. I am not going to attempt any weird licensing system. I am making this statement here: the program, its design, and all my work over the last 18 months on this program is mine. Please use it, please enjoy it, please don't steal it, reverse engineer it, pass it off as your own work, alter it, or any of the other nasty things people have tried to do to software in recent years. This is my gift back to the community that has given me so much pleasure. Please don't make me regret it. Thank you... and see you in the contests! 73! -- Scott (NE1RD) B. Scott Andersen | "Magic is real, unless declared integer." bsandersen@mac.com | -- The collected sayings of Wiz Zumwalt Acton, Massachusetts | Ham: NE1RD, QRP ARCI#11588, FP#-910 From bsandersen at mac.com Fri Mar 25 22:38:25 2005 From: bsandersen at mac.com (B. Scott Andersen) Date: Fri Mar 25 22:38:34 2005 Subject: [MacLoggerContest] Contesting with MacLoggerDX Message-ID: <1c1fb71f69c9e454498f2a6e65b1071d@mac.com> Dear fellow MacLoggerDX contesters: I originally posted some general guidelines for contesting with MacLoggerDX about two years ago. A great deal has happened since then. For one, MacLoggerDX has gotten even better. This has become a fine platform for contesting on the Macintosh. The second thing to have happened is the nearly pervasive use of the file format known as "Cabrillo" for submissions of logs to contest sponsors. More and more contests now demand that submissions be made electronically (via the web or email) and in this format. This quick note is my views on how to use MacLoggerDX to get those entries successfully submitted to the contest sponsors like the ARRL and CQ Magazine. They are by no means comprehensive and I'm sure opinions differ so don't take anything below as the only version of the truth. Contesting should be fun. MacLoggerDX certainly makes the logging aspect fun. The rest is up to you. Here are my set of helpful hints for successful contesting: 1. Make the radio talk nice to the computer Get a good connection to the rig via RS232C. I'm sure you've done this but I'll mention it anyway. Make sure that the radio and the computer are talking nicely. If you forget to set this up you'll log a bunch of folks in MacLoggerDX and you'll not even know what band you used! [I've done this; yes, it is embarrassing...] 2. Does anybody really know what time it is? Set the clock on the Macintosh. I've got mine synchronized off the web so I never really think about it until contest time. Then, I just take a quick glance to make sure my log entries aren't from 1904 (presumably with spark gap!). 3. Read the contest rules Read the rules for the contest before the contest begins. Really. Really really. Can you work somebody twice in the same contest? Can you work somebody on the same band if you use different modes? 4. Understand the exchange Know what you need to capture for each QSO and how Contests almost always have some fixed exchange information such as RS(T), zone, year first licensed, serial number, etc. 5. Plan on using Cab-converter(tm) If you are sending serial numbers, check out the item in the preferences panel for auto incrementing the serial number. My program Cab-converter is a FREE program that can take an exported ADIF file from MacLoggerDX and translate it into a Cabrillo file for submission. You must read the contest-specific notes in the Cab-converter documentation to know where to put the exchange information and how that information should be formatted. Each contest is different and Cab-converter depends on having the exchange information stored properly for that particular contest. If you don't put the exchange information in the right place (and in the right form), Cab-converter won't be able to create a Cabrillo file for you. 6. Decide if you will use a separate log Should you use a separate log file for a contest? MacLoggerDX can be a little more nimble if you start with a fresh, empty log. Merging this log back into your main log after the contest is as easy as importing an ADIF file. If you decide to try the fresh log approach, practice this well before the contest begins! 7. Check for duplicates during the contest Use the "Previous" panel to check for repeats. Assuming you don't have this OM in the log 8 times, a quick glance will let you know if you've worked them this contest. This is where a fresh log really helps since you'll only see the QSOs that matter for this contest (and not the other twenty times you worked that OM in contests last year). 8. Listen Going to all the trouble of making the QSO and then misunderstanding the exchange costs you points and costs points to the fellow you just worked. Listen and record the information carefully. Read and review your entry before and after you push "Log QSO". Here I must admit I don't always follow my own advice and, on those occasions where I didn't proofread my work, I've regretted it (and it cost me a couple of points). Here's my thinking: it is better to make fewer contacts because you spent a bit of time proofreading than to make 5 more QSOs with a buggy log. 9. After the contest is over Extract the portion of your log relating to the contest and create an ADIF file. Run Cab-converter to generate your Cabrillo file. Send it off. You might also wish to peek in the file at the "Claimed score:" line. I've worked hard to try to accurately compute your score for the submission. While the contest sponsors have the final say on your score and might deduct points for broken QSOs, bad exchanges, etc., the "Claimed score:" line should give you an idea of how well you did. 10. Watch the web and those magazines The lead time for contest results is mindbogglingly long in this age of instant information. Some contests don't report the results for nearly a year after the event. Still, it would be nice to see postings to the MacLoggerDX reflector with scores (or claimed scores) after contests so we MacLoggerDX users could see how our fellow contesters faired. So ends my helpful hints. See you on the bands! -- Scott (NE1RD) From bsandersen at mac.com Sun Mar 27 22:07:09 2005 From: bsandersen at mac.com (B. Scott Andersen) Date: Sun Mar 27 22:07:35 2005 Subject: [MacLoggerContest] Cab-converter v1.0.1 now available Message-ID: <4e500b9de6b49d0af2a3c7c9fdfc9cd2@mac.com> The WPX contest has concluded and I hope everybody had as much fun participating as I did! Now that the contest is over, we need to get our logs converted to Cabrillo format and submitted to CQ Magazine. I have completed version 1.0.1 of Cab-converter(TM) which supports this contest. I did fix some things so please upgrade to this new version. I have posted the software in a new Yahoo group specifically created to support the Cab-converter product. You can find the group here: http://groups.yahoo.com/group/cab-converter/ I hope you will join, download the newest Cab-converter version (in the "Files" section), and enjoy the other features the group has to offer such as a shared calendar where I'll post important dates relating to Cab-converter- supported contests, group messaging, and more. Don't forget to peek inside your generated Cabrillo file to see your "Claimed score". While it isn't the final word (contest sponsors always have that) it should give you an idea of how well you did. One final note: I'd like to publicly thank Jeff Beiermann, WB0M, who was very helpful in recent weeks helping me get Cab-converter back on track. Thanks, Jeff! See you on the bands. 73! -- Scott (NE1RD) Author of Cab-converter B. Scott Andersen | "Magic is real, unless declared integer." bsandersen@mac.com | -- The collected sayings of Wiz Zumwalt Acton, Massachusetts | Ham: NE1RD, QRP ARCI#11588, FP#-910 From dagro at dogparksoftware.com Wed Mar 30 09:23:55 2005 From: dagro at dogparksoftware.com (Don Agro) Date: Wed Mar 30 09:24:00 2005 Subject: [MacLoggerContest] Cab-converter review on eHam Message-ID: <9927778fdffaf8e123ad7ac522fde5fa@dogparksoftware.com> Jeff, WB0M got the ball rolling and gave Cab-converter a perfect 5 in an eHam review... 73 Don Agro VE3VRW D o g P a r k S o f t w a r e L t d . email: dagro@dogparksoftware.com www: http://www.dogparksoftware.com iChat AV:dogpark@mac.com