Re: [wsjt-devel] FW: UDP interface for WSJT-X control.
He did say he's able to get rid of all file/directory accesses so that will solve that problem. Looks like your first stab got everything covered. 73 Mike W9MDB From: Bill Somerville [mailto:g4...@classdesign.com] Sent: Tuesday, May 05, 2015 8:16 AM To: wsjt-devel@lists.sourceforge.net Subject: Re: [wsjt-devel] FW: UDP interface for WSJT-X control. On 05/05/2015 14:06, Michael Black wrote: Hi Mike, Laurie said he doesn't see anything else he needs. Had to tell him Replay was for getting the current statuses which he didn't quite make the connection.he thought it was related to Decode again. Do you think it might be more aptly named StatusReplay and move the description in NetworkMessage.hpp to right below Status since they're related? I am surprised that there are not other bits of status info that would be helpful, I guess since Laurie has other mechanisms in place there is little direct benefit at the moment. The main thing as far as I am concerned is to get rid of the contention on the file based decodes interface which is blocking WSJT-X in its present form. I would have thought the replay is more related to decodes than status. I have keep the list of commands in numerical order which I think probably makes sense for a implementer of the protocol. I was going to revisit the documentation and note the null byte string behaviour since it isn't documented fully in the Qt QDataStream format. I will try and make everything a bit clearer. 73 Mike W9MDB 73 Bill G4WJS. From: Bill Somerville [mailto:g4...@classdesign.com] Sent: Sunday, May 03, 2015 9:58 AM To: wsjt-devel@lists.sourceforge.net Subject: Re: [wsjt-devel] FW: UDP interface for WSJT-X control. On 03/05/2015 15:42, Michael Black wrote: Hi Mike, Small bug.I tried to see how this was happening but couldn't quite figure it out. Seems when DXCall is empty it is initialized correctly to a 0-length string when the INI file has it as empty. This is expected behaviour. The Qt serialization format differentiates between a null QString and an empty QString as documented here: http://doc.qt.io/qt-5/datastreamformat.html . For this case I expect that both can be interpreted as empty. I am a bit surprised this is happening because we convert to a QByteArray of utf8 code points before we stream the data but looking at the Qt source reveals that QByteArray like QString sets the length to 0x for null as well. It may be because m_hisCall isn't initialized to anything from the INI file. Grid might be same problem too? As Laurie is looking at using this new interface I wonder if there is any other status content that would be valuable to him, particularly if it avoids any Windows cross process gymnastics to discover them? Mike W9MDB 73 Bill G4WJS. From: hamapps-b...@yahoogroups.com.au [mailto:hamapps-b...@yahoogroups.com.au] Sent: Sunday, May 03, 2015 12:18 AM To: hamapps-b...@yahoogroups.com.au Subject: Re: [HamApps-Beta] UDP interface for WSJT-X control. Mike, Testing WSJT-X 1.5 r5249 here and found a bug within the UDP data. When WSJT-X first starts without a DXCall set, the UDP status packet has the length for the DXCall set to 0x, rather than the true length which is 0x. If I enter a character and delete it, so that the DXCall is empty, the Status packet has the correct zero length set in the DXCall utf8 data. So this is only a startup problem which I have coded around, but thought you may like to pass it on as here may be other startup bogus data in the current UDP implementation. de Laurie VK3AMA -- One dashboard for servers and applications across Physical-Virtual-Cloud Widest out-of-the-box monitoring support with 50+ applications Performance metrics, stats and reports that give you Actionable Insights Deep dive visibility with transaction tracing using APM Insight. http://ad.doubleclick.net/ddm/clk/290420510;117567292;y___ wsjt-devel mailing list wsjt-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wsjt-devel
Re: [wsjt-devel] FW: UDP interface for WSJT-X control.
On 05/05/2015 14:06, Michael Black wrote: Hi Mike, Laurie said he doesn't see anything else he needs. Had to tell him Replay was for getting the current statuses which he didn't quite make the connection…he thought it was related to Decode again. Do you think it might be more aptly named StatusReplay and move the description in NetworkMessage.hpp to right below Status since they're related? I am surprised that there are not other bits of status info that would be helpful, I guess since Laurie has other mechanisms in place there is little direct benefit at the moment. The main thing as far as I am concerned is to get rid of the contention on the file based decodes interface which is blocking WSJT-X in its present form. I would have thought the replay is more related to decodes than status. I have keep the list of commands in numerical order which I think probably makes sense for a implementer of the protocol. I was going to revisit the documentation and note the null byte string behaviour since it isn't documented fully in the Qt QDataStream format. I will try and make everything a bit clearer. 73 Mike W9MDB 73 Bill G4WJS. *From:*Bill Somerville [mailto:g4...@classdesign.com] *Sent:* Sunday, May 03, 2015 9:58 AM *To:* wsjt-devel@lists.sourceforge.net *Subject:* Re: [wsjt-devel] FW: UDP interface for WSJT-X control. On 03/05/2015 15:42, Michael Black wrote: Hi Mike, Small bug…I tried to see how this was happening but couldn't quite figure it out. Seems when DXCall is empty it is initialized correctly to a 0-length string when the INI file has it as empty. This is expected behaviour. The Qt serialization format differentiates between a null QString and an empty QString as documented here: http://doc.qt.io/qt-5/datastreamformat.html . For this case I expect that both can be interpreted as empty. I am a bit surprised this is happening because we convert to a QByteArray of utf8 code points before we stream the data but looking at the Qt source reveals that QByteArray like QString sets the length to 0x for null as well. It may be because m_hisCall isn't initialized to anything from the INI file. Grid might be same problem too? As Laurie is looking at using this new interface I wonder if there is any other status content that would be valuable to him, particularly if it avoids any Windows cross process gymnastics to discover them? Mike W9MDB 73 Bill G4WJS. *From:*hamapps-b...@yahoogroups.com.au mailto:hamapps-b...@yahoogroups.com.au [mailto:hamapps-b...@yahoogroups.com.au] *Sent:* Sunday, May 03, 2015 12:18 AM *To:* hamapps-b...@yahoogroups.com.au mailto:hamapps-b...@yahoogroups.com.au *Subject:* Re: [HamApps-Beta] UDP interface for WSJT-X control. Mike, Testing WSJT-X 1.5 r5249 here and found a bug within the UDP data. When WSJT-X first starts without a DXCall set, the UDP status packet has the length for the DXCall set to 0x, rather than the true length which is 0x. If I enter a character and delete it, so that the DXCall is empty, the Status packet has the correct zero length set in the DXCall utf8 data. So this is only a startup problem which I have coded around, but thought you may like to pass it on as here may be other startup bogus data in the current UDP implementation. de Laurie VK3AMA -- One dashboard for servers and applications across Physical-Virtual-Cloud Widest out-of-the-box monitoring support with 50+ applications Performance metrics, stats and reports that give you Actionable Insights Deep dive visibility with transaction tracing using APM Insight. http://ad.doubleclick.net/ddm/clk/290420510;117567292;y___ wsjt-devel mailing list wsjt-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wsjt-devel
[wsjt-devel] FW: [HamApps-Beta] Re: UDP interface for WSJT-X control.
On further reflection Laurie does have a wish list. Mike W9MDB From: hamapps-b...@yahoogroups.com.au [mailto:hamapps-b...@yahoogroups.com.au] Sent: Tuesday, May 05, 2015 9:58 PM To: hamapps-b...@yahoogroups.com.au Subject: Re: [HamApps-Beta] Re: UDP interface for WSJT-X control. I was premature when I said I don't think there is any additional status data. I totally overlooked what I am doing with JTMacros. Trying to determine the current operating state of the WSJT-X GUI and where radio buttons and edit controls are located (which breaks as soon as font sizes are altered) and generating mouse clicks is very hacky and not ideal and now that font changing is available, no longer a reliable technique. My wish list ... 1. A status update when WSJT-X changes TX/RX state. I use this to avoid sending free-text messages when WSJT-X is TXing. I am currently using pixel color detection. 2. A Halt TX UDP command rather than sending keystrokes to GUI. 3. A UDP command to accept free-text to either Tab 1 or 2. I am currently detecting the active Tab using pixel color detection and then determining the Free-text edit control position (Tab dependant) before pasting the text into the edit field. 4. A UDP command to enable the free-text radio button on Tab 1 or Tab 2. If this becomes 2 separate UDP commands then a UDP status of Active Tab will be needed. I can't think of anything else. de Laurie VK3AMA __._,_.___ _ Posted by: Laurie, VK3AMA vk3ama.ham.a...@gmail.com _ https://au.groups.yahoo.com/neo/groups/HamApps-Beta/conversations/messages/ 1104;_ylc=X3oDMTJxZThocXFwBF9TAzk3NDkwNDMzBGdycElkAzg2Njk3MTIzBGdycHNwSWQDMT c0MDA2MzEwOARtc2dJZAMxMTA0BHNlYwNmdHIEc2xrA3JwbHkEc3RpbWUDMTQzMDg4MTA5Mg--?a ct=replymessageNum=1104 Reply via web post . mailto:vk3ama.ham.a...@gmail.com?subject=Re%3A%20%5BHamApps-Beta%5D%20Re%3A %20UDP%20interface%20for%20WSJT-X%20control%2E Reply to sender . mailto:hamapps-b...@yahoogroups.com.au?subject=Re%3A%20%5BHamApps-Beta%5D%2 0Re%3A%20UDP%20interface%20for%20WSJT-X%20control%2E Reply to group . https://au.groups.yahoo.com/neo/groups/HamApps-Beta/conversations/newtopic; _ylc=X3oDMTJmc21pNjlrBF9TAzk3NDkwNDMzBGdycElkAzg2Njk3MTIzBGdycHNwSWQDMTc0MDA 2MzEwOARzZWMDZnRyBHNsawNudHBjBHN0aW1lAzE0MzA4ODEwOTI- Start a new topic . https://au.groups.yahoo.com/neo/groups/HamApps-Beta/conversations/topics/10 58;_ylc=X3oDMTM1Z25rZTFyBF9TAzk3NDkwNDMzBGdycElkAzg2Njk3MTIzBGdycHNwSWQDMTc0 MDA2MzEwOARtc2dJZAMxMTA0BHNlYwNmdHIEc2xrA3Z0cGMEc3RpbWUDMTQzMDg4MTA5MgR0cGNJ ZAMxMDU4 Messages in this topic (41) https://au.groups.yahoo.com/neo/groups/HamApps-Beta/info;_ylc=X3oDMTJmMmxtZ 2g1BF9TAzk3NDkwNDMzBGdycElkAzg2Njk3MTIzBGdycHNwSWQDMTc0MDA2MzEwOARzZWMDdnRsB HNsawN2Z2hwBHN0aW1lAzE0MzA4ODEwOTI- Visit Your Group https://au.groups.yahoo.com/neo;_ylc=X3oDMTJldDNhYjNpBF9TAzk3NDkwNDMxBGdycE lkAzg2Njk3MTIzBGdycHNwSWQDMTc0MDA2MzEwOARzZWMDZnRyBHNsawNnZnAEc3RpbWUDMTQzMD g4MTA5Mg-- https://au.groups.yahoo.com/neo;_ylc=X3oDMTJldDNhYjNpBF9TAzk3NDkwNDMxBGdycE lkAzg2Njk3MTIzBGdycHNwSWQDMTc0MDA2MzEwOARzZWMDZnRyBHNsawNnZnAEc3RpbWUDMTQzMD g4MTA5Mg-- . Privacy . Unsubscribe . Terms of Use https://au.groups.yahoo.com/neo;_ylc=X3oDMTJldDNhYjNpBF9TAzk3NDkwNDMxBGdycE lkAzg2Njk3MTIzBGdycHNwSWQDMTc0MDA2MzEwOARzZWMDZnRyBHNsawNnZnAEc3RpbWUDMTQzMD g4MTA5Mg-- https://au.groups.yahoo.com/neo;_ylc=X3oDMTJldDNhYjNpBF9TAzk3NDkwNDMxBGdycE lkAzg2Njk3MTIzBGdycHNwSWQDMTc0MDA2MzEwOARzZWMDZnRyBHNsawNnZnAEc3RpbWUDMTQzMD g4MTA5Mg-- . https://au.groups.yahoo.com/neo;_ylc=X3oDMTJldDNhYjNpBF9TAzk3NDkwNDMxBGdycE lkAzg2Njk3MTIzBGdycHNwSWQDMTc0MDA2MzEwOARzZWMDZnRyBHNsawNnZnAEc3RpbWUDMTQzMD g4MTA5Mg-- https://au.groups.yahoo.com/neo;_ylc=X3oDMTJldDNhYjNpBF9TAzk3NDkwNDMxBGdycE lkAzg2Njk3MTIzBGdycHNwSWQDMTc0MDA2MzEwOARzZWMDZnRyBHNsawNnZnAEc3RpbWUDMTQzMD g4MTA5Mg-- __,_._,___ -- One dashboard for servers and applications across Physical-Virtual-Cloud Widest out-of-the-box monitoring support with 50+ applications Performance metrics, stats and reports that give you Actionable Insights Deep dive visibility with transaction tracing using APM Insight. http://ad.doubleclick.net/ddm/clk/290420510;117567292;y___ wsjt-devel mailing list wsjt-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wsjt-devel
Re: [wsjt-devel] WSJT PPAs
On Tue, 5 May 2015 16:36:45 +0100 Richard Bown rich...@g8jvm.com wrote: Hi Are there some where PPAs usable ubuntu , linuxmint ect containing wsjt10, I went to compile the latest and I'm getting a few probs where I've a mix of python2.7 and 3.4 ( I think) on my machines, the last build I had which was OK until upgrading to LM17.1 was r42xx. Thanks I'm now back up and running again r5247, I had to modify the Makefile to use /usr/bin/python3.4 and /usr/bin/f2py3.4 -- -- Best wishes /73 Richard Bown Email : rich...@g8jvm.com HTTP : http://www.g8jvm.com nil carborundum a illegitemis ## Ham Call: G8JVM . QRV: 50-432 MHz + Microwave 23 cms 140W, 13 cms 100W 3cms 5W Maidenhead QRA: IO82SP38, LAT. 52 39.720' N LONG. 2 28.171 W QRV VHF 6mtrs 200W, 4 mtrs 150W, 2mtrs 400W, 70cms 200W OS: Linux Mint 17.1 x86_64 on a Dell Inspiron N5030 laptop ## -- One dashboard for servers and applications across Physical-Virtual-Cloud Widest out-of-the-box monitoring support with 50+ applications Performance metrics, stats and reports that give you Actionable Insights Deep dive visibility with transaction tracing using APM Insight. http://ad.doubleclick.net/ddm/clk/290420510;117567292;y ___ wsjt-devel mailing list wsjt-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wsjt-devel
[wsjt-devel] Welcome to K9AN... and some wsprd developments
Hi all, First, please join me in welcoming Steve Franke, K9AN, as a new member of the WSJT Development group! I'm not sure that Steve has subscribed to this email list yet, so I'm copying him directly on this message. Many of you will already know Steve as the author of an alternative WSPR decoder, k9an-wsprd, written in C and configured as a drop-in replacement for the Fortran-coded wsprd currently packaged with WSPR-X. Steve's program is also used as the decoder in a wholly independent WSPR implementation called WSPRlinux, by DJ0ABR. Steve's wsprd is better than the original in several respects. Moreover, over the past week I've done a series of further optimizations that improved its performance a bit more and made it *much* faster than either of the original programs. In the same spirit as the messages I've posted here over the past several months in the thread Summary of Decoder Performance, here's a brief table summarizing the decoding performance and speed of (1) the original wsprd (built in March 2013), (2) k9an-wsprd, and (3) the current wsprd committed to our SourceForge repository earlier today. As figures of merit I used the time to process a sample of 638 *.wav files and the total number of decoded messages produced from those files. The following table summarizes the results up to now. Most of the tests were made on a Linux machine, but my changes included what was necessary to make the program easy to build for Windows (under MinGW) as well. I've therefore included a few test runs done on a Windows machine. # Linux Windows Program Time Decodes Time Decodes - wsprd (Mar 2013) 2413 1451 2718 1451 k9an-wsprd 1800 2122 k9an_wsprd -q 354 1939 wsprd 399 2190 356 2190 wsprd -q 214 2034 192 2034 wsprd* 1240 2215 wsprd# 1599 2220 - * maxcycles=3 # maxcycles=2, iifac=1 Otherwise, maxcycles=1, iifac=3. Option -q invokes quick mode decoding - Test data: 638 *.wav files (recorded by WSJT-X) - Linux machine: Core 2 Duo, E6750 CPU Windows machine: 4-Core i5-2500 CPU - ## The new wsprd will be used for the WSPR capability being developed for WSJT-X. I expect that it will also be very useful for a WSPR-lite implementation. Some of us -- Steve, Edson/PY2SDR, and I, and perhaps others -- expect to be working further on it in coming weeks. Comments and other contributions will be welcome, as always! -- 73, Joe, K1JT -- One dashboard for servers and applications across Physical-Virtual-Cloud Widest out-of-the-box monitoring support with 50+ applications Performance metrics, stats and reports that give you Actionable Insights Deep dive visibility with transaction tracing using APM Insight. http://ad.doubleclick.net/ddm/clk/290420510;117567292;y ___ wsjt-devel mailing list wsjt-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wsjt-devel
Re: [wsjt-devel] RR73 proposed patch
Michael Black mdblack98@... writes: Simple…most people send the extra 73..at least that's what I see 50% of the time. I've had people keep sending me a 73 waiting for a 73 in reply. Go for it Mike. Many people have stopped sending RRRs too. RR73 as default is an excellent move IMHO. Guy G4DWV/4X1LT -- One dashboard for servers and applications across Physical-Virtual-Cloud Widest out-of-the-box monitoring support with 50+ applications Performance metrics, stats and reports that give you Actionable Insights Deep dive visibility with transaction tracing using APM Insight. http://ad.doubleclick.net/ddm/clk/290420510;117567292;y ___ wsjt-devel mailing list wsjt-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wsjt-devel
[wsjt-devel] Online manual
FYI.online manual with the new -devel filename isn't working.404 error.. The old main manual is still there as linked from the main WSJT-X page. Local manual works 'jes fine. Mike W9MDB -- One dashboard for servers and applications across Physical-Virtual-Cloud Widest out-of-the-box monitoring support with 50+ applications Performance metrics, stats and reports that give you Actionable Insights Deep dive visibility with transaction tracing using APM Insight. http://ad.doubleclick.net/ddm/clk/290420510;117567292;y___ wsjt-devel mailing list wsjt-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wsjt-devel
