Date   

Re: Filters/Reports

Dave, AA6YQ <dhb@...>
 

Great, Rich. If I'm not mistaken, you can save your queries for later
re-use.

73,

Dave, AA6YQ

-----Original Message-----
From: Richard B. Drake [mailto:rich@...]
Sent: Saturday, December 29, 2001 11:20 AM
To: dxlab@...
Subject: RE: [dxlab] Filters/Reports


> you can use Excel 2000's Data:GetExternalData:NewDatabaseQuery
> command to create a spreadsheet from a query on your log. You'll need MS
> Query, which shows up on the Office 2000 setup under "Add-ins".

Wow! It took about 2 minutes to install the Add-Ins (ODBC and MS-Query)
and
another two minutes to construct a Query that gave me just what I wanted.
I'm sure it's doing an SQL Query but it has a set of very easy to use
interactive dialogs for setting up a Query. No knowledge of SQL needed to
use it. Thanks for the tip.

----
73, Rich - W3ZJ



Yahoo! Groups Sponsor
ADVERTISEMENT




To unsubscribe from this group, send an email to:
dxlab-unsubscribe@...



Your use of Yahoo! Groups is subject to the Yahoo! Terms of Service.


Re: Filters/Reports

Richard B Drake
 

you can use Excel 2000's Data:GetExternalData:NewDatabaseQuery
command to create a spreadsheet from a query on your log. You'll need MS
Query, which shows up on the Office 2000 setup under "Add-ins".
Wow! It took about 2 minutes to install the Add-Ins (ODBC and MS-Query) and
another two minutes to construct a Query that gave me just what I wanted.
I'm sure it's doing an SQL Query but it has a set of very easy to use
interactive dialogs for setting up a Query. No knowledge of SQL needed to
use it. Thanks for the tip.

----
73, Rich - W3ZJ


Re: Filters/Reports

Richard B Drake
 

Dave,

Your plan for replacing the Broke button with an Advanced button, sounds
right on target to me.

I agree that SQL queries would require users to have some basic knowledge of
SQL. But basic SQL queries are pretty intuitive and there are a plethora of
books available on the topic. With a couple hours reading a semi-skilled
user would find himself able to do some pretty amazing things with his data.

I wasn't aware of the MS Query add in for Excel 2000 but am indeed about to
find out about it :-)

----
73, Rich - W3ZJ

-----Original Message-----
From: Dave, AA6YQ [mailto:dhb@...]
Sent: Saturday, December 29, 2001 2:57 AM
To: dxlab@...
Subject: RE: [dxlab] Filters/Reports

[Snip]
Using the Log report as a way of exporting to Excel to get
filtering beyond
DXKeeper's present capabilities is clever, but indicates a gap in
functionality. The only real challenge in adding additional filtering
capabilities -- including an ad hoc SQL query -- is finding room in the
Window for the command buttons. I propose to do this by replacing the
current "Broke" filter command button with a button captioned "Advanced".
Clicking the "Advanced" filter button would display a window full of
additional filter commands, including the "Broke" and the ad hoc
SQL query.
I'd probably implement the ad hoc query first, since it permits
everything,
and then later add a user interface that supports the composition
of useful
queries without requiring knowledge of SQL.. Comments on this approach,
and/or suggested alternatives would be greatly appreciated.

Since DXKeeper's log database files are compatible with the
Microsoft Access
database, you can use Excel 2000's Data:GetExternalData:NewDatabaseQuery
command to create a spreadsheet from a query on your log. You'll need MS
Query, which shows up on the Office 2000 setup under "Add-ins". If you
happen to have MS Access, you can view and query your log database files
directly; just be careful if you attempt to modify anything.

73 and Happy New Year...


DXKeeper 1.3.9 is available

Dave, AA6YQ <dhb@...>
 

This release

- corrects several defects in generated Log Reports (see earlier message
on this topic)

- creates ARRL (DXCC) QSL card submission reports that include 17m and
12m

- properly advises you to submit a received QSL card to the ARRL (DXCC),
by considering

- whether the band and mode are in fact verified by the ARRL's DXCC
desk

- whether or not verification is required to meet you awards
objectives

- whether or not the band and mode have already been verified


To upgrade, follow the instructions in
http://www.qsl.net/dxkeeper/upgrade.htm -- you'll be downloading
www.qsl.net/dxkeeper/DXKeeper139Update.exe .

73,

Dave, AA6YQ


Re: Filters/Reports

Dave, AA6YQ <dhb@...>
 

The log report, generated by clicking the Report button on the Log QSOs tab,
was in pretty sad shape. It was intended to print the contents of the Log
Page Display, meaning all QSOs "surviving" the current filter and the subset
of fields that appear in the Log Page Display. One defect resulted in only
the first few fields being included. Another defect resulted in extremely
poor performance. In the forthcoming version 1.3.9, I have corrected these
defects, and added both a progress indicator and the ability to abort the
operation -- generating a report containing thousands of QSOs still takes
awhile. So if you want a report that includes the Power, add the TX_Power
field to the Log Page Display (as described in the online help) and then
click the Report button.

Using the Log report as a way of exporting to Excel to get filtering beyond
DXKeeper's present capabilities is clever, but indicates a gap in
functionality. The only real challenge in adding additional filtering
capabilities -- including an ad hoc SQL query -- is finding room in the
Window for the command buttons. I propose to do this by replacing the
current "Broke" filter command button with a button captioned "Advanced".
Clicking the "Advanced" filter button would display a window full of
additional filter commands, including the "Broke" and the ad hoc SQL query.
I'd probably implement the ad hoc query first, since it permits everything,
and then later add a user interface that supports the composition of useful
queries without requiring knowledge of SQL.. Comments on this approach,
and/or suggested alternatives would be greatly appreciated.

Since DXKeeper's log database files are compatible with the Microsoft Access
database, you can use Excel 2000's Data:GetExternalData:NewDatabaseQuery
command to create a spreadsheet from a query on your log. You'll need MS
Query, which shows up on the Office 2000 setup under "Add-ins". If you
happen to have MS Access, you can view and query your log database files
directly; just be careful if you attempt to modify anything.

73 and Happy New Year...

Dave, AA6YQ

-----Original Message-----
From: Richard B. Drake [mailto:rich@...]
Sent: Friday, December 28, 2001 23:02 PM
To: dxlab@...
Subject: [dxlab] Filters/Reports


Dave,

I have found that I want some more filters than DXKeeper currently offers.
For example, I sometimes operate with 500 watts, sometimes 100 watts and
sometimes 5 watts. I would like to be able to filter on the power field to
single out the 5 watt QSO's for QRP awards. I would also like to filter on
mode so I can single out PSK QSO's for 070 club awards. I figured that if
I
generated a report of my log I could import it to Excel and filter with
that. My log page is showing the fields: Call, DXCC, Starting UTC, Band,
Mode, Name, QSL_Snt, RST_Snt, RST_Rcvd and Power. However when I generated
a
report, all it showed was : Call, DXCC, Starting UTC and Band. The fields
I
want to filter on are missing. Why isn't the report showing all of the
fields in my log page? Bye the way, it would be really neat if we could
filter using ad hoc sql strings, then anyone could have it any way they
want
it :-)

----
73, Rich - W3ZJ



Yahoo! Groups Sponsor



To unsubscribe from this group, send an email to:
dxlab-unsubscribe@...



Your use of Yahoo! Groups is subject to the Yahoo! Terms of Service.


Filters/Reports

Richard B Drake
 

Dave,

I have found that I want some more filters than DXKeeper currently offers.
For example, I sometimes operate with 500 watts, sometimes 100 watts and
sometimes 5 watts. I would like to be able to filter on the power field to
single out the 5 watt QSO's for QRP awards. I would also like to filter on
mode so I can single out PSK QSO's for 070 club awards. I figured that if I
generated a report of my log I could import it to Excel and filter with
that. My log page is showing the fields: Call, DXCC, Starting UTC, Band,
Mode, Name, QSL_Snt, RST_Snt, RST_Rcvd and Power. However when I generated a
report, all it showed was : Call, DXCC, Starting UTC and Band. The fields I
want to filter on are missing. Why isn't the report showing all of the
fields in my log page? Bye the way, it would be really neat if we could
filter using ad hoc sql strings, then anyone could have it any way they want
it :-)

----
73, Rich - W3ZJ


FW: allowing multiple Windows applications to share one serial port

Bill Vodall WA7NWP <wa7nwp@...>
 

There'd be
technical arguments (DDE vs. COM vs. something that would work with
Linux),
And some would say it should be TCP/IP sockets that would work
universally between applications. Much APRS and also SV2AGW software
already provides ports for additional applications to connect to.

73,
Bill - WA7NWP


FW: allowing multiple Windows applications to share one serial port

Dave, AA6YQ <dhb@...>
 

-----Original Message-----
From: Dave, AA6YQ [mailto:dhb@...]
Sent: Monday, December 24, 2001 20:19 PM
To: Gabriella & Fabrizio
Cc: dxlab@yahoogroups; Moe AE4JY
Subject: RE: allowing multiple Windows applications to share one serial
port


I didn't know about the UART trick, Fab -- very clever. Unfortunately, these
sorts of things don't often survive major platform releases.

Both PSKCORE and the MTTY engine use windows messsages for interapplication
communication. While this works ok, it generates overhead -- the message
handler has to dispatch *every* windows message that goes by, even though
most are irrelevant. And in Visual Basic, an exception or a breakpoint while
the message handler is active will crash everything; the former can be
mitigated by adding exception handlers to every procedure, but the latter
makes debugging both slow and painful. So if the choice is DDE or windows
messages, I'd prefer the former.

73,

Dave, AA6YQ

-----Original Message-----
From: Gabriella & Fabrizio [mailto:rac2610@...]
Sent: Monday, December 24, 2001 19:20 PM
To: Dave, AA6YQ
Subject: Re: allowing multiple Windows applications to share one serial
port


Dear Dave,

I can bring some results of my experience but I know it won't help
much in this case.
In windows 95/98, more than one application could use the same port
by writing bytes to the UART's I/O address.
I use this technique to pass DX spots from DXTelnet to any
terminal programme:
The terminal programme (say Hyperterminal) opens the serial port
and initializes it.
DXTelnet writes bytes to the UART's I/O address of the SAME port
(say, Hyperterminal on COM1 and DXtelnet writes on &H3F8)
A dummy connector, on that port, has pins 2-3 shorted together.
DXTelnet writes to UART, UART serializes and the terminal
programme receives at initialized data speed.
With this trick I pass data to any log with serial port control,
without changes in the source code of the log, and it never locks.
A slightly different method works in DOS:
I had to make a TSR to accomplish this:
DXtelnet passes data to the DOS TSR (via file) the DOS TSR writes
on UART's I/O ad, the UART serializes, the dummy connector
bridges TX to RX and CT receives in the same DOS shell of the TSR.
Incredible to say, this works flawlessly on Win 95/98.

Drawbacks:
Link is one way (DXT > Terminal)
This does not work with Win NT 2K, XP.

I like the idea of using DDE to negotiate a unique port sharing
controlled by a server.
Another technique could be using sendmessage with WM_COPYDATA
instead of DDE.
In this case the master application needs to know slave applications'
windows' names and classes.
You are right, developing such a server would be useful only
if software developers used it.

Dave, you can post this on the reflector if you wish.
Ciao
Merry XMas and HNY 2002 de Fabrizio (IK4VYX)

To address the original problem, we need a simple server application that
uses DDE to interact with its clients -- other applications wishing to send
and receive data via one serial port. To use the serial port server, a
client application would be required to first register via a DDE message;
the serial port server would send all data received from the serial port to
all registered client applications. When a client application wishes to
send
a message to the serial port, it would send the message via DDE to the
serial port server, which would transmit it via the serial port on behalf
of
the client; by requiring clients to present the entire outgoing message to
the server (rather than dribble it out a few bytes at a time), we enable
the
server to ensure that outgoing messages originated by different clients
never collide or interdigitate.

To use the serial port server, the author of a client application would
have
to replace serial port operations (e.g. open, read, write, close) with DDE
interactions. For some applications, this would be very straightforward.
Those applications that previously dribbled out the transmitted bytes would
have to add buffering in order to present a complete message before
transmitting.

Implementing the serial port server is a straightforward task. But the
serial port server is worthless unless applications use it; persuading a
critical mass of commercial, shareware, and freeware developers to adopt
such a standard is far more daunting than implementing it. There'd be
technical arguments (DDE vs. COM vs. something that would work with Linux),
but inertia would be the biggest challenge: no one likes to invest their
scarce development cycles to "go sideways".

Note that the serial port server does not interpret or add value to the
bytes it sends and receives to the serial port. Thus every client
application must contain sufficient knowledge of transceiver control to
accomplish its tasks. In a suite like DXLab, this redundancy would be
unmanageable -- thus I would modify Commander to use the serial port server
for interacting with the transceiver being controlled, but continue to have
the other DXLab applications (SpotCollector, DXView, etc) rely on Commander
to satisfy their transceiver control needs. This would not prevent the user
from choosing other transceiver control or logging programs (as long as
they
use the serial port server).

It seems conceptually possible to create a higher-level transceiver server.
Whereas the serial port server described above handles operations like
"transmit these 18 bytes", a transceiver server would handle operations
like
"Set VFO A to 14100.00" or "send me a message whenever the transceiver's
frequency changes". The transceiver server would have to support the union
of all transceiver capabilities, providing a single unified programming
model upon which any number of applications could be built; newly released
transceivers with new capabilities might require a new release of the
transceiver server, but this would be implemented and tested once, rather
than independently in many different applications as is the case today. The
transceiver server would have no user interface; many alternative user
interfaces could be constructed using the transceiver server's
facilities --
some providing the basics in a small window (like Commander), others
providing an all-out replacement of the radio's front panel. A transceiver
server is more challenging to implement, but ongoing maintenance as new
transceivers are introduced would require ongoing effort from some
responsible group. Setting this up, and getting the
commericial/shareware/freeware community onboard would make the analogous
serial port server effort look trivial.

Dave WA0TTN has a project called RigX that may be moving in this direction;
see http://www.netdave.com/wa0ttn/RigX.asp for more information.

73,

Dave, AA6YQ


Re: Date format

Chris BONDE <ve7hcb@...>
 

At 11:57 PM 2001-12-24 +0000, you wrote:
Hi Guys
Will the date format in Logger 32 be multi choice????? just asking!!!! Christmas day has started in typical fashion here. . . . . with rain.
Take care all and 'have a nice day'.
Jim - M0ZAK
What is rain in December?

I have a few comments about "time" format. That is the fromat that include the popular date and time comment. I think that HAMs should be forward looking a promont the decending format of time recording. ie CCYYMMDDHHMMSS where CC equal century 20 YY equals year 01 MM equals month 12 (or some DE) DD equals day 24, HH equals hour 00 and MM equals minute 30 (seconds etc may be added, Therefore now is 2001 1224 0031, with or without the blanks.

Just my humble opinion

Chris opr VE7HCB


Date format

Jim Steel <jim.steel@...>
 

Hi Guys
Will the date format in Logger 32 be multi choice????? just asking!!!! Christmas day has started in typical fashion here. . . . . with rain.
Take care all and 'have a nice day'.
Jim - M0ZAK


allowing multiple Windows applications to share one serial port

Dave, AA6YQ <dhb@...>
 

To address the original problem, we need a simple server application that
uses DDE to interact with its clients -- other applications wishing to send
and receive data via one serial port. To use the serial port server, a
client application would be required to first register via a DDE message;
the serial port server would send all data received from the serial port to
all registered client applications. When a client application wishes to send
a message to the serial port, it would send the message via DDE to the
serial port server, which would transmit it via the serial port on behalf of
the client; by requiring clients to present the entire outgoing message to
the server (rather than dribble it out a few bytes at a time), we enable the
server to ensure that outgoing messages originated by different clients
never collide or interdigitate.

To use the serial port server, the author of a client application would have
to replace serial port operations (e.g. open, read, write, close) with DDE
interactions. For some applications, this would be very straightforward.
Those applications that previously dribbled out the transmitted bytes would
have to add buffering in order to present a complete message before
transmitting.

Implementing the serial port server is a straightforward task. But the
serial port server is worthless unless applications use it; persuading a
critical mass of commercial, shareware, and freeware developers to adopt
such a standard is far more daunting than implementing it. There'd be
technical arguments (DDE vs. COM vs. something that would work with Linux),
but inertia would be the biggest challenge: no one likes to invest their
scarce development cycles to "go sideways".

Note that the serial port server does not interpret or add value to the
bytes it sends and receives to the serial port. Thus every client
application must contain sufficient knowledge of transceiver control to
accomplish its tasks. In a suite like DXLab, this redundancy would be
unmanageable -- thus I would modify Commander to use the serial port server
for interacting with the transceiver being controlled, but continue to have
the other DXLab applications (SpotCollector, DXView, etc) rely on Commander
to satisfy their transceiver control needs. This would not prevent the user
from choosing other transceiver control or logging programs (as long as they
use the serial port server).

It seems conceptually possible to create a higher-level transceiver server.
Whereas the serial port server described above handles operations like
"transmit these 18 bytes", a transceiver server would handle operations like
"Set VFO A to 14100.00" or "send me a message whenever the transceiver's
frequency changes". The transceiver server would have to support the union
of all transceiver capabilities, providing a single unified programming
model upon which any number of applications could be built; newly released
transceivers with new capabilities might require a new release of the
transceiver server, but this would be implemented and tested once, rather
than independently in many different applications as is the case today. The
transceiver server would have no user interface; many alternative user
interfaces could be constructed using the transceiver server's facilities --
some providing the basics in a small window (like Commander), others
providing an all-out replacement of the radio's front panel. A transceiver
server is more challenging to implement, but ongoing maintenance as new
transceivers are introduced would require ongoing effort from some
responsible group. Setting this up, and getting the
commericial/shareware/freeware community onboard would make the analogous
serial port server effort look trivial.

Dave WA0TTN has a project called RigX that may be moving in this direction;
see http://www.netdave.com/wa0ttn/RigX.asp for more information.

73,

Dave, AA6YQ

-----Original Message-----
From: Richard B. Drake [mailto:rich@...]
Sent: Sunday, December 23, 2001 21:21 PM
To: dxlab@...
Subject: RE: [dxlab] RE: [1000mp] MpFilters and Mpcw4Win Updates


I think this was the original question:

>
> What we need is some program that abritrates asynchronous
> communications from two separate programs and acts
> as a traffic cop to pass traffic between the one radio and two
> separate COM ports (for two different programs).
> Any such beast out there?
>

The answer is no, and there is not likely to be one in the foreseeable
future because of the rather complex issues that Dave and I have been
batting around here.

What might work however, is if we could get the authors of these rig
control
applications, such as Simon Brown who has developed a terrific (free)
FT-817
commander and Dave Bernstein to talk with one another we might be able to
get them to agree on a communications protocol and implement a DDE link
between the applications such that we could use the fancy dancy commanders
in place of CI-V commander and in conjunction with the rest of the DXLab
suite. That would be one killer application for the rigs that have these
full function commanders. Not knocking CI-V commander Dave it does a good
job of basic frequency/mode/split control. But these things really control
the rigs to the n'th degree including display of meter functions, filter
control, memory control, you name it, if can possibly be read or
controlled,
it is.

Dave, I mentioned this thought to Simon and he didn't reply so I can only
assume that he wasn't overly enthusiastic about the idea. But, to me it's
in
the same vein that you have implemented PSK using Moe Wheatly's
pskcore.dll
and MMTTY using JE3HHT's RTTY engine. You didn't have to reinvent the
wheel
to implement these things. Perhaps if you approached Simon with an offer
of
collaboration the response might be different.

----
73, Rich - W3ZJ


Re: DX Central

Richard B Drake
 

Yes DX Central seems to be dead here also. K4UGA is fine though and seems to
be connected to the same network and provides the same spots. IP:
128.192.52.40 Port: 599.

73, Rich - W3ZJ

-----Original Message-----
From: Dave, AA6YQ [mailto:dhb@...]
Sent: Monday, December 24, 2001 12:35 AM
To: dxlab@...
Subject: RE: [dxlab] DX Central


DX Central is dead from here too.

73,

Dave, AA6YQ

-----Original Message-----
From: Mike & Lara Pagel [mailto:mpagel@...]
Sent: Monday, December 24, 2001 0:11 AM
To: dxlab@...
Subject: [dxlab] DX Central


Anyone else having trouble with SpotCollector connecting to DX Central?

I altered the port number per Dave's message on December 4. Had
no trouble
till this evening.

Happy holidays to all.

73, de Mike, K9UW
Amherst, WI



To unsubscribe from this group, send an email to:
dxlab-unsubscribe@...



Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/




To unsubscribe from this group, send an email to:
dxlab-unsubscribe@...



Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/



Re: DX Central

Dave, AA6YQ <dhb@...>
 

DX Central is dead from here too.

73,

Dave, AA6YQ

-----Original Message-----
From: Mike & Lara Pagel [mailto:mpagel@...]
Sent: Monday, December 24, 2001 0:11 AM
To: dxlab@...
Subject: [dxlab] DX Central


Anyone else having trouble with SpotCollector connecting to DX Central?

I altered the port number per Dave's message on December 4. Had no trouble
till this evening.

Happy holidays to all.

73, de Mike, K9UW
Amherst, WI



To unsubscribe from this group, send an email to:
dxlab-unsubscribe@...



Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/


DX Central

Mike & Lara Pagel <mpagel@...>
 

Anyone else having trouble with SpotCollector connecting to DX Central?

I altered the port number per Dave's message on December 4. Had no trouble
till this evening.

Happy holidays to all.

73, de Mike, K9UW
Amherst, WI


Re: [1000mp] MpFilters and Mpcw4Win Updates

Richard B Drake
 

I think this was the original question:


What we need is some program that abritrates asynchronous
communications from two separate programs and acts
as a traffic cop to pass traffic between the one radio and two
separate COM ports (for two different programs).
Any such beast out there?
The answer is no, and there is not likely to be one in the foreseeable
future because of the rather complex issues that Dave and I have been
batting around here.

What might work however, is if we could get the authors of these rig control
applications, such as Simon Brown who has developed a terrific (free) FT-817
commander and Dave Bernstein to talk with one another we might be able to
get them to agree on a communications protocol and implement a DDE link
between the applications such that we could use the fancy dancy commanders
in place of CI-V commander and in conjunction with the rest of the DXLab
suite. That would be one killer application for the rigs that have these
full function commanders. Not knocking CI-V commander Dave it does a good
job of basic frequency/mode/split control. But these things really control
the rigs to the n'th degree including display of meter functions, filter
control, memory control, you name it, if can possibly be read or controlled,
it is.

Dave, I mentioned this thought to Simon and he didn't reply so I can only
assume that he wasn't overly enthusiastic about the idea. But, to me it's in
the same vein that you have implemented PSK using Moe Wheatly's pskcore.dll
and MMTTY using JE3HHT's RTTY engine. You didn't have to reinvent the wheel
to implement these things. Perhaps if you approached Simon with an offer of
collaboration the response might be different.

----
73, Rich - W3ZJ


Re: [1000mp] MpFilters and Mpcw4Win Updates

Dave, AA6YQ <dhb@...>
 

I assumed that the constraint was "must work with existing applications
without modification". One could develop a new driver that supporta 4
virtual COM ports -- say COM5 through COM8. These ports would look to an
application just like a COM port. Data sent to one of these ports would be
buffered (to assemble a complete message) and then transmitted via a real
COM port to the transceiver; it may not be possible to implement this
reliably, since there is no indication of when a message is complete, and
getting it wrong could result in messages from two different applications
being interdigitated. Data received from the transceiver would be sent to
each application through the virtual COM ports.

If we don't have to live with the "no modifications " constraint, then there
are many ways to solve the problem -- but getting everyone to modify their
software to a common standard seems challenging, to put it mildly.

73,

Dave, AA6YQ

-----Original Message-----
From: Richard B. Drake [mailto:rich@...]
Sent: Sunday, December 23, 2001 17:27 PM
To: dxlab@...
Subject: RE: [dxlab] RE: [1000mp] MpFilters and Mpcw4Win Updates


Dave,

I would think it would have to be done similar to the way the TCP/IP stack
works. I.E.: One background application (a stack manager) has control of
the
COM port. Multiple foreground applications can place messages on and
retrieve messages directed to them from the stack. It would require a
complete revision of the way most of our current ham applications deal
with
COM ports.

----
73, Rich - W3ZJ


> -----Original Message-----
> From: Dave, AA6YQ [mailto:dhb@...]
> Sent: Sunday, December 23, 2001 12:00 PM
> To: 1000mp@...
> Cc: dxlab@...
> Subject: [dxlab] RE: [1000mp] MpFilters and Mpcw4Win Updates
>
>
> I won't say that its impossible to multiplex a COM port among two
separate
> Windows applications, but it would certainly involve some serious
> low-level
> programming. It would be easier to do this with a dedicated
microprocessor
> (a BasicStamp or an 8051) that performed the appropriate buffering and
> routing externally. Each application would require a dedicated
> COM port, but
> all would have direct access to the transceiver.
>
> In DXLab I took a different approach. I created one application
> (Commander)
> to provide transceiver control, but set it up to serve as a "transceiver
> control server" for the other DXLab applications such as DXKeeper
(logging
> and QSL card/label generation), WinWarbler (soundcard PSK31 and RTTY),
and
> SpotCollector (realtime telnet/IRC DX spot collection and analysis).
These
> applications all interoperate by exchanging messages using a standard
> Windows protocol known as DDE; thus, exactly one COM port can handle all
> transceiver interactions (unless you're using FSK rather than
> AFSK for RTTY
> transmission, in which case a second port is required for an FSK
> interface).
>
> The most recent development release of Commander -- version 3.1.8 --
> displays and provides direct control of MP1000 and MP1000 Mark V
filters.
> Over the next weeek, I'll be extending this to support user-defined
Filter
> Groups. You might create a Group named "DXing" that looks like this:
>
> 2nd IF 3rd IF Sub
>
> SSB 1800 1800 2400
> CW 250 250 500
> RTTY 500 500 500
>
> or a group named "RagChewing" that looks like this:
>
>
> 2nd IF 3rd IF Sub
>
> SSB 2400 2400 2400
> CW 500 500 500
> RTTY 500 500 500
>
> Switching between Filter Groups will be accomplished via a single
> pull-down
> control.
>
> All DXLab applications are free; they're available via www.qsl.net/dxlab
.
>
> 73,
>
> Dave, AA6YQ
>
> -----Original Message-----
> From: 1000mp-admin@...
> [mailto:1000mp-admin@...]On Behalf Of Tom Rohlfing
> Sent: Sunday, December 23, 2001 10:51 AM
> To: 1000mp@...
> Subject: Re: [1000mp] MpFilters and Mpcw4Win Updates
>
>
> Question for the group:
>
> I see lots of cool computer programs that do good things with the
> MP -- rig
> control programs, S-meter reading programs, memory control programs,
etc.
> etc.
>
> But I never use any of them for one simple reason: my logging program
> (Logger) uses the radio's CAT control connector to get band,
> frequency, and
> mode information from the radio. I really like this feature, and so I
> always leave the logging program active, and it therefore eats up the
COM
> port that the radio is connected to. If I try to run some other
> program to
> connect to the radio, the first thing it does is ask for the COM port
> number, and of course that fails because the radio's COM port (COM1) is
> already busy, and can't be connected with.
>
> So, is this just a fundamental limitation, or is there some way around
it?
> Do I really have to decide what ONE program I want to use to communicate
> with my MP? Or is there some clever way to have two programs actively
> sharing communications with the MP?
>
> I hope this question makes sense. What we need is some program that
> abritrates asynchronous communications from two separate programs and
acts
> as a traffic cop to pass traffic between the one radio and two
> separate COM
> ports (for two different programs). Any such beast out there?
>
> 73,
> Tom / W7GT
>
> _______________________________________________
> 1000mp mailing list
> 1000mp@...
> http://mailman.qth.net/mailman/listinfo/1000mp
>
>
>
> To unsubscribe from this group, send an email to:
> dxlab-unsubscribe@...
>
>
>
> Your use of Yahoo! Groups is subject to
http://docs.yahoo.com/info/terms/
>
>
>



Yahoo! Groups Sponsor
ADVERTISEMENT




To unsubscribe from this group, send an email to:
dxlab-unsubscribe@...



Your use of Yahoo! Groups is subject to the Yahoo! Terms of Service.


Re: [1000mp] MpFilters and Mpcw4Win Updates

Richard B Drake
 

Dave,

I would think it would have to be done similar to the way the TCP/IP stack
works. I.E.: One background application (a stack manager) has control of the
COM port. Multiple foreground applications can place messages on and
retrieve messages directed to them from the stack. It would require a
complete revision of the way most of our current ham applications deal with
COM ports.

----
73, Rich - W3ZJ

-----Original Message-----
From: Dave, AA6YQ [mailto:dhb@...]
Sent: Sunday, December 23, 2001 12:00 PM
To: 1000mp@...
Cc: dxlab@...
Subject: [dxlab] RE: [1000mp] MpFilters and Mpcw4Win Updates


I won't say that its impossible to multiplex a COM port among two separate
Windows applications, but it would certainly involve some serious
low-level
programming. It would be easier to do this with a dedicated microprocessor
(a BasicStamp or an 8051) that performed the appropriate buffering and
routing externally. Each application would require a dedicated
COM port, but
all would have direct access to the transceiver.

In DXLab I took a different approach. I created one application
(Commander)
to provide transceiver control, but set it up to serve as a "transceiver
control server" for the other DXLab applications such as DXKeeper (logging
and QSL card/label generation), WinWarbler (soundcard PSK31 and RTTY), and
SpotCollector (realtime telnet/IRC DX spot collection and analysis). These
applications all interoperate by exchanging messages using a standard
Windows protocol known as DDE; thus, exactly one COM port can handle all
transceiver interactions (unless you're using FSK rather than
AFSK for RTTY
transmission, in which case a second port is required for an FSK
interface).

The most recent development release of Commander -- version 3.1.8 --
displays and provides direct control of MP1000 and MP1000 Mark V filters.
Over the next weeek, I'll be extending this to support user-defined Filter
Groups. You might create a Group named "DXing" that looks like this:

2nd IF 3rd IF Sub

SSB 1800 1800 2400
CW 250 250 500
RTTY 500 500 500

or a group named "RagChewing" that looks like this:


2nd IF 3rd IF Sub

SSB 2400 2400 2400
CW 500 500 500
RTTY 500 500 500

Switching between Filter Groups will be accomplished via a single
pull-down
control.

All DXLab applications are free; they're available via www.qsl.net/dxlab .

73,

Dave, AA6YQ

-----Original Message-----
From: 1000mp-admin@...
[mailto:1000mp-admin@...]On Behalf Of Tom Rohlfing
Sent: Sunday, December 23, 2001 10:51 AM
To: 1000mp@...
Subject: Re: [1000mp] MpFilters and Mpcw4Win Updates


Question for the group:

I see lots of cool computer programs that do good things with the
MP -- rig
control programs, S-meter reading programs, memory control programs, etc.
etc.

But I never use any of them for one simple reason: my logging program
(Logger) uses the radio's CAT control connector to get band,
frequency, and
mode information from the radio. I really like this feature, and so I
always leave the logging program active, and it therefore eats up the COM
port that the radio is connected to. If I try to run some other
program to
connect to the radio, the first thing it does is ask for the COM port
number, and of course that fails because the radio's COM port (COM1) is
already busy, and can't be connected with.

So, is this just a fundamental limitation, or is there some way around it?
Do I really have to decide what ONE program I want to use to communicate
with my MP? Or is there some clever way to have two programs actively
sharing communications with the MP?

I hope this question makes sense. What we need is some program that
abritrates asynchronous communications from two separate programs and acts
as a traffic cop to pass traffic between the one radio and two
separate COM
ports (for two different programs). Any such beast out there?

73,
Tom / W7GT

_______________________________________________
1000mp mailing list
1000mp@...
http://mailman.qth.net/mailman/listinfo/1000mp



To unsubscribe from this group, send an email to:
dxlab-unsubscribe@...



Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/



Re: how many people actually use DXLab applications?

gw3zcf <RTrebil640@...>
 

Dave,
I regularly use DXView, PropView and Pathfinder Web Client v1.1
I use WinWarbler occasionally
Happy holidays
Robin GW3ZCF


--- In dxlab@y..., "Dave, AA6YQ" <dhb@m...> wrote:
There's no way to know how many people actually use these
applications; in
fact, there's no way to know exactly how many people downloaded
them. The
closest we can come is to know how many unique visitors there were
to each
application's download page. Obviously someone can visit a download
page and
then decide not to download the application; or they can download an
application and never install it, or install it and never use it.
On the
other hand, there appear to be several sites that have chosen
to "mirror"
WinWarbler and DXView; who knows how many people have downloaded the
applications from those sites.

At any rate, the "download page" counters serve as a reasonable
proxy for
interest level. You can navigate to each download page and scroll
to the
bottom to see its counter, or you can look at
http://www.qsl.net/dxlab/status.htm where I've aggregated all of the
download counters. I also added the counter for visits to DXLab's
main page.

73 and Happy Holidays to all,

Dave, AA6YQ


Re: [1000mp] MpFilters and Mpcw4Win Updates

Dave, AA6YQ <dhb@...>
 

I won't say that its impossible to multiplex a COM port among two separate
Windows applications, but it would certainly involve some serious low-level
programming. It would be easier to do this with a dedicated microprocessor
(a BasicStamp or an 8051) that performed the appropriate buffering and
routing externally. Each application would require a dedicated COM port, but
all would have direct access to the transceiver.

In DXLab I took a different approach. I created one application (Commander)
to provide transceiver control, but set it up to serve as a "transceiver
control server" for the other DXLab applications such as DXKeeper (logging
and QSL card/label generation), WinWarbler (soundcard PSK31 and RTTY), and
SpotCollector (realtime telnet/IRC DX spot collection and analysis). These
applications all interoperate by exchanging messages using a standard
Windows protocol known as DDE; thus, exactly one COM port can handle all
transceiver interactions (unless you're using FSK rather than AFSK for RTTY
transmission, in which case a second port is required for an FSK interface).

The most recent development release of Commander -- version 3.1.8 --
displays and provides direct control of MP1000 and MP1000 Mark V filters.
Over the next weeek, I'll be extending this to support user-defined Filter
Groups. You might create a Group named "DXing" that looks like this:

2nd IF 3rd IF Sub

SSB 1800 1800 2400
CW 250 250 500
RTTY 500 500 500

or a group named "RagChewing" that looks like this:


2nd IF 3rd IF Sub

SSB 2400 2400 2400
CW 500 500 500
RTTY 500 500 500

Switching between Filter Groups will be accomplished via a single pull-down
control.

All DXLab applications are free; they're available via www.qsl.net/dxlab .

73,

Dave, AA6YQ

-----Original Message-----
From: 1000mp-admin@...
[mailto:1000mp-admin@...]On Behalf Of Tom Rohlfing
Sent: Sunday, December 23, 2001 10:51 AM
To: 1000mp@...
Subject: Re: [1000mp] MpFilters and Mpcw4Win Updates


Question for the group:

I see lots of cool computer programs that do good things with the MP -- rig
control programs, S-meter reading programs, memory control programs, etc.
etc.

But I never use any of them for one simple reason: my logging program
(Logger) uses the radio's CAT control connector to get band, frequency, and
mode information from the radio. I really like this feature, and so I
always leave the logging program active, and it therefore eats up the COM
port that the radio is connected to. If I try to run some other program to
connect to the radio, the first thing it does is ask for the COM port
number, and of course that fails because the radio's COM port (COM1) is
already busy, and can't be connected with.

So, is this just a fundamental limitation, or is there some way around it?
Do I really have to decide what ONE program I want to use to communicate
with my MP? Or is there some clever way to have two programs actively
sharing communications with the MP?

I hope this question makes sense. What we need is some program that
abritrates asynchronous communications from two separate programs and acts
as a traffic cop to pass traffic between the one radio and two separate COM
ports (for two different programs). Any such beast out there?

73,
Tom / W7GT

_______________________________________________
1000mp mailing list
1000mp@...
http://mailman.qth.net/mailman/listinfo/1000mp


Re: how many people actually use DXLab applications?

KB6NAN Dianna Killeen <dx@...>
 

Hi Dave

if you are making a list put me on for dxkeeper and dxview and Pathfinder.

Happy Holidays and thank you

--
KB6NAN Dianna R. Killeen
http://www.southcoast.net/dx/dxmain.html


"Dave, AA6YQ" wrote:

There's no way to know how many people actually use these applications; in
fact, there's no way to know exactly how many people downloaded them. The
closest we can come is to know how many unique visitors there were to each
application's download page. Obviously someone can visit a download page and
then decide not to download the application; or they can download an
application and never install it, or install it and never use it. On the
other hand, there appear to be several sites that have chosen to "mirror"
WinWarbler and DXView; who knows how many people have downloaded the
applications from those sites.

At any rate, the "download page" counters serve as a reasonable proxy for
interest level. You can navigate to each download page and scroll to the
bottom to see its counter, or you can look at
http://www.qsl.net/dxlab/status.htm where I've aggregated all of the
download counters. I also added the counter for visits to DXLab's main page.

73 and Happy Holidays to all,

Dave, AA6YQ


To unsubscribe from this group, send an email to:
dxlab-unsubscribe@...



Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/