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

donate to eham
   Home   Help Search  
Pages: Prev 1 2 [3]   Go Down
  Print  
Author Topic: Logging and an Overall Software Strategy  (Read 11840 times)
HAMSTUDY
Member

Posts: 477




Ignore
« Reply #30 on: May 16, 2016, 11:26:57 PM »

How viable is it to use AC Log in place of HRD's logger and still use the rest of HRD's functions, or are there other surrounding apps that AC Log users prefer vs HRD?

I am thinking this is probably not possible. At the core of both of these programs is the ability to communicate with your radio and as far as I know (and I could be wrong - it has happened before!) you can't have one device talk to two different programs since the first program will want to take exclusive control of that device.

Per other info posted in this thread perhaps it is possible for two programs to control a transceiver, but I appreciate you pointing out that it might be challenging and I realize it could have some performance or reliability risks.

Quote
The point I will try to make is that by all indications, all of this is just theoretical for you. Given the fact that your screen name is not an amateur radio callsign, we can make two assumptions:
1) You are not (yet) a licensed amateur radio operator
2) You are a licensed amateur radio operator but for some reason, you have chosen not to share that with us.

I have a license but so far only as a Technician, not yet a General.  More on that below.

Quote
Until we know more about you, all of this is theoretical. Is your list of "requirements" a true list of requirements based on years of experience or is it merely a "wish list" of things you would like to have?

Not sure what you need to know to recommend software.  I'm just a new ham trying to figure out what software helps record and confirm contacts, is user friendly and enjoyable to use.  I'd also like software that will play nicely with other software - that's why this thread was entitled "Logging and an Overall Software Strategy".  As a new ham I'm not sure what functions are likely to be important to consider beyond logging but I know enough to know that logging is likely to be only one function among several that might have to share fields among various types of records in a database.  I get software somewhat and I'm just starting to figure out ham operations but as a new ham who hasn't used call logging software (so far I'm just using a spreadsheet for VHF/UHF) I can't specify "a true list of requirements based on years of experience", so I guess my interests in finding software that is user friendly and enjoyable to use falls under the category of "wish list" as you say.

Quote
And the other thing to realize is that no matter what someone tells you about a specific piece of software, it will be subjective from their point of view.

Thanks for helping me understand that what someone says about software might be subjective.Smiley  I'll keep that in mind but I think that's partly why people ask other people about their experience with software - to get their opinions based on their experience and their perspective.

Quote
As was suggested in an earlier post, try the various programs and see which one(s) work for YOU!

I have loaded HRD and a few other trial programs - so I am developing a sense for what they do, but there is a learning curve.  In parallel I'm getting ready to hopefully pass the General test and make an investment in a transceiver and antenna and I thought I'd ask around to learn from more experienced users.

Quote
My reason for preferring one piece of software over another is because it suits my operating style.
For me, except for:
1) Contesting logging (in which case I use N1MM+)
2) FSK RTTY (in which case I use MMTTY)
3) The "JT" modes (which I do not use)
HRD works fine... for me. I have been licensed for 23½ years. I have my share of DXCC and WAS certificates. I also have my share of fairly decent contest finishes. The bottom line is that my choice of programs is indeed based on decades of experience.

Cool, an opinion in context!

---

Not sure what flips out some people about other members here without a call sign.  My guess is that there are probably some people here thinking about becoming a ham who don't have a license and probably others who have a call sign but who prefer a non call sign user name.  Regardless, I suspect that most people who are forum members here joined in part to learn from others.

As for not using a call sign, the primary and initial reason was simply that I didn't have one until a few months ago.  I signed up on eHam to get a head start on learning to use my new VHF/UHF rig and to do some operating homework in preparation for HF.  But FWIW, after reading and making posts here I'm increasingly of the opinion that using a call sign in this forum might not necessarily be the preferred way to participate.  Most of the time people seem to be level headed, although occasionally though some comments make you wonder.  In just the short time I've been on the air with VHF/UHF I've already had one ham jump into a repeater QSO to volunteer "remember, anyone can be listening".  I love technology but I'm sometimes a little disappointed in the genie society has let out of the bottle.  You might feel differently.

Hope that answers some of your questions and concerns.  73
Logged
HAMSTUDY
Member

Posts: 477




Ignore
« Reply #31 on: May 16, 2016, 11:34:28 PM »

Just discovered AC Log.  Anyone have any comments on AC Log vs HRD?  Thx

Here are 186 people who have heard of it.... giving it an overall rating of 4.8 out of 5!

http://www.eham.net/reviews/detail/1565

Of course the main difference is that it is not a "station management" program like HRD so you can't really make an "apples to apples" comparison.

Ok, fair enough.  Let me rephrase the question.  For people who have used both, how does AC Log compare to the logging function in HRD?  How viable is it to use AC Log in place of HRD's logger and still use the rest of HRD's functions, or are there other surrounding apps that AC Log users prefer vs HRD?  Sort of leads to whether people prefer integrating diverse best of category apps or go with good enough, maybe not the best in various categories, but benefit from tighter integration.  Just looking for recommendations, especially from users who have tried various products and combinations.

I tried ACLog for a few months.  I went back to HRD. Both met my needs for basic logging but HRD allows more customization of the screen layout.  It was just a matter of preference not capabilities. Try them both. ACLog and HRD both have a free trial.  

Having more than one program performing rig control is possible.  You have to share a COM port (only one cable is connected to your radio).  Software is available to create "Virtual Serial Ports". Take a look at Com0Com and Eterlogic's Virtual Serial Port Emulator (ie. VSPE).  I use several virtual serial ports in my setup.

Do you have a radio?

Thanks for sharing your experience on ACL vs HRD.  It's interesting to hear you found HRD to be more customizable; I've found HRD to be pretty customizable but some of the windowing features seem a little clunky - but that might be my particular screen layout and resolution.  I don't know much yet about ACL but from what I've seen I thought it looked more streamlined/clean, but that's based on a very limited understanding of what logging really entails.

I appreciate the info on Virtual Serial Ports.  I'd like to keep things somewhat simple but if a VSPE is needed it's good to know it's possible.

No radio yet (except VHF/UHF) but a Kenwood 590SG seems to be calling CQ in my dreams. Smiley

With respect to a 590SG, I'm not sure yet if VPSE might be part of the solution but in addition to using logging (and other software) I'm pretty committed to building a computer-based panadapter by interfacing a SDRPlay between the computer and the 590SG.  As I understand it, the computer (running HDSDR) software will have a USB connection to the SDRPlay which will connect it's SMA input to the 590SG's DRV RCA output.  In turn the 590SG will have a USB CAT interface to the computer.  So that's two USB connections to the computer (one from the SDRPlay and one from the 590SG).  Not sure that either of those will require a VPSE but if the CAT interface from the computer to the transceiver is used to create bidirectional tuning control (so that the transceiver knob will adjust the panadapter frequency and the panadapter's mouse driven frequency control will adjust the transceiver's frequency), then maybe there is a further need to synchronize all this with HRD or whatever is providing logging (and maybe DX cluster) management.  (Maybe there is a reason in here to use a VPSE?).

Net, net, net:  I wouldn't call this "theoretical", I'd call it "planning" (which generally makes execution go smoother).  I hope.  Smiley
« Last Edit: May 17, 2016, 12:07:47 AM by HAMSTUDY » Logged
HAMSTUDY
Member

Posts: 477




Ignore
« Reply #32 on: May 16, 2016, 11:50:15 PM »

Having more than one program performing rig control is possible.  You have to share a COM port (only one cable is connected to your radio).  Software is available to create "Virtual Serial Ports". Take a look at Com0Com and Eterlogic's Virtual Serial Port Emulator (ie. VSPE).  I use several virtual serial ports in my setup.

Unless the transceiver control applications you're using explicitly support this configuration, having two transceiver control applications simultaneously sending CAT commands to the same transceiver via a dumb port splitter can be dangerous.

Most transceiver control applications assume that they alone send CAT commands to the transceiver. If Application A sends command A to the transceiver, and Application B then sends command B to the same transceiver, application B will see the transceiver's response to command A, which it does not expect. Application A will see an unexpected response to Command B. Furthermore, some transceivers are limited in the number of commands they can accept "back-to-back" without pacing. Two transceiver control applications that individually comply with such constraints might violate those constraints when both are issuing commands to the same transceiver through a dumb port splitter. Commands could be dropped or improperly executed by the transceiver's embedded microprocessor.

Ops often respond to this point with "but mine is working fine". Depending upon the rate at which the transceiver applications are issuing CAT commands and the specifics of the code running on the transceiver's embedded microprocessor, the rate at which bad things happen may be quite low, to the point of being unnoticeable. But all it takes is one bad sequence of events to let the smoke out - like dropping a QSY command before switching from RX to TX; are you feeling lucky?

In contrast to a dumb port splitter, a port splitter that understands the transceiver's CAT protocol and routes transceiver responses to the appropriate CAT application while enforcing pacing constraints would be reliable. K9JM's CI-V router uses this technique to prevent a latent defect in Icom PW1 amplifiers from causing serious damage.

An application that passively monitors CAT commands and responses to enable a device (amplifier, antenna, switch, tuner, etc.) to track the transceiver's frequency is also no threat to reliability.

Thanks.  This is a prime example of why this is such a good forum and also why people might ask "theoretical" questions about "wish list" requirements.  

First I was just trying to figure out a path from logging software to an overall software solution.  That led to HRD or other "integrated suites" vs. standalone software applications from multiple software providers.  That led to basic software data sharing (among fields and records, etc.).  That led to some folks saying you can only have one software package control a transceiver.  That led to the use of virtual ports.  That led to some possible challenges with virtual ports.  Which now has me thinking about how to integrate logging and other fairly standard software with my plans for creating a bidirectional panadapter (see post above).

(All this might seem trivial to experienced users but 6 months ago when I first discovered SDR in general and then the SDRPlay, and saw how cool a radio panadapter is, I had no idea I was headed down the ham route - so everything is new.  And it seems like every time you peel back a layer there is another layer.  Which is frankly a lot fun - it's like an Easter Egg hunt, but it's also an investment in time and $ so I'm doing some homework and appreciate the guidance here.)  

I definitely appreciate the info everyone has provided as this discussion thread has developed - and I hope those who wonder why would anyone ask such open ended theoretical wish list questions might look at this thread as an example of why it sometimes makes sense to ask questions and explore possible paths before just loading up software and creating records.  I'm chomping at the bit to pass the General and get a HF rig put together but it seems like a good opportunity in the meantime to learn from those with more experience - it's interesting and fun - and it could help avoid some detours that might otherwise provide a less than highly scenic route.

BTW, if you think this thread has stirred some discussion about theoretical software, you can check out some of my earlier threads over in the antenna section.  Software is easy compared to antennas Smiley

Net, net:  HRD is still looking good, I'm still interested in learning more about ACL, and I'm very open to hearing about any other software that people really enjoy using (for DX cluster management, for any mode specific software including SSB, data, CW, or for anything else).  73
« Last Edit: May 17, 2016, 12:28:53 AM by HAMSTUDY » Logged
AA6YQ
Member

Posts: 2750


WWW

Ignore
« Reply #33 on: May 17, 2016, 12:37:41 AM »


First I was just trying to figure out a path from logging software to an overall software solution.  That led to HRD or other "integrated suites" vs. standalone software applications from multiple software providers.  


There are integrated suites that interoperate with applications from multiple software providers.


Net, net:  HRD is still looking good, I'm still interested in learning more about ACL, and I'm very open to hearing about any other software that people really enjoy using (for DX cluster management, for any mode specific software including SSB, data, CW, or for anything else).  

This is the architecture used by DXLab to extract and exploit information from up to 6 sources of DX spots:



If you'd like to learn more, see Getting Started with Active DX Identification and Analytics.
Logged
Pages: Prev 1 2 [3]   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!