Date   

Re: DXLab on Linux Question about serial ports

n6ws
 

Dave,

There is one error in my procedure. The selection for USB v2.0 is a second checkbox after you have enable USB support.
Step 4 under USB requires a change from:

Enable the*USB Controller* or*USB 2.0 Controller*

***To:*

**

**

**

Enable the*USB Controller*
Enable the*USB 2.0 (EHCI) Controller* if you are using USB v2.0

I wasn't sure how to word my explanation to Mark for USB 2.0, so I used and 'or' between the steps. If you don't select the first USB option the USB 2.0 is greyed out.

73, Bill
N6WS

On 06/30/2011 05:53 PM, Dave AA6YQ wrote:

Many thanks, Bill. I have taken the liberty of adding the information you
provided below to the "DXLab on Linux" article in "Getting Started with
DXLab" at

<http://www.dxlabsuite.com/dxlabwiki/DXLabLinux>

Please let me know if corrections or additions are in order.

73,

Dave, AA6YQ

-----Original Message-----
From: dxlab@yahoogroups.com <mailto:dxlab%40yahoogroups.com>
[mailto:dxlab@yahoogroups.com <mailto:dxlab%40yahoogroups.com>]On
Behalf Of
Bill Shell
Sent: Thursday, June 30, 2011 12:56 AM
To: dxlab@yahoogroups.com <mailto:dxlab%40yahoogroups.com>
Cc: wc5m
Subject: Re: [dxlab] DXLab on Linux Question about serial ports

Mark,

Are you using regular serial ports or USB serial ports? The steps to
configure the ports are slightly different for each.

- When you first launch VirtualBox Manager highlight the guest OS with a
single mouse-click.
- At the top, click on the Gear Icon labelled Settings.
- If you are using a regular RS232 serial port, select 'Serial Ports'.
- - From the Serial Ports screen you can configure one or two serial
ports for use by the guest OS.
- If you are using USB serial ports, select USB.
- - Enable the USB Controller or USB 2.0 Controller.
- - Select the USB Add (+) from the far right set of icons.
- - Select the device that represents the USB serial port you are adding.
- Click 'OK' at the bottom right of either screen (Serial Port or USB).
- Launch the guest OS.
- Win-XP will go through the normal process of finding new hardware,
loading the necessary drivers, etc.

The serial ports should then be visible to your application.

I hope this helps.

73, Bill
N6WS

On 06/19/2011 02:24 PM, wc5m wrote:

I am trying to set up DXLab running on a Ubuntu 10.04 Linux host
computer using VirtualBox and Windows XP Pro as the guest OS and
cannot figure out how to set up the serial ports. FWIW I've read the
VB manual and still scratching my head. Any help is greatly appreciated.

73,
Mark WC5M



------------------------------------

Yahoo! Groups Links

-----
No virus found in this message.
Checked by AVG - www.avg.com
Version: 10.0.1388 / Virus Database: 1516/3733 - Release Date: 06/29/11


Re: Label Counter

Jay <PCB4U@...>
 

Dave

Your method below...

This is something I've done and didn't sink in to leave those over 30 in there and use them for the next batch....but I do have reason for my madness thus I never got into that mode.

Believe it or not (HI) the 30 count target is not something I geared up for driven by the label count on the 5160 sheets only. I need to go thru a phase of allowing the stupid QSO verify stamp ink to dry so it doesn't smear, and for the JAs about 20% of their envelopes have no glue whatsoever so I need to use a gluestick to seal those envelopes and then I have to apply the return air mail stamp for about 90% of the non USA requests. The 30 count gives me time to do all this touch labor and gets me away from the PC screen for about 10 minutes..

I'll try your method and see how that works

73 and thanks for the time on the keyboard.

Jay



Processing QSLs in exact batches of 30 is indeed consuming a great deal
of time. You can avoid printing partial pages without doing this. As I
described, first fill up the QSL Queue with entries for the incoming QSLs
you plan to process. Then do a print preview, and examine the last page to
see how many of its labels are used; if the number is 11, say, then uncheck
the QSL boxes of 11 singleton QSOs in the QSL Queue, and direct DXKeeper to
print your labels; I assume you'll be able to feed labels to your printer
one-at-a-time as it prints this batch. Then click the "Update Log" button;
the 11 QSOs for which no labels were printed will automatically be included
in the next batch of labels you print when you click "Add Requested".
----- Original Message -----
From: "Dave AA6YQ" <aa6yq@ambersoft.com>
To: <dxlab@yahoogroups.com>
Sent: Thursday, June 30, 2011 5:24 PM
Subject: RE: [dxlab] Re: Label Counter


AA6YQ comments below
-----Original Message-----
From: dxlab@yahoogroups.com [mailto:dxlab@yahoogroups.com]On Behalf Of
JayKay
Sent: Thursday, June 30, 2011 6:17 PM
To: dxlab@yahoogroups.com
Subject: Re: [dxlab] Re: Label Counter


Dave

I am only printing QSL labels

1) I put their call in the CALL filter window

2) I look at their QSL and compare with the data just filtered by the CALL
search

3) If all is OK I either (a) if 2 or less Q's, I left/right click on each Q
and send to the print queue or (b) or 3 or more I go to QSL tab and then do
an ADD ALL

4) I keep doing items 1 thru 3 until I "feel" I have done or near filling in
30 labels

5) I keep previewing the print queue until the 30 labels have been accounted
for as I don't want to create another re-feed situation and do the USED
label function...again this is just my way of doing this as I noted
previously re-feeds, in my opinion, will chew up time

6) I feed the HP1320 one sheet of labels from the front

7) I then print the 1 sheet of labels and apply labels as needed

What I am getting at is that steps 4 and 5 above can eat up a lot of time
over 30K Q's (as I have been experiencing) and if a window said " There are
16 labels left" I would then have an idea of how many envelopes I need to
pull versus previewing the print queue which is a tab click, print labels
click and then OK on the number of used labels...so a total of 3
interventions. Seems like nothing but after 2 solid weeks of this its just
something I see that would be helpful.

Its really an attempt to reduce the time finding out how many labels I have
available as I pull envelopes.

Processing QSLs in exact batches of 30 is indeed consuming a great deal
of time. You can avoid printing partial pages without doing this. As I
described, first fill up the QSL Queue with entries for the incoming QSLs
you plan to process. Then do a print preview, and examine the last page to
see how many of its labels are used; if the number is 11, say, then uncheck
the QSL boxes of 11 singleton QSOs in the QSL Queue, and direct DXKeeper to
print your labels; I assume you'll be able to feed labels to your printer
one-at-a-time as it prints this batch. Then click the "Update Log" button;
the 11 QSOs for which no labels were printed will automatically be included
in the next batch of labels you print when you click "Add Requested".

When printing cards or labels, DXKeeper does not pre-compute the number
of cards or labels that will be generated by the entries in the QSL Queue
because the algorithm for assigning QSOs to cards or labels is non-trivial:
two QSOs can only be confirmed on the same card or label if they were made
with the same station callsign from the same "my QTH" with the same "QSL
Via". Thus providing a display of the number of cards or labels that would
be generated if the QSL Queue were printed would require a print preview
operation. Your DXpedition situation is simpler, as all QSOs are made with
the same station callsign from the same location with the same "QSL Via"
information, but an extension to DXKeeper would have to work correctly in
all situations.

73,

Dave, AA6YQ



------------------------------------

Yahoo! Groups Links



Re: DXLab on Linux Question about serial ports

Dave AA6YQ
 

Many thanks, Bill. I have taken the liberty of adding the information you
provided below to the "DXLab on Linux" article in "Getting Started with
DXLab" at

<http://www.dxlabsuite.com/dxlabwiki/DXLabLinux>

Please let me know if corrections or additions are in order.

73,

Dave, AA6YQ

-----Original Message-----
From: dxlab@yahoogroups.com [mailto:dxlab@yahoogroups.com]On Behalf Of
Bill Shell
Sent: Thursday, June 30, 2011 12:56 AM
To: dxlab@yahoogroups.com
Cc: wc5m
Subject: Re: [dxlab] DXLab on Linux Question about serial ports


Mark,

Are you using regular serial ports or USB serial ports? The steps to
configure the ports are slightly different for each.

- When you first launch VirtualBox Manager highlight the guest OS with a
single mouse-click.
- At the top, click on the Gear Icon labelled Settings.
- If you are using a regular RS232 serial port, select 'Serial Ports'.
- - From the Serial Ports screen you can configure one or two serial
ports for use by the guest OS.
- If you are using USB serial ports, select USB.
- - Enable the USB Controller or USB 2.0 Controller.
- - Select the USB Add (+) from the far right set of icons.
- - Select the device that represents the USB serial port you are adding.
- Click 'OK' at the bottom right of either screen (Serial Port or USB).
- Launch the guest OS.
- Win-XP will go through the normal process of finding new hardware,
loading the necessary drivers, etc.

The serial ports should then be visible to your application.

I hope this helps.

73, Bill
N6WS


On 06/19/2011 02:24 PM, wc5m wrote:

I am trying to set up DXLab running on a Ubuntu 10.04 Linux host
computer using VirtualBox and Windows XP Pro as the guest OS and
cannot figure out how to set up the serial ports. FWIW I've read the
VB manual and still scratching my head. Any help is greatly appreciated.

73,
Mark WC5M








------------------------------------

Yahoo! Groups Links



-----
No virus found in this message.
Checked by AVG - www.avg.com
Version: 10.0.1388 / Virus Database: 1516/3733 - Release Date: 06/29/11


Re: Label Counter

Dave AA6YQ
 

AA6YQ comments below
-----Original Message-----
From: dxlab@yahoogroups.com [mailto:dxlab@yahoogroups.com]On Behalf Of
JayKay
Sent: Thursday, June 30, 2011 6:17 PM
To: dxlab@yahoogroups.com
Subject: Re: [dxlab] Re: Label Counter


Dave

I am only printing QSL labels

1) I put their call in the CALL filter window

2) I look at their QSL and compare with the data just filtered by the CALL
search

3) If all is OK I either (a) if 2 or less Q's, I left/right click on each Q
and send to the print queue or (b) or 3 or more I go to QSL tab and then do
an ADD ALL

4) I keep doing items 1 thru 3 until I "feel" I have done or near filling in
30 labels

5) I keep previewing the print queue until the 30 labels have been accounted
for as I don't want to create another re-feed situation and do the USED
label function...again this is just my way of doing this as I noted
previously re-feeds, in my opinion, will chew up time

6) I feed the HP1320 one sheet of labels from the front

7) I then print the 1 sheet of labels and apply labels as needed

What I am getting at is that steps 4 and 5 above can eat up a lot of time
over 30K Q's (as I have been experiencing) and if a window said " There are
16 labels left" I would then have an idea of how many envelopes I need to
pull versus previewing the print queue which is a tab click, print labels
click and then OK on the number of used labels...so a total of 3
interventions. Seems like nothing but after 2 solid weeks of this its just
something I see that would be helpful.

Its really an attempt to reduce the time finding out how many labels I have
available as I pull envelopes.

Processing QSLs in exact batches of 30 is indeed consuming a great deal
of time. You can avoid printing partial pages without doing this. As I
described, first fill up the QSL Queue with entries for the incoming QSLs
you plan to process. Then do a print preview, and examine the last page to
see how many of its labels are used; if the number is 11, say, then uncheck
the QSL boxes of 11 singleton QSOs in the QSL Queue, and direct DXKeeper to
print your labels; I assume you'll be able to feed labels to your printer
one-at-a-time as it prints this batch. Then click the "Update Log" button;
the 11 QSOs for which no labels were printed will automatically be included
in the next batch of labels you print when you click "Add Requested".

When printing cards or labels, DXKeeper does not pre-compute the number
of cards or labels that will be generated by the entries in the QSL Queue
because the algorithm for assigning QSOs to cards or labels is non-trivial:
two QSOs can only be confirmed on the same card or label if they were made
with the same station callsign from the same "my QTH" with the same "QSL
Via". Thus providing a display of the number of cards or labels that would
be generated if the QSL Queue were printed would require a print preview
operation. Your DXpedition situation is simpler, as all QSOs are made with
the same station callsign from the same location with the same "QSL Via"
information, but an extension to DXKeeper would have to work correctly in
all situations.

73,

Dave, AA6YQ


Re: DXLab Sometimes Breaks Windows Task Switching

Dave AA6YQ
 

+++ AA6YQ comments below

-----Original Message-----
From: dxlab@yahoogroups.com [mailto:dxlab@yahoogroups.com]On Behalf Of
g4wjs
Sent: Thursday, June 30, 2011 5:19 PM
To: dxlab@yahoogroups.com
Subject: [dxlab] Re: DXLab Sometimes Breaks Windows Task Switching




--- In dxlab@yahoogroups.com, Rich - W3ZJ <rich@...> wrote:

Closing the DXLab applications might free up enough CPU to allow your
machine to recover but that's a result of the problem, not likely the
cause of it.

The next time that happens to you try the following:

1) Open task manager (since the machine is unresponsive that might take
a while).
2) Click on the "Show processes from all users" button.
3) Click on the CPU heading once or twice to sort the list in descending
order by CPU usage.
4) See what process is chewing up most of your CPU

It might be task manager itself but we know that's overloaded so look
for the next one down the list. Chances are it will be something that
you don't know why it's there or what it's doing. There is a good chance
that it is part of your anti malware program that has become confused
and is beating up your machine. Search the Internet for a solution. You
are undoubtedly not the only one who has had the same problem and there
is a good chance you'll find a solution.
I think you are misunderstanding, I probably wasn't clear in my original
post. The machine is not at all unresponsive in this case, task switching
works instantaneously as normal but the switch just cycles around the
windows of one of the DXLab applications that has two windows open. For
example Commander or DXView. Also if it helps anyone diagnose this, it tries
to switch to another task but seems to get rapidly switched back
automatically to the original DXLab application.

+++ This is not something I will attempt to diagnose. The task switcher is a
part of Windows, and that is where the responsible defect most likely lies.

73,

Dave, AA6YQ


Re: PropView feature request

Dave AA6YQ
 

AA6YQ comments below
-----Original Message-----
From: dxlab@yahoogroups.com [mailto:dxlab@yahoogroups.com]On Behalf Of
Peter Zingsheim
Sent: Thursday, June 30, 2011 1:05 PM
To: dxlab@yahoogroups.com
Subject: [dxlab] PropView feature request


Dave,

by and large, dxlab offers more than I can ever hope to use as a casual
non-competitive dxer, who is not after awards. On the reflector, I�m more of
a lurker, meaning that everything works just splendidly! Thanks!

Therefore I feel reluctant about "request". To me, that word sounds so
demanding. Anyway:

With conds changing for the better, I find myself listening more frequently
to the NCDXF/IARU beacons and would like to compare what I hear with
propagation predictions.

1)Propview plots the monitored beacon on DXView�s map. Would it be possible
also to show a prediction for that beacon? (Much in the same way that
clicking a spot can evoke a prediction.)

Good idea!

2) Also, is there any chance that Propview automatically updates the beacon
status from the NCDXF/IARU beacon website?

That would be difficult to implement robustly. Direct you browser to
visit

<http://www.ncdxf.org/beacon/beaconschedule.html>

and then do a "view source" command to look at the HTML for that big
table. The code would have to extract information from the 10th column of
each row.

What would make this practical would be for the same information to be
made accessible in XML format...

73,

Dave, AA6YQ


Re: Label Counter

JayKay <PCB4U@...>
 

Dave

I am only printing QSL labels

1) I put their call in the CALL filter window

2) I look at their QSL and compare with the data just filtered by the CALL search

3) If all is OK I either (a) if 2 or less Q's, I left/right click on each Q and send to the print queue or (b) or 3 or more I go to QSL tab and then do an ADD ALL

4) I keep doing items 1 thru 3 until I "feel" I have done or near filling in 30 labels

5) I keep previewing the print queue until the 30 labels have been accounted for as I don't want to create another re-feed situation and do the USED label function...again this is just my way of doing this as I noted previously re-feeds, in my opinion, will chew up time

6) I feed the HP1320 one sheet of labels from the front

7) I then print the 1 sheet of labels and apply labels as needed

What I am getting at is that steps 4 and 5 above can eat up a lot of time over 30K Q's (as I have been experiencing) and if a window said " There are 16 labels left" I would then have an idea of how many envelopes I need to pull versus previewing the print queue which is a tab click, print labels click and then OK on the number of used labels...so a total of 3 interventions. Seems like nothing but after 2 solid weeks of this its just something I see that would be helpful.

Its really an attempt to reduce the time finding out how many labels I have available as I pull envelopes.

73
Jay

----- Original Message -----
From: "Dave" <aa6yq@ambersoft.com>
To: <dxlab@yahoogroups.com>
Sent: Thursday, June 30, 2011 2:51 PM
Subject: [dxlab] Re: Label Counter


### AA6YQ

--- In dxlab@yahoogroups.com, "Jay" <PCB4U@...> wrote:

Dave

And that's another method I have used....refeed the sheet and use the "used"
count...but this extra process could be removed by a label counter telling
me how many are left for that one sheet (I only have a 1 sheet feed). Not
having to preview and then figure out how many more envelopes to pull (which
is a guess as I have no real idea how many Q's are in each
envelope...averaging 1-2) to finish the one label sheet would be great.

What I see as a possible addition, since I can only do one sheet at a time,
is a "view" into how many labels remain for that one sheet when I do an ADD
into the print queue. Feeding and re-feeding is extra time when dealing with
31K Q's so I do previews over this feed/refeed method.

The average DXer may not need this but a QSL manager could use as it helps
him to see what's going on versus having to check the print preview with a
boxes of envelopes next to him.

Just a suggestion.....
### I still don't understand what you need.

### My QSLing for 8P9RY involves fewer cards than your operation, but let me describe my workflow:

1. when a stack of incoming cards is available, use the Call filter to locate each QSO in the log and the CTRL-ALT-C keyboard short cut to mark it confirmed (if the info on the card matches the info in my log)

2. load the printer with card stock

3. on the Main window's QSL tab,

3a. set the "QSL Via" panel to "Cards"

3b. click "Add Requested" to populate the QSL Queue with newly-confirmed QSOs

3c. click "Print QSL cards"

4. separate the cards (they're printed 4 to a sheet) with a paper cutter

5. insert each card into its SASE


### Were I printing labels instead of cards, my workflow would be

1. when a stack of incoming cards is available, use the Call filter to locate each QSO in the log and the CTRL-ALT-C keyboard short cut to mark it confirmed (if the info on the card matches the info in my log)

2. load the printer with 3-column label sheets

3. on the Main window's QSL tab,

3a. set the "QSL Via" panel to "3-column labels"

3b. click "Add Requested" to populate the QSL Queue with newly-confirmed QSOs

3c. specify the number of missing labels on the first label sheet

3d. click "Print QSL labels"

4. affix each label to a QSL card

5. insert each card into its SASE


### What's your workflow?

73,

Dave, AA6YQ




------------------------------------

Yahoo! Groups Links



Re: Label Counter

Dave AA6YQ
 

### AA6YQ

--- In dxlab@yahoogroups.com, "Jay" <PCB4U@...> wrote:

Dave

And that's another method I have used....refeed the sheet and use the "used"
count...but this extra process could be removed by a label counter telling
me how many are left for that one sheet (I only have a 1 sheet feed). Not
having to preview and then figure out how many more envelopes to pull (which
is a guess as I have no real idea how many Q's are in each
envelope...averaging 1-2) to finish the one label sheet would be great.

What I see as a possible addition, since I can only do one sheet at a time,
is a "view" into how many labels remain for that one sheet when I do an ADD
into the print queue. Feeding and re-feeding is extra time when dealing with
31K Q's so I do previews over this feed/refeed method.

The average DXer may not need this but a QSL manager could use as it helps
him to see what's going on versus having to check the print preview with a
boxes of envelopes next to him.

Just a suggestion.....
### I still don't understand what you need.

### My QSLing for 8P9RY involves fewer cards than your operation, but let me describe my workflow:

1. when a stack of incoming cards is available, use the Call filter to locate each QSO in the log and the CTRL-ALT-C keyboard short cut to mark it confirmed (if the info on the card matches the info in my log)

2. load the printer with card stock

3. on the Main window's QSL tab,

3a. set the "QSL Via" panel to "Cards"

3b. click "Add Requested" to populate the QSL Queue with newly-confirmed QSOs

3c. click "Print QSL cards"

4. separate the cards (they're printed 4 to a sheet) with a paper cutter

5. insert each card into its SASE


### Were I printing labels instead of cards, my workflow would be

1. when a stack of incoming cards is available, use the Call filter to locate each QSO in the log and the CTRL-ALT-C keyboard short cut to mark it confirmed (if the info on the card matches the info in my log)

2. load the printer with 3-column label sheets

3. on the Main window's QSL tab,

3a. set the "QSL Via" panel to "3-column labels"

3b. click "Add Requested" to populate the QSL Queue with newly-confirmed QSOs

3c. specify the number of missing labels on the first label sheet

3d. click "Print QSL labels"

4. affix each label to a QSL card

5. insert each card into its SASE


### What's your workflow?

73,

Dave, AA6YQ


Re: DXLab Sometimes Breaks Windows Task Switching

g4wjs
 

--- In dxlab@yahoogroups.com, Rich - W3ZJ <rich@...> wrote:

Closing the DXLab applications might free up enough CPU to allow your
machine to recover but that's a result of the problem, not likely the
cause of it.

The next time that happens to you try the following:

1) Open task manager (since the machine is unresponsive that might take
a while).
2) Click on the "Show processes from all users" button.
3) Click on the CPU heading once or twice to sort the list in descending
order by CPU usage.
4) See what process is chewing up most of your CPU

It might be task manager itself but we know that's overloaded so look
for the next one down the list. Chances are it will be something that
you don't know why it's there or what it's doing. There is a good chance
that it is part of your anti malware program that has become confused
and is beating up your machine. Search the Internet for a solution. You
are undoubtedly not the only one who has had the same problem and there
is a good chance you'll find a solution.
I think you are misunderstanding, I probably wasn't clear in my original post. The machine is not at all unresponsive in this case, task switching works instantaneously as normal but the switch just cycles around the windows of one of the DXLab applications that has two windows open. For example Commander or DXView. Also if it helps anyone diagnose this, it tries to switch to another task but seems to get rapidly switched back automatically to the original DXLab application. So for example I might see a flash of Spot Collector getting the focus, but it almost instantly jumps back to the application it is stuck on.


73, Rich - W3ZJ

Dave AA6YQ wrote:
AA6YQ comments below
-----Original Message-----
From: dxlab@yahoogroups.com [mailto:dxlab@yahoogroups.com]On Behalf Of
g4wjs
Sent: Wednesday, June 29, 2011 9:36 PM
To: dxlab@yahoogroups.com
Subject: [dxlab] DXLab Sometimes Breaks Windows Task Switching


Hi,

I notice that DXLab applications sort themselves in the active task list so
that Alt+TAB always goes to the next window for the application that has the
focus. I am finding that on a busy XP SP3 system sometimes this breaks the
system Alt+TAB task switching and I get stuck with only the windows of one
of the DXLab applications and cannot Alt+TAB to any other task. Also
sometimes the problem is even worse where the task bar itself becomes broken
and clicking items for tasks doesn't work. The problem has, so far, been
resolved by killing the active task and restarting it.


DXLab applications play no active role in determining their position on
the Windows task list; the "sorting" you mention above is accomplished by
Windows. If Alt+TAB is not functioning correctly on your system, that's most
likely due to a defect in Windows, perhaps exposed by a shortfall in needed
resources.

73,

Dave, AA6YQ


Regards
Bill
G4WJS.


Re: Label Counter

Jay <PCB4U@...>
 

Dave

And that's another method I have used....refeed the sheet and use the "used" count...but this extra process could be removed by a label counter telling me how many are left for that one sheet (I only have a 1 sheet feed). Not having to preview and then figure out how many more envelopes to pull (which is a guess as I have no real idea how many Q's are in each envelope...averaging 1-2) to finish the one label sheet would be great.

What I see as a possible addition, since I can only do one sheet at a time, is a "view" into how many labels remain for that one sheet when I do an ADD into the print queue. Feeding and re-feeding is extra time when dealing with 31K Q's so I do previews over this feed/refeed method.

The average DXer may not need this but a QSL manager could use as it helps him to see what's going on versus having to check the print preview with a boxes of envelopes next to him.

Just a suggestion.....

73
Jay

----- Original Message -----
From: "Dave" <aa6yq@ambersoft.com>
To: <dxlab@yahoogroups.com>
Sent: Thursday, June 30, 2011 1:26 PM
Subject: [dxlab] Re: Label Counter


+++ More AA6YQ comments below

--- In dxlab@yahoogroups.com, "Jay" <PCB4U@...> wrote:

Hi Dave

Not in my case...I would only request an indicator how many labels remain
unused per page. I have a HP1320 Laserjet and its a 1 page manual feed from
the front.

For a laserjet type printer I have read that its not wise to feed the labels
from the normal tray as the label sheet would have to go thru rollers and
change direction
and this could result in labels coming off within the printer. Thus its
advised to feed the sheet from the front and have it exit out the
rear...thus the label sheet moves straight thru the printer. Also multiple
sheets in a laserjet would really raise the temperature of the rollers and
all the internal "stuff" so I only do one sheet at a time, process those
envelopes and then start the next 30 labels allowing the printer to go thru
a cool down cycle. The labels sheet, when exiting, is quite warm.

If there were multiple sheets in a feeder I guess the code could track that
by how many "NEXT" occurrences there were in the print queue.

The software is slick now and does a great job for me. The indicator would
add a bit more efficiency in printing out the 1000's of labels I have to do.
+++ I don't understand what it is you are requesting. When printing a batch of labels, only one sheet ends up with unused labels (the last one), you can easily see how many unused labels remain on that sheet, and you won't need to specify this as a parameter till you use this partially-populated sheet as the first sheet of the next batch.

73,

Dave, AA6YQ




------------------------------------

Yahoo! Groups Links



Re: Label Counter

Dave AA6YQ
 

+++ More AA6YQ comments below

--- In dxlab@yahoogroups.com, "Jay" <PCB4U@...> wrote:

Hi Dave

Not in my case...I would only request an indicator how many labels remain
unused per page. I have a HP1320 Laserjet and its a 1 page manual feed from
the front.

For a laserjet type printer I have read that its not wise to feed the labels
from the normal tray as the label sheet would have to go thru rollers and
change direction
and this could result in labels coming off within the printer. Thus its
advised to feed the sheet from the front and have it exit out the
rear...thus the label sheet moves straight thru the printer. Also multiple
sheets in a laserjet would really raise the temperature of the rollers and
all the internal "stuff" so I only do one sheet at a time, process those
envelopes and then start the next 30 labels allowing the printer to go thru
a cool down cycle. The labels sheet, when exiting, is quite warm.

If there were multiple sheets in a feeder I guess the code could track that
by how many "NEXT" occurrences there were in the print queue.

The software is slick now and does a great job for me. The indicator would
add a bit more efficiency in printing out the 1000's of labels I have to do.
+++ I don't understand what it is you are requesting. When printing a batch of labels, only one sheet ends up with unused labels (the last one), you can easily see how many unused labels remain on that sheet, and you won't need to specify this as a parameter till you use this partially-populated sheet as the first sheet of the next batch.

73,

Dave, AA6YQ


Re: Label Counter

Jay <PCB4U@...>
 

Hi Dave

Not in my case...I would only request an indicator how many labels remain unused per page. I have a HP1320 Laserjet and its a 1 page manual feed from the front.

For a laserjet type printer I have read that its not wise to feed the labels from the normal tray as the label sheet would have to go thru rollers and change direction
and this could result in labels coming off within the printer. Thus its advised to feed the sheet from the front and have it exit out the rear...thus the label sheet moves straight thru the printer. Also multiple sheets in a laserjet would really raise the temperature of the rollers and all the internal "stuff" so I only do one sheet at a time, process those envelopes and then start the next 30 labels allowing the printer to go thru a cool down cycle. The labels sheet, when exiting, is quite warm.

If there were multiple sheets in a feeder I guess the code could track that by how many "NEXT" occurrences there were in the print queue.

The software is slick now and does a great job for me. The indicator would add a bit more efficiency in printing out the 1000's of labels I have to do.

73
Jay

----- Original Message -----
From: "Dave AA6YQ" <aa6yq@ambersoft.com>
To: <dxlab@yahoogroups.com>
Sent: Thursday, June 30, 2011 10:05 AM
Subject: RE: [dxlab] Label Counter


AA6YQ comments below
-----Original Message-----
From: dxlab@yahoogroups.com [mailto:dxlab@yahoogroups.com]On Behalf Of
Jay
Sent: Thursday, June 30, 2011 11:04 AM
To: dxlab@yahoogroups.com
Subject: [dxlab] Label Counter


I believe a label counter would be a nice feature.

As a QSL manager for T31A, I see that I have to preview the print queue to
see how many more labels I have on the Avery label sheet (5160). If the
setup knows the number of columns (it does) and how many rows (not sure but
assume it does), and knows if there any skipped used labels, a simple
subtraction routine could be performed and displayed in the QSL window.

Are you requesting a displayed count of the number of label sheets to be
placed in the printer?

73,

Dave, AA6YQ



------------------------------------

Yahoo! Groups Links



Re: DXLab Sometimes Breaks Windows Task Switching

Richard B Drake
 

Closing the DXLab applications might free up enough CPU to allow your machine to recover but that's a result of the problem, not likely the cause of it.

The next time that happens to you try the following:

1) Open task manager (since the machine is unresponsive that might take a while).
2) Click on the "Show processes from all users" button.
3) Click on the CPU heading once or twice to sort the list in descending order by CPU usage.
4) See what process is chewing up most of your CPU

It might be task manager itself but we know that's overloaded so look for the next one down the list. Chances are it will be something that you don't know why it's there or what it's doing. There is a good chance that it is part of your anti malware program that has become confused and is beating up your machine. Search the Internet for a solution. You are undoubtedly not the only one who has had the same problem and there is a good chance you'll find a solution.

73, Rich - W3ZJ

Dave AA6YQ wrote:

AA6YQ comments below
-----Original Message-----
From: dxlab@yahoogroups.com [mailto:dxlab@yahoogroups.com]On Behalf Of
g4wjs
Sent: Wednesday, June 29, 2011 9:36 PM
To: dxlab@yahoogroups.com
Subject: [dxlab] DXLab Sometimes Breaks Windows Task Switching


Hi,

I notice that DXLab applications sort themselves in the active task list so
that Alt+TAB always goes to the next window for the application that has the
focus. I am finding that on a busy XP SP3 system sometimes this breaks the
system Alt+TAB task switching and I get stuck with only the windows of one
of the DXLab applications and cannot Alt+TAB to any other task. Also
sometimes the problem is even worse where the task bar itself becomes broken
and clicking items for tasks doesn't work. The problem has, so far, been
resolved by killing the active task and restarting it.


DXLab applications play no active role in determining their position on
the Windows task list; the "sorting" you mention above is accomplished by
Windows. If Alt+TAB is not functioning correctly on your system, that's most
likely due to a defect in Windows, perhaps exposed by a shortfall in needed
resources.

73,

Dave, AA6YQ



Re: Keeper: Setting LOTW "S" and "V" status after the fact?

Dave AA6YQ
 

AA6YQ comments below
-----Original Message-----
From: dxlab@yahoogroups.com [mailto:dxlab@yahoogroups.com]On Behalf Of
Bert - W0RSB
Sent: Thursday, June 30, 2011 12:22 PM
To: dxlab@yahoogroups.com
Subject: [dxlab] Keeper: Setting LOTW "S" and "V" status after the fact?


I only recently starting using DXKeeper, so all my LOTW sent and received
entries are simply marked "Y"

I already have Mixed and CW DXCC, and Basic WAS, purely via LOTW, with the
submissions done via the ARRL LOTW Web site.

My understanding is that "S" means a contact has been submitted to ARRL for
consideration of an award and "V" means that ARRL has applied it toward an
award.

Correct.
Is there any way to get the "S" and "V" statuses applied to these contacts?

I've seen the same question posted earlier, but the replies were to the
effect that at the time there was no way to get that information from the
ARRL Web site.

However, I see that on the DXKeeper "Check Progress" tab, the DXCC "Compare"
function is able to at least see the "verified" status for many of these
contacts. But I still don't see any way to automatically transfer this
information to the log.

There is no way to automatically mark QSOs as submitted; only you know
the identity of these QSOs, and whether they were submitted as Card or LotW
credits. Thus you'll have to manually set the appropriate "QSL Rcvd" and
"LotW QSL Rcvd" items to 'S'. DXKeeper provides a "DXCC Submission
Generator" that automatically determines which confirmed-but-not-verified
QSO should be submitted to the DXCC desk based on your specified DXCC award
objectives, changes their "QSL Rcvd" and "LotW QSL Rcvd" items to 'S', and
prints the required paperwork. You'll be able to use this function to
generate future submission -- after DXKeeper is updated to reflect DXCC
credits already granted.

The ARRL does not currently provide a programmatic interface that would
allow applications like DXKeeper to download your DXCC award credits in the
same manner that such applications can now download your LotW confirmations.
However, one can log into the LotW web site and view one's DXCC credits as
web pages. An application could log in using your credentials, download
these web pages, extract the award information, and use it to update your
log to reflect credit granted. This process, affectionately referred to as
"screen scraping", is how DXKeeper's "DXCC Compare" function is able to
highlight discrepancies between the award credits shown in your log and the
award credits accessible via your LotW web page. Screen scraping is
notoriously fragile because the least little change to the web page format
can turn the extracted information into gibberish; I've already had to
update DXKeeper to deal with such a change that broke the "DXCC Compare"
function.

Alex VE3NEA has developed a standalone application called "DXCC Credit
Importer" that downloads DXCC credits from the ARRL and optionally updates a
DXKeeper log to reflect DXCC credits granted; it's available via

<http://www.dxatlas.com/Misc/DxCred.zip>

For a discussion of this application, see the thread that begins with
<http://groups.yahoo.com/group/dxlab/message/88758>

As discussed in that thread, I extended DXKeeper to provide this
capability in a more flexible manner. User testing of this extension
revealed that the "download all credits, analyze, and (if enabled) update"
usage model is too awkward. If you're pursuing DXCC Challenge, it can take
several hours to download all of your DXCC credits. These downloaded credits
will contain errors that don't affect your award status, but make it
difficult to unambiguously match the credits to logged QSOs -- e.g. an
incorrect callsign or date. So one would start by having DXKeeper simply
analyze the downloaded credits, highlighting errors and indicating what
changes would be made if updating were enabled. One might wish to run this
procedure in "analysis only" mode several times before finally authorizing
DXKeeper to update your log with the downloaded credits. Each of these runs
would require the lengthy re-downloading of DXCC credits -- which likely
have not changed (unless you contacted the DXCC desk to have them correct
substantive errors exposed by the analysis).

Based on the feedback from this first attempt, I have revised the
extension to operate in two steps:

1. download DXCC credits

2. analyze the downloaded credits, and optionally update logged QSOs to
reflect the downloaded credit

I am still thinking about how best to deal with errors that prevent
DXKeeper from unambiguously matching a downloaded DXCC credit with a logged
QSO; it would be nice to allow the user to simply correct the downloaded
credit (e.g. change the callsign or QSO date), but the downloaded credits
are currently saved as HTML files. I'm thinking of performing the
screen-scraping during the download process so that each DXCC credit is
saved as a simple, easy-to-edit text file that a user could correct. That
still leaves the issue of how to handle subsequent award credit downloads
without losing a user's previous corrections -- and without creating a
process so complex that few will attempt it.

Bottom line: you can try "DXCC Credit Importer" now; be sure to backup
your log in case you don't like the results. If "DXCC Credit Importer"
doesn't meet your needs, DXKeeper should eventually do so.

73,

Dave, AA6YQ





------------------------------------

Yahoo! Groups Links



-----
No virus found in this message.
Checked by AVG - www.avg.com
Version: 10.0.1388 / Virus Database: 1516/3735 - Release Date: 06/30/11


Re: Label Counter

Dave AA6YQ
 

AA6YQ comments below
-----Original Message-----
From: dxlab@yahoogroups.com [mailto:dxlab@yahoogroups.com]On Behalf Of
Jay
Sent: Thursday, June 30, 2011 11:04 AM
To: dxlab@yahoogroups.com
Subject: [dxlab] Label Counter


I believe a label counter would be a nice feature.

As a QSL manager for T31A, I see that I have to preview the print queue to
see how many more labels I have on the Avery label sheet (5160). If the
setup knows the number of columns (it does) and how many rows (not sure but
assume it does), and knows if there any skipped used labels, a simple
subtraction routine could be performed and displayed in the QSL window.

Are you requesting a displayed count of the number of label sheets to be
placed in the printer?

73,

Dave, AA6YQ


PropView feature request

Peter
 

Dave,

by and large, dxlab offers more than I can ever hope to use as a casual non-competitive dxer, who is not after awards. On the reflector, I´m more of a lurker, meaning that everything works just splendidly! Thanks!

Therefore I feel reluctant about "request". To me, that word sounds so demanding. Anyway:

With conds changing for the better, I find myself listening more frequently to the NCDXF/IARU beacons and would like to compare what I hear with propagation predictions.

1)Propview plots the monitored beacon on DXView´s map. Would it be possible also to show a prediction for that beacon? (Much in the same way that clicking a spot can evoke a prediction.)

2) Also, is there any chance that Propview automatically updates the beacon status from the NCDXF/IARU beacon website?

TNX, GL, 73, Peter


Keeper: Setting LOTW "S" and "V" status after the fact?

Bert Hyman
 

I only recently starting using DXKeeper, so all my LOTW sent and received entries are simply marked "Y"

I already have Mixed and CW DXCC, and Basic WAS, purely via LOTW, with the submissions done via the ARRL LOTW Web site.

My understanding is that "S" means a contact has been submitted to ARRL for consideration of an award and "V" means that ARRL has applied it toward an award.

Is there any way to get the "S" and "V" statuses applied to these contacts?

I've seen the same question posted earlier, but the replies were to the effect that at the time there was no way to get that information from the ARRL Web site.

However, I see that on the DXKeeper "Check Progress" tab, the DXCC "Compare" function is able to at least see the "verified" status for many of these contacts. But I still don't see any way to automatically transfer this information to the log.


Label Counter

Jay <PCB4U@...>
 

I believe a label counter would be a nice feature.

As a QSL manager for T31A, I see that I have to preview the print queue to see how many more labels I have on the Avery label sheet (5160). If the setup knows the number of columns (it does) and how many rows (not sure but assume it does), and knows if there any skipped used labels, a simple subtraction routine could be performed and displayed in the QSL window.

Jay
W2IJ


Re: New Callbook www.hamQTH.com Error

Earl Needham
 

Mine is off a little, looks like it might be using the middle of the zip
code or something similar.

Vy 7 3
Earl
KD5XB

On Wed, Jun 29, 2011 at 7:49 PM, DANNY DOUGLAS <n7dc@comcast.net> wrote:

**


Mine was off fm08w? instead of fm08wk, that is about 3 miles away, and if
he is using postoffice location (zip code) Im in the next county from mine.,
and have found that on several instances. I dont know if any data base
actually is 100 percent right? I changed mine in his data base., and believe
I had to do that in QRZ.com or another database as well.
Danny Douglas
N7DC
ex WN5QMX ET2US WA5UKR ET3USA SV0WPP VS6DD N7DC/YV5 G5CTB
All 2 years or more (except Novice). Short stints at: DA/PA/SU/HZ/7X/DU
CR9/7Y/KH7/5A/GW/GM/F
Pls QSL direct, buro, or LOTW preferred,
I Do not use, but as a courtesy do upload to eQSL for those who do.
Moderator
DXandTALK
http://groups.yahoo.com/group/DXandTalk
Digital_modes
http://groups.yahoo.com/group/digital_modes/?yguid=341090159


----- Original Message -----
From: Bob Craig
To: dxlab@yahoogroups.com
Sent: Wednesday, June 29, 2011 9:24 PM
Subject: [dxlab] RE: New Callbook www.hamQTH.com Error

Just a heads up:

Every lookup I've done so far has the wrong gridsquare displayed.

My call displays with the GS which is one block north of may actual
location.
Others are 1-2-3 squares off. Some north; some south.

73,
Bob K8RC







[Non-text portions of this message have been removed]


Re: Question about Icom USB interface

Bill, W6WRT <dezrat1242@...>
 

ORIGINAL MESSAGE:

On Thu, 30 Jun 2011 02:22:53 -0400, "Dave AA6YQ" <aa6yq@ambersoft.com> wrote:


So far, the only ways I've found to check whether an already-opened
serial port is still present is by checking the Windows Registry, or by
closing and then attempting to re-open it. I'm reluctant to have Commander
do either of these each time its about to send a "polling" command to the
transceiver.
REPLY:

Thanks, Dave and Gary (AB9M). I was hoping there would be an easy fix, but I
guess I can live with it as is. I just have to remember - turn off the radio
last.

73, Bill W6WRT

112121 - 112140 of 205894