Date: 94-02-09 21:08:39 est From: lvn@fox.gsfc.nasa.gov Subj: CT vs. NA vs. N6TR Summary (LONG) To: KA9FOX Last week I posted a question about why people use CT vs. NA vs. N6TR. Here are the replies I got, mostly unedited except to make them anonymous. Some of them were posted on the reflector, but I felt that anyone who email'ed me directly might like to be anonymous. These comments were reviewed by K1EA and N6TR but not by K8CC (I couln't find an email address for him either in hams-on-usenet or on the mailing list for this reflector. The bottom line seems to be that all three programs are fine programs - many, many people use at least two of them - lots of people have all three. Also, W5XD's WriteLog got some good comments if you run Windows. If you have additional comments, please email me directly - I'm toying with the idea of a review article for NCJ. Anyway, here are the comments - enjoy. Larry, K3TLX lnovak@cen.com ----------------------------------------------------------------------- The general answer has been "it's the only show in town". CT has been around for some years, it supports the major contests, and it has capabilities that none of the other programs (have) had. NA is picking up more contests, but it doesn't support large numbers of QSOs. N6TR is a relative newcomer, but Tree's program may have promise. I've just ordered it. I've had CT and NA for some years now. These features distinguish CT from the pack: 1) Large logs (multi-multi stations need this). I don't think NA supports a log whose size exceeds 10K QSOs or so. 2) Support for networked computers. 3) Rig control for ALL the popular newish transceivers. N6TR has omitted ICOM support. 4) Integration of packetcluster spots, including filtering spots thru what you've already worked. 5) Support for the excellent K1EA DVP board (NA and N6TR will probably add this). 6) Log format supported by a large number of logger's import. Your K1EA CT log can be easily integrated into several vendors' logs. 7) Rapid response to new features. Ken has been incredibly responsive to year upon year of request. Not all requests, but many common requests. 8) Word of mouth. All the top contesters use CT. If you have a guest op, he probably already knows CT. 9) RAPID check partial and super check partial. This becomes important when the log size gets quite large. 10) Excellent CW support. N6TR is doing well here, too. 11) Although there are bugs, Ken fixes them, and has on occasion done a mass mailing prior to a contest because of a serious data-loss bug. Some of us would rather have Ken add requested support items rather than "dig in" and freeze the program to work out the last few bugs. Most of the bugs have been things we could live with, and over time we learn to hang on to a few versions of CT. You can usually do the contest with the program, and fix things later. ----------------------------------------------------------------------- ... (upgrade costs kept going up) and the product didn't seem to be getting any better. ... [CT] doesn't give you any control over your CW weighting, and N6TR has done it forever. ... user interface for CT [isn't so good] especially the ... start-up sequence. I switched to N6TR and I think it's far superior for a single-op CW contester. It's much more natural (I don't need to tape pages out of the manual to remember how to use it, as I did with CT). Now that his newest version supports the .CTY files, he's fixed the only weakness (imho) in his program. I've never had a crash or other problem, and Tree is very responsive to questions and requests. ----------------------------------------------------------------------- Yeah, CT has bugs...alot for M/S and M/M use. for single op not to bad. Why did I start with CT? I was not aware of N6TR's package at the time (almost 4 years ago), and what I got off the internet for NA did not impress me. For the most part, the bugs that come up have not affected me and it works quite well and it supports a lot of the contests that I do. At this time I am not sure of the CT vs NA line of contests, but my impression is that CT supports more. Both CT and NA support a DVK on the LPT, N6TR does not. I've heard a lot of good things about N6TR's package, but for me the lack of support of the DVK is a factor. Now, not to put another fly in the ointment, but you left out W5XD's(?) writelog! I used that for the last NA QSO party since CT did not support the contest, I did not have NA and N6TR did not support the DVK. It seemed like a pretty good package. I had some problems getting it to score correctly, but overall I liked it. I would put it on par with CT. I have not used writelog for a single op assisted effort yet so your milage may vary. You can scarf writelog from the internet...archie on wrtlog60.zip. I forget where I found it. Oops, forgot, writelog! is a windows app... this might be a BIG factor. ----------------------------------------------------------------------- I have all three programs, and they all work quite nicely. CT has been around the longest and is used universally. Log data is easily transfered to most QSO databases for this reason, but it has two problems - code speed is limited on the lower end to 22 wpm. It does not support some of the important contests for contester, such as NA QSO and Sprint. NA and N6TR Log fill that hole, the former goes down to 12 wpm and the latter to 5 wpm. The latter also supports the use of two rigs, but is not very good in transfering data to QSO databases. We are not talking about a lot of money with this software, if you can afford to bear the expense of optimizing your station for contest it makes little sense to constrain yourself on the cost of software. I would suggest that you get them all, and then you only have to worry about updates. If one program crashes terminally, then you will have two others to get you through any of the "big" contests and if you get to guest op, you won't have to go thru any "learning curve". ----------------------------------------------------------------------- I think the answer is "whoever gits there fustest with the mostest" ;-) CT was such a cut above the other programs available at the time that it became a de facto standard. N6TR's software has a somewhat different interface design and uses more intelligence. NA is basically a close variant of CT. Yes, CT's upgrades tend to have more bugs than would be allowable in commercial software. However, given the limited resources available to the programmers (repeat after me...it IS a hobby...) a less-than-complete testing program is to be expected. That said, I'm surprised that 8.52 went out with busted "check-partial", if true as reported...it's kind of a major function. My personal preference would be to have fewer upgrades with better testing of each version. The option to beta test new revisions could then be up to the operator who would be more aware of the risks. "never buy version 1.0 of anything if you're not willing to do some troubleshooting" I see that N6TR version 4.10 accepts .CTY files now...good move. In this turbulent time, having one standard reference format for country/zone/etc data is the right way to go. ----------------------------------------------------------------------- Here is my opinion on why everyone uses CT... It was first. It works (except when it doesn't). People are used to it. Getting people to change is like getting someone to switch word processors. You will use what you are comfortable with even though you know there is something better on the market. I hear lots of reasons why people won't use [N6TR]. Most of them fit into the cateogry of someone who hasn't tried it, picks on one negative feature and then uses that to be comfortable in their decision. [N6TR] still won't do summary sheets for example. It's focus has been what happens during the contest (ie: instead of hitting the INSERT key, hit RETURN instead and keep your hands in the same place). ----------------------------------------------------------------------- I am a former die hard user of CT, but I got tired of buying upgrade after upgrade and finally quit at version 6. [NA] does everything I want as a single operator, except for handling a couple of contests. It also has a good dxpedition mode for just logging stations. I have also used NA in the past for NA QSO party, Sprint, etc. However, I am evaluating N6TR's package and W5XD's WriteLog. I think when I get the hang of the N6TR package, I'm going to like it and stick to it. It's cheaper than CT, too! It must be very frustrating to want to download a new copy of a program, and to have it constantly have bugs. I guess CT was (almost) first, and everyone got used to it. ----------------------------------------------------------------------- CT generates the greatest number of bug reports largely because it has the greatest number of users, and they eventually find everything. Also, it has more function than the others (packet, multi-op, multi- computer, etc.), and has been around longer. The current release probably has very few bugs. NA and CT are very easy to use. NA is a clone of CT. I avoided NA for years because it didn't have the "type ahead" feature. That's where you don't have to finish typing the callsign before you start sending the callsign. You can press the button that sends the callsign and exchange, then finish typing the rest of the call as long as your ahead of the outgoing CW. CT supports the K1EA DVP board, which is probably the best on the market since it can also *record* signals off the air for later playback. N6TR's is much more "configuration file" driven than CT. If you are comfortable with DOS and know how to edit text files, the N6TR program should work fine. However, it is much harder to learn than either CT or NA, though you end up using a lot fewer keystrokes to do the same thing. If you are a Windows or OS/2 user, you might also want to consider WriteLog by W5XD. Unlike the rest, you can use it for free, then pay up after you make 100 QSOs. I still use CT for most contests. It seems to be the most stable and the most reliable, notwithstanding the bug redports. ----------------------------------------------------------------------- I use NA. I do like the CW practice option. Have used CT in the past. My reason for going NA was because it was the domestic equivalent to CT. Since then, I've stayed, for no particular reason. Have never tried the N6TR software. Was going to download it last weekend, but Tree's bbs was off during the 160 test. ----------------------------------------------------------------------- This is a reasonable question. Speaking as a Minor-League software author and a non-user of any of the popular logging programs (ie. an unbiased observer), here are my answers: 1) ALL software has bugs. The more ambitious a package is, the more likely it is to have a bug or two. Packages that play it safe usually don't have all the bells'n whistles that people want. So, the fact that CT has a burp or two is no big surprise. I'll bet that the other "big" logging programs have 'em too. 2) People remain loyal to the software that they already know how to use. The best software pkg. (for you) is the one you're familiar with. For example, a ba-zillion people still use WordStar even though it's awful and has been superceded by many better programs. Why? Because these people already know WordStar, it works for them, and they have no need/time/desire to climb another learning curve. I can't blame them. ----------------------------------------------------------------------- Well Larry, lets see. I paid over $75 for it. I guess I am trying to get my moneys worth out of it. Just like paying too much for a new car and driving it until the doors fall off. You would think after 8 major revisions the S/W would be Bug-free? NOT!!! it is useful for the small number of contests it supports, however. ----------------------------------------------------------------------- Right on. I *want* the bells and whistles...the more new ones I have to play with, the happier I am. Using new gizmos, be they hardware (antennas, DSPs, headsets, radios, etc.) or software, is what keeps contesting interesting for me. We recognize the risk in using the "latest and greatest" version of CT, which is why we ALWAYS have instantly available an older, known to be reliable, version to which we can revert if the need arises. And it has occasionally. I *like* the fact that K1EA has decided to be progressive with his updates, and accept willingly the risks involved. After 5 years of experience with CT, I have finally mastered the keystrokes. I need neither a keyboard template nor reference to the built in help screen to operate efficiently, and there surely is benefit in that. From reading the reflector, I know that N6TR's program has some nifty bells and whistles missing in CT, and I'd like to play with it some time to see for myself. However, there would have to be some extremely useful feature to lure me away from CT, since I am so high on the CT learning curve. ----------------------------------------------------------------------- [N6TR] does about 35 different contests, about 3 times as many as CT. Also, it does networking and packet. ----------------------------------------------------------------------- [CT] works. It works well, for the most part. Obvious bugs like this last one we're hearing about with super-check-partial are just stupid little flubs that can be fixed pretty easily. MAJOR bugs -- like not scoring the contest correctly -- are rare. And it's the default lingua franca of contesting. Granted, Microsoft is not well liked these days, either.... but if the new revs get buggier and buggier (unlikely) then someone new can always try to muscle in with a new package. Ever think of what CT's doing while you're running 20?. Lots of info going out lots of ports. Coordinating all the computers and rigs for multis. All happening real-time while you're sending CW. As Tony LaRussa said, 'There's a lot of stuff goes on'. This is off on a tangent, but stop a minute and think. When do people whine about these bugs? Seems like it's usually just before a contest. Great timing. Would you buy the latest new version of your word-processing package and attempt to use it the day before an important document is due? Or would it be better to install it (of course, WITHOUT deleting the previous version) and give it a test run when nothing's happening? You can always go back to an earlier rev of CT - 6.26 is available as shareware if you don't own any. MINOR revisions usually remove bugs. MAJOR revs add them. Software becomes bug-free (after bug fixes, of course) when no new features are added anymore. And, as Ward N0AX pointed out, there is not an army of beta testers that debugs every minor rev. Ken makes each available as quickly as possible -- this is a tradeoff. Version 8.31 shows 16 contests + DXpedition mode. That's almost all my operating with exception of NAQP (which NA supports) and the RTTY contests. I know one of the big pushes for v9 is user-defined contests. That would end that discussion, right? Look, K1EA isn't paying me to write this. I just think that overall CT is a good package which does a lot. The bottom line is still supply and demand. Write a better one. Sorry, I'll stop flaming. ----------------------------------------------------------------------- I don't want to waste a lot of bandwidth on this ... As mentioned by others, CT supports a bewildering array of options: - Lots of contests - Lots of modes (single, M/S, M/M, M/2, DXpedition, ... ) - Lots of radios - Multi-computer networking - PacketCluster support - Post-contest stats, QSL's, logs ,... Here's one not mentioned - For the inexperienced op, it has an easy-to-learn human interface (the same can be said for NA). When you run small-time multi's, with operators who don't do CT with every contest, every weekend, it is important that your ops get up to speed quickly. Yes, it requires a lot of keystrokes for simple operations, but that's a small price to pay for simplicity. I too, get frustrated at the little bugs that are introduced in each release (and subsequently get fixed). When I am doing single-op, no packet, and don't care about the radio interface, I long for good old CT 5.08 - It worked great on my dog 8088 computer, and was relatively bug-free. ----------------------------------------------------------------------- Observations have been made along the lines of "after 8 major releases, one would think that CT would be bug-free by now". Software development doesn't work that way, as many of us who are involved in that field have learned. First, one must recognize that the capabilities of CT in release 8 are substantially beyond what exists in, say, release 2! Whenever new features are introduced into software, there are two repercussions: -- the new feature itself may have bugs -- the interaction between the software associated with the new feature and older software may also introduce bugs. Professionally software houses spend a lot of time in "regression testing", which is intended to smoke out bugs of the second type. However, it is both expensive and time-consuming to do (and also BORING!). As reflector messages show, people also want ADDITIONAL IMPROVEMENTS in software packages like CT. So, the choices are: a) pay K1EA and others much more money, so they can quit their jobs and work full-time on making CT perfect in every way. [This is unrealistic.....] b) if you prefer NOT to deal with bugs, use versions of software which are OLDER... e.g., release 7 or 6..... and be satisified with the capabilities associated therein. c) if you enjoy exercising the newer features, then use the more recent releases of code AND be prepared for the associated bugs. Be prepared to "work around" when some bug arises ... and, give clear feedback to the author(s) explaining the exact circumstances which can cause a bug to reliably appear. The clearer and more precise the bug report, the quicker the fix. All of us who use CT are part of a cycle: software becomes available, we try it, and report problems as well as wishes for additional capabilities. ----------------------------------------------------------------------- About the time that the profits from CT stopped going to YCCC, and the price charged for the software started to get on up there, I think the user should have been able to expect something more nearly approaching "commercial" quality control. Both CT7 and CT8 have had to be fixed many times, to fix things that were broken in prior revisions, and not caught before those revisions went on the street. While I'm not familiar with the source code, my impression is that there must be a fair bit of "spaghetti" in there, given that things often get broken when another (seemingly unrelated) function is fixed. I also question whether it makes sense to integrate all the code required to support multi-single and multi-multi operation, instead of making it a separate module for those who want and need it. I don't suppose this situation is likely to change , and so will continue to use CT versions that are at least three or four revs earlier than the current one, so that bugs -- at least bugs I care about -- are discovered by someone else. Meanwhile, I have just begun experimenting with N6TR's software, which is commendably compact and easy to use on the air, though painfully lacking in post-contest creature comforts. ----------------------------------------------------------------------- As another "minor league software developer" watching the CT bug discussion with some interest, I want to find out what it takes to get contesters to simply try a different software product. I know from personal experience that its NOT enough to: 1. advertise in NCJ 2. send you a demo floppy with an SASE requesting your comments (20 of you requested such from me last May and ZERO responded) 3. switch to shareware 4. hand carry copies to some of you Might it actually be in your best interest to give a little feedback to the masochistic non-conformist developers once in a while? Otherwise you'll never have anything better than CT. ----------------------------------------------------------------------- With the ongoing CT vs everything else thread, I thought I'd add my 2 pence worth. Various contributors to the reflector have rightly suggested that with increased complexity and functionality comes increased probibility of software problems or "bugs". As a commercial developer, the method that we use to overcome this is three-fold: (1) Strive for zero-defects in the generation of the source code. This means applying techniques to write good quality code, first time. (2) Employ first and second software testing and acceptance teams. (3) Do regression testing using automated testing tools. We find it works for us, since our bug-rates are thankfully quite good (but then we spend an awful lot of pounds achieving this). For CT, which is now a large and well-featured product, it could be possible to do the above, but it would take time and money. Ken, K1EA, has already asked _us_ about details and ideas for CT 9.xx. As an aside, for the "spaghetti" arguement, from what I've seen of the source code, it is "tight" and well-optimised. IMHO, the crux of the matter is that we cannot tell Ken what to write and how to write it (we have to ask _very_ nicely). But, what we could do to help Ken and our fellow conteters, is be part of a good beta-test programme for version 9.xx. One that fully pushes the new (and old) features to the "edge of the envelope". Is there any mechanism like this in place already? (which at the moment seems to be, wait for a major contest and use it!) Or in the end is it really worth going to these lengths? ----------------------------------------------------------------------- Gee, exactly what CT (or any new program) was about 5 years ago..... Now, of course, people will ask for more features, and it'll get buggy, and people will start complaining about it, so everyone will start using some new program which is compact and easy to use but lacking in creature comforts, so, of course, people will ask for more features, and it'll get buggy, and..... :-) ----------------------------------------------------------------------- This is unfortunately a Catch-22. The best way to test the software is to use it during a contest. However, who wants to trust their log to a program that might have some bugs in it? With Ken's blessing, I hope to use a beta copy of Version 9 during both ARRL weekends, both multi-op. However, there's no way we'll find everything that's broken, and if the software starts to give us trouble, then it's back to an older version (winning is more important). I encourage other big guns to ask Ken to do the same. ARRL DX and WPX SSB are the only really big contests where CT can be tested before it's released. ----------------------------------------------------------------------- Over the past couple years of adding features and creating bugs, I have tried to add features that help verify a new version of the software. First off, a simulator for the major contests was added allowing you to work random stations and see how they were logged. The next step was to make the simulator work itself so you can run up big contest scores while you are sleeping in bed. A recently added step is to let the program use a log file from some previous contest as input for re-working the contest (including the exchanges). This feature allowed my new version of the program to re-work the CQ WW from TI1C (with 6475 QSOs) in about eight hours. Comparing the final scores between the old version and the new one with .CTY files is a great way to see how things are working. All of these testing procedures are available to the end user so they can also get confidence in a new version before the contest. Of course, there are still things that can't really be tested, but there is a lot more that can still be done before we reach the limit. Tree N6TR ----------------------------------------------------------------------- ARRL RTTY on CT would be hard ... lots of typing in the packet window, but for state QSO parties you probably could work over the .CTY file for CQP. At least it would dupe check your contacts and give you an indication of mulitpliers and Q's. The scoring probably would be off and would need some work. KI3V/7 has a CQP.CTY for out-of-state verus the in-state .CTY file supplied...not sure but it might be on the distribution list. This probably is not the real answer, but certainly better than paper and pencil. I did it one year for the PA contest, but don't know if I have the .CTY file around anymore. ----------------------------------------------------------------------- I am not interested in having Ken support every little contest; but I would really like the ability to configure CT to work with most any old contest, so my wish-list has user configurability at the top. There are just too many contests to have them built in to a single program, what with all the QSO parties, foreign radio association contests like the recent Belgian one. Even if it did little more than log the qsos, exchanges and multipliers it would be better than what I have now, which is a piece of paper. Even so there will be some contests with rules too weird for a what a user might be allowed to do, and probably even what I have expressed a wish looks to be pretty hard. Oh well. ----------------------------------------------------------------------- A quick plug here for some software I think is great in this respect - Tree's N6TR LOG has user defined contests. You can modify the scoring to fit your needs. Not to mention it is cheaper than CT :-)!! I highly reccommend getting the PD version and running the simulator. You have to give up the CT mind-set to make the learning curve smaller, but once you get the hang of it it flows alot more naturally than CT (for me at least). ----------------------------------------------------------------------- Sorry, CT CTY files will not work with NA. Send an SASE to LTA for the latest NA CTY files. ----------------------------------------------------------------------- I am happy with CT (except for the small bugs) for the major contests, but I run some of the not-so-major contests like ARRL RTTY, PA QSO party, NY QSO Party, NH QSO party, QRP contests, and others where CT sits on the shelf useless because it doesnt support them, and I have no (user) power to make it understand the smaller contests. I can handle small bugs, but when a fine piece of equipment (or S/W in this case) sits on the shelf it is useless!!! Come on CT, let the users support some of the smaller (and FUN!) contests. If CT doesnt I will search for something that does. ----------------------------------------------------------------------- I agree, CT is a good package, but it could be better. This is the type of input the CT author needs! I hope he is listening. ----------------------------------------------------------------------- The contests CT supports are based on user demand, and similarity of rules with already supported contests. CT probably doesn't support the contests you mention because not enough people have asked for it. You admit yourself that they're "not-so-major" contests. That very wording just supports this reasoning - why support those contests if they're "not-so-major"? Ken has been thinking of user-defined contests for a while. I have no idea whether he plans on including them in CT version 9 or not. But remember, increased functionality often results in increased bugs!