[wsjt-devel] R: Re: wsjtx-1.4.0-rc4-Darwin Rig Control Error
Hello Bill Franco politely ask if the version for windows to let the cat test so that we can give reports. there is a compatibility list of the various models I own a Yaesu FT DX 3000 problems and cat Fake lt ditto with Icom 756pro3 Congratulations to the whole group developers are doing a great job I wanted to alert you to a problem when you install various versions * * .txt files .adi replaced size zero so the log is lost folder C: \ Users \ to \ AppData \ Local \ WSJT-X 73 Franco excuse translation google Ogg: Re: [wsjt-devel] wsjtx-1.4.0-rc4-Darwin Rig Control Error On 13/03/2015 21:34, William Wuttke wrote: Hi William, CC'ing to John as he looks after Mac support for the WSJT programs. Sorry you are having issues with the WSJT-X v1.4.0-rc4 beta release. So I can see what is going wrong, here is an instrumented version of WSJT-X: https://dl.dropboxusercontent.com/u/4192709/wsjtx-1.4.0-rc4-Darwin-CAT-trace. dmg There is no need to install it, just run it directly from the installer DMG. Please run the following test: 1) Start the application, 2) Change band using the WSJT-X band drop down menu, 3) When the error occurs, click Cancel to exit the application. The run will have created a trace log file: $TMPDIR/WSJT-X_trace.log -- Dive into the World of Parallel Programming The Go Parallel Website, sponsored by Intel and developed in partnership with Slashdot Media, is your hub for all things parallel software development, from weekly thought leadership blogs to news, videos, case studies, tutorials and more. Take a look and join the conversation now. http://goparallel.sourceforge.net/ ___ wsjt-devel mailing list wsjt-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wsjt-devel
Re: [wsjt-devel] R: Re: wsjtx-1.4.0-rc4-Darwin Rig Control Error
On 14/03/2015 22:00, Franco wrote: Hi Franco, Hello Bill Franco politely ask if the version for windows to let the cat test so that we can give reports. I will reply to that off list a little later. there is a compatibility list of the various models I own a Yaesu FT DX 3000 problems and cat Fake lt ditto with Icom 756pro3 Congratulations to the whole group developers are doing a great job I wanted to alert you to a problem when you install various versions * * .txt files .adi replaced size zero so the log is lost Your old log files are not lost, you need to move the old log files to the new folder. If you have made new QSOs then you must merge the log files together. folder C: \ Users \ to \ AppData \ Local \ WSJT-X 73 Franco excuse translation google 73 Bill G4WJS. Ogg: Re: [wsjt-devel] wsjtx-1.4.0-rc4-Darwin Rig Control Error On 13/03/2015 21:34, William Wuttke wrote: Hi William, CC'ing to John as he looks after Mac support for the WSJT programs. Sorry you are having issues with the WSJT-X v1.4.0-rc4 beta release. So I can see what is going wrong, here is an instrumented version of WSJT-X: https://dl.dropboxusercontent.com/u/4192709/wsjtx-1.4.0-rc4-Darwin-CAT-trace. dmg There is no need to install it, just run it directly from the installer DMG. Please run the following test: 1) Start the application, 2) Change band using the WSJT-X band drop down menu, 3) When the error occurs, click Cancel to exit the application. The run will have created a trace log file: $TMPDIR/WSJT-X_trace.log -- Dive into the World of Parallel Programming The Go Parallel Website, sponsored by Intel and developed in partnership with Slashdot Media, is your hub for all things parallel software development, from weekly thought leadership blogs to news, videos, case studies, tutorials and more. Take a look and join the conversation now. http://goparallel.sourceforge.net/ ___ wsjt-devel mailing list wsjt-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wsjt-devel -- Dive into the World of Parallel Programming The Go Parallel Website, sponsored by Intel and developed in partnership with Slashdot Media, is your hub for all things parallel software development, from weekly thought leadership blogs to news, videos, case studies, tutorials and more. Take a look and join the conversation now. http://goparallel.sourceforge.net/ ___ wsjt-devel mailing list wsjt-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wsjt-devel
Re: [wsjt-devel] WSJT-X: automatic processing of received messages enhancements
On 14/03/2015 21:14, Michael Black wrote: Thanks for spotting that Mike. 73 Bill G4WJS. -- Dive into the World of Parallel Programming The Go Parallel Website, sponsored by Intel and developed in partnership with Slashdot Media, is your hub for all things parallel software development, from weekly thought leadership blogs to news, videos, case studies, tutorials and more. Take a look and join the conversation now. http://goparallel.sourceforge.net/ ___ wsjt-devel mailing list wsjt-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wsjt-devel
Re: [wsjt-devel] CQ 000
John G4KLA mentioned: I see CQ 000 for some of the same stations that Mike reported: IW1ARK, VA3MJR, GW3UOF for example. ALL.TXT goes back to Oct 14. First occurrence of CQ 000 on Feb 4. All CQ 000 are for JT65 decodes - none seen for JT9 but there are many fewer JT9 decodes compared to JT65. I too have seen quite a bit of these - I don't think I've worked any of the stations that were calling CQ 000 ... Here's the calls that I've seen with this in March 2015: IW1ARK DF9FP RX4CG IK8UHA WA3MEZ G6CHD UN5J I'm running 1.5 ... and I don't recall whether I saw this with 1.4. Bob W1QA -- Dive into the World of Parallel Programming The Go Parallel Website, sponsored by Intel and developed in partnership with Slashdot Media, is your hub for all things parallel software development, from weekly thought leadership blogs to news, videos, case studies, tutorials and more. Take a look and join the conversation now. http://goparallel.sourceforge.net/ ___ wsjt-devel mailing list wsjt-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wsjt-devel
Re: [wsjt-devel] WSJT-X: automatic processing of received messagesenhancements
I have had several qso's this evening using 5056 both calling cq and answering cq calls and the double clicking the sent text for a reply worked fine as did the log input but all calls were standard calls. The 1 thing I noticed was I started to call cq but got distracted a station replied and I never noticed, while tx was still enabled it did not send a 2nd cq it waited for me to reply so it missed a minute, normally it would continue to call cq, I noticed after the station called me twice and the qso went ahead as normal. Richard m0clz -Original Message- From: Bill Somerville Sent: Saturday, March 14, 2015 7:26 PM To: WSJT software development Subject: [wsjt-devel] WSJT-X: automatic processing of received messagesenhancements Hi All, I have just committed the second phase of my changes related to compound callsigns to the development branch. Here is the commit message: r5055 | bsomervi | 2015-03-14 19:13:18 + (Sat, 14 Mar 2015) | 21 lines Improved automatic message handling More consistent and accurate processing of compund callsigns including recognizing the user's call in both base and fully qualified form, extracting reports from special type one and type two compound call messages. Ensure that CQ DX message prefixes are recognized and processd correctly. The cycle of double clicking through a QSO has been enhanced to recognoize the standard messages correctly and use the correct next message. The automatic transmission button Enable Tx now does what it says and does not double as a stop transmit button. This allows the current transmission to complete even if the automatic transmission feature is disabled. In line with this the stop sending after a 73 message is sent feature turns off the automatic transmission enable at the start of the sending of a 73 message and also the next message is now set up as the CQ message automatically in this scenario. A 73 message is now either a standard message containing the word 73 or any free text message containing 73 (not necessarily as a distinct word). This change is a fairly radical reworking of the way incoming messages are parsed and the actions taken when messages are double clicked in the activity windows. It should handle QSOs by and with compound callsign holders far better than previously and has other benefits for all QSO types. I strongly recommend that testers experiment with using double clicks in the activity to progress their QSOs and report back any incorrect behaviour of the application. With these changes I find that having the settings Double-click on call sets Tx enable and Disable Tx after sending 73 both checked makes the QSO process extremely smooth using just double-clicks on calls and responses, only having to revert to specific clicks and typing when I want to send a free text message or if my QSO partner sends an out of sequence message. If you are testing these changes; please double check that, when you come to log the QSO, the callsign, the report sent and received have been correctly transferred to the Log QSO pop up dialog. 73 Bill G4WJS. -- Dive into the World of Parallel Programming The Go Parallel Website, sponsored by Intel and developed in partnership with Slashdot Media, is your hub for all things parallel software development, from weekly thought leadership blogs to news, videos, case studies, tutorials and more. Take a look and join the conversation now. http://goparallel.sourceforge.net/ ___ wsjt-devel mailing list wsjt-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wsjt-devel - No virus found in this message. Checked by AVG - www.avg.com Version: 2015.0.5751 / Virus Database: 4306/9299 - Release Date: 03/14/15 -- Dive into the World of Parallel Programming The Go Parallel Website, sponsored by Intel and developed in partnership with Slashdot Media, is your hub for all things parallel software development, from weekly thought leadership blogs to news, videos, case studies, tutorials and more. Take a look and join the conversation now. http://goparallel.sourceforge.net/ ___ wsjt-devel mailing list wsjt-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wsjt-devel
Re: [wsjt-devel] UDP Server
Hi again Mike, related to this I have my new processing of decoded messages changes ready for commit. I was testing them but I have done enough to justify committing them to the development branch. They are going to collide with your UDP receiver changes so I will commit them now, you probably want to update now before you get too involved in changing mainwindow.cpp otherwise the eventual merge is going to be complex. I will commit in a few minutes. 73 Bill G4WJS. On 14/03/2015 15:08, Bill Somerville wrote: Hi Mike, I did note your comments on the Hamapps list related to this. First off it would help to have a clear idea of what remote control features you are considering. I ask because the way that the activity windows are currently implemented may not be very amenable what you might wish to do. With respect to processing incoming UDP datagrams, you have two choices, either asynchronous or synchronous. You might choose synchronous is there is likely to be long running activity as a result of receiving a datagram. In the synchronous case you would need to have a thread available and bind the UDP socket in that thread so that any activity does not block the GUI thread. The asynchronous approach is normally harder to implement but Qt actually makes it the easiest and most natural approach. You bind the UDP socket in the main GUI thread and connect the readReady signal to a suitable slot. In that slot you process the incoming datagrams. The signal will only be emitted when there is a pending UDP datagram awaiting processing. Just be sure that slot that handles the readReady signal does not block. The BIG advantage of asynchronous processing is that it is thread safe since everything runs in the main thread. Your doCall mechanism is duplicating what Qt does for you already when it emits the readReady signal. Beware reading strings from a socket, sockets are byte oriented and the QString class is unicode, you need to define a protocol for the on the wire transfer - utf8 for strings is usually good ASCII may be acceptable - and translate as necessary. Looks to me like you are attempting to receive a decoded message and trigger a double click on that message, you may find it easier to receive a callsign+DF pair and search for that in the activity list. You should be starting with a protocol and defined messages that WSJT-X is willing to accept. Seems to me that you are starting with an implementation perhaps without thinking through how it is going to work for the user. HTH 73 Bill G4WJS. On 14/03/2015 14:40, Michael Black wrote: After some communication with Laurie on JTAlert we have started down the path of integrating WSJT-X a bit more. The idea is that WSJT-X should have a UDPServer that can receive commands to do things so, for example, one could double-click on a JTAlert entry and it could command WSJT-X to do its thing. To this end I started coding one but am having QT class problems that are befuddling me and was hoping someone (Bill?) could assist. So far this implementation is intended to just take a CQ decoded message and put it in the Rx Frequency window. Then I was going to add the double-click action once the first was working and stable. I got this somewhat working but debugging complained about sending signals when I just threaded a function inside then mainwindow.cpp plus gui stuff isn't thread safe. So I made the udp server a separate class and started trying slots/signals. But now connecting the slot/signal burps on compiling and I can't quite figure out the magic incantation to make it happy. This is the line it complains about on MainWindow::doCall connect(m_UDPServer,UDPServer::on_doCall,this,MainWindow::doCall); doCall is declared as a public slot in mainwindow.h and defined in mainwindow.cpp C:/JTSDK/qt5/5.2.1/mingw48_32/include/QtCore/qobject.h: In instantiation of 'static QMetaObject::Connection QObject::connect(const type name QtPrivate::FunctionPointerFunc::Object*, Func1, const typename QtPrivate::FunctionPointerFunc2::Object*, Func2, Qt::Connection Type) [with Func1 = void (UDPServer::*)(DecodedText); Func2 = void (MainWindow::*)(DecodedText); typename QtPrivate::FunctionPointerFu nc::Object = UDPServer; typename QtPrivate::FunctionPointerFunc2::Object = MainWindow]': C:\JTSDK\src\wsjtx\mainwindow.cpp:461:69: required from here C:/JTSDK/qt5/5.2.1/mingw48_32/include/QtCore/qobject.h:222:9: error: static assertion failed: No Q_OBJECT in the class with the signal Q_STATIC_ASSERT_X(QtPrivate::HasQ_OBJECT_Macrotypename SignalType::Object::Value, ^ Here's a UDP client to work with it that just cycles through a few CQ messages. All being done on port 5001 right now. https://www.dropbox.com/s/pp5z7nqrtdeug9a/UDPClient.exe?dl=0 Mike W9MDB -- Dive into the World of Parallel Programming The Go Parallel Website, sponsored by
Re: [wsjt-devel] WSJT-X: automatic processing of received messages enhancements
Trivial patch to fix compiler warning about s1 initialization
Index: decodedtext.cpp
===
--- decodedtext.cpp (revision 5055)
+++ decodedtext.cpp (working copy)
@@ -5,7 +5,7 @@
QString DecodedText::CQersCall()
{
// extract the CQer's call TODO: does this work with all call
formats?
- int s1;
+ int s1=0;
int position;
if ((position = _string.indexOf ( CQ DX )) = 0)
{
-Original Message-
From: Bill Somerville [mailto:g4...@classdesign.com]
Sent: Saturday, March 14, 2015 2:27 PM
To: WSJT software development
Subject: [wsjt-devel] WSJT-X: automatic processing of received messages
enhancements
Hi All,
I have just committed the second phase of my changes related to compound
callsigns to the development branch. Here is the commit message:
r5055 | bsomervi | 2015-03-14 19:13:18 + (Sat, 14 Mar 2015) | 21 lines
Improved automatic message handling
More consistent and accurate processing of compund callsigns including
recognizing the user's call in both base and fully qualified form,
extracting reports from special type one and type two compound call
messages. Ensure that CQ DX message prefixes are recognized and
processd correctly.
The cycle of double clicking through a QSO has been enhanced to
recognoize the standard messages correctly and use the correct next
message. The automatic transmission button Enable Tx now does what it
says and does not double as a stop transmit button. This allows the current
transmission to complete even if the automatic transmission feature is
disabled. In line with this the stop sending after a 73 message is sent
feature turns off the automatic transmission enable at the start of the
sending of a 73 message and also the next message is now set up as the CQ
message automatically in this scenario. A 73 message is now either a
standard message containing the word 73 or any free text message
containing 73 (not necessarily as a distinct word).
This change is a fairly radical reworking of the way incoming messages are
parsed and the actions taken when messages are double clicked in the
activity windows. It should handle QSOs by and with compound callsign
holders far better than previously and has other benefits for all QSO types.
I strongly recommend that testers experiment with using double clicks in the
activity to progress their QSOs and report back any incorrect behaviour of
the application.
With these changes I find that having the settings Double-click on call
sets Tx enable and Disable Tx after sending 73 both checked makes the QSO
process extremely smooth using just double-clicks on calls and responses,
only having to revert to specific clicks and typing when I want to send a
free text message or if my QSO partner sends an out of sequence message.
If you are testing these changes; please double check that, when you come to
log the QSO, the callsign, the report sent and received have been correctly
transferred to the Log QSO pop up dialog.
73
Bill
G4WJS.
--
Dive into the World of Parallel Programming The Go Parallel Website,
sponsored by Intel and developed in partnership with Slashdot Media, is your
hub for all things parallel software development, from weekly thought
leadership blogs to news, videos, case studies, tutorials and more. Take a
look and join the conversation now. http://goparallel.sourceforge.net/
___
wsjt-devel mailing list
wsjt-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wsjt-devel
--
Dive into the World of Parallel Programming The Go Parallel Website, sponsored
by Intel and developed in partnership with Slashdot Media, is your hub for all
things parallel software development, from weekly thought leadership blogs to
news, videos, case studies, tutorials and more. Take a look and join the
conversation now. http://goparallel.sourceforge.net/
___
wsjt-devel mailing list
wsjt-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wsjt-devel
Re: [wsjt-devel] CQ 000
Turns out this is a bug with a recent JT65HF version. Soon to be fixed we hope Mike W9MDB -Original Message- From: Bob McCormick W1QA [mailto:e...@w1qa.com] Sent: Saturday, March 14, 2015 3:48 PM To: 'WSJT software development' Subject: Re: [wsjt-devel] CQ 000 John G4KLA mentioned: I see CQ 000 for some of the same stations that Mike reported: IW1ARK, VA3MJR, GW3UOF for example. ALL.TXT goes back to Oct 14. First occurrence of CQ 000 on Feb 4. All CQ 000 are for JT65 decodes - none seen for JT9 but there are many fewer JT9 decodes compared to JT65. I too have seen quite a bit of these - I don't think I've worked any of the stations that were calling CQ 000 ... Here's the calls that I've seen with this in March 2015: IW1ARK DF9FP RX4CG IK8UHA WA3MEZ G6CHD UN5J I'm running 1.5 ... and I don't recall whether I saw this with 1.4. Bob W1QA -- Dive into the World of Parallel Programming The Go Parallel Website, sponsored by Intel and developed in partnership with Slashdot Media, is your hub for all things parallel software development, from weekly thought leadership blogs to news, videos, case studies, tutorials and more. Take a look and join the conversation now. http://goparallel.sourceforge.net/ ___ wsjt-devel mailing list wsjt-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wsjt-devel -- Dive into the World of Parallel Programming The Go Parallel Website, sponsored by Intel and developed in partnership with Slashdot Media, is your hub for all things parallel software development, from weekly thought leadership blogs to news, videos, case studies, tutorials and more. Take a look and join the conversation now. http://goparallel.sourceforge.net/ ___ wsjt-devel mailing list wsjt-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wsjt-devel
[wsjt-devel] DX Grid leftovers
DX Grid doesn't get cleared if you double-click on an entry that has no grid. Noticed this while debugging the udp server code. The offsets from the diff are wrong on this patch (I'm in the middle of other mods) but easy enough to find and fix. Mike W9MDB @@ -2027,12 +2030,12 @@ // i.e. compound version of same base call ui-dxCallEntry-setText(hiscall); } + ui-dxGridEntry-setText(); // set empty in case we get no grid result if (gridOK(hisgrid)) ui-dxGridEntry-setText(hisgrid); if (ui-dxGridEntry-text()==) lookup(); m_hisGrid = ui-dxGridEntry-text(); - int n = decodedtext.timeInSeconds(); int nmod=n%(m_TRperiod/30); m_txFirst=(nmod!=0); -- Dive into the World of Parallel Programming The Go Parallel Website, sponsored by Intel and developed in partnership with Slashdot Media, is your hub for all things parallel software development, from weekly thought leadership blogs to news, videos, case studies, tutorials and more. Take a look and join the conversation now. http://goparallel.sourceforge.net/___ wsjt-devel mailing list wsjt-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wsjt-devel
[wsjt-devel] CALL3.TXT
I see there's an attempt to lookup grids if needed from call3.txt but no such file seems to be included. I assume it's the same CALL3.TXT that comes from HRD? Is this an oversight or dead code? Mike W9MDB -- Dive into the World of Parallel Programming The Go Parallel Website, sponsored by Intel and developed in partnership with Slashdot Media, is your hub for all things parallel software development, from weekly thought leadership blogs to news, videos, case studies, tutorials and more. Take a look and join the conversation now. http://goparallel.sourceforge.net/___ wsjt-devel mailing list wsjt-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wsjt-devel
[wsjt-devel] wsjtx-1.4.0-rc4-Darwin Rig Control Error
When changing bands - Rig Split operation enabled - Yaesu FT-DX1200 - use Hamlib FT-DX5000 settings on a USB serial port 4800-8-1, No handshake, RTS enabled, USB mode, Poll interval 2s. I get the following error: Rig Control Error Hamlib error: Communication timed out while getting mode of split TX VFO Retry OK. The above rig setup has been working fine for me for a log time on v1.3, r3673. -- Dive into the World of Parallel Programming The Go Parallel Website, sponsored by Intel and developed in partnership with Slashdot Media, is your hub for all things parallel software development, from weekly thought leadership blogs to news, videos, case studies, tutorials and more. Take a look and join the conversation now. http://goparallel.sourceforge.net/ ___ wsjt-devel mailing list wsjt-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wsjt-devel
Re: [wsjt-devel] wsjtx-1.4.0-rc4-Darwin Rig Control Error
Please report your problem to Bill, G4WJS, who has handled most of the CAT control issues. His email address is g4...@classdesign.com . -- 73, Joe, K1JT On 3/13/2015 5:34 PM, William Wuttke wrote: When changing bands - Rig Split operation enabled - Yaesu FT-DX1200 - use Hamlib FT-DX5000 settings on a USB serial port 4800-8-1, No handshake, RTS enabled, USB mode, Poll interval 2s. I get the following error: Rig Control Error Hamlib error: Communication timed out while getting mode of split TX VFO Retry OK. The above rig setup has been working fine for me for a log time on v1.3, r3673. -- Dive into the World of Parallel Programming The Go Parallel Website, sponsored by Intel and developed in partnership with Slashdot Media, is your hub for all things parallel software development, from weekly thought leadership blogs to news, videos, case studies, tutorials and more. Take a look and join the conversation now. http://goparallel.sourceforge.net/ ___ wsjt-devel mailing list wsjt-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wsjt-devel -- Dive into the World of Parallel Programming The Go Parallel Website, sponsored by Intel and developed in partnership with Slashdot Media, is your hub for all things parallel software development, from weekly thought leadership blogs to news, videos, case studies, tutorials and more. Take a look and join the conversation now. http://goparallel.sourceforge.net/ ___ wsjt-devel mailing list wsjt-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wsjt-devel
Re: [wsjt-devel] wsjtx-1.4.0-rc4-Darwin Rig Control Error
On 13/03/2015 21:34, William Wuttke wrote: Hi William, CC'ing to John as he looks after Mac support for the WSJT programs. Sorry you are having issues with the WSJT-X v1.4.0-rc4 beta release. So I can see what is going wrong, here is an instrumented version of WSJT-X: https://dl.dropboxusercontent.com/u/4192709/wsjtx-1.4.0-rc4-Darwin-CAT-trace.dmg There is no need to install it, just run it directly from the installer DMG. Please run the following test: 1) Start the application, 2) Change band using the WSJT-X band drop down menu, 3) When the error occurs, click Cancel to exit the application. The run will have created a trace log file: $TMPDIR/WSJT-X_trace.log please send me this file for analysis. When changing bands - Rig Split operation enabled - Yaesu FT-DX1200 - use Hamlib FT-DX5000 settings on a USB serial port 4800-8-1, No handshake, RTS enabled, USB mode, Poll interval 2s. I get the following error: Rig Control Error Hamlib error: Communication timed out while getting mode of split TX VFO Retry OK. The above rig setup has been working fine for me for a log time on v1.3, r3673. 73 Bill G4WJS. -- Dive into the World of Parallel Programming The Go Parallel Website, sponsored by Intel and developed in partnership with Slashdot Media, is your hub for all things parallel software development, from weekly thought leadership blogs to news, videos, case studies, tutorials and more. Take a look and join the conversation now. http://goparallel.sourceforge.net/ ___ wsjt-devel mailing list wsjt-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wsjt-devel
Re: [wsjt-devel] WSJT-X Version 1.4.0-rc4
Bill Somerville g4wjs@... writes: What error message are you getting? Mni tnx, 73 de Guy G4DWV/4X1LT 73 Bill G4WJS. Hi Bill, TS2000 support is broken wrt Flex rigs. TS-480 works FB. The error message is Hamlib error: IO error while opening connection to rig. I am really looking forward to the 1.5 RC1 release. Hopefully, I will be able to simultaneously decode JT65 and JT9 - I have spent ages trying to do this with 1.3 and briefly with 1.4 RC4. Is there a known issue in this regard? Sri to wonder OT. Regards Guy G4DWV/4X1LT -- Dive into the World of Parallel Programming The Go Parallel Website, sponsored by Intel and developed in partnership with Slashdot Media, is your hub for all things parallel software development, from weekly thought leadership blogs to news, videos, case studies, tutorials and more. Take a look and join the conversation now. http://goparallel.sourceforge.net/ ___ wsjt-devel mailing list wsjt-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wsjt-devel
[wsjt-devel] UDP Server
After some communication with Laurie on JTAlert we have started down the
path of integrating WSJT-X a bit more.
The idea is that WSJT-X should have a UDPServer that can receive commands to
do things so, for example, one could double-click on a JTAlert entry and it
could command WSJT-X to do its thing.
To this end I started coding one but am having QT class problems that are
befuddling me and was hoping someone (Bill?) could assist.
So far this implementation is intended to just take a CQ decoded message
and put it in the Rx Frequency window. Then I was going to add the
double-click action once the first was working and stable.
I got this somewhat working but debugging complained about sending signals
when I just threaded a function inside then mainwindow.cpp plus gui stuff
isn't thread safe.
So I made the udp server a separate class and started trying slots/signals.
But now connecting the slot/signal burps on compiling and I can't quite
figure out the magic incantation to make it happy.
This is the line it complains about on MainWindow::doCall
connect(m_UDPServer,UDPServer::on_doCall,this,MainWindow::doCall);
doCall is declared as a public slot in mainwindow.h and defined in
mainwindow.cpp
C:/JTSDK/qt5/5.2.1/mingw48_32/include/QtCore/qobject.h: In instantiation of
'static QMetaObject::Connection QObject::connect(const type
name QtPrivate::FunctionPointerFunc::Object*, Func1, const typename
QtPrivate::FunctionPointerFunc2::Object*, Func2, Qt::Connection
Type) [with Func1 = void (UDPServer::*)(DecodedText); Func2 = void
(MainWindow::*)(DecodedText); typename QtPrivate::FunctionPointerFu
nc::Object = UDPServer; typename QtPrivate::FunctionPointerFunc2::Object
= MainWindow]':
C:\JTSDK\src\wsjtx\mainwindow.cpp:461:69: required from here
C:/JTSDK/qt5/5.2.1/mingw48_32/include/QtCore/qobject.h:222:9: error: static
assertion failed: No Q_OBJECT in the class with the signal
Q_STATIC_ASSERT_X(QtPrivate::HasQ_OBJECT_Macrotypename
SignalType::Object::Value,
^
Here's a UDP client to work with it that just cycles through a few CQ
messages. All being done on port 5001 right now.
https://www.dropbox.com/s/pp5z7nqrtdeug9a/UDPClient.exe?dl=0
Mike W9MDB
#include QUdpSocket
#include QHostInfo
#include UDPServer.h
UDPServer::UDPServer() {
m_kill = false;
}
UDPServer::~UDPServer() {
m_kill = true;
}
void UDPServer::stop() {
m_kill = true;
}
void UDPServer::start()
{
udpSocket = new QUdpSocket(this);
udpSocket-bind(QHostAddress::Any,5001);
while(!m_kill) {
while(udpSocket-hasPendingDatagrams()) {
QByteArray datagram;
datagram.resize(udpSocket-pendingDatagramSize());
QHostAddress sender;
quint16 senderPort;
udpSocket-readDatagram(datagram.data(),datagram.size(),sender,senderPort);
QString calltext(datagram);
//doubleClickOnCall(false,false,calltext);
DecodedText decodedtext;
decodedtext = calltext;
emit on_doCall(decodedtext);
}
}
QThread::msleep(100);
}
#ifndef UDPSERVER_h
#define UDPSERVER_h
#include QTWidgets
#include decodedtext.h
class UDPServer: public QObject
{
private:
QUdpSocket *udpSocket;
int m_kill;
public:
UDPServer();
~UDPServer();
void start();
signals:
void on_doCall(DecodedText decodedtext);
public slots:
void stop();
};
#endif // UDPSERVER_H
udpserver.diff
Description: Binary data
--
Dive into the World of Parallel Programming The Go Parallel Website, sponsored
by Intel and developed in partnership with Slashdot Media, is your hub for all
things parallel software development, from weekly thought leadership blogs to
news, videos, case studies, tutorials and more. Take a look and join the
conversation now. http://goparallel.sourceforge.net/___
wsjt-devel mailing list
wsjt-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wsjt-devel
Re: [wsjt-devel] WSJT-X Version 1.4.0-rc4
On 14/03/2015 14:47, Guy G4DWV/4X1LT wrote: Bill Somerville g4wjs@... writes: What error message are you getting? Mni tnx, 73 de Guy G4DWV/4X1LT 73 Bill G4WJS. Hi Bill, Hi Guy, TS2000 support is broken wrt Flex rigs. TS-480 works FB. The error message is Hamlib error: IO error while opening connection to rig. I am really looking forward to the 1.5 RC1 release. Hopefully, I will be able to simultaneously decode JT65 and JT9 - I have spent ages trying to do this with 1.3 and briefly with 1.4 RC4. Is there a known issue in this regard? Sri to wonder OT. See my reply to your other message off list. Regards Guy G4DWV/4X1LT 73 Bill G4WJS. -- Dive into the World of Parallel Programming The Go Parallel Website, sponsored by Intel and developed in partnership with Slashdot Media, is your hub for all things parallel software development, from weekly thought leadership blogs to news, videos, case studies, tutorials and more. Take a look and join the conversation now. http://goparallel.sourceforge.net/ ___ wsjt-devel mailing list wsjt-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wsjt-devel
Re: [wsjt-devel] UDP Server
Hi Mike, I did note your comments on the Hamapps list related to this. First off it would help to have a clear idea of what remote control features you are considering. I ask because the way that the activity windows are currently implemented may not be very amenable what you might wish to do. With respect to processing incoming UDP datagrams, you have two choices, either asynchronous or synchronous. You might choose synchronous is there is likely to be long running activity as a result of receiving a datagram. In the synchronous case you would need to have a thread available and bind the UDP socket in that thread so that any activity does not block the GUI thread. The asynchronous approach is normally harder to implement but Qt actually makes it the easiest and most natural approach. You bind the UDP socket in the main GUI thread and connect the readReady signal to a suitable slot. In that slot you process the incoming datagrams. The signal will only be emitted when there is a pending UDP datagram awaiting processing. Just be sure that slot that handles the readReady signal does not block. The BIG advantage of asynchronous processing is that it is thread safe since everything runs in the main thread. Your doCall mechanism is duplicating what Qt does for you already when it emits the readReady signal. Beware reading strings from a socket, sockets are byte oriented and the QString class is unicode, you need to define a protocol for the on the wire transfer - utf8 for strings is usually good ASCII may be acceptable - and translate as necessary. Looks to me like you are attempting to receive a decoded message and trigger a double click on that message, you may find it easier to receive a callsign+DF pair and search for that in the activity list. You should be starting with a protocol and defined messages that WSJT-X is willing to accept. Seems to me that you are starting with an implementation perhaps without thinking through how it is going to work for the user. HTH 73 Bill G4WJS. On 14/03/2015 14:40, Michael Black wrote: After some communication with Laurie on JTAlert we have started down the path of integrating WSJT-X a bit more. The idea is that WSJT-X should have a UDPServer that can receive commands to do things so, for example, one could double-click on a JTAlert entry and it could command WSJT-X to do its thing. To this end I started coding one but am having QT class problems that are befuddling me and was hoping someone (Bill?) could assist. So far this implementation is intended to just take a CQ decoded message and put it in the Rx Frequency window. Then I was going to add the double-click action once the first was working and stable. I got this somewhat working but debugging complained about sending signals when I just threaded a function inside then mainwindow.cpp plus gui stuff isn't thread safe. So I made the udp server a separate class and started trying slots/signals. But now connecting the slot/signal burps on compiling and I can't quite figure out the magic incantation to make it happy. This is the line it complains about on MainWindow::doCall connect(m_UDPServer,UDPServer::on_doCall,this,MainWindow::doCall); doCall is declared as a public slot in mainwindow.h and defined in mainwindow.cpp C:/JTSDK/qt5/5.2.1/mingw48_32/include/QtCore/qobject.h: In instantiation of 'static QMetaObject::Connection QObject::connect(const type name QtPrivate::FunctionPointerFunc::Object*, Func1, const typename QtPrivate::FunctionPointerFunc2::Object*, Func2, Qt::Connection Type) [with Func1 = void (UDPServer::*)(DecodedText); Func2 = void (MainWindow::*)(DecodedText); typename QtPrivate::FunctionPointerFu nc::Object = UDPServer; typename QtPrivate::FunctionPointerFunc2::Object = MainWindow]': C:\JTSDK\src\wsjtx\mainwindow.cpp:461:69: required from here C:/JTSDK/qt5/5.2.1/mingw48_32/include/QtCore/qobject.h:222:9: error: static assertion failed: No Q_OBJECT in the class with the signal Q_STATIC_ASSERT_X(QtPrivate::HasQ_OBJECT_Macrotypename SignalType::Object::Value, ^ Here's a UDP client to work with it that just cycles through a few CQ messages. All being done on port 5001 right now. https://www.dropbox.com/s/pp5z7nqrtdeug9a/UDPClient.exe?dl=0 Mike W9MDB -- Dive into the World of Parallel Programming The Go Parallel Website, sponsored by Intel and developed in partnership with Slashdot Media, is your hub for all things parallel software development, from weekly thought leadership blogs to news, videos, case studies, tutorials and more. Take a look and join the conversation now. http://goparallel.sourceforge.net/ ___ wsjt-devel mailing list wsjt-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wsjt-devel -- Dive
Re: [wsjt-devel] UDP Server
I am trying to figure out the best way to do this. I had tried and was successful on using readyReady but now that I think of it I had it in a separate thread and that's not needed. I'll go back and try that again as that is a lot more intuitive. I can ultimately see controlling all button clicks and such..just wanted to start with the obvious one which is Hey WSJT-X.here's a CQ message..do your thing. I was concerned a bit about using the activity list since there's been discussion on when things should get cleared.so JTAlert might at some point keep calls around after WSJT-X has cleared them giving bad behavior. I figured handling an external CQ message was more like the result of double-clicking a Band Activity entry so was trying to repeat the result and if I put the CQ in the RX side I know it's there. I'll play with it a bit and see what works. Thanks. Mike W9MDB From: Bill Somerville [mailto:g4...@classdesign.com] Sent: Saturday, March 14, 2015 10:09 AM To: wsjt-devel@lists.sourceforge.net Subject: Re: [wsjt-devel] UDP Server Hi Mike, I did note your comments on the Hamapps list related to this. First off it would help to have a clear idea of what remote control features you are considering. I ask because the way that the activity windows are currently implemented may not be very amenable what you might wish to do. With respect to processing incoming UDP datagrams, you have two choices, either asynchronous or synchronous. You might choose synchronous is there is likely to be long running activity as a result of receiving a datagram. In the synchronous case you would need to have a thread available and bind the UDP socket in that thread so that any activity does not block the GUI thread. The asynchronous approach is normally harder to implement but Qt actually makes it the easiest and most natural approach. You bind the UDP socket in the main GUI thread and connect the readReady signal to a suitable slot. In that slot you process the incoming datagrams. The signal will only be emitted when there is a pending UDP datagram awaiting processing. Just be sure that slot that handles the readReady signal does not block. The BIG advantage of asynchronous processing is that it is thread safe since everything runs in the main thread. Your doCall mechanism is duplicating what Qt does for you already when it emits the readReady signal. Beware reading strings from a socket, sockets are byte oriented and the QString class is unicode, you need to define a protocol for the on the wire transfer - utf8 for strings is usually good ASCII may be acceptable - and translate as necessary. Looks to me like you are attempting to receive a decoded message and trigger a double click on that message, you may find it easier to receive a callsign+DF pair and search for that in the activity list. You should be starting with a protocol and defined messages that WSJT-X is willing to accept. Seems to me that you are starting with an implementation perhaps without thinking through how it is going to work for the user. HTH 73 Bill G4WJS. On 14/03/2015 14:40, Michael Black wrote: After some communication with Laurie on JTAlert we have started down the path of integrating WSJT-X a bit more. The idea is that WSJT-X should have a UDPServer that can receive commands to do things so, for example, one could double-click on a JTAlert entry and it could command WSJT-X to do its thing. To this end I started coding one but am having QT class problems that are befuddling me and was hoping someone (Bill?) could assist. So far this implementation is intended to just take a CQ decoded message and put it in the Rx Frequency window. Then I was going to add the double-click action once the first was working and stable. I got this somewhat working but debugging complained about sending signals when I just threaded a function inside then mainwindow.cpp plus gui stuff isn't thread safe. So I made the udp server a separate class and started trying slots/signals. But now connecting the slot/signal burps on compiling and I can't quite figure out the magic incantation to make it happy. This is the line it complains about on MainWindow::doCall connect(m_UDPServer,UDPServer::on_doCall,this,MainWindow::doCall); doCall is declared as a public slot in mainwindow.h and defined in mainwindow.cpp C:/JTSDK/qt5/5.2.1/mingw48_32/include/QtCore/qobject.h: In instantiation of 'static QMetaObject::Connection QObject::connect(const type name QtPrivate::FunctionPointerFunc::Object*, Func1, const typename QtPrivate::FunctionPointerFunc2::Object*, Func2, Qt::Connection Type) [with Func1 = void (UDPServer::*)(DecodedText); Func2 = void (MainWindow::*)(DecodedText); typename QtPrivate::FunctionPointerFu nc::Object = UDPServer; typename QtPrivate::FunctionPointerFunc2::Object = MainWindow]': C:\JTSDK\src\wsjtx\mainwindow.cpp:461:69: required from here C:/JTSDK/qt5/5.2.1/mingw48_32/include/QtCore/qobject.h:222:9: error:
Re: [wsjt-devel] UDP Server
Hi All, in case anyone is confused, in this thread all references by me to the readReady() Qt signal should be readyRead() as in QIODevice::readyRead(). I knew what I meant but not what I typed :( 73 Bill G4WJS. -- Dive into the World of Parallel Programming The Go Parallel Website, sponsored by Intel and developed in partnership with Slashdot Media, is your hub for all things parallel software development, from weekly thought leadership blogs to news, videos, case studies, tutorials and more. Take a look and join the conversation now. http://goparallel.sourceforge.net/ ___ wsjt-devel mailing list wsjt-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wsjt-devel
Re: [wsjt-devel] UDP Server
On 14/03/2015 15:19, Michael Black wrote: Hi Mike, I am trying to figure out the best way to do this. I had tried and was successful on using readyReady but now that I think of it I had it in a separate thread and that's not needed. I'll go back and try that again as that is a lot more intuitive. It takes a bit of practice to get used to the Qt asynchronous model. Once you get the hang of it you will see that it is an excellent way of handling multiple tasks in parallel without the complexities and hazards of multiple threads. readReady in the main thread is the right way to go, stick with it ;) The example here: http://doc.qt.io/qt-5/qudpsocket.html#details has everything you need for processing incoming UDP datagrams. For Server you can safely read MainWindow if the processing of the datagrams (processTheDatagram()) doesn't block. I can ultimately see controlling all button clicks and such….just wanted to start with the obvious one which is Hey WSJT-X…here's a CQ message….do your thing. That's ambitious! I was concerned a bit about using the activity list since there's been discussion on when things should get cleared…so JTAlert might at some point keep calls around after WSJT-X has cleared them giving bad behavior. I would probably limit actions on activity to the last reported period. I figured handling an external CQ message was more like the result of double-clicking a Band Activity entry so was trying to repeat the result and if I put the CQ in the RX side I know it's there. OK, but for for now it might be best to limit the remote command to reply to a CQ from the station with callsign X and DF Y. This is probably the most useful remote command that JTAlert can utilize i.e. initiate a QSO from an alert. I'll play with it a bit and see what works… Thanks… Mike W9MDB 73 Bill G4WJS. *From:*Bill Somerville [mailto:g4...@classdesign.com] *Sent:* Saturday, March 14, 2015 10:09 AM *To:* wsjt-devel@lists.sourceforge.net *Subject:* Re: [wsjt-devel] UDP Server Hi Mike, I did note your comments on the Hamapps list related to this. First off it would help to have a clear idea of what remote control features you are considering. I ask because the way that the activity windows are currently implemented may not be very amenable what you might wish to do. With respect to processing incoming UDP datagrams, you have two choices, either asynchronous or synchronous. You might choose synchronous is there is likely to be long running activity as a result of receiving a datagram. In the synchronous case you would need to have a thread available and bind the UDP socket in that thread so that any activity does not block the GUI thread. The asynchronous approach is normally harder to implement but Qt actually makes it the easiest and most natural approach. You bind the UDP socket in the main GUI thread and connect the readReady signal to a suitable slot. In that slot you process the incoming datagrams. The signal will only be emitted when there is a pending UDP datagram awaiting processing. Just be sure that slot that handles the readReady signal does not block. The BIG advantage of asynchronous processing is that it is thread safe since everything runs in the main thread. Your doCall mechanism is duplicating what Qt does for you already when it emits the readReady signal. Beware reading strings from a socket, sockets are byte oriented and the QString class is unicode, you need to define a protocol for the on the wire transfer - utf8 for strings is usually good ASCII may be acceptable - and translate as necessary. Looks to me like you are attempting to receive a decoded message and trigger a double click on that message, you may find it easier to receive a callsign+DF pair and search for that in the activity list. You should be starting with a protocol and defined messages that WSJT-X is willing to accept. Seems to me that you are starting with an implementation perhaps without thinking through how it is going to work for the user. HTH 73 Bill G4WJS. On 14/03/2015 14:40, Michael Black wrote: After some communication with Laurie on JTAlert we have started down the path of integrating WSJT-X a bit more. The idea is that WSJT-X should have a UDPServer that can receive commands to do things so, for example, one could double-click on a JTAlert entry and it could command WSJT-X to do its thing. To this end I started coding one but am having QT class problems that are befuddling me and was hoping someone (Bill?) could assist. So far this implementation is intended to just take a CQ decoded message and put it in the Rx Frequency window. Then I was going to add the double-click action once the first was working and stable. I got this somewhat working but debugging complained about sending signals when I just threaded a function inside then mainwindow.cpp
