Call Search
     

New to Ham Radio?
My Profile

Community
Articles
Forums
News
Reviews
Friends Remembered
Strays
Survey Question

Operating
Contesting
DX Cluster Spots
Propagation

Resources
Calendar
Classifieds
Ham Exams
Ham Links
List Archives
News Articles
Product Reviews
QSL Managers

Site Info
eHam Help (FAQ)
Support the site
The eHam Team
Advertising Info
Vision Statement
About eHam.net

   Home   Help Search  
Pages: [1] 2 3 Next   Go Down
  Print  
Author Topic: Logging Software  (Read 1770 times)
KC2LYQ
Member

Posts: 7




Ignore
« on: April 21, 2007, 06:44:04 PM »

Hello,

I am looking for a new logging software.  The current one I am using just doesn't do it for me, and the new update is almost as much as the original software.  I was really most interested in the two loggers EasyLog 5 and LOGic 8, but I could'nt really tell the major differences between the two.  Would someone with more experience please help me?  Feel free to recommend other loggers as well.  Thank you very much for the help!

73 de KC2LYQ Mike
Logged
KE4DRN
Member

Posts: 3710




Ignore
« Reply #1 on: April 21, 2007, 06:55:47 PM »

hi mike,

http://www.n3fjp.com/

nice software at great price.

73 james
Logged
VE3VID
Member

Posts: 145




Ignore
« Reply #2 on: April 21, 2007, 11:47:26 PM »

I'm with James, N3FJP has some nice software at great prices.  Download & test from their website.  I use their event software, then import to DXbase which is the main software.  DXbase is expensive ($100us), but it truly does it all.  73 & cheers!!!  David
Logged
VA1CQ
Member

Posts: 70


WWW

Ignore
« Reply #3 on: April 22, 2007, 01:51:56 PM »

For general operation, you owe it to yourself to first check Logger32. The program supports transmitting keyboard CW. It also supports most digital modes using your computer soundcard. It has packetcluster operation. And it logs contacts too. This is freeware so you won't find a better deal:
http://www.logger32.net/

Murray
VE7HA
7J1AQH
Logged
AA6YQ
Member

Posts: 1529


WWW

Ignore
« Reply #4 on: April 22, 2007, 10:09:47 PM »

The DXLab Suite is free. Besides the usual logging, transceiver control, DX spot collection and digital mode features you'll find in most applications, DXLab

- provides operations that can alter many logged QSOs simultaneously without requiring the user to modify ADIF files -- e.g. performing callbook lookups on already-logged QSOs, or adjusting the start times of QSOs logged during a specific time range, or extracting QTH information from COMMENT fields, or...

- synchronizes with LotW and eQSL.cc, initiating upload and download operations with a single mouse click without requiring the user to manually invoke TQSL

- directly prints QSL labels and 4-to-a-page QSL cards

- directly prints addresses on envelopes or labels

- tracks confirmation and verification of QSOs for DXCC and TopList awards, highlighting needed DX spots, automatically generating outgoing QSLs that request confirmation of needed QSLs, identifying confirmed QSOs for submission to the ARRL DXCC desk, and generating DXCC submission paperwork

- reports progress towards DXCC, TopList, Challenge VUCC, Marathon, WAS, WAC, IOTA, WAZ, WPX, and county awards

- extracts address information from all 3 CDROM callbooks and QRZ.com

- provides one-click access to more than 100 web-accessible sources of QSL information

- displays frequency-dependent settings for devices like tuners and amplifiers

- provides both map-driven and callsign-driven operation of all known PC-controllable rotators

- captures DX spots from up to 6 sources (telnet clusters, packetclusters, DX Summit), creating and maintaining a local database with one entry for each active DX station that is color coded by "need" and LotW participation, and whose entries can be independently filtered and displayed in a table, on its world map, and on a zoomable bandspread

- extracts QSX frequencies from DX spot notes, enabling accurate transceiver setup for split frequency operation with one user action

- captures solar and geomagnetic data from WWV spots and uses this data to display easy-to-understand QST-style graphical propagation forecasts, and to depict the auroral oval on its world map

- monitors user-specified NCDXF/IARU HF beacon schedules to rapidly calibrate propagation forecasts with actual propagation

- decodes all PSK31 or PSK63 QSOs within your transceiver's bandpass and extract callsigns to create and maintain a "stations heard" window

- simultaneously runs soundcard RTTY (using the MMTTY engine) and an external modem (e.g. a KAM or PK232) to provide diversity decoding or the ability to simultaneously decode a DX station and callers

- supports PSK, RTTY, CW (generation only), and Phone (voice keying) with a single user interface and macro facility

- interoperates with with MultiPSK, MMSSTV, MMVARI, MMTTY, MixW, and DX Atlas

- is updated frequently, and downloads/installs upgrades with a single mouse click

- is driven by an active and friendly user community open to everyone

The DXLab Suite is available via http://www.dxlabsuite.com/

   73,

       Dave, AA6YQ
Logged
W5GA
Member

Posts: 430




Ignore
« Reply #5 on: April 24, 2007, 10:02:51 AM »

There are several large differences that I see between Easylog and Logic.  Easylog will interface to two radios, Logic will do 8.  Logic will also interface to band decoders.  Logic does up to 4 rotors, Easylog 2.  Probably the largest difference is in the searching and reporting capability.  Logic will search and report on ANY field (even user defined), and give you the results on PAPER.  I don't know about you, but I hate looking at that sort of thing on screen.  I've been using Logic since '92 (ver. 2)but periodically look at all the others I can find just to see if there is anything I just have to have.  So far, I haven't found anything that is nearly as flexible as Logic.  And that includes DX Lab, although DX Lab comes closer than anybody else has to date.

Logics shortcomings:
the contesting side shows that it really isn't made for it.  It'll do in a pinch, but lacks a couple necessary features to make it shine.  For this I use N3FJP.

High initial cost

Where Logic really shines:

searching and reporting.  Any of the canned reports (lots of them included) are user customizable.
QSL and label printing, same comment as above.
support, Dennis WN4AZY is just a phone call away and is always happy to help.
If you are familiar Xbase commands, you can really make it sit up and dance.  It has a command screen built in.  Conversely, if you don't know what you are doing you can really screw your log up!(voice of experience)  BACKUPS!!!!

Another plus - This has been on the market a LONG time.  I don't think you'll see it go away anytime soon.

Good luck!

Doug

Logged
K1GMG
Member

Posts: 1


WWW

Ignore
« Reply #6 on: April 24, 2007, 10:28:03 AM »

I use Ham Radio Deluxe and it's free.
http://hrd.ham-radio.ch
It's easy to use and easy to edit entries if you make a mistake.
Does more just logging.  Also does not require downloading a call sign database like other logging software, pulls call sign info from qrz.com
Logged
AA6YQ
Member

Posts: 1529


WWW

Ignore
« Reply #7 on: April 24, 2007, 10:59:37 AM »

DXKeeper, the DXLab's Suite's logging component, will search and report on any field and, if desired, print the resulting report on paper. Access to the log using Structured Query Language (SQL) is available; a log can also be directly loaded into Microsoft Excel for data analysis, charting, etc.

   73,

       Dave, AA6YQ
Logged
N8UZE
Member

Posts: 1524




Ignore
« Reply #8 on: April 28, 2007, 10:45:00 AM »

First you really need to define what you feel is lacking in your current software.  Is it too cumbersome to use?  What features do you like that you want to be sure the next software has?  What features do you feel it is lacking?  And so on.  Until you do that, it will be very difficult for others to recommend something and very difficult for you to make a choice.
Logged
N8UZE
Member

Posts: 1524




Ignore
« Reply #9 on: April 28, 2007, 10:45:26 AM »

First you really need to define what you feel is lacking in your current software.  Is it too cumbersome to use?  What features do you like that you want to be sure the next software has?  What features do you feel it is lacking?  And so on.  Until you do that, it will be very difficult for others to recommend something and very difficult for you to make a choice.
Logged
GM4AHW
Member

Posts: 44




Ignore
« Reply #10 on: May 07, 2007, 04:36:32 PM »

Right on! Define your requirement, then - what? How the hell do you find out what programs actually deliver what you want? My guess? They won't.

Here's why. Computers really deliver everything. Hams are really into everything. So they try to deliver it via software. So the programs very quickly get totally over-bloated (like Word - you know what I mean).

Yes, I know about DXLab, and its granular structure, but actually, like all of these "super logger" programs,it doesn't deliver when it comes to the basics. Like for example, I contact a buddy on 80, and log his start time. Then another buddy crashes in, so I try to log him too, without closing the previous QSO. I have yet to see a PC package which allows that, without going back into the QSO entry and editing the stop time of the first QSO. PLEASE, if you know of one, let me know.

What I want (and again PLEASE, if you know of a program which does this well, tell me!) is control over the end time of each QSO. I envisage multiple QSO-entry panes all active (or preferably one which can switch between currently un-closed QSOs) into which I can command the end time of that particular QSO, rather than having the software decide that if a new QSO is started, then the old one must have stopped. ~Is that too much to ask?

And I absolutely DON'T want a package that handles QSOs in nets by deciding on a start or end time based on the start time of a previous QSO - that sucks. I want control.

And another thing. I log my test transmissions. Comes from an earlier era in the UK when ALL transmissions were logged, irrespective of whether or not they involved other people. I see no way of logging this kind of test transmission in the currently available "logger" programs, which all demand the involvement of a QSO. That sucks too.

And yet another thing! Sorry about this, but I'm on a roll now. I care not at all for DX contests, or any other contest for that matter. I have a logbook into which I have assiduously entered absolutely every RF emission from my shack since, well, since before you were born, probably. I'd like a computer version of that, with all the expected search and autofill facilities that computers can provide, but without the bells and whistles which go off every time a contest target approaches.

I don't want bloatware which will warn me that a particular DX location is the only one missing from my DXCC award - I don't care. I want an automatic, functioning, computer-based logbook. With the accent on LOG.

Too much to ask? Too little to ask? I guess the latter.
Logged
AA6YQ
Member

Posts: 1529


WWW

Ignore
« Reply #11 on: May 07, 2007, 05:21:59 PM »

GM4AHW:

In DXKeeper (the logging component of DXLab),

1. For your "my buddy crashed in" scenario, adjusting the stop-time of the first QSO after you finish takes exactly 3 mouse clicks: 1 to select the previous QSO, and a double-click on the stop-time to update it to "now". This is exactly one mouse-click more than would be required in the solution you propose.

2. You can log a test transmission or any other RF emission by prepending an exclamation mark to a descriptive term you place in the callsign field, e.g. !TESTING or !Antenna_Test or !GridDipOscillator. Such entries provide autofill (e.g. frequency and mode from the transceiver) and are accessible via the standard search mechanisms.

3. Many options are provided to let you tailor the application to your needs. These are preconfigured "out of the box" so that a user can get started without first consulting the documentation, but they are available for anyone interested in performing the optimization.

   73,

       Dave, AA6YQ
Logged
GM4AHW
Member

Posts: 44




Ignore
« Reply #12 on: May 07, 2007, 06:12:10 PM »

Dave,

You entirely miss my point. The user interface is not about how many clicks it takes to do something. In a menu system, for example, if each level of the menu holds, say, ten items, then just three clicks of the mouse will allow you to access any one of a thousand items. Which isn't a selling point if you don't know exactly where each of these thousand items is hiding. The point is that no sane developer would have 1000 items lurking within a menu system, but nevertheless, the truth is that three clicks will navigate the complete space.

So counting clicks gets you nowhere.

You need to look at how operators interface to a real logbook, and replicate that interface as much as possible, while also of course providing the added value that computers can offer. So for example, in my "crashing buddy" scenario, I'd like to leave all QSOs open until I decide they are closed (and don't forget those buddies who keep coming pack at ya even though the have said thay are QRT), and then when I decide it's over, I double-click (in your world) the end time entry in the actual log to write the actual current time there, which is closely analogous to writing the end time in a real log. And if my buddy comes back at me after that, I can always do it again.

The point is that I shouldn't need to "call up" the QSO at all - it is still active, remember -  and I should be able to directly and rapidly manipulate individual fields IN THE LOG. And when I say "in the log" I don't mean in a popup window containing all sorts of irrelevant data which I have to scan through to find the one datum I want to modify - I have already clicked in the log book  on the field I want to change.
Logged
AA6YQ
Member

Posts: 1529


WWW

Ignore
« Reply #13 on: May 07, 2007, 06:37:55 PM »

GM4AHW wrote:

"You entirely miss my point. The user interface is not about how many clicks it takes to do something. In a menu system, for example, if each level of the menu holds, say, ten items, then just three clicks of the mouse will allow you to access any one of a thousand items. Which isn't a selling point if you don't know exactly where each of these thousand items is hiding. The point is that no sane developer would have 1000 items lurking within a menu system, but nevertheless, the truth is that three clicks will navigate the complete space. So counting clicks gets you nowhere."

AA6YQ response:

There are no menus in any DXLab application. In the scenario you described, DXKeeper would present you with a table whose entries show you the data from your most recent QSOs. Clicking on one of these entries lets you modify that QSO's data; specifically, you could then double-click your first  QSO's end-time to update it to "now".

GM4AHW wrote:

"You need to look at how operators interface to a real logbook, and replicate that interface as much as possible, while also of course providing the added value that computers can offer. So for example, in my "crashing buddy" scenario, I'd like to leave all QSOs open until I decide they are closed (and don't forget those buddies who keep coming pack at ya even though the have said thay are QRT), and then when I decide it's over, I double-click (in your world) the end time entry in the actual log to write the actual current time there, which is closely analogous to writing the end time in a real log. And if my buddy comes back at me after that, I can always do it again."


AA6YQ response:

Replicating a pen-and-paper interface is no guarantee of ease-of-use. Should I artificialluy limit the number of QSOs simultaneously visible to the 25 or so shown on a typical paper logbook page?

In your "crashing buddy" scenario, the only thing DXKeeper does differently than you would wish is to set the stop-time of one QSO when you start the next one. You can easily update these stop-times when the group QSO actually finishes, just as you desire.


GM4AHW wrote:

"The point is that I shouldn't need to "call up" the QSO at all - it is still active, remember -  and I should be able to directly and rapidly manipulate individual fields IN THE LOG. And when I say "in the log" I don't mean in a popup window containing all sorts of irrelevant data which I have to scan through to find the one datum I want to modify - I have already clicked in the log book  on the field I want to change."

AA6YQ responded:

A list of your most recent QSOs -- including the ones you consider currently active -- is not "all sorts of irrelevant data". Have you actually tried using DXKeeper in this scenario?

   73,

       Dave, AA6YQ
Logged
GM4AHW
Member

Posts: 44




Ignore
« Reply #14 on: May 07, 2007, 07:06:46 PM »

Dave,

I really didn't intend to use this forum as a battleground, but I still feel you have missed my point.

I didn't say there were menus in DXLab. You were using a click count as an indicator of ease of use, and I was saying it ain't so.

I didn't say that you need to limit the number of visible QSOs to that shown on a traditional log page. Just the active ones will do, ie. those that I haven't closed with an end time.

Your definition of "easily update these stop times" is at the centre of my argument. I just disagree that a system which calls up a popup which contains data I don't want to update is not as user-friendly as clicking on the actual datum that I DO want to update. You have to agree that the popup necessarily contains data that I am not actually interested in at that point, ie. the point at which I want to close the QSO, even though the data contained therein may be of great interest to me at another time.

But I realise we won't see eye to eye on this. If you are the developer of this system, good work. It's just not intuitive enough for me, but don't get in a flap about that, there are plenty of other non-intuitive programs out there, and at least DXLab has the kudos of being one of the best.
Logged
Pages: [1] 2 3 Next   Go Up
  Print  
 
Jump to:  

Powered by MySQL Powered by PHP Powered by SMF 1.1.11 | SMF © 2006-2009, Simple Machines LLC Valid XHTML 1.0! Valid CSS!