|
locked
Display state of sending call after decode
Greg Van Scott
I just changed computers & can't figure out how to get JTalert displaying the STATE of a decoded call into view. It used to do it and I can't seem to find anything of the sort in settings. Anyone know?
|
|
|
|
locked
Re: Settings Not Saved
Laurie, VK3AMA <groups08@...>
On 7/04/2017 6:22 AM, John Mira
jayemsr@... [HamApps] wrote:
Thank you, that worked. Now if I can just figure out how to send you that troublesome config file. I'll keep trying though! I will attach it here but continue to try though Contact Support in the app.If the config backup file rename worked, then there is no need for me to examine your config.sqlite file. When you use the Contact Support link, your config file along with debug (session) files are automatically included when you use the "Send Email" button. There is no option to add specific files, all the files I need to examine will be automatically included in the email. de Laurie VK3AMA
|
|
|
|
locked
Re: Settings Not Saved
Laurie, VK3AMA <groups08@...>
On 7/04/2017 12:22 AM,
jayemsr@... [HamApps] wrote:
I recently uploaded version 2.9.2 and find that when I go to Settings > Manage Settings and change anything such as background color or font color, then save that none of the change are saved. In fact, when I set the app to dock to WSJT window, that change is also lost when I next open JTAlert. Any Ideas? Yourhelp is much appreciated.John, Sounds like you may have a corrupt config file. Please use the "? -> Contact Support" menu, on the JTAlert title-bar, to send me your Configuration file for analysis. You can try restoring a config backup from prior to the problem appearing by doing the following.. You can restore a previous version of your config file. Try the following...
Let me know how you get on. de Laurie VK3AMA
|
|
|
|
locked
Settings Not Saved
John M
I recently uploaded version 2.9.2 and find that when I go to Settings > Manage Settings and change anything such as background color or font color, then save that none of the change are saved. In fact, when I set the app to dock to WSJT window, that change is also lost when I next open JTAlert. Any Ideas? Yourhelp is much appreciated.
John - KD1GQ
|
|
|
|
locked
Re: JTAlertX 2.9.2 Changes - Solved
Laurie, VK3AMA <groups08@...>
The forced upper-case grids was only being applied to grids received
via an XML lookup. This is corrected for the next release.
toggle quoted messageShow quoted text
Random Upper-case QTHs is due to how the QTH is recorded on the XML lookup service. If JTAlert is set to log the full QTH returned from an XML lookup, the QTH (which can be a complex address string) is simply passed, unaltered by JTAlert. This setting is under the "Logging" section of the Settings window. If JTAlert is set to NOT log the full XML QTH, it attempts to determine the QTH, discarding irrelevant data, often from complex address data (qrz.com doesn't have a dedicated QTH XML field!). Since JTAlert is manipulating this XML returned data it does apply character case formatting (first character upper, remaining lower). This setting will result in more consistent formatting of the logged QTH. de Laurie VK3AMA
On 6/04/2017 2:21 AM, Ed Wilson
ed.wilson@... [HamApps] wrote:
|
|
|
|
locked
Re: JTAlertX 2.9.2 Changes
Ed Wilson
Mike, You are correct!!! I guess that even long-time users of JTAlert such as me need to check for new settings now and then. This probably was in the release notes as well...my bad. Ed, K0KC k0kc@... http://k0kc.us/
From: "Black Michael mdblack98@... [HamApps]" To: "HamApps@..." Sent: Wednesday, April 5, 2017 1:23 PM Subject: Re: [HamApps] JTAlertX 2.9.2 Changes There's a realtively new setting under "Alerts/CQ and QRZ" for using a "#" indicator for directional CQs so those kind of CQ's stick out....and you can hover over the call slot to see the CQ line. You probably just have the "*" checked. de Mike W9MDB From: "Ed Wilson ed.wilson@... [HamApps]" <HamApps@...> To: "HamApps@..." Sent: Wednesday, April 5, 2017 12:06 PM Subject: Re: [HamApps] JTAlertX 2.9.2 Changes Laurie, I forgot to mention another change in JTAlert behavior that I have observed perhaps with 2.9.1 or maybe earlier. When a station calls CQ DX (say CQ DX K0KC EN80), the asterisk (*) shows in the call sign display in JTAlert. I seem to recall that the asterisk did not show previously in such cases so that one could double-click on the call in JTAlert and not call someone who was not DX. Again, if this change was intentional, I apologize. Thanks! Ed, K0KC k0kc@... http://k0kc.us/ From: "Ed Wilson ed.wilson@... [HamApps]" To: "HamApps@..." Sent: Wednesday, April 5, 2017 12:25 PM Subject: [HamApps] JTAlertX 2.9.2 Changes Laurie, I installed 2.9.2 this morning hoping that the last two characters in the Grid would not be forced to ALL CAPS as was the case with 2.9.1. Unfortunately, it still seems that all characters in the Grid are still being forced to ALL CAPS in most, but not all, instances. Another change that I observed in 2.9.2 is that the QTH is now forced to ALL CAPS, again in most instances, but not all. Is there a setting that I have missed? I would like to see the Grid show with the first four characters in upper case and the last two in lower case as has been the convention for many years. I would also like to see the QTH displayed with the first letter capitalized and the rest of the city name (QTH) in lower case. I apologize if these changes were intentional and if I am the only person who wants to go back to the "old" way that the log information was presented; if so, please just ignore this email. Although I do not think it matters, I am currently using HRD 5.24 for my logging. Thanks! Ed, K0KC k0kc@... http://k0kc.us/
|
|
|
|
locked
Re: JTAlertX 2.9.2 Changes
Michael Black
There's a realtively new setting under "Alerts/CQ and QRZ" for using a "#" indicator for directional CQs so those kind of CQ's stick out....and you can hover over the call slot to see the CQ line. You probably just have the "*" checked. de Mike W9MDB
From: "Ed Wilson ed.wilson@... [HamApps]" To: "HamApps@..." Sent: Wednesday, April 5, 2017 12:06 PM Subject: Re: [HamApps] JTAlertX 2.9.2 Changes Laurie, I forgot to mention another change in JTAlert behavior that I have observed perhaps with 2.9.1 or maybe earlier. When a station calls CQ DX (say CQ DX K0KC EN80), the asterisk (*) shows in the call sign display in JTAlert. I seem to recall that the asterisk did not show previously in such cases so that one could double-click on the call in JTAlert and not call someone who was not DX. Again, if this change was intentional, I apologize. Thanks! Ed, K0KC k0kc@... http://k0kc.us/ From: "Ed Wilson ed.wilson@... [HamApps]" To: "HamApps@..." Sent: Wednesday, April 5, 2017 12:25 PM Subject: [HamApps] JTAlertX 2.9.2 Changes Laurie, I installed 2.9.2 this morning hoping that the last two characters in the Grid would not be forced to ALL CAPS as was the case with 2.9.1. Unfortunately, it still seems that all characters in the Grid are still being forced to ALL CAPS in most, but not all, instances. Another change that I observed in 2.9.2 is that the QTH is now forced to ALL CAPS, again in most instances, but not all. Is there a setting that I have missed? I would like to see the Grid show with the first four characters in upper case and the last two in lower case as has been the convention for many years. I would also like to see the QTH displayed with the first letter capitalized and the rest of the city name (QTH) in lower case. I apologize if these changes were intentional and if I am the only person who wants to go back to the "old" way that the log information was presented; if so, please just ignore this email. Although I do not think it matters, I am currently using HRD 5.24 for my logging. Thanks! Ed, K0KC k0kc@... http://k0kc.us/
|
|
|
|
locked
Re: JTAlertX 2.9.2 Changes
Ed Wilson
Laurie, I forgot to mention another change in JTAlert behavior that I have observed perhaps with 2.9.1 or maybe earlier. When a station calls CQ DX (say CQ DX K0KC EN80), the asterisk (*) shows in the call sign display in JTAlert. I seem to recall that the asterisk did not show previously in such cases so that one could double-click on the call in JTAlert and not call someone who was not DX. Again, if this change was intentional, I apologize. Thanks! Ed, K0KC k0kc@... http://k0kc.us/
From: "Ed Wilson ed.wilson@... [HamApps]" To: "HamApps@..." Sent: Wednesday, April 5, 2017 12:25 PM Subject: [HamApps] JTAlertX 2.9.2 Changes Laurie, I installed 2.9.2 this morning hoping that the last two characters in the Grid would not be forced to ALL CAPS as was the case with 2.9.1. Unfortunately, it still seems that all characters in the Grid are still being forced to ALL CAPS in most, but not all, instances. Another change that I observed in 2.9.2 is that the QTH is now forced to ALL CAPS, again in most instances, but not all. Is there a setting that I have missed? I would like to see the Grid show with the first four characters in upper case and the last two in lower case as has been the convention for many years. I would also like to see the QTH displayed with the first letter capitalized and the rest of the city name (QTH) in lower case. I apologize if these changes were intentional and if I am the only person who wants to go back to the "old" way that the log information was presented; if so, please just ignore this email. Although I do not think it matters, I am currently using HRD 5.24 for my logging. Thanks! Ed, K0KC k0kc@... http://k0kc.us/
|
|
|
|
locked
JTAlertX 2.9.2 Changes
Ed Wilson
Laurie, I installed 2.9.2 this morning hoping that the last two characters in the Grid would not be forced to ALL CAPS as was the case with 2.9.1. Unfortunately, it still seems that all characters in the Grid are still being forced to ALL CAPS in most, but not all, instances. Another change that I observed in 2.9.2 is that the QTH is now forced to ALL CAPS, again in most instances, but not all. Is there a setting that I have missed? I would like to see the Grid show with the first four characters in upper case and the last two in lower case as has been the convention for many years. I would also like to see the QTH displayed with the first letter capitalized and the rest of the city name (QTH) in lower case. I apologize if these changes were intentional and if I am the only person who wants to go back to the "old" way that the log information was presented; if so, please just ignore this email. Although I do not think it matters, I am currently using HRD 5.24 for my logging. Thanks! Ed, K0KC k0kc@... http://k0kc.us/
|
|
|
|
locked
Re: logging not confirmed and failure to display worked B 4.
Laurie, VK3AMA <groups08@...>
On 5/04/2017 2:29 PM, rbreshe275@... [HamApps] wrote:
Richard, If JTAlert is reporting a failure to confirm logging and the QSO is logged, usually indicates that the "Check QSO Log Record" time needs to be increased. This may be due to an underpowered PC or the logger performing other actions (like uploading to online logs) before actually writing the QSO to its log and JTAlert trying to read the log before it is writtenit in order to try and confirm that the QSO did get logged. Visit the JTAlert Settings and navigate to the "Miscellaneous -> Performance" section and increase the "Check QSO Log Record" time. For DXKeeper if it is uploading to online logs, I suggest 10 seconds. You may have to adjust this a couple of times. If you still get the failure to confirm message after increasing this time, use the "? -> Contact Support" menu, on the JTAlert title-bar, to send me your Configuration and Session files for analysis. Be sure to send the files within 24 hours of a logging so I have something to examine. de Laurie VK3AMA
|
|
|
|
locked
logging not confirmed and failure to display worked B 4.
Richard Breshears
When I log to DX Keeper from wsjt x thru JTx alert I get a notice that says cannot confirm logging. I do not get a worked B4 notice on JT alert in the call sign window. The QSO's are logged in DX Keeper. It seems that JT alert is not able to read the log for the B4 look up. Any solutions or ideas welcome. Thanks WE6V 73 Richard
|
|
|
|
locked
New JTAlert 2.9.2 available - Fixes and Changes
HamApps Support (VK3AMA) <groups08@...>
JTAlert Download Link: Visit HamApps.com for the link and upgrade instructions Please review these Release Notes.... � Changes: de Laurie VK3AMA
|
|
|
|
locked
Re: New State is not a new state - ignoring
JTAlert Support (VK3AMA)
On 4/04/2017 8:05 AM, 77indianajones@...
[HamApps] wrote:
Marcus, The usual cause of this is tracking States by individual modes and having manually unset a State as needed for only one mode and then receiving a decode of that State for another mode. For example un-setting the State for JT65, the receiving a JT9 decode will trigger the State alert. If you believe you have correctly set the needed States and are still getting incorrect alerts, I will need to examine your session and config files for an identified case, the Callsign and the UTC date/time. Please use the "? -> Contact Support" menu, on the JTAlert title-bar, to send me your Configuration and Session files for analysis. Only the most recent 24hours of activity is retained in the session files, so don't wait too long before sending and be sure to identify the offending decode. de Laurie VK3AMA
|
|
|
|
locked
Re: : Re: Lock Wide Graph
Laurie, VK3AMA <groups08@...>
On 4/04/2017 10:55 AM, bswag@... [HamApps] wrote:
Bill, Visit the JTAlert Settings, Applications -> WSJT-X section and enable the "Waterfall follows WSJT-X minimize and restore" setting. While this doesn't provide Waterfall docking, it will bring the Waterfall forward of other windows when the JTAlert window is made active and brings the WSJT-X forward. de Laurie VK3AMA
|
|
|
|
locked
Re: : Re: Lock Wide Graph
Laurie - Thank you for answer. I was hoping that the ability was already present and I just didn't know how to use it. I definitely like the feature to dock the JT Alert and JT Macro windows. Maybe the WSJTx developers will do that at some point. I will take your suggestion to contact them.
Thanks and 73! Bill, N8KSG
|
|
|
|
locked
Re: New State is not a new state - ignoring
Laurie, VK3AMA <groups08@...>
On 4/04/2017 8:05 AM,
77indianajones@... [HamApps] wrote:
Marcus, The usual cause of this is tracking States by individual modes and having manually unset a State as needed for only one mode and then receiving a decode of that State for another mode. For example unsetting the State for JT65, the receiving a JT9 decode will trigger the State alert. If you believe you have correctly set the needed States and are still getting incorrect alerts, I will need to examine your session and config files for an identified case, the Callsign and the UTC date/time. Please use the "? -> Contact Support" menu, on the JTAlert title-bar, to send me your Configuration and Session files for analysis. Only the most recent 24hours of activity is retained in the session files, so don't wait too long before sending and be sure to identify the offending decode. de Laurie VK3AMA
|
|
|
|
locked
Re: Lock Wide Graph
Laurie, VK3AMA <groups08@...>
On 3/04/2017 10:54 PM, Black Michael
mdblack98@... [HamApps] wrote:
Mike, I have not added it because I don't feel it should be JTAlert responsibility along with the extra overhead it would add to an already tight loop monitoring the different windows and their states (moved, minimised, maximised and if changed from the last checked state). This has been discussed previously (quite a while ago). IMO, it should be the responsibility of WSJT-X to provide this functionality. The Waterfall is a child of WSJT-X and should be handled its parent, the main WSJT-X window. This needs to be coded by the WSJT-X devs, who in the past have shown no interest in doing so when it has been raised as a feature request. In the past I reluctantly added the ability to JTAlert to have the Waterfall follow the minimize/restore/bring-forward state of the WSJT-X main window. This was after numerous requests and the unwillingness of the WSJT-X devs to add Waterfall docking to their program. Sorry, I will not be adding to JTAlert the docking of the Waterfall to the main WSJT-X gui. This is functionality that WSJT-X should be responsible for, IMO. de Laurie VK3AMA
|
|
|
|
locked
Re: Lock Wide Graph
Laurie, VK3AMA <groups08@...>
On 3/04/2017 8:05 PM, bswag@... [HamApps] wrote:
Bill, Not possible within the current WSJT-X. Your best to raise this with the WSJT-X developers, they may have changed their stance on not providing this functionality within their program since it was last requested and rejected. de Laurie VK3AMA
|
|
|
|
locked
New State is not a new state - ignoring
77indianajones@...
Hello everyone, JTAlertX 2.9.1. I am tracking wanted State and wanted DXCC by band/mode for JT9 and JT65. But I've realized that it's announcing stations as New State and highlighting them yellow yet I've unchecked them for the band and mode. Anyone else observed this? Sincerely, Marcus Sutliff/N5ZY Edmond Amateur Radio Society License Class Coordinator, VP. ARRL Volunteer Examiner
|
|
|
|
locked
Re: Lock Wide Graph
Michael Black
Hmmm...not sure why Laurie hasn't added that function. Might be a reason for it. I've found clicking on JTAlert brings the waterfall to the top. de Mike W9MDB From: "bswag@... [HamApps]" To: HamApps@... Sent: Monday, April 3, 2017 7:43 AM Subject: [HamApps] Lock Wide Graph Can anyone tell me how (if possible) I can lock the wide graph display to the main WSJTx window, similar to how the JTAlert & Macro windows can be locked? I'd like to be able to have it move with the main display, and also come to the top at the end of the TX/RX period as the other windows do. 73, Bill N8KSG
|
|
|