[wsjt-devel] 2.5.0-rc2 minor bug
Hi, With 2.5.0-rc2 the Q65 Decode Normal and Decode Deep settings no longer stick when shutting down the program while in Q65 mode and then restarting; WSJT-X always starts with Decode Fast. This is with the windows 64 bit version, both when downloaded as binary and when compiled from source. Thanks for all that you do and have a great week! 73, Roger W3SZ ___ wsjt-devel mailing list wsjt-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wsjt-devel
Re: [wsjt-devel] Call for information about PC systems being used for WSJT-X
Hi Bill, I am still using four Core 2 Duo E8500 CPU-computers (Q1 2008) on which I run WSJT-X. They don't support AVX, of course. They are old but since they have up until now been (barely/marginally) OK in terms of speed and CPU utilization even with Windows 10 I haven't replaced them before now. All each of them does is run an SDR program, WSJT-X, and Dimension-4. If WSJT-X added performance enhancements that would only work with a newer CPU, that would probably push me to upgrade them. I had been considering doing that anyway, as they have slowed enough with Windows 10 and each of its major updates that I suspect they won't be "OK" for my purposes for much longer, as each major Windows update slows them further. So if I need to get new computers to get the most out of a future version of WSJT-X, I will thank you for pushing me to do what I should have already done by now. From my perspective, I would say don't spend any time just to keep my ancient Core 2 Duos running with WSJT-X. Getting 13 years out of a CPU/motherboard is plenty :) Thanks for polling the group on this and for all that you do, and 73, Roger W3SZ On 6/8/2021 07:38 PM, Bill Somerville wrote: Hi all WSJT-X users, we are looking into some performance enhancements that will take advantage of some parallel processing features of modern CPU architectures. In order to gauge how much backwards compatibility for older CPUs we will have to implement it would help to know who is using such older processors. Please don't turn this thread in to a mine is better than yours conversation, all I need to know is who or how many of you are using the older CPU architectures. Note that this applies to MS Windows, Intel Linux, and Intel macOS users, it is about CPUs not operating systems. The technology we will use is called AVX and that is present on all Intel CPUs branded Core i3/i5/i7/i9 (circa 2010 to present), it is also present on AMD CPUs since the Jaguar or Puma based CPU models (some late Athlon-II CPUs, all Zen based CPUs, including Ryzen) circa 2013 to present. Notably Intel CPUs branded Celeron, Pentium, or Atom do not support the AVX technology. So in summary, look up your CPU and if it **does not support AVX** (https://en.wikipedia.org/wiki/Advanced_Vector_Extensions) then let me know. 73 Bill G4WJS. ___ wsjt-devel mailing list wsjt-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wsjt-devel ___ wsjt-devel mailing list wsjt-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wsjt-devel
Re: [wsjt-devel] WSJT-X 2.5.0-rc1 and MAP65 3.0-rc1
Thank you Joe and Bill and the rest of the team for this wonderful new version! I am finding that it does the Doppler compensation with Q65-15C extremely rapidly even with the Max Drift set to 50 and with wide FTol settings. Its performance is truly amazing!! With 2.5.0-RC1 we are getting consistent decodes using Q65-15C with Doppler shift rates of up to 20 Hz/sec, which is all the higher I have tested thus far as we don't anticipate rates of change greater than this with 10 GHz aircraft scatter, which is our current interest in this regard. I have noticed one minor and esoteric issue when using mode Q65-15C, which I am reporting for completeness, as requested in your announcement email. I apologize for the long message but I wanted to give all the details. In testing I am using settings that I would not use in practice, in order to test the extremes of the program environment, and I have found that I can produce a sub-process error that results in program shut-down by using an odd choice of settings when decoding wave files. The error occurs at the time that decoding is attempted. Report is below: This is of course with WSJT-X version 2.5.0-RC1. OS is Windows 10 Pro version 20H2. The critical choice of settings that is required to produce the error seems to be [1] Max Drift Rate greater than zero, with [2] combinations of FTol and Rx frequency where FTol=500 or FTol=1000 and Rx frequency are chosen so that the lower limit of Ftol's frequency range is zero or negative. As the error message that this set of conditions produces indicates, this combination of parameters pushes the index of dimension 1 of s1avg in q65.f90 below its lower limit of 1. For FTol = 1000 any Rx Freq of 1003 or lower produces this error. For FTol = 500 any Rx Freq of 503 or lower produces this error. Interestingly, I don't see this when I choose FTol=400 or FTol=300 and then select the Rx freq so as to push the lower limit of FTol below 0 and then attempt to decode. Because the lower limit of Rx freq is 200, I of course can't produce this error condition with FTol values of 200 or less. And I don't see the error if I first set Rx Freq to a low value such as 200 Hz with FTol 400 Hz or lower and then increase FTol to 500 or 1000 so that the lower limit of FTol will be below zero and then attempt to decode. But then, by clicking to several different Rx frequencies where the lower limit of FTol is above zero and attempting decodes (which of course produce no errors) and then clicking again to an Rx Freq so that the lower FTol limit is below zero, I can again elicit the subprocess error with FTol=500 or FTol=1000. The other settings that are in use when this error occurs are: Q65-15C Tx freq 700 Hz Max Drift 50 Decode Deep Waterfall frequency limits are 200-3125 Hz. With Rx Freq = 980 and FTol=1000 the MessageBox error produced shows: - Subprocess Error Subprocess failed with exit code 2. "Details" are: Running: C:\WSJT\wsjtx\2pt5pt0-rc1\bin\jt9 -s "WSJT-X - VK7MO_Tests" -w 1 -m 3 -e C:\WSJT\wsjtx\2pt5pt0-rc1\bin -a "C:\Users\73w3s\AppData\Local\WSJT-X - VK7MO_Tests" -t "C:\Users\73w3s\AppData\Local\Temp\WSJT-X - VK7MO_Tests" At line 447 of file C:\Users\bill\src\k1jt\wsjtx\lib\qra\q65\q65.f90 Fortran runtime error: Index '-3' of dimension 1 of array 's1avg' below lower bound of 1 Error termination. Backtrace: Could not print backtrace: libbacktrace could not find executable to open #0 0x #1 0x #2 0x #3 0x #4 0x #5 0x #6 0x #7 0x #8 0x #9 0x #10 0x #11 0x #12 0x #13 0x #14 0x - With Rx freq = 1003 and Ftol=1000 details are the same except for the index value: Fortran runtime error: Index '0' of dimension 1 of array 's1avg' below lower bound of 1 With Rx freq = 900 and FTol=1000 this line is: Fortran runtime error: Index '-15' of dimension 1 of array 's1avg' below lower bound of 1 WIth Rx freq = 436 and FTol=500 this line is: Fortran runtime error: Index '-10' of dimension 1 of array 's1avg' below lower bound of 1 etc. This is not a complaint and I would not likely use such wide FTol values in actual operation but I figured that I should report it in case you had not noticed this behavior and in case you wanted to trap the error condition. Of course when the error MessageBox is closed, WSJT-X shuts down as is appropriate. Thanks again for this great software! I am really enjoying its amazing capabilities, and the above issue does not detract at all from my use and enjoyment of it! 73, Roger Rehr W3SZ On 6/2/2021 05:34 PM, Joe Taylor wrote: Dear WSJT-X and MAP65 Users, We hope you will enjoy using this beta release of WSJT-X 2.5.0 and MAP65 3.0.0, and exercising the new mode Q65. As a beta teste
Re: [wsjt-devel] Windows WSJT-X Version 2.4.0-rc4 crashes
Thanks Bill! Unfortunately Dave and I both didn't have "Save All" turned on...we apologize for this. There was nothing of note in the Windows Event Log. I will let you and the team know if this reoccurs and I have useful data about the event. I expect it won't reoccur :) Have a great weekend, Thanks Again for all that you do, and 73, Roger W3SZ On2021-04-28 10:15:18, Bill Somerville wrote: Hi Roger, although they are not particularly helpful, some information that may help should be recorded in the Windows Event log . The most useful diagnostic would be the saved .WAV file that causes the crash, assuming the decoder is the source of the crash which is likely. 73 Bill G4WJS. ___ wsjt-devel mailing list wsjt-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wsjt-devel
[wsjt-devel] Windows WSJT-X Version 2.4.0-rc4 crashes
shmem size: 48275456 We had, minutes before the crashes during the same session operated FT8, JT9F and JT9H, and Q65-15C without crashes and after the crashes we went back to Q65-15C and then tried FT8 again all without crashes. After the crashes we switched back to Q65-15C and had no crashes with that mode or for the rest of our operating session. We did not go back and re-test Q65-60D again as we both had engagements to meet. But today I went back to my remote site and set up WSJT-X and the rest of my software just as they were set up yesterday, and I turned the computer clock back to April 26 at 1533 UTC and let things run until the clock reached 1616 UTC, spanning the times during which Dave and I had the crashes, and no crashes occurred. I had thought that the crashes were somehow time-related, but this result indicates otherwise. I have operated Q65-60D with v 2.4.0-rc4 on multiple occasions at another site (also with Windows 10, but I am not sure if it was 20H2 or 2004) on 10 GHz for EME without any problems. The kenwood_transaction errors and warnings shown in the above syslog excerpt are a common occurrence here and did not occur more often yesterday than on prior days. They could relate to the fact that I sometimes forget to "activate" the CAT on my software before starting WSJT-X, but I guess they could also relate to some error in the AI response that I coded when I wrote the SDR code back in 2014. In any event, this error is not germane to the events occurring yesterday and CAT control has always worked flawlessly both with WSJT-X and with the other software my SDR interfaces with. The dropped audio samples are also common at my QTH as well as at K1RZ's, although none occurred at K1RZ's during our operating session yesterday. I have no idea what caused the crashes and find it hard to believe that it was anything other than a non-reproducible event that may never recur, but since it happened to K1RZ and myself simultaneously at our individual stations I figured I would report it in order to provide information to the development team. Sorry for the potentially unnecessary bandwidth. I did think hard before posting this report before deciding that it would be better to do so than to not do so. Thanks to the team for all that you do and 73, Roger Rehr W3SZ ___ wsjt-devel mailing list wsjt-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wsjt-devel
Re: [wsjt-devel] possible anomaly in type 2 udp messages
Thanks Bill! I very much appreciate the explanation! The current situation is not a problem for me; I had been doing very tight error checking at my end, being unaware of the extra text included in the message, and so error flags popped up at this end when messages with the appended AP information arrived. I had not previously seen the error messages because previously I had not been running the AP decode option. After seeing the error messages here on Saturday I loosened my error checking and all has been well here since :) Thanks again Bill for the explanation and for all that you do! Have a great week and 73, Roger W3SZ On 1/20/2020 11:38 AM, Bill Somerville wrote: On 20/01/2020 00:25, Roger Rehr W3SZ wrote: Today I noticed a very occasional variation in type 2 UDP network messages sent by WSJTX version 2.1.2. The issue of variation is that the length of the text message as specified in the UDP message is longer than the "correct" text message length, and in fact the "text message" portion of the UDP message consists of the "correct" text message followed by a number of spaces, followed sometimes other character and finally followed by "a1" before the Low Confidence and Off air bits of the message are given (in their correct position based on the specified "text message" length). Hi Roger, thanks for reporting this. The decoded message appendages are an artefact of some rather messy internal implementation details of WSJT-X. The decoder appends some statistical information about decode quality when the decoded message is passed to the user interface part of WSJT-X, the reason for this is historical and the information should be passed as separate fields or arguments but it was simpler to append the text at the time. The extra text should be trimmed off before exporting via the UDP messages although the current content does reflect exactly what is printed on the WSJT-X UI, so it is not technically incorrect. I note also that the "Low confidence" marker is not being set correctly, it should have a true value when there is a '?' character near the end of the message. I will fix this for the next release of WSJT-X. 73 Bill G4WJS. ___ wsjt-devel mailing list wsjt-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wsjt-devel ___ wsjt-devel mailing list wsjt-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wsjt-devel
Re: [wsjt-devel] possible anomaly in type 2 udp messages
Thanks Joe, That fits perfectly and explains exactly what I was seeing. I very much appreciate the info! Thanks again and thanks for all that you do! 73, Roger W3SZ On 1/20/2020 11:04 AM, Joe Taylor wrote: Hi Roger, You will probably get a better answer to your query from Bill, G4WJS. But it seems that the messages you are flagging as "bad" are simply the ones resulting from successful "a priori" decoding. This is described in the Section 12.1 of the WSJT-X 2.1 User Guide: http://www.physics.princeton.edu/pulsar/K1JT/wsjtx-doc/wsjtx-main-2.1.2.html#_ap_decoding -- 73, Joe, K1JT On 1/19/2020 7:25 PM, Roger Rehr W3SZ wrote: This message is informational only, for the developers. The issue raised does not represent an operational problem for me as the issue is simple to handle in code at the receiving end. But I thought that you should be made aware of the behavior in case it is unintended. It may well be intended, and in that I case I apologize for missing the memo and creating unnecessary bandwidth :) Today I noticed a very occasional variation in type 2 UDP network messages sent by WSJTX version 2.1.2. The issue of variation is that the length of the text message as specified in the UDP message is longer than the "correct" text message length, and in fact the "text message" portion of the UDP message consists of the "correct" text message followed by a number of spaces, followed sometimes other character and finally followed by "a1" before the Low Confidence and Off air bits of the message are given (in their correct position based on the specified "text message" length). I don't think that this represents mangling of the UDP packet in transit because the size of the text message as specified in the message is correct for the included data, and as just noted the Low Confidence and Off air bits appear at their expected positions given the specified text message length. If the observed anomaly were a result of mangling of the message in transit, there would not be this congruity. Below are print outs of a couple of examples of this anomaly, and then of a "good" message. The "0 Array" is the entire network UDP message. "1 Array" thru "11 array" represent the corresponding message parts as specified in NETWORK_MESSAGE_HPP. I used 3 carets and then 3 percentage markers to bracket the text message in the first line so that, when analyzing this, I could tell where the text message actually began and ended if there were non printing characters present. Here is an example of a "bad" message: From handleMsg2 Routine msg is ^^^CQ TEST N2CG FN20 ? a1%%% CQ2 is --- Grid is FN20 Call is N2CG The 0 Array is AD BC CB DA 00 00 00 02 00 00 00 02 00 00 00 10 57 53 4A 54 2D 58 20 2D 20 4D 61 69 6E 32 31 30 01 04 CE ED 30 FF FF FF EF 3F F1 99 99 A0 00 00 00 00 00 06 60 00 00 00 01 7E 00 00 00 28 43 51 20 54 45 53 54 20 4E 32 43 47 20 46 4E 32 30 20 20 20 20 20 20 20 20 20 20 20 20 20 20 20 20 20 20 20 3F 20 61 31 00 00 The 1 Array is AD BC CB DA 00 00 00 02 00 00 00 02 00 00 00 The 2 Array is 57 53 4A 54 2D 58 20 2D 20 4D 61 69 6E 32 31 30 The 3 Array is 01 The 4 Array is 04 CE ED 30 The 5 Array is EF FF FF FF The 6 Array is 00 00 00 A0 99 99 F1 3F The 7 Array is 60 06 00 00 The 8 Array is 7E 01 The 9 Array is 43 51 20 54 45 53 54 20 4E 32 43 47 20 46 4E 32 30 20 20 20 20 20 20 20 20 20 20 20 20 20 20 20 20 20 20 20 3F 20 61 31 The 10 Array is 00 The 11 Array is 00 2 ID SIZE is 16 2 Rig Name is WSJT-X - Main210 3 IsNew is 1 5 snr is -17 6 Delta time is 1.1002384186 7 Delta freq is 1632 8 Mode is FT8 9 message is is CQ TEST N2CG FN20 ? a1 10 Low confidence is 0 11 Off Air is 0 --end of Bad Type 2 message Here is another example of a Bad Type 2 message: From handleMsg2 Routine msg is ^^^CQ TEST N4HB FM17 a1%%% CQ2 is --- Grid is FM17 Call is N4HB The 0 Array is AD BC CB DA 00 00 00 02 00 00 00 02 00 00 00 10 57 53 4A 54 2D 58 20 2D 20 4D 61 69 6E 32 31 30 01 04 CF D7 90 FF FF FF E9 3F F6 66 66 60 00 00 00 00 00 04 41 00 00 00 01 7E 00 00 00 28 43 51 20 54 45 53 54 20 4E 34 48 42 20 46 4D 31 37 20 20 20 20 20 20 20 20 20 20 20 20 20 20 20 20 20 20 20 20 20 61 31 00 00 The 1 Array is AD BC CB DA 00 00 00 02 00 00 00 02 00 00 00 The 2 Array is 57 53 4A 54 2D 58 20 2D 20 4D 61 69 6E 32 31 30 The 3 Array is 01 The 4 Array is 04 CF D7 90 The 5 Array is E9 FF FF FF The 6 Array is 00 00 00 60 66 66 F6 3F The 7 Array is 41 04 00 00 The 8 Array is 7E 01 The 9 Array is 43 51 20 54 45 53 54 20 4E 34 48 42 20 46 4D 31 37 20 20 20 20 20 20 20 20 20 20 20 20 20 20 20 20 20 20 20 20 20 61 31 The 10 Array is 00 The 11 Array is 00 2 ID SIZE is 16 2 Rig Name is WSJT-X - Main210 3 IsNew is 1 5 snr is -23 6 Delta time is 1.3997615814 7 Delta freq is 1089 8 Mode is FT8 9 message i
[wsjt-devel] possible anomaly in type 2 udp messages
4 Array is 04 CF 62 60 The 5 Array is E8 FF FF FF The 6 Array is 00 00 00 60 66 66 F6 3F The 7 Array is 0B 04 00 00 The 8 Array is 7E 01 The 9 Array is 43 51 20 54 45 53 54 20 4E 34 48 42 20 46 4D 31 37 The 10 Array is 00 The 11 Array is 00 2 ID SIZE is 16 2 Rig Name is WSJT-X - Main210 3 IsNew is 1 5 snr is -24 6 Delta time is 1.3997615814 7 Delta freq is 1035 8 Mode is FT8 9 message is is CQ TEST N4HB FM17 10 Low confidence is 0 11 Off Air is 0 end of Good Type 2 message 73, Roger Rehr W3SZ ___ wsjt-devel mailing list wsjt-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wsjt-devel
[wsjt-devel] Problem with wav file reads for JT4 with wav files produced by modified WSJTX
Hi All, I have modified WSJTX 2.0.0 (old version rather than 2.0.1 because I don't want to switch versions mid project) to produce 12000 samples per second wav files for data analysis. The files produced work properly for every mode, both fast and slow, except for JT4. I did not mess with any mode-specific code. The JT4 files produced decode properly if they are run in a program such as CoolEdit and sent to WSJTX via VAC, but fail to decode if run by using the File>>Open>>read_wav_file facility of WSJTX, even though the waterfall that they produce looks identical to the waterfall produced when CoolEdit is feeding WSJTX. The problem wav files give no error message, and produce a normal-appearing waterfall, and WSJTX does attempt to decode but I get an non-decode message like " 22 -1.0 700 $*" in the Single Period Decodes window for JT4. And the dB report is 12-20 dB lower than expected Also, if I have WSJTX produce 48000 samples per second sampling rate files and then decimate them to 12000 using MATLAB I get the same result; with this method as well all modes work properly except for JT4, which behaves exactly as just described above. The JT4 wav files "saved" by WSJTX after a successful decode of one of the problem JT4 wav files sent to WSJTX from CoolEdit work properly using the WSJTX File>>Open>>read_wav_file facility. I am hoping that someone has run into some similar problem before or has an idea about what the problem may be. I've been over the code and am stuck. Here is some data: waterfall showing CoolEdit input on the bottom and WSJTX File>>Open>>read_wav_file input on the top: http://w3sz.x10.mx/WSJTX/1-JT4GLowerTraceFromCoolEditUpperTraceDirectFromFileToReceiveWSJTX.PNG As noted above, the bottom trace decoded and the top one did not. waterfall running audio output of one instance of WSJTX to input of another via VAC, same signal as above (strength is much greater but I get same results with all reasonable signal levels): http://w3sz.x10.mx/WSJTX/1-JT4GDirectFromNormal2pt0pt0ToReceiveWSJTX.PNG 12000 sampling rate wav file produced by modified WSJTX: http://w3sz.x10.mx/WSJTX/JT4_12000_FromModifiedWSJTX.wav 12000 sampling rate produced by standard version of WSJTX when it decodes above (input via CoolEdit) http://w3sz.x10.mx/WSJTX/190404_0233a.wav I produced the 12000 sampling rate files in WSJTX by modifying Modulator.cpp, changing TX_SAMPLING_RATE to 12000, and then making the necessary housekeeping changes to Modulator.cpp associated with the above. It is likely that I did something stupid to cause this problem, I just can't figure out what that is. My code is here: http://w3sz.x10.mx/WSJTX/Modulator.cpp A comparison with the original code is here (original is on the left): http://w3sz.x10.mx/WSJTX/DiffModulatorDotcpp.htm I don't think it could be a header problem because all of the other modes work fine, but just in case here is some header info below. The header section of a problem wav file is in the first 44 bytes of this pdf: http://w3sz.x10.mx/WSJTX/JT4GdotWAVfromModifiedWSJTX_HEX.pdf and the header from the "good" wav file WSJTX saved after decoding the above is here: http://w3sz.x10.mx/WSJTX/JT4GdotWAVsavedFromStandardWSJTX_SuccessfulDecode_HEX.pdf Thanks in advance, and 73, Roger Rehr W3SZ ___ wsjt-devel mailing list wsjt-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wsjt-devel
[wsjt-devel] Question on Cocumentation of MessageTypes
Hi All, Thanks for the great and always improving software! This is a report being made in case the behavior that I have observed is not what the developers intended. It is not a complaint and it is not a request for any changes to be made in the WJSTX code. I am working with the UDP message facility and v 2.0.0 and all is going well without issues. The "message types" references below relalte to the message types of UDP messages as defined in the document "NetworkMessage.hpp" and have nothing to do with the type designations relating to callsign/compound callsign structure. My question regards the documentation and implementation of the message structure for Type 2 messages asd defined in that document. For the most part, the documentation in NetworkMessage.hpp regarding message structure matches with what I have found. However, in type 2 messages the documentation says that "Mode" is to be sent in UTF8, so I expected to see in type 2 messages what I see sent for Mode in the Type 1 messages, e.g for FT8 "03 46 54 38" which is of course just the size index "03" followed by the ascii bytes for "FT8". Instead, in the type 2 messages I see for example for FT8 "01 7E" in the byte array, 01 being the size index and 7E being the payload, which is the extended ascii code for "~". For each of the modes that I checked I see as the mode designation in type 2 messages: With HF Settings: FT8: 01 7E JT4: - JT9: 01 40 JT65: 01 23 MSK144: 01 26 ISCAT: - QRA64 02 3A 2A With VHF Settings: FT8: 01 7E JT4: - JT9: 01 40 (all submodes, fast and slow) JT65: 02 23 2A (all submodes) MSK144: 01 26 ISCAT: (01 2D) QRA64 02 3A 2A (all submodes) Also, I do not see any evidence of type 2 messages being sent with successful decodes of JT4 or ISCAT messages with HF settings, and have only once seen an ISCAT type 2 message sent with VHF settings, after giving the GUI a heavy workout, and I have not been able to reproduce that condition where I did see an ISCAT type 2 message. As is the case with HF, I never see any type 2 message being sent after successful JT4 decodes. Is all of this (mode designations differing between type 2 and type 3 messages, and the lack of sending of type 2 messages for JT4 and ISCAT decodes) expected and desired behavior? Thanks in advance for the info, and 73, Roger Rehr W3SZ ___ wsjt-devel mailing list wsjt-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wsjt-devel
[wsjt-devel] jt49sim jt4 mode producing jt9 code. correction to code given below
Here I find the following:
When jt49sim is commanded to produce a jt4 wave file it produces a jt9
wave file, e.g. the command:
jt49sim "K1ABC W9XYZ EN37" 4C 1 0.0 0.0 1 -15
produces a JT9C wave file instead of the expected JT4C wave file, even
though the console message says that a JT4 wave file is being created:
===console message follows
C:\JTSDK\wsjtx\garc\qt52\1.9.0\Release\install\bin>jt49sim "K1ABC W9XYZ
EN37" 4C 1 0.0 0.0 1 -15
File Sig Freq Mode S/N DT Dop Message
1 1 1000.000 4C -15.0 0.00 0.0 K1ABC W9XYZ EN37
===end of console message
The wave file produced is a JT9 wave file:
http://w3sz.com/JT4C-Original.wav
So whether the specified mode is "4" or "9", a JT9 mode wave file is
always produced.
This is so with version 1.9.0-rc4 r8642 from directory
C:\JTSDK\wsjtx\garc\qt52\1.9.0\Release\build (which I copied to
..Release\install\bin)
compiled locally using JTSDK 2.0.6-0 Release r715.
This is true for all sub-modes JT4A-G.
I thought that the likely culprit causing this problem was line 56 in
jt49sim.f90, "imode = 9" which is placed right before the imode "if"
statement, which you can see here:
https://sourceforge.net/p/wsjt/wsjt/8642/tree/tags/wsjtx-1.9.0-rc4/lib/jt49sim.f90
I suspect that this line was accidentally left in place after it was
added during debugging.
Removing line 56 ("imode = 9") and recompiling corrects the problem so
that JT4 files are produced by the "4" option and JT9 files are produced
by the "9" option. A wave file created using the same command line as
was given above, but after the correction to the code as just described,
is here:
http://w3sz.com/JT4C-Corrected.wav
73,
Roger Rehr
W3SZ
--
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
___
wsjt-devel mailing list
wsjt-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wsjt-devel
[wsjt-devel] Questions about (mostly fast) mode characteristics
Hi All, I am trying to understand some practical and pretty basic aspects of the decoding of the various modes and have some questions because my knowledge base / brain power have not permitted me to come to a complete understanding of the issues involved, even after reviewing the source code. So I am asking the group for help, as I know there are smarter and better educated folks in abundance here. Here are my impressions and associated questions: 1. ISCAT, JT9 Fast modes, and MSK144 repeat the message block many times during a single transmit cycle. Is there signal averaging of the data received during a SINGLE receive cycle to improve signal to noise ratio for ISCAT, JT9 Fast modes, or MSK144? I believe the answer is "no" but I would like confirmation of this. 2. I believe that received data from MULTIPLE transmit/receive cycles can be averaged by JT4 and JT65, but not by other modes. Is this correct? 3. If the answer to #1 above is that there is not averaging of the multiple message blocks WITHIN A SINGLE receive cycle, then the multiple blocks within a receive cycle give more chances for the SNR to be sufficient for decoding, but if the actual channel propagation characteristics are perfectly constant during the transmit/receive cycle, there is actually no greater probability of getting a successful decode from the entire T/R cycle than there would be for getting a successful decode if the transmit/receive cycle time were equal to the duration of a single message block. Is this correct? 4. If the answer to #1 above is that there is not averaging of the multiple message blocks WITHIN A SINGLE receive cycle, then the important time frame for determining what amount of frequency drift (in Hz/second) is important relative to the tone spacing for these modes is not a function of the tone spacing divided by the duration of the entire transmit cycle, but rather a function of the tone spacing divided by the duration of the duration of a single message block. For JT9H-Fast with a 15 second duration cycle length, the difference in tolerated frequency drift would be approximately (222.222 Hz/15 sec =) 14.8 Hz/sec vs (222.222/0.425) = 523 Hz/second, neglecting the slight difference between the actual receive cycle time and 15 seconds. Please accept my apologies for any stupidities in the above. It is my lack of understanding that is the reason for this post, and if I really understood the issues I would not need to post! (Ignorance is not Bliss.) 73, Roger Rehr W3SZ -- Check out the vibrant tech community on one of the world's most engaging tech sites, Slashdot.org! http://sdm.link/slashdot ___ wsjt-devel mailing list wsjt-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wsjt-devel
Re: [wsjt-devel] FT8: Potential new mode for fast QSOs
Bill G4WJS had given a warning on June 9 to "Beware if building from development sources" with revisions later than r7703, due to some transmission modulation issues. Given the recommendations for us to try JT8 and the great enthusiasm being shown for it by users now running r7750 or later, is it safe to assume that that warning has been lifted? I looked for an email rescinding the warning but couldn't find one. Or is the current recommendation that we run r7750 or later version for JT8 BUT r7703 or earlier for other modes? Thanks in advance, and 73, Roger Rehr W3SZ > If you can build WSJT-X from source code revision r7750 -- Check out the vibrant tech community on one of the world's most engaging tech sites, Slashdot.org! http://sdm.link/slashdot___ wsjt-devel mailing list wsjt-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wsjt-devel
Re: [wsjt-devel] Sending WSJT-X Log Information to N1MM+ as each QSO is completed
Thanks Mike! I will check it out. 73, Roger On 6/20/2017 8:17 AM, Black Michael via wsjt-devel wrote: > JTAlert is the one that handles many logging programs. > Perhaps you should ask on that list. > > I don't think the WSJT-X team wants to get into the logging business > to all the different loggers when it's already well satisfied by > JTAlert and other such intermediaries. > > de Mike W9MDB > > > -------- > *From:* Roger Rehr W3SZ <w3s...@gmail.com> > *To:* WSJT software development <wsjt-devel@lists.sourceforge.net> > *Sent:* Tuesday, June 20, 2017 7:10 AM > *Subject:* [wsjt-devel] Sending WSJT-X Log Information to N1MM+ as > each QSO is completed > > HI All, > > One of the issues that users of WSJT-X face is that of transferring > their contacts logged in WSJT-X to their logging program. Getting the > WSJT-X contacts into N1MM+ in particular has been a challenge because > of N1MM's rejection of any import that contains even one contact > already in the N1MM log. > > Now there is potentially good news on the horizon! > > N1MM+ has recently expanded its ability to interact with external > programs via UDP and TCP connections, as described here: > http://n1mm.hamdocs.com/tiki-index.php?page=UDP+Broadcasts > > Importantly, it now has capability, as described in #9 on the above > page, to accept log data from other programs via a TCP connection, > using the ADIF format. > > Thus it would be possible, if WSJT-X implements this TCP connection, > to have WSJT-X send a complete QSO information to N1MM+ via this TCP > connection the moment a contact is logged in WSJT-X. > > I am hopeful that the WSJT-X developers will consider adding this > "wish" to their already ample list of users' feature requests, in > spite of their very busy schedules. > > If this capability already exists in WSJT-X or one of its add-ons, I > [1] apologize for the bandwidth and [2] would be most appreciative of > being pointed in the right direction so that I can peruse the > documentation. > > Have a great week All, and Thanks for All that You Do!! > > 73, > > Roger Rehr > W3SZ > -- > Check out the vibrant tech community on one of the world's most > engaging tech sites, Slashdot.org! > http://sdm.link/slashdot___ > wsjt-devel mailing list > wsjt-devel@lists.sourceforge.net <mailto:wsjt-devel@lists.sourceforge.net> > https://lists.sourceforge.net/lists/listinfo/wsjt-devel > > > > > -- > Check out the vibrant tech community on one of the world's most > engaging tech sites, Slashdot.org! http://sdm.link/slashdot > > > ___ > wsjt-devel mailing list > wsjt-devel@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/wsjt-devel -- Check out the vibrant tech community on one of the world's most engaging tech sites, Slashdot.org! http://sdm.link/slashdot___ wsjt-devel mailing list wsjt-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wsjt-devel
[wsjt-devel] Sending WSJT-X Log Information to N1MM+ as each QSO is completed
HI All, One of the issues that users of WSJT-X face is that of transferring their contacts logged in WSJT-X to their logging program. Getting the WSJT-X contacts into N1MM+ in particular has been a challenge because of N1MM's rejection of any import that contains even one contact already in the N1MM log. Now there is potentially good news on the horizon! N1MM+ has recently expanded its ability to interact with external programs via UDP and TCP connections, as described here: http://n1mm.hamdocs.com/tiki-index.php?page=UDP+Broadcasts Importantly, it now has capability, as described in #9 on the above page, to accept log data from other programs via a TCP connection, using the ADIF format. Thus it would be possible, if WSJT-X implements this TCP connection, to have WSJT-X send a complete QSO information to N1MM+ via this TCP connection the moment a contact is logged in WSJT-X. I am hopeful that the WSJT-X developers will consider adding this "wish" to their already ample list of users' feature requests, in spite of their very busy schedules. If this capability already exists in WSJT-X or one of its add-ons, I [1] apologize for the bandwidth and [2] would be most appreciative of being pointed in the right direction so that I can peruse the documentation. Have a great week All, and Thanks for All that You Do!! 73, Roger Rehr W3SZ -- Check out the vibrant tech community on one of the world's most engaging tech sites, Slashdot.org! http://sdm.link/slashdot___ wsjt-devel mailing list wsjt-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wsjt-devel
Re: [wsjt-devel] First Alpha Release of MAP65 v2.7
QSL Joe! I understand and will post devel-type-stuff to devel and operating type/general interest type stuff to MoonNet. Thanks again for all of this. I can tell you that many, many PackRats have become so re-excited and re-energized by the new JT stuff, and one of my 80 year old buddies W3HMS is having a ball with MSK144 on 6 meters. He is absolutely enthralled with it; it is really cool to see his enthusiasm So you are even making the old young again!! 73, Roger On 1/20/2017 1:55 PM, Joe Taylor wrote: > Hi Roger, > > QSL on all your comments! > >> With this version I also get the Fortran error when I have Linrad set to >> 40 M band instead of 2M, where it belongs. > Code revision r7547 protects against possible forwarding of invalid > frequencies to the decoder. > >> One last point. In his initial posting about the Windows installer >> version, Joe said that he preferred discussion occur on MoonNet. That >> makes sense for comments regarding decoding performance, GUI >> bugs/glitches/complaints, etc. But do you really want comments >> regarding install issues, coding/error trapping issues, etc. to occur on >> Moon Net rather than here? > No, of course most software issues should be discussed here. Reports > about how well QRA64 works, etc., can go either here or to Moon-Net. > > I mentioned Moon-Net only because most of the users who volunteered for > testing MAP65 v2.7 are not members of wsjt-devel. > > -- Joe, K1JT > > -- > Check out the vibrant tech community on one of the world's most > engaging tech sites, SlashDot.org! http://sdm.link/slashdot > ___ > wsjt-devel mailing list > wsjt-devel@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/wsjt-devel -- Check out the vibrant tech community on one of the world's most engaging tech sites, SlashDot.org! http://sdm.link/slashdot ___ wsjt-devel mailing list wsjt-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wsjt-devel
Re: [wsjt-devel] First Alpha Release of MAP65 v2.7
I apologize for not making it clear that my reports from "last night" were using the MAP65 Windows Installer version. I did not know that the new version was also on the svn. Posts to this list today make it clear that the new version is also available as source code, so I have installed and will do all further tests with the versions from the svn unless you folks direct me otherwise. I have now installed 2.7 r7546 from source using JTSDK and it installs and runs without errors so far. With this version I also get the Fortran error when I have Linrad set to 40 M band instead of 2M, where it belongs. The error is as I reported before. Verbatim the error I just created now by putting Linrad on 40M is: "Fortran runtime error: Index '-2809519' of dimension 1 of array 'ca' outside of expected range (1:5376000)" With Linrad set to 7.025 this is identical to the error message I reported before with Linrad also set to 7.025 at that time. The error still causes MAP6's Decode button to be stuck in light blue decoding mode. I understand that this is not "usual" use of MAP65. I report it for the reasons detailed in my previous post. Double-left-clicking on a signal on the zoomed lower portion of the Wide Graph display will also cause MAP65 to be stuck in Decode mode. Again, this is not "usual" use of the program. Once MAP65 has receive a full sequence's worth of data and done its own first automatic decode, double-lef-clicking in the lower zoomed portion of the Wide Graph display does not cause problems. MAP65 attempts to decode and then the Decode button returns to gray background color state. This test is on another computer than the one I used for "last night's" testing; this one is at my station and so when the moon rises I will have a chance to see how it decodes. I will be able to run it vs multiple instances of WSJT-X to do a comparison of decoding at some point, but that won't get done this weekend given that the ARRL Jan VHF contest will be running and I will be busy with that. The OS is still 64 bit Windows 10. One last point. In his initial posting about the Windows installer version, Joe said that he preferred discussion occur on MoonNet. That makes sense for comments regarding decoding performance, GUI bugs/glitches/complaints, etc. But do you really want comments regarding install issues, coding/error trapping issues, etc. to occur on Moon Net rather than here? That seems less than optimal to me in at least 2 ways [1] many MoonNet users won't understand or give a hoot about these technical and more esoteric issues and [2] while Joe monitors MoonNet carefully, I am not sure that all of the other developers do so. I will follow your preference on this, just let me know what it is. The most logical choice to me is to triage the email to one list or the other depending upon its content. There is also the issue that there are still a few "digital haters" on the MoonNet list, so it would be prudent not to flood that list with MAP65 bug reports, I think. Thanks and keep up the great work as well as your spirits! 73, Roger W3SZ -- Check out the vibrant tech community on one of the world's most engaging tech sites, SlashDot.org! http://sdm.link/slashdot ___ wsjt-devel mailing list wsjt-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wsjt-devel
Re: [wsjt-devel] Waterfall Zero and Gain controls
Hi Michael, Thanks for the note! Flatten does not prevent the temporal variation in noise floor levels. It alters (straightens) the noise level across the frequency spectrum at a particular point in time. 73, Roger W3SZ On 11/9/2016 3:59 PM, Black Michael wrote: > The "Flatten" doesn't work? > > de Mike W9MDB > > > -------- > *From:* Roger Rehr W3SZ <w3s...@gmail.com> > *To:* WSJT software development <wsjt-devel@lists.sourceforge.net> > *Sent:* Wednesday, November 9, 2016 2:44 PM > *Subject:* [wsjt-devel] Waterfall Zero and Gain controls > > I am hoping that this is the right place to make this comment/request > regarding what is essentially the ergonomics of the WSJT-X GUI. > > I've been using the devel versions of WSJT-X for several hours a day for > the past several weeks for 144 MHz EME reception in a location with > significant and constantly varying noise levels that cause the noise > floor to undulate continually. > > I find the waterfall zero control to be very awkward to use for > frequent, very small adjustments of this parameter. I understand that > it is possible to use the arrows on the keyboard to adjust this > parameter after selecting the waterfall zero level control with the > mouse or trackball, but that too is awkward to do on a frequent basis. > I would much prefer either arrow up/down boxes, ideally with a > user-adjustable increment size, or a text box where I could type in the > zero level that I want. To help you understand what I want, I will > refer to Linrad, which uses each of these types of controls for some > functions. For example, the up/down arrow boxes are used in Linrad to > set both the gain and the zero level of the main spectrum, and the text > boxes are used to set the gain and zero level of the main waterfall. > > This is more than just a whimsical preference. If that were all that it > is, I would not bother the development team. What prompted me to post > this rather than just grinning and bearing the current user interface is > the fact that the 4th and 5th digits on my right hand have become > painful when performing this activity, as a result of the need to tense > the muscles and make tiny movements to make tiny changes in the zero > level value without "going too far" in one direction or the other > repetitively day after day for the past few weeks. Either arrows or > text boxes would eliminate the production of this kind of > musculoskeletal stress by the WSJT-X GUI. > > I have no problem with the spectrum gain and zero controls, for they do > not require such fine motions to set appropriately. > > As an aside, in all of the pieces of software that I have used over the > years, I have found the "auto zero", "auto gain", and "waterfall AGC" > functions to NOT set the zero level or gain of the waterfall to my > satisfaction. So I would NOT suggest adding such a function as a > possible solution to this problem. > > Thanks in advance, and thanks for all of the great work that you do! > > 73, > > Roger Rehr W3SZ > > > > -- > Developer Access Program for Intel Xeon Phi Processors > Access to Intel Xeon Phi processor-based developer platforms. > With one year of Intel Parallel Studio XE. > Training and support from Colfax. > Order your platform today. http://sdm.link/xeonphi > ___ > wsjt-devel mailing list > wsjt-devel@lists.sourceforge.net <mailto:wsjt-devel@lists.sourceforge.net> > https://lists.sourceforge.net/lists/listinfo/wsjt-devel > > -- Developer Access Program for Intel Xeon Phi Processors Access to Intel Xeon Phi processor-based developer platforms. With one year of Intel Parallel Studio XE. Training and support from Colfax. Order your platform today. http://sdm.link/xeonphi___ wsjt-devel mailing list wsjt-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wsjt-devel
[wsjt-devel] Waterfall Zero and Gain controls
I am hoping that this is the right place to make this comment/request regarding what is essentially the ergonomics of the WSJT-X GUI. I've been using the devel versions of WSJT-X for several hours a day for the past several weeks for 144 MHz EME reception in a location with significant and constantly varying noise levels that cause the noise floor to undulate continually. I find the waterfall zero control to be very awkward to use for frequent, very small adjustments of this parameter. I understand that it is possible to use the arrows on the keyboard to adjust this parameter after selecting the waterfall zero level control with the mouse or trackball, but that too is awkward to do on a frequent basis. I would much prefer either arrow up/down boxes, ideally with a user-adjustable increment size, or a text box where I could type in the zero level that I want. To help you understand what I want, I will refer to Linrad, which uses each of these types of controls for some functions. For example, the up/down arrow boxes are used in Linrad to set both the gain and the zero level of the main spectrum, and the text boxes are used to set the gain and zero level of the main waterfall. This is more than just a whimsical preference. If that were all that it is, I would not bother the development team. What prompted me to post this rather than just grinning and bearing the current user interface is the fact that the 4th and 5th digits on my right hand have become painful when performing this activity, as a result of the need to tense the muscles and make tiny movements to make tiny changes in the zero level value without "going too far" in one direction or the other repetitively day after day for the past few weeks. Either arrows or text boxes would eliminate the production of this kind of musculoskeletal stress by the WSJT-X GUI. I have no problem with the spectrum gain and zero controls, for they do not require such fine motions to set appropriately. As an aside, in all of the pieces of software that I have used over the years, I have found the "auto zero", "auto gain", and "waterfall AGC" functions to NOT set the zero level or gain of the waterfall to my satisfaction. So I would NOT suggest adding such a function as a possible solution to this problem. Thanks in advance, and thanks for all of the great work that you do! 73, Roger Rehr W3SZ -- Developer Access Program for Intel Xeon Phi Processors Access to Intel Xeon Phi processor-based developer platforms. With one year of Intel Parallel Studio XE. Training and support from Colfax. Order your platform today. http://sdm.link/xeonphi ___ wsjt-devel mailing list wsjt-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wsjt-devel
Re: [wsjt-devel] ALL.txt idea
I use the All.txt now for research by parsing it and feeding it into an SQLite database. I think that having WSJTX write to an SQLite or equivalent database would be a good solution, and as David says, separate purpose-built utilities accessing that database could serve a wide range of end users with varying needs without needlessly increasing the complexity of WSJTX. 73, Roger Rehr W3SZ On 11/7/2016 10:22 AM, David Tiller wrote: > > Michael, > > > My suggestion would be to follow the Unix design philosophy - do one > thing, and do it well. I vote for any of the ALL.TXT > searching/manipulation/modification be handled in a separate utility > that's decoupled from the WSJT-X codebase. > > > -- > > *David Tiller | *Senior Manager > dtil...@captechconsulting.com > c 804.304.0638 / o 804.355.0511 > > <http://www.captechconsulting.com/> > > <http://www.facebook.com/CapTechCareers> > <http://www.twitter.com/CapTechListens> > <http://www.linkedin.com/company/captech-ventures> > <http://www.stackoverflow.com/jobs/companies/captech-consulting> > <http://www.youtube.com/user/CapTechConsulting> > <https://www.instagram.com/lifeatcaptech/> > > *Best Firms 2016 #2* in Information Technology > > > > > *From:* Black Michael <mdblac...@yahoo.com> > *Sent:* Monday, November 7, 2016 9:18 AM > *To:* Greg Beam; WSJT software development > *Subject:* Re: [wsjt-devel] ALL.txt idea > > I wouldn't be inclined to add database support when the most common > operations are achievable with the existing ALL.TXT. Haven't we > discussed this before? Somebody said something about putting the > messages in an sqlite database as I recall and had implemented something. > Though I'm sure we could make it portable it's adding a fair bit of > new stuff and overhead for doing this simple task. Right now my logic > is about 100 lines of code and can pick up non-standard end-of-qso > messages to some degree right now. > > Is there some other function desirable from a database that would > justify it? I can see where adding a field for "Rx Frequency" window > message presence would help in processing QSOs. Non-standard QSO > messages would be an SQL challenge. > > > de Mike W9MDB > > > > > *From:* Greg Beam <ki7m...@gmail.com> > *To:* Black Michael <mdblac...@yahoo.com>; WSJT software development > <wsjt-devel@lists.sourceforge.net> > *Sent:* Monday, November 7, 2016 12:37 AM > *Subject:* Re: [wsjt-devel] ALL.txt idea > > Hi Mike, > > This is another email I just pulled out of the spam box. No wonder I was > missing the other half of the conversation. > > Ive been thinking about these text files for some time now. There has to > be a better way than exercising command-line foo to get the data folks > need. Not that I mind the command line, I spend most of my time there, > but that's not very helpful to the masses. > > There seems to be allot of different uses for CALL3.txt and the ALL.txt > files. I keep circling back to database tables and I've played with the > CALL.txt file a bit with WSJT, but the Qt / C++ deal with WSJT-X I've > not gotten through yet. > > Maybe if we sit down and try to capture most or at least some of the > requirements, we could start kicking around some DB integration design > concepts. > > 73's > Greg, KI7MT > > > On 11/6/2016 11:03 AM, Black Michael wrote: > > Pretty simplewhen, for example, on eQSL, you get a mismatched QSL > > you can look at your messages to see if they got it wrong or you did. > > And you can submit the evidence to them so they can correct or you > > correct your own. > > > > I've also used it when noticing in JTAlert that a band isn't > > confirmed...I can look them up and see the evidence again and either > > correct my log or ask them to correct theirs. > > > > With LOTW you don't have that luxury.since there's no visibility of > > mismatched QSOs > > > > And yes...this is a WSJT Dev list item as I'm proposing submitting a > > patch to make this easy for everyone instead of just those with grep, > > EMACS, or whatever they may be currently using. > > > > de Mike W9MDB > > > > > > > > *From:* Greg Beam <ki7m...@gmail.com <mailto:ki7m...@gmail.com>> > > *To:* WSJT software development <wsjt-devel@lists.sourceforge.net > <mailto:wsjt-devel@lists.sourceforge.net>> > > *Se
Re: [wsjt-devel] call3.txt
Relu, You can download a call3.txt file from: http://www.mmmonvhf.de There are many uses for such a file other than just WSJT and its related programs. I use call3.txt with my Aircraft Scatter software, for example. If on the website just noted you click on VHF-DATABASE and then "Edit my Data" you can enter or change your data in the call3.txt file that others will download. I believe that is what you want to do. You need to log in to do that. Call3.txt is updated daily, so if you add your data it will be quickly available to others. To download the call3.txt file click on VHF-DATABASE and then on "Download" and then select call3.txt from the list of files presented. If you look at the file, you will see that it is useful for far more than EME. I use the entire file with my Aircraft Scatter software, and I use a smaller version with WSJT and related programs. A utility keeps all of my WSJT-related call3.txt files in various directories in sync with each other when changes are made, but this utility does not touch nor examine the Aircraft-Scatter-related call3.txt. Hope that helps! 73, Roger Rehr W3SZ On 11/2/2016 2:21 PM, Relu Jianu wrote: > I'm sorry for stirring this up, I was more concerned with the > usefulness of this file in the VLF and VHF/UHF and or EME modes where > I would think (maybe naively) that priori would benefit a user giving > the additional deep decode advantage. > > I know there are a list of sites where this file can be obtained and a > user can "add" to it locally but thought it would be beneficial to > find a way for users to add their call to that file for the benefit of > others. > > It might be faster than waiting for this information to be received or > decoded over time. > > Another question: Do all decoded calls automatically update this file > locally or only when you click "add"? > > 73 Relu NJ9R > -- Developer Access Program for Intel Xeon Phi Processors Access to Intel Xeon Phi processor-based developer platforms. With one year of Intel Parallel Studio XE. Training and support from Colfax. Order your platform today. http://sdm.link/xeonphi ___ wsjt-devel mailing list wsjt-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wsjt-devel
Re: [wsjt-devel] Still suspect something Evil in latest W10 Updates
You might also try uninstalling the app[s] / drivers in question and then rebooting and then reinstalling the apps / drivers. That has been known to fix problems with many apps that crop up after Windows 10 updates. Unfortunately, it does not fix all such problems. I had to uninstall/reinstall VAC here to resolve some problems that cropped up after a Win 10 update. 73, Roger Rehr W3SZ On 10/7/2016 10:55 AM, Josh Rovero wrote: > On one of my recently updated W10 PCs, when wsjtx is terminated, the > wsjtx process remains active (according to task manager) even though > the GUI is gone. It is impossible to terminate HDSDR instances except > through task manager (i.e., STOP and EXIT buttons don't work), And > when wsjtx is launched, the audio level via VAC is zero, nada, > niente. Yesterday, it seemed to launch ok, but terminated (froze) > within an hour. > > The RF is processed by a QS1R via CWSL to both CW Skimmer Server and > multiple instances of HDSDR. > > Wouldn't be an issue except that normally I'd be running 7 * wsjtx in > WSPR-2 mode, 2 * wsjtx in JT65+JT9 mode, and 8 * fldigi in PSK mode on > this box. The flidigi VAC connections to HDSDR seem OK. CW Skimmer > Server and CW Reporter are running OK. Only the wsjtx/HDSDR > connections are having issues. That connection is via VAC, which is > working fine for fldigi and HDSDR. > > Will try running all applications as administrator, and see if that > helps. > > -- > P.J. "Josh" Rovero http://www.roveroresearch.org > Ham Radio: KK1D http://www.roveroresearch. > <http://www.roveroresearch.org/>net > http://www.roveroresearch.info > > > -- > Check out the vibrant tech community on one of the world's most > engaging tech sites, SlashDot.org! http://sdm.link/slashdot > > > ___ > wsjt-devel mailing list > wsjt-devel@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/wsjt-devel -- Check out the vibrant tech community on one of the world's most engaging tech sites, SlashDot.org! http://sdm.link/slashdot___ wsjt-devel mailing list wsjt-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wsjt-devel
[wsjt-devel] WSJTX-1.7.0-rc1 Fortran error
Hi All, I wasn't sure whether or not I should post this here, but here it is. Last weekend while operating the ARRL EME contest on 10 GHz and running Windows 10 32 bit with wsjtx-1.7.0-rc1 I noticed the following wsjtx error: Subprocess Error Subprocess failed with exit code 2. The Details of this error were: - Running: C:\JTSDK\wsjtx\devel\qt52\1.7.0\Release\install\bin\jt9 -s WSJT-X -w 1 -m 3 -e C:\JTSDK\wsjtx\devel\qt52\1.7.0\Release\install\bin -a C:\Users\PSDR\AppData\Local\WSJT-X -t C:\Users\PSDR\AppData\Local\Temp\WSJT-X At line 40 of file C:\JTSDK\src\wsjtx\lib\xcor4.f90 Fortran runtime error: Index '0' of dimension 1 of array 'nch' below lower bound of 1 - This happened repeatedly. I was using CAT rig control and DTR PTT, and Virtual Audio Cables for my input and output audio devices. I switched back to version 1.66.1-devel and all was OK. I've run 1.7.0-rc1 before and since on the same computer without problems. So I don't know why I had the error message appear repeatedly at that time, but figured that I should make it known. 73, Roger Rehr W3SZ -- Check out the vibrant tech community on one of the world's most engaging tech sites, SlashDot.org! http://sdm.link/slashdot ___ wsjt-devel mailing list wsjt-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wsjt-devel
[wsjt-devel] MAP65 azel.dat file
Hi All, Is it intentional that MAP65 azel.dat file from v2.5, r4705 puts DxDop and not myDop on line 4? I would think that MyDop would be useful for those using this file to set radio frequency. Thanks and 73, Roger Rehr W3SZ -- ___ wsjt-devel mailing list wsjt-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wsjt-devel
