At 17:03 08/01/2003 -0500, Jack wrote:
>Hi Ron,
>
>I'll pass these along to the developers. I know they have been hard at work
>for several weeks now and don't know how much "extra" development time
>remains available for this cycle.
Seeing as there is another version in the offing perhaps I could trouble
you with a reminder of the various requests I have made over the last year
or so
these are simply cut 'n paste from previous E-mails so there may be some
duplication and more than a little disorganization to this list but I hope
they provide food for thought.
1 biggie though
the grid square feature should always treat 4 figure grids as a subset of 6
figure grids, for instance searching for IO53 does not correctly cross
reference with entries that have 6 figures such as IO53hu.
A search for IO53 will never find IO53hu
This is unworkable for the 6m operator which is why I ADIF export my vhf
logs to VQlog for proper manipulation.
www.vqlog.com
At the bottom of this list is a repeat of my request for a much improved
radios.ini file and rig support, this will, I feel make life easier for all
in the long run, currently rig support seems to be added by us the users
and giving us better (i.e more flexible ) tools to do this with can only be
a good thing for DXB2004 as it gives DB the edge over the competition (Who
are also suffering form changing interface standards from radio
manufacturers) thanks to superior radio support.
1/ Spot filtering. Spot filtering should not filter repeat spots for a Call
sign IF originating Call is different.
E.g Dx de G7CUW : 50120 VK2MS
and
DX de EI4IZ: 50120 VK2MS
should both appear in the dx info window instead of just the first spot.
2/ Cut and paste between windows should work much more efficiently. for
example it should be possible to cut and paste address info into DXbase
after doing a QRZ search (which after all DXbase supports from the
toolbar). Currently you can only paste address info line by line.
It would be great to be able to copy and paste info from the QSL Info
window into the log (E.G grid squares.
3/ CD rom lookup needs to be more intelligent, eg. EI7IQ produces a valid
lookup whereas EI7IQ/P does not. EA8/EI7IQ fills in the details on CD rom
for the EA8 buero, Not helpful.. EA8/EI7IQ shoud take name and QSL info
from EI7IQ burt leave grid QTH and county blank 9as he is operating EA8/
EI7IQ/m (or p or / anything else ) should be treated the same way
4/ Whilst it is nice to be able to resize the rows in all the windows it
should be possible to lock them to a certain size as resizing by accident
is a big problem.
5/ deleting records does not work reliably using the delete key, the menu
option works fine, this is due to selection not always being straightforward
6/ DX spots really ought to expire after a set time interval, I know
emptying the DX info window works but it would be better if spots could be
configured to expire after a user configurable period of time. old spots
are not useful to anyone.
7/ packet window should not open automatically at startup IF there is no
TNC configured, it should be possible to configure an auto connect
at start up for both / either the packet and Internet clusters as a option
if required
8/ summary window should always give the bearing based on the grid square
IF the grid is available in the QSL info, It already does this when in VHF
grids mode,so do the same in the other modes IF the grid is available and
the call is not ??/ or /?? I.e vk/ei6iz or ei6iz/m
9/ the incoming DX cluster (& Internet cluster ) should accept data in more
than one format, I .e spots come in as
DX de EI4IZ: 50120 VK2MS
but if I do a SH/DX spots are in a different format
1822.4 HK4CZE 9-Jan-2003 0137Z <K9DX>
It would be nice to be able to use the spots from a SH/DX comand (many
clusters including my own will do a SH/DX/10 when you log in ) to populate
the dx column
10/ ability to populate log entries with information from CD database after
the contact has been logged
12/ It would be nice to be able to set the log window to be always on top'
for those pileup situations
13/ If you enter a call DXbase does a CD rom lookup and enters the results
into the log (which is good) however if you change the callsign again
because of a typo etc a new lookup isn't done but the call changes, a new
lookup should be done IF that contact hadn't been logged (I.e Entered into
the database by using the down arrow, Mousing onto the next row or using
the enter key)
Grids in previous QSO's window
lookup by partial grids E.g EL98 should produce a list of all qsos
with EL98 whereas EL98HK shows only qsos with EL98HK
partial call lookup would be nice as well E.g EI7 should list all
EI7 s worked.
TNC interface
ability to interface with the AGWpacket engine
1/ Some of us are using this software to connect more than one
application to 1 TNC
2/ some are using it to get on packet with just a sound card.
3/ it provides an excellent interface for the Bayom TNC (which has
no command interface) or the various cheap KISS only TNC types.
the programmer makes everything needed available for 3rd party software
support
http://www.elcom.gr/sv2agw/
Roger Barker (author of UIview ) also has good info on AGW
http://www.ui-view.com/
TNC interface
Proper scripting support for things like the Kenwood TMD700.
Cluster
1/ Please stop the tnc window loading if the TNC isn't enabled
2/ Allow for automatic internet cluster logon for those of us who have
always on Internet (or are running a cluster on the local network ;-)
DXinfo window
More flexible filtering please.
it would be just heaven if for example I could allow ALL 6m spots
to appear in the DX info window along with only the HF spots I need
Wild card filtering by call sign E.g EI* in the call sign alerts list
should be permitted, more call sign alert slots.
Always replace an old spot in the dxwindow with a newer spot for the same
station.
An expire time option,
spots are pretty useless once they are older than a certain period of time
so discard old spots from the dxinfo pane, time to be configurable by the
user, set to 0 for current behavior
Fonts and things.
if I use the zoom tool it would be nice if DXB remembered this for
the next time I open the program.
I can't seem to change the font size for the QSL info pane
It would be nice to be able to make global font changes sometimes
I would LOVE to be able to 'lock' the resize all rows ' feature' as I am
always accidentally resizing rows when trying to select a single row,
resizing not something that I actually want to do very often.
I would also love to be able to lock out the 1 click sort that I do from
time to time when I click on a column header, perhaps make sort and resize
right click items?
bands and modes
It would be really nice to be able to Hide bands, modes, QSL
routes etc that don't ever get used by me from the various pull down menus.
I want to hide the following, all modes except SSB,CW,FM,Pactor. all bands
above 70Cm and 222 Mhz which we don't have. all qsl routes except none,
Buro, Manager.
Add JT44 and JT441 as modes (6m & 2m Meteor scatter modes ) allow user
defined modes ??
Radio interface.
The new mute function is good but I still have to disable the
radio control port when I want to use some of my pactor software as it
expects (& I want it to) to be able to control the radio directly.
It would be nice if the options menu remembered which pane was
open last time.
how about providing a virtual com port which would allow other
software to pass commands to and from the radio through DXB?
Summary window
A redesign to use less screen area might be worth considering
Possible BUGS with 2003.
Dxinfo pane
possible bug, I cant hide columns I don't want, I can only make
them very narrow.
Radio not responding error
Still present I am afraid with my ICOM radio, very infrequent with
driver X disabled, quite frequent with driver X enabled. Now using a
different Win2k machine (faster CPU, different Motherboard etc ) and a
different radio (756PRO2) but noticed no difference in the frequency of
this error.
I am willing to work with you on this one, perhaps a DXB2003 EXE that is
compiled to log all radio data both ways & I can then send you the logs. I
have not had any problems with other software and radio control, just DXB.
New features
How about a Split screen terminal built in that can be configured on a
separate or the same com port as the packet (but in this case can only be
opened if the DXcluster connection via packet is closed) That can be used
for keyboard modes with A TNC or multimode modem such as the SCS-PTC
modems. include some user defined keys and a few memories for brag sheets,
common commands etc.
Include a simple log interface (e.g point and click on a call to log the call)
Logging interface
How about adding an interface like that of VQ log (& many others) for
logging. Allow the user to define which fields need filling which would
make moving around this new interface using TAB and arrow keys very quick.
E.g when working 6m pileups all I want to enter is
Call RSTs RSTr GRID. I expect the software to get the frequency & mode from
the radio and tentatively fill in the Grid from the callbook or past qso's
this would provide a less cluttered interface for entering lots of contacts
Allow the user to save multiple setups of this interface, e.g 1 for 6m 1
for Hf CW etc.
perhaps this new interface could be done as an expansion of the contest mode.
Since it would appear that support for new radios is actually added in most
cases by the users, not Scientific solutions and the protocols used by
various radios constantly changing when new models come out, It Seems to me
that future versions of DXB could do more to make the job of adding support
for future radios easier to do and allow for some improvements to existing
radios.
Here are my suggestions for some improvements, most of these appeared
initially as part of the TS2000 thread
DXB does a better job than most with the radios.ini file approach and I am
happy to write a new entry if I am the first user with a particular radio
as I have done with the K2. I am also happy to share this file with other
users.
What I would like to see from the software authors is more control over
what one can do in the radios.ini file.
Such as.
Error handling (for radio OR software errors)
Ability to code in some of the serial port parameters I.e some radios only
support certain baud rates (or even have 1 fixed baud rate) and require
certain parity and stop bit settings, obviously the com port # need not be
coded into the .ini file! this would make it easier for the end user it
would provide less room for error by removing the settings that won't work.
If there are no com port parameters set then all possible options are
available like now
PORT_SPEED = 4800,9600,19200 (means that user can only select from these
values)
PORT_PARITY= NONE (or EVEN ODD etc)
PORT_BIT= 8 (or 7 etc)
PORT_STOP=1 (or 0,1,2 etc )
PORT_HANDSHAKE = Hard (or NONE or CWKEY (to allow the same com port for CW
keying by means of the RTS or DTR lines) )
An option to force DXB to write a logfile of all data sent to and from the
radio for debugging when making changes to the radios.ini file
Support for extended modes (I.e CW-R etc) which simply would involve DXB
accepting more than one value as a response for a mode query.
Ability (where available ) to make use of information concerning which VFO
is active.
An understanding of Dual watch as well as split. (optionally treat the same
as split )
The ability (where the radio supports it ) to key CW by sending the
appropriate ASCII strings to the radio (kenwood TS2000, elecraft K2 and
probably other recent kenwoods ) along with other support required for this
feature.
It would be important to be able to specify the order in which commands are
used. These changes would require the radios.ini file to undergo an overall
rewrite. but since most radio files work as they are this would be a fairly
trivial issue of adding a generic extra bit to each of the existing
entries. (or even just assuming a generic order where not otherwise defined
) Therefore it should be possible to add these new features breaking ay
existing ones
I propose that the radios.ini format continues to define each command
EXACTLY as is now done and adds support for any user defined commands that
may be required in the future or to handle certain special features.
After the commands are defined, the strings sent (action definitions) along
with any additional pauses for replies etc for each action in DXB can be
defined.
Action definitions should only allow use of the predefined commands (to
stop things getting messy, don't forget the support for user defined
commands!) and the built in timing commands such as eoc(100)
CLICKSPOT = GETvfoa, GETmodeA, GETvfob, GETModeB,GetSplit, GetActiveVFO,
SETVFOA, SETmodeA, SETVFOB, SETmodeB, SETsplit
READ_LOG = GETvfoa, GETmodeA, GETvfob, GETModeB,GetSplit, GetActiveVFO
you get the idea
followed by error handling entries
RETRIES = 3 <-how many retries before annoying the user with an error
message WHATEVER the cause of the error.
RETRY_WAIT = 200 <-how many msec to wait before repeating the command when
retrying
followed by the debug options
ERROR_LOG = 0
0= no log, 1 only log errors or retires (including the previously sent
string), 3 log everything in from rig, 4 log everything out, 5 log all commands
put an extra <CR> after each response from the radio to make things easier
to read
LOGFORMAT = HEX (or ASCII )
LOGFILENAME = whatever.txt (saved in the DXB directory )
In the absence of any of these new features from a particular entry in the
INI file DXB could assume the current default behavior to ensure 100%
backward compatibility with older radios.ini files.
The DXB help file would need more information added on how the radios.ini
file works as well..
regards
Brendan EI6IZ
