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: Prev 1 [2]   Go Down
  Print  
Author Topic: Hdwr Ctrl, Timers, Serial Port Access in VB6  (Read 2247 times)
AE6Y
Member

Posts: 30




Ignore
« Reply #15 on: February 06, 2004, 09:56:33 PM »

Dave,
  Re timing, I've been using  a simple software algorithm to send CW, first in DOS with my contest logging program CQP, and for the last 8 years or so in Windows with CQPWIN, now written in VB 6.
  I can send you the code if you like, but I basically initialize the CW timing at the start of the program by counting how many repetitions of a common arithmetic operation (as I recall, a simple floating point division) occur in a fixed period of time (like 2 seconds or so).  I then use this to define my basic timing parameter, which is the number of repetitions of this operation needed for one dot length at 28 wpm.  Depending on computer speed, this will be many thousands of repetitions.
   When I send CW, I just turn on the appropriate serial or parallel port while the computer churns away on a dot or dash then turn off the port. To change speeds, I apply the ratio of speeds to the number of repetitions to change the dot lentgth.  I check for keyboard input after each character so that one can change the CW speed or abort sending in the middle of a message.
  I find this method to be almost flawless.  Every so often, something seems to happen in the background to cause a slight hiccup, but nothing that is ever bothersome.  I really haven't had Windows timing problems with it, even going back to Win 3.1 (although in earlier versions of Windows, moving the mouse or a disk copy could disrupt sending).
  I've used this program for years on CW, including, e.g., a 3rd place world finish in 2002 WPX CW and 4th place world finish (both from P40Y) in 2003 ARRL DX CW. Of course, the Aruba location helps, but the software works very effectively in a fast-paced contest environment.
  As I said, I'd be happy to send you VB6 code if you like.  I'd like some help in return on serial communication with the radio, as the one thing I don't do with CQPWIN is control frequency or other radio functions (other than PTT, CW, DVK, and Radio 1/2 switching).
  73 and GL, Andy, AE6Y
 
 
Logged
AA6YQ
Member

Posts: 1588


WWW

Ignore
« Reply #16 on: February 06, 2004, 10:26:01 PM »

Thanks for the offer, Andy!

As I understand your approach, you are consuming 100% of the CPU cycles. That's fine if you're only running the CW application, but doesn't work if you also want to do logging, transceiver control, DX spot collection and analysis, etc.

I have an implementation that uses the Windows Multimedia timer -- so instead of counting arithemetic operations as you do, I count 1 ms time intervals; during those time intervals, the CPU is free to run other applications. This works well, but there is the occasional extended dot or dash, even though the code is running at the highest Windows priority. Eliminating these "hiccups" has driven my search for other techniques, but your experience would seem to indicate that they are unavoidable.

If you're are interested in transceiver control or other station automation, take a look at www.qsl.net/dxlab -- a suite of free tools I've developed. If you'd like to continue this interaction, my email address is available via QRZ.com .

     73,

        Dave, AA6YQ
Logged
K3AN
Member

Posts: 787




Ignore
« Reply #17 on: February 08, 2004, 12:14:20 PM »

Dave,

I suspect that Andy and I use pretty much the same approach for CW timing and sending, and as long as there is a DoEvents statement in the code timing loop, the computer can do other tasks while waiting for the loop to time out. Yes, once in a while a code element (dot, dash or space) will be "stretched," but it's so infrequent as to be acceptable.

Bill
Logged
AE6Y
Member

Posts: 30




Ignore
« Reply #18 on: February 09, 2004, 02:07:45 AM »

Dave and Bill,
  Thanks for the replies.  I'm an amateur programmer (actually a lawyer by profession), so I tend to stumble around, rather than necessarily figuring out the best way to do things.  
  Dave, DXLAB certainly looks like a sophisticated suite of applications.  Congratulations.  I think initially to expand CQPWIN, all I want to do at first is just add communications for radio band switching and frequency control -- in truth, I've been able to live without it quite well, but it definitely seems to be an appropriate addition.
  I've noticed that W5XD seems to believe that CW should be sent with an outboard device to avoid Windows hiccups, but with my limited program, I haven't found them objectionable.  Ironically, when I first wrote my DOS logging program, CQP, I used exactly that technique, sending characters to a PK232 to generate the code -- I dropped it as inelegant, hi.
  Query whether doing rig control would be the same using Bill's and my simple method of timing, with, as Bill's  suggests, a DoEvents thrown in (perhaps between characters) to allow rig polling to take place.
  I may look at this further when I get back from Aruba, where I am going next Saturday to operate in ARRL DX CW as P40Y.  My main taks, however, is to try to set up a whole lot of SO2R gear that I have been buying boxes and fabricating interconnects for during the last month.
  I'd appreciate the chance to pick your brains every so often on radio/computer communications techniques in VB6.
  73, andy, ae6y
Logged
AA6YQ
Member

Posts: 1588


WWW

Ignore
« Reply #19 on: February 09, 2004, 03:38:01 AM »

FB. Andy.

If by "frequency control", you mean setting the transceiver frequency from your software, you can certainly do that in between outgoing CW characters. However, if you want to track your transceiver's frequency -- to display it on screen, or log it -- you'll need to poll the transceiver and interpret its response. This will require the insertion of a DoEvents somewhere, as Bill suggests. The problem is that you won't know how much time elapsed while the CPU was off dealing with your transceiver. If you are only soliciting the frequency so you can log it, then between CW words should be more than often enough; if you're trying for a smooth on-screen display, however, you'll need to poll more frequently than that -- typically every 200 ms. or so.

My plan is to include a "software" implementation of CW generation based on the multimedia timer, but also support CW generation through external modems like the PK232 or KAM, or via a keyer like the WinKey. Some recent transceivers can be directed to transmit CW via their CAT interface, so I'll support that as well.

Good luck in the contest, and safe travels!

    73,

        Dave, AA6YQ
Logged
AE6Y
Member

Posts: 30




Ignore
« Reply #20 on: February 09, 2004, 01:43:03 PM »

Dave,
  Thanks for the info. You're really inspiring me to tackle the radio communications issues that I have been ducking for years.  Do you know how N1MM handles CW generation in the midst of radio polling?  I believe that program is also a VB6 effort, that seems to be pretty popular right now.
  73, andy, ae6y
Logged
Pages: Prev 1 [2]   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!