Loading ...
Sorry, an error occurred while loading the content.

centralized logging

Expand Messages
  • Brian Lloyd
    One of the problems I am having is that I use many different computers for logging as I am working out of two stations and each station has more than one
    Message 1 of 31 , Apr 3, 2010
    • 0 Attachment
      One of the problems I am having is that I use many different computers
      for logging as I am working out of two stations and each station has
      more than one computer. My problem comes from needing to merge all the
      logs from different programs (I have a mix of Windows, MacOS, and
      Linux machines) into one master logbook and then making sure that the
      new entries make it up to eQSL. (I ran into so many roadblocks with
      LoTW that I just gave up trying to make that work.)

      The other issue I ran into is trying to consolidate log entries for
      dupe checking when running multiple transmitters on Field Day. I
      suppose I could segregate the transmitters by band and mode but
      sometimes that just doesn't work out so being able to detect a dupe
      from a contact made with the other transmitter and computer would be
      really useful.

      In the non-ham world I would solve the problem by writing the
      application to write the logs using SQL and then setting up a MySQL
      server to handle all the transactions. This would also allow multiple
      logging programs from different platforms to easily share data.
      (Fldigi is making it easier as I can depend on it more and more as a
      single cross-platform solution.)

      There is one other thing that using a separate database would do; it
      would make it easy to distribute the logging and log-uploading
      functions as they could be separate programs running on separate
      computers.

      --
      73 de Brian, WB6RQN/J79BPL
    • Brian Lloyd
      ... Actually, the first phase should be a list of requirements. You have to clearly define what problem you are trying to solve before you try to solve the
      Message 31 of 31 , Apr 7, 2010
      • 0 Attachment
        On Wed, Apr 7, 2010 at 10:29 AM, w1hkj <w1hkj@...> wrote:
         

        Simon HB9DRV wrote:
        > Yes,
        >
        > Move it there but make sure that it's understood that the first phase is a
        > spec.
        >
        > Simon Brown, HB9DRV
        > http://sdr-radio.com
        >
        agreed

        Actually, the first phase should be a list of requirements. You have to clearly define what problem you are trying to solve before you try to solve the problem. I would even go so far as to suggest that the requirements include something that describes *how* you know that the requirements have been met. Once you have those two things it becomes much easier to craft a specification and then determine if the specification actually ends up with something that solves the problem. ;-)


        --
        73 de Brian, WB6RQN/J79BPL

      Your message has been successfully submitted and would be delivered to recipients shortly.