Spotcollector sends calls to other DxLab Suite
Hi,
?
I have been using Dxlab Suite for a long time.? For about a
week,? I have been researching for an answer to a (maybe of not) slight
problem.? But did not find and answer.
?
When right click on a call line in Spotcollector,? that call populates
(goes to) call field of DxKeeper, DxView, Pathfinder and Commander's
Bandspread.? Also there is an indication on that band in PropView
Prediction.
?
I thought that right clicking on a call line in Spotcollector also send
that call to Winwarbler.? If so then it is no longer doing it.
?
Is this a "senior moment" or I may have clicked a wrong buttons in any
DxLab Config?
?
Question: When right clicking on a call in Spotcollector, is that call sent
to WW?
?
Thanking you in advance for information.
?
73 de Rick W4UEF
?
|
Re: SQL filter for specific spotters?
Works great. Even the audio announcements work correctly (announcing only when spot comes in from me for the first time and not on consecutive spots from others).
?
Thanks and 73
Andy
KU7T
?
toggle quoted message
Show quoted text
From: dxlab@... [mailto:dxlab@...]
Sent: Thursday, March 3, 2016 11:36 AM
To: dxlab <dxlab@...>
Subject: Re: [dxlab] SQL filter for specific spotters?
?
?
On Thu, Mar 3, 2016 at 10:48 AM, ku7t@... [dxlab]
<dxlab@...> wrote:
>
> I want to fine tune a query so it will only include spots from my own skimmer (fed to RBN). It sort of works. When a spot spotted by me comes in, it shows up in the grid, but then quickly disappears. I believe this is because it has been re-spotted by someone
else.
>
> Is there any setting or trick I could use to make this work? Basically I would like to filter out all my spots that are needed for better visibility and also audio announcements.
Try:
Cumulative like '*de KU7T *'
(assuming that's the 'Source' of your skimmer spots - don't include
the '-#' suffix, since SpotCollector appears to chop that off before
adding to 'Cumulative')
73,
~iain / N6ML
|
Re: SQL filter for specific spotters?
On Thu, Mar 3, 2016 at 10:48 AM, ku7t@... [dxlab] <dxlab@...> wrote:
I want to fine tune a query so it will only include spots from my own skimmer (fed to RBN). It sort of works. When a spot spotted by me comes in, it shows up in the grid, but then quickly disappears. I believe this is because it has been re-spotted by someone else.
Is there any setting or trick I could use to make this work? Basically I would like to filter out all my spots that are needed for better visibility and also audio announcements.
Try: Cumulative like '*de KU7T *' (assuming that's the 'Source' of your skimmer spots - don't include the '-#' suffix, since SpotCollector appears to chop that off before adding to 'Cumulative') 73, ~iain / N6ML
|
SQL filter for specific spotters?
Hi,
I want to fine tune a query so it will only include spots from my own skimmer (fed to RBN).? It sort of works. When a spot spotted by me comes in, it shows up in the grid, but then quickly disappears. I believe this is because it has been re-spotted by someone else.
Is there any setting or trick I could use to make this work?? Basically I would like to filter out all my spots that are needed for better visibility and also audio announcements.
Thanks and 73 Andy KU7T
|
AA6YQ comments below
-----Original Message----- From: dxlab@... [mailto:dxlab@...] Sent: Thursday, March 03, 2016 6:52 AM To: dxlab@... Subject: [dxlab] Sliders? I busy with digital modes and DXLab. wel this work great I hve now the bridge and DM78 HRD working with DXKeeper. I see in HRD sliders to change the power settings and al lot more my question is this also possible in DXLab? Yes: see
<> Check this Yahoo group's
Files > Command Sequences and Sliders area to see if the sliders you seek for your transceiver have been shared by other DXLab users. To use these sliders, see
<> 73, Dave, AA6YQ
|
Re: Transceiver command rejected
If the "transceiver command rejected" messages only occurs when you're transmitting, then RFI is most likely the cause, and there's no need to send me an errorlog.txt file.
73,
Dave, AA6YQ
toggle quoted message
Show quoted text
-----Original Message-----
From: dxlab@... [mailto:dxlab@...]
Sent: Thursday, March 03, 2016 9:34 AM
To: dxlab@...
Subject: Re: [dxlab] Transceiver command rejected
I'm not sure if it is happening when transmitting or not, as the box appears on the left-most monitor and it's out of my field of view. I'll check and advise. I'll also do the log debugging and get it to you as soon as I can.
Many thanks as always!
73 de Chuck, WS1L
On Wed, Mar 2, 2016 at 7:54 PM, ' Dave AA6YQ' aa6yq@... [dxlab] <dxlab@...> wrote:
>>>AA6YQ comments below
-----Original Message-----
From: dxlab@... [mailto:dxlab@...]
Sent: Wednesday, March 02, 2016 8:50 PM
To: dxlab@...
Subject: [dxlab] Transceiver command rejected
I'm getting these error boxes fairly frequently. Often it is Request meter (S) but other times it's different.
>>>Does this happen exclusively when transmitting?
Rig is a ten tec Orion. Interval is set to 200. Serial port is 57600 8n1 DTR N RTS X.
This is new for the last few Commander updates.
Anything I can do to help this?
>>>On the Configuration window's General tab, check the "log debugging info" box. When the "transceiver command rejected" box next appears,
1. On the Configuration window's General tab, uncheck the "log debugging info" box
2. Attach the errorlog.txt file from your Commander folder to an email message, and send it to me via
aa6yq (at) ambersoft.com
73,
Dave, AA6YQ
--
===================
Chuck Chandler
chandlerusm@...
===================
|
Re: Transceiver command rejected
I'm not sure if it is happening when transmitting or not, as the box appears on the left-most monitor and it's out of my field of view.? I'll check and advise.? I'll also do the log debugging and get it to you as soon as I can.
Many thanks as always!
73 de Chuck, WS1L
On Wed, Mar 2, 2016 at 7:54 PM, ' Dave AA6YQ' aa6yq@... [dxlab] <dxlab@...> wrote:
?
>>>AA6YQ comments below
-----Original Message-----
From: dxlab@... [mailto:dxlab@...]
Sent: Wednesday, March 02, 2016 8:50 PM
To: dxlab@...
Subject: [dxlab] Transceiver command rejected
I'm getting these error boxes fairly frequently. Often it is Request meter (S) but other times it's different.
>>>Does this happen exclusively when transmitting?
Rig is a ten tec Orion. Interval is set to 200. Serial port is 57600 8n1 DTR N RTS X.
This is new for the last few Commander updates.
Anything I can do to help this?
>>>On the Configuration window's General tab, check the "log debugging info" box. When the "transceiver command rejected" box next appears,
1. On the Configuration window's General tab, uncheck the "log debugging info" box
2. Attach the errorlog.txt file from your Commander folder to an email message, and send it to me via
aa6yq (at)
73,
Dave, AA6YQ
--
=================== Chuck Chandler ===================
|
Re: Background colors DXKeeper Log Page Display
OK I understand now the relationship between the 2 apps. Thanks
73 de Jeff VA2SS
|
Hi , I busy with digital modes and DXLab. wel this work great I hve now the bridge and DM78 HRD working with DXKeeper. I see in HRD sliders to change the power settings and al lot more my question is this also possible in DXLab? With some sliders to change the Audio or power setting?
|
Re: SpotCollector no JH2ZYY reports
Please do the following:
1. direct the Launcher to upgrade SpotCollector to the current version, which is 7.4.8
2. start SpotCollector 7.4.8
3. on the Configuration window's General tab, check the "log debugging info" box
4. terminate SpotCollector
5. start SpotCollector 7.4.8
6. wait 5 minutes
7. on the Configuration window's General tab, uncheck the "log debugging info" box
8. attach the errorlog.txt file from your SpotCollector folder to an email message, and send it to me via
aa6yq (at) ambersoft.com
73,
Dave, AA6YQ
toggle quoted message
Show quoted text
-----Original Message-----
From: dxlab@... [mailto:dxlab@...]
Sent: Wednesday, March 02, 2016 10:00 PM
To: dxlab@...
Subject: RE: [dxlab] Re: SpotCollector no JH2ZYY reports
hi Dave, did everything that you said. The Spot source window for JH2ZYY says [SpotCollector 6.9.6 connected] but the spot source status light on the main SpotCollector window is still yellow regards Wayne VK4WTN
|
Re: SpotCollector no JH2ZYY reports
hi Dave, did everything that you said. The Spot source window for JH2ZYY says [SpotCollector 6.9.6 connected] but the spot source status light on the main SpotCollector window is still yellow
regards Wayne VK4WTN
|
Re: Transceiver command rejected
AA6YQ comments below
-----Original Message----- From: dxlab@... [mailto:dxlab@...] Sent: Wednesday, March 02, 2016 8:50 PM To: dxlab@... Subject: [dxlab] Transceiver command rejected I'm getting these error boxes fairly frequently. Often it is Request meter (S) but other times it's different. Does this happen exclusively when transmitting?
Rig is a ten tec Orion. Interval is set to 200. Serial port is 57600 8n1 DTR N RTS X. This is new for the last few Commander updates. Anything I can do to help this? On the Configuration window's General tab, check the "log debugging info" box. When the "transceiver command rejected" box next appears,
1. On the Configuration window's General tab, uncheck the "log debugging info" box 2. Attach the errorlog.txt file from your Commander folder to an email message, and send it to me via aa6yq (at) ambersoft.com 73, Dave, AA6YQ
|
Transceiver command rejected
I'm getting these error boxes fairly frequently. Often it is Request meter (S) but other times it's different.
Rig is a ten tec Orion. Interval is set to 200. Serial port is 57600 8n1 DTR N RTS X.
This is new for the last few Commander updates.
Anything I can do to help this? --
Chuck Chuck Chandler chandlerusm@...
|
Commander 12.1.5 is available
This release
- correctly evaluates the Shift modifier applied to "Quick Split" buttons
- when controlling an Elecraft K3, implements the "VFO B" panel's? "up 1", "up 2", "up 5", up "10",? "dn 1", "dn 2", "dn 5", and dn
"10" buttons with a faster set of CAT commands, including the Shift options that simply increase or decrease VFO B's frequency by
the specified amount (tnx to Iain N6ML)
- provides additional support for the new Icom IC-7300; note: this has not yet tested with an IC-7300
- doesn't clear Bandspread spots when the transceiver is tuned out of the current band (tnx to Joe W4TV and Iain N6ML)
Notes:
1. Update your firewall and anti-malware applications to consider this new version of Commander to be "safe"
2. If this upgrade doesn't work correctly, see the "After an Upgrade" section of
<>
3. After upgrading, to revert to the previous version of Commander, see
<>
Commander 12.1.5 is available via the DXLab Launcher and via
<>
73,
Dave, AA6YQ
|
Re: Commander Bandspread "tolerance"
AA6YQ comments below
-----Original Message----- From: dxlab@... [mailto:dxlab@...] Sent: Wednesday, March 02, 2016 8:21 PM To: dxlab@... Subject: Re: [dxlab] Commander Bandspread "tolerance" > +++ That said, I don't see or recall any reason to hide spots when > you tune out of the current band. I've sent you and Joe W4TV a > version of Commander that no longer does that; please let me know > how it goes... Works as advertised. I appreciate not losing spots in the band map when tuning the RX a short way out of the band. I have other soft- ware and hardware that inhibit PTT when the transmitter is out of band. Thanks for the testing, Joe!
73, Dave, AA6YQ
|
Re: Commander Bandspread "tolerance"
+++ That said, I don't see or recall any reason to hide spots when
you tune out of the current band. I've sent you and Joe W4TV a
version of Commander that no longer does that; please let me know
how it goes... Works as advertised. I appreciate not losing spots in the band map when tuning the RX a short way out of the band. I have other soft- ware and hardware that inhibit PTT when the transmitter is out of band. 73, ... Joe, W4TV On 3/2/2016 12:49 AM, ' Dave AA6YQ' aa6yq@... [dxlab] wrote: +++ AA6YQ comments below
-----Original Message-----
From: dxlab@... [mailto:dxlab@...]
Sent: Tuesday, March 01, 2016 10:24 PM
To: dxlab
Subject: Re: [dxlab] Commander Bandspread "tolerance"
On Tue, Mar 1, 2016 at 6:30 PM, ' Dave AA6YQ' aa6yq@... [dxlab] <dxlab@...> wrote:
AA6YQ comments below
-----Original Message-----
From: dxlab@... [mailto:dxlab@...]
Sent: Tuesday, March 01, 2016 10:52 AM
To: dxlab@...
Subject: [dxlab] Commander Bandspread "tolerance"
This morning 3XY1T was calling CQ (split) just a hundred (if that) Hz or so below 24,890 for a while. Tuning to him - even when split with the TX VFO in the band - caused Commander to blank the bandspread and switch to the "out of band" color.
How did that impede your ability to work 3XY1T? Presumably you weren't interested in other 17m spots at that moment.
When working split, a considerate operator would try to be aware of other DX "up the band", and try to avoid transmitting over it.
+++ Right, but the considerate operator should do that by tuning up the band and listening, not by relying on cluster spots.
It might also be helpful when determining the spread of the target DX's pile (if there are multiple "clumps", some of them may be calling other DX).
+++ Callers in a pileup generally aren't spotted.
+++ That said, I don't see or recall any reason to hide spots when you tune out of the current band. I've sent you and Joe W4TV a version of Commander that no longer does that; please let me know how it goes...
73,
Dave, AA6YQ
------------------------------------
Posted by: " Dave AA6YQ" <aa6yq@...>
------------------------------------
------------------------------------
Yahoo Groups Links
|
Re: A difficult request to clean up and old problem
Peter, if you have an ADIF file that contains QSOs with split frequencies specified in Comment fields, please attach it to an email message, and send it to me via
aa6yq (at) ambersoft.com
Without it, I won't be able to extend DXKeeper to properly extract such split frequencies when importing an ADIF file exported by DXBase.
73,
Dave, AA6YQ
toggle quoted message
Show quoted text
-----Original Message-----
From: dxlab@... [mailto:dxlab@...]
Sent: Tuesday, March 01, 2016 12:28 PM
To: dxlab@...
Subject: [dxlab] A difficult request to clean up and old problem
There's one thing I'd love to do but honestly I don't know if it's possible or feasible. As you know, I converted my entire log from DX Base format three years ago, and that program has a bizarre way of recording split. Instead of logging RX and TX frequencies in their respective fields, as DXK does, it populates the TX Freq field with the RX freq and puts the TX Freq as the first string in the comments. So if I logged a station that was transmitting on 14.195 and I worked them by transmitting at 14.200, when that QSO was imported into DX Keeper, the entry's RX frequency field would be blank, the TX frequency would be converted to 14.195 and the comment field would begin with the characters 14200.00 (in kHz, not MHz). DX Base for whatever reason uses only the TX Frequency field to record the VFO-A frequency. This makes zero sense but it is what it is.
Is it possible to bulk fix these? Is it even worth considering?
Below are just rambling, random comments, not requests/etc, that may be of interest to those who've imported their logs from other software into DX Keeper.
Per my issue in the OQRS discussion thread, I spent about 4 hours this morning parsing my log for erroneous QSL sent settings. I set all the QSL_SENT requests that had been flagged "N" to nil (empty value), but the real fun one was about 500 QSOs from the spring of 2013 that had the sent flag set to S, but nothing in the sent-via field and no QSL sent or received date. The intention was to identify all of these and, like the first group, set their QSL Sent status to undefined.
The filter I had to use for the latter took a while to build but it finally worked:
(QSO_Begin between #2001-03-01# and #2013-05-21#) and (QSL_SENT_VIA not in ('E','B', 'D')) and (QSL_SENT in ('Y')) and (QSLSDATE = #4000-01-01#) and (QSLRDATE = #4000-01-01#). Then I bulk modified QSL_SENT to nil. I'm assuming that "no value" should be the default state of QSL_SENT and QSL_Rcvd unless deliberately acted upon (I've requested a QSL card or I've answered a QSL request).
I also went through and set correct CONTEST_ID values for every contest Q dating back to the beginning, and everything's backed up to the cloud. I never realized how much erroneous info was in there over the years, and I'm sure there's so much more that remains hidden, awaiting some future attempt to do something.
|
Re: ClubLog Inbound OQRS and QSL_Rcvd
QSOs for which an Inbound OQRS request have been received cannot be distinguished from QSOs for which no Inbound OQRS request has been received: each logged QSO has "QSL Sent Via" and "QSL Rcvd Via" items, but there is no "QSL Requested Via" item.
Adding a "never request confirmation" option to the "QSL Configuration" window's "Inbound OQRS" panel as I initially proposed would require adding a "QSL Requested Via" item to every logged QSO. To avoid that, I have instead added a new "Add Requested never request confirmation" option to the "Add Requested" panel on the "QSL Configuration" window's General tab. When this new option is enabled, QSL cards or labels generated from QSOs added to the QSL Queue by the "Add Requested" function will not include 'please!' or 'pse!' in their QSL column.
This new "Add Requested never request confirmation" option is saved in the log file. Thus you can enable it for DXpedition logs, but disable it for you K0PC log. Loading a log file will automatically set the "Add Requested never request confirmation" option to the value you last specified with that log open.
I have sent you a version of DXKeeper with this "Add Requested never request confirmation" option implemented. Please let me know how it goes. Thanks!
73,
Dave, AA6YQ
toggle quoted message
Show quoted text
-----Original Message----- From: dxlab@... [mailto:dxlab@...] Sent: Wednesday, March 02, 2016 1:40 PM To: dxlab@... Subject: [dxlab] Re: ClubLog Inbound OQRS and QSL_Rcvd &&&& ->K0PC comments below ---In dxlab@..., <aa6yq@...> wrote :+++ +++ I thought it inappropriate to automatically consider every OQRS request as "un-needed", but I see now that the "QSL Configuration" window's "Inbound OQRS" panel needs a "never request confirmation" option whose setting is independently stored in each log. #### I agree, this is a needed option. I don't think many garden-variety stations will get many OQRS requests in the first place, so that leaves small and medium sized DXpeditions and 2nd and 3rd tier DX stations to really take adavntage of this addition of OQRS functionality (in addition to major DXpeditions, that is). There's no way someone in ZS or TF will want QSLs back from every single W2 and VE3 they work and who requests their card via OQRS. &&&& This change would solve my problem. It seems that even if the DX stations has K confirmed on 17M CW I still get pse! in the label if the QSL_ Rcvd is blank. I need to set QSL_Rcvd=I to eliminate it.
|
Re: SpotCollector no JH2ZYY reports
AA6YQ comments below
-----Original Message----- From: dxlab@... [mailto:dxlab@...] Sent: Wednesday, March 02, 2016 6:32 PM To: dxlab@... Subject: [dxlab] Re: SpotCollector no JH2ZYY reports hi Dave, in config/ spot sources on jh2zyy the user name is VK4WTN but there is no password ( none of the other DXclusters have a password either but they are working). In the Cmd box I have put unset/prompt regards Please do the following:
1. clear the Cmd box where you put the unset/prompt command 2. in the "Spot source status" panel at the top of SpotCollector's Main window, click the yellow "LED-like display" this will display the "spot source" window for JH2ZYY 3. in the "spot source" window for JH2ZYY 3a. in the "Transmit pane" immediately above the Macros panel, type unset/prompt and then strike the Enter key 3b. click the Connect button to the left of the Macros panel Does the yellow "LED-like display" in the "Spot source status" window change from yellow to green? 73, Dave, AA6YQ
|
Re: SpotCollector no JH2ZYY reports
hi Dave, in config/ spot sources on jh2zyy the user name is VK4WTN but there is no password ( none of the other DXclusters have a password either but they are working). In the Cmd box I have put unset/prompt
regards Wayne VK4WTN
|
iain macdonnell
Chuck, WS1L
Rien Aarden