Re: [wsjt-devel] How to use JT9.EXE?
Hi Rik, Maybe you can find this post of mine useful, as it includes examples about how to generate and decode your own JT9 (and other) signals using the WSJT-X command line tools. https://destevez.net/2016/10/simulating-jt-modes-how-low-can-they-get/ (This was done a couple years ago, so I think that something has changed slightly, but not much). 73, Dani. signature.asc Description: OpenPGP digital signature ___ wsjt-devel mailing list wsjt-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wsjt-devel
Re: [wsjt-devel] JT9-2 mode?
El 11/09/18 a las 12:04, Rik Strobbe escribió: > Hello Joe, all, > > I understand that there are better ways to achieve a lower S/N decoding than > going back to JT9-2. > But awaiting this I would anyway want to do some tests with longer JT9 > transmission on 630m. > Since I am afraid that it is out of my league to dive in to the WSJT-X code > and modify it I thought of an alternative route: > Generate a "normal" JT9 signal, but transmit it at half speed. This > transmission will take 98 seconds and be at half the original audio frequency > (also half bandwidth). > At the RX side the audio is recorded as a WAV file, speed is doubled again > (just by changing the sample rate in the WAV file header) and this file is > fed to WSJT-X. > I know it sounds is a a bit of an odd thing to do, but at least feasible for > me. > Would this work (and improve SNR), or am I just trying to be too smart? Hi Rik, That would work. I have thought of the same idea sometime in the past, but never got to test it. 73, Dani EA4GPZ. ___ wsjt-devel mailing list wsjt-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wsjt-devel
[wsjt-devel] SVN repository failure?
Hello, Has anything happened to the SVN repository? It seems that it has rolled back to 2009: $ svn log svn://svn.code.sf.net/p/wsjt/wsjt | head r1476 | k1jt | 2009-10-01 22:23:28 +0200 (jue, 01 oct 2009) | 2 lines YES!!! It now works with soft decisions, using KVASD2.EXE. r1475 | k1jt | 2009-10-01 21:29:55 +0200 (jue, 01 oct 2009) | 2 lines We have a working (hard decision) JT64 decoder! 73, Dani EA4GPZ. -- 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] Fwd: Re: 20 M FT8 freqs for DXpeditions? (long)
El 20/08/17 a las 22:21, Alex, VE3NEA escribió: > Of course, 400W should be the average power of the amplifier, not the > peak power. > > Splitting the power unevenly between the messages (in favor of the > callers on a difficult path) may improve the peak to average power ratio. Or more interestingly, if the frequencies of the signals bear no simple relation then a large fraction of the time PAPR is not so high and not much is lost by bringing the amplifier a bit into compression. This is used in FreeDV 700C, where the PSK carriers use some well thought spacing instead of a multiple of the baudrate as OFDM would say. My guess is that if one puts 10 FT8 signals at random frequencies, then the signals are not so affected by compression in the amplifier. However, this would generate a lot of spurious signals as IMD. But still, if this is for a DXpedition working several caller simultaneously in a pileup we might deem all this IMD as a minor problem and end up seeing this as acceptable behaviour. This thing about transmitting several signals at the same time is quite interesting, since I haven't seen much done about it in ham radio. 73, Dani EA4GPZ. -- 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] Bugs in command line tools in WSJTX 1.8.0-rc1
Hi all, I have compiled WSJTX 1.8.0-rc1 from source an I'm finding the following bugs in the command line tools. jt9 will always segfault when run for JT9: $ jt9 -9 00_01.wav Program received signal SIGSEGV: Segmentation fault - invalid memory reference. Backtrace for this error: #0 0x7F9211B1DD98 #1 0x7F9211B1CF30 #2 0x7F92108100CF #3 0x4110F0 in symspec_ #4 0x406D52 in MAIN__ at jt9.f90:? Segmentation fault - ft8d will also segfault always: --- $ ft8d 40 2 00_01.wav Program received signal SIGSEGV: Segmentation fault - invalid memory reference. Backtrace for this error: #0 0x7F4C03C8ED98 #1 0x7F4C03C8DF30 #2 0x7F4C029810CF #3 0x414C60 in bpdecode174_ #4 0x403A5D in ft8b_ #5 0x402693 in MAIN__ at ft8d.f90:? Segmentation fault - ft8sim doesn't seem to work properly. When run as suggested in the example: ft8sim "K1ABC W9XYZ EN37" 0.0 0.1 1.0 10 -18 all the samples of the generated wav file are 0. When run as ft8sim "EA4GPZ M0HXM IO94" 0.0 0.0 0.0 1 0 there is noise and a signal in the generated wav file, but the signal is not valid FT8 (it covers more than 2kHz of spectrum). 73, Dani. -- 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 notes
El 30/06/17 a las 19:06, Joe Taylor escribió: > Anyone is welcome to build WSJT-X from source code, and use the results > on the air. But please DO NOT post your pre-built binaries for others > to download. This causes needless support problems for us. We have no > way of knowing exactly what you did. And if all you post is some sort > of binary, you're violating our GPL license. Hi Joe, I don't want to get into an argument here, and I understand the reason for frowning upon people posting pre-built binaries, but I just wanted to clarify the statement about the GPL license. I'm not a lawyer, so I might not be 100% correct on this, but, as far as I know, you can redistribute binaries for GPL software without the accompanying source code. However, you should be ready to provide the source code _if_ you are asked to do so by whoever got your binary. No need to send any source code if you're not asked to do so. Also, if the code you have compiled is available online (say, from the WSJT SVN) and you have not modified it (as it is the case with pre-built binaries of the SVN trunk), it might be enough to point the user to the location of the source online. 73, Dani EA4GPZ. -- 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] AP for DX call only if VHF/uW enabled
El 22/04/17 a las 11:56, Charles Suckling escribió: > Hi Dani > > Not sure we are seeing exactly the same behaviour. > > If I start program having closed from QRA64 then it is active. > > If then without closing I select eg JT4 then it is greyed out in JT4, as it > should be. > > If I then return to QRA64, without closing the program, it is greyed out. > The only way to get it back is to then close and restart. Hi Charlie, No. We're not seeing the same thing. If I start the program having closed from QRA64, then it is active. Without closing I select JT4 and it's still active. If I go back to QRA64, it's still active. But if I start the program having closed from, say JT4, then it's always grayed out. I have VHF/uW disabled, by the way. I'm not sure if this makes a difference. 73, Dani. -- 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] AP for DX call only if VHF/uW enabled
El 22/04/17 a las 06:52, Charles Suckling escribió: > Hi Dani > > We have found some time ago that if you have "Enable AP for DX call" active > then open the settings tab to make some other change, after that action > "Enable AP for DX call" becomes greyed out. > > Try making your change (eg to disable VHF and up), close WSJT-X and restart. > You may then find "Enable AP for DX call" is active again. Hi Charlie, Thanks for the tip. I've found that if WSJT-X starts in QRA64 mode (because this was the mode selected when I closed it before), then "Enable AP for DX call" is active regardless of the mode I select. However, if WSJT-X starts in another mode, then "Enable AP for DX call" is grayed out even if I select QRA64. I'm running r7648. 73, Dani. -- 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] AP for DX call only if VHF/uW enabled
Hi, I've noted that the "Enable AP for DX call" option is only active if VHF/uW features are enabled. Otherwise this option is grayed out and can not be toggled. I think is a bug, because AP for DX call is also useful for HF. 73, Dani. -- 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] JT65 HF bands capacity, spectra allocation, and software support
El 04/03/17 a las 09:58, Takehiko Tsutsumi escribió: > All; > > This Saturday afternoon, 15m is crowded and occupied with 100 TX , 83 RX > stations according to JT Alert and the most strong spectrum on 15m > exists on JT65 channel. Wsjt-x Water fall window is really colorful. > See attached screen shot. > > Even though we are demonstrating how JT65 is spectrum efficient format, > it is not called as "week signal format" by the reason that we are > creating interference with ourselves packed in single narrow channel. I > need full power to chase DX. > > We need to spread out. Hi all, This makes me wonder why people don't use JT9A, which is much more efficient than JT65A for HF use. Maybe this pushes more people into trying JT9. Also, people tend to pack themselves willingly into a 2.5kHz slice, since otherwise people with conventional SSB radios won't see you and you'll get less QSOs. 73, Dani. -- 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] Proposal to include Future WSJT-X Specification
El 08/02/17 a las 06:50, Takehiko Tsutsumi escribió: > Hi, > > I am a newbie of this mailing list and I do not know the details of the > procedure to add new feature to WSJT-X specification and implement new > feature. > > However, I have a proposal of these and it is attached to this mail. > > I am happy if somebody guides me to participate the process defined in > this society. > > I am waiting the reply soon. Hi Takehiko, I've read your notes and I don't understand well what this Frequency Management Center is. Is it some sort of online server to exchange the information about what frequencies people are using? I think that would belong more to an online chat server or some other service where people can set up skeds rather than WSJT-X. I think that it's important that QSOs with WSJT-X can be done without exchanging any data through the internet, so people can choose if they want to coordinate QSOs with the help of the internet or not. A better solution to the problem you mention about incompatible band plans is to listen simultaneously on different frequencies so that split random QSOs can happen without the need for external coordination about the frequencies. This can be done with adequate hardware (SDR). In the HF bands it is easy to accomplish this. I understand that this problem also happens in 13cm EME, where different countries have really different allocations. Here it is more difficult to listen on all the possible frequencies (the separation is several MHz), so people coordinate frequencies using HB9Q chat or other sked online services. It would be nice to allow for the possibility of indicating in the CQ call which other frequencies you're listening to. The problem is that this is potentially too much data to include in the short messages that the JT modes use. The only similar feature is the "CQ nnn" feature, where you can indicate another frequency where you're listening and where people are supposed to call you. Finally, I think it's important to try to harmonize working frequencies on a global basis. This simplifies things a great deal. Sometimes it is not possible to achieve a completely global solution due to different band plans, but imagine the mess if every country used a different working frequency. 73, Dani. -- 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] Problem in HamlibTransceiver.cpp with rigctld and FT-817ND
Hi, There is a problem in HamlibTransceiver::do_start() which manifests itself when using a FT-817ND through rigctld. The FT-817ND doesn't have support for get_vfo, set_vfo, nor RIG_OP_TOGGLE. However, rigctld advertises all the capabilities, so each of the capabilities must be tested instead of trusting rig_->caps Currently, only get_vfo is tested (get_vfo_works_). The problem is as follows: In lines 461 and 481 of HamlibTransceiver.cpp, either RIG_OP_TOGGLE or set_vfo is used according as to whether rig_->caps->set_vfo is false. However, the FT-817ND supports none of this. Probably the whole block of code between lines 446 and 511 should not run for the FT-817ND. The main problem is the (rig_->caps->set_vfo || rig_has_vfo_op (rig_.data (), RIG_OP_TOGGLE) condition in the if statement for this block. If using rigctld this evaluates to true, since rig_->caps->set_vfo is true regardless of whether the rig supports it or not. It would be better to test for set_vfo before and use a variable set_vfo_works_ instead of rig->caps->set_vfo (in the manner of get_vfo_works_). I am not doing this change myself because I'm not familiar with the code and I'm not sure if my proposed solution will give problems with other rigs. 73, Dani EA4GPZ. -- 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] JT9 decoder broken in WSJT-X r7552
El 27/01/17 a las 03:29, Bill Somerville escribió: > On 26/01/2017 21:55, Dani EA4GPZ wrote: >> I've found that the JT9 decoder in r7552 seems to be broken. > > Hi Dani, > > thanks for reporting this issue and providing data to reproduce it. > > I have temporarily reverted a change that caused the issue, r7555 should > be working better. Hi Bill, Thanks for fixing this quickly. r7555 is working fine for me. 73, Dani. -- 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] JT9 decoder broken in WSJT-X r7552
Hi all, I've found that the JT9 decoder in r7552 seems to be broken. I'm listening on 40m and signals are good. Some periods I get decodes as normally, while other periods I get no decodes. Here is the recording of one of the periods where I got no decodes, using the jt9 command line tool. $ jt9 -d 3 -9 ~/.local/share/WSJT-X/save/170126_2128.wav 0 0 If I use jt9 from 1.7.0 on the same file, then I get decodes. $ ./jt9 -d 3 -9 ~/.local/share/WSJT-X/save/170126_2128.wav 2128 -6 0.1 1511 @ CQ G0NNF IO92 2128 -22 0.3 672 @ VA3MJR EC1DBO -16 2128 -24 0.9 801 @ ON4VT CG3KI 73 2128 3 -0.5 997 @ PB7JOS IK2CTH JN46 2128 -23 0.4 1105 @ ON8IM N3GGT 73 2128 -13 0.2 1343 @ EA4GPZ W1YIF 73 0 6 This sort of thing has also happened in many other periods. This particular recording can be downloaded here: https://drive.google.com/open?id=0B2pPGQkeEAfdczB2dlJQQXFfMlk It seems that the JT65 decoder also suffers the same problem, but I haven't looked into it any further. 73, Dani EA4GPZ. -- 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] Status of QRA64 in WSJT-X v1.7
El 17/11/16 a las 20:27, Joe Taylor escribió: > Please join me in again thanking Nico Palermo, IV3NWV, who designed the > basic codec for QRA64 -- including novel features for handling Doppler > spreads that may be even larger than the tone spacing. Well said Joe, When I read Nico's original paper "QRA codes for EME", I was fascinated by his idea of this new mode, especially the way it handles a priori information to improve the decoding threshold. I think we should all thank Nico and that this is the start of a new world of possibilities for EME and other weak signal work, including allowing even smaller stations than what was possible with JT65. I'm eager to see some documentation on these new features for Doppler spreads you mention (of course I'm confident that something will be published in due time). 73, Dani EA4GPZ. -- ___ wsjt-devel mailing list wsjt-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wsjt-devel
Re: [wsjt-devel] QRA64 2m transatlantic contact
El 06/10/16 a las 19:35, Joe Taylor escribió: > Hi Dani, > > Dani EA4GPZ wrote: >> Probably we've all heard about the recent 2m QRA64 transatlantic contact: >> >> http://www.arrl.org/news/transatlantic-contact-completed-on-2-meters >> >> What I find a bit strange is the signal reports of -36dB and -37dB SNR >> that they give. Even though QRA64 is quite good, I would expect that >> it's almost impossible to copy QRA64 signals at -36dB. > > Evidently you have not seen the messages I posted yesterday to > "wsjtgroup". For completeness they are copied below. Hi Joe, Many thanks for the info. That really explains things. Silly me, I didn't know about wsjtgroup and I thought all the "action" happened in wsjt-devel. I'll go suscribe to wsjtgroup also. 73, Dani. -- 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] QRA64 2m transatlantic contact
Hi all, Probably we've all heard about the recent 2m QRA64 transatlantic contact: http://www.arrl.org/news/transatlantic-contact-completed-on-2-meters What I find a bit strange is the signal reports of -36dB and -37dB SNR that they give. Even though QRA64 is quite good, I would expect that it's almost impossible to copy QRA64 signals at -36dB. I haven't seen sensitivity graphs for the QRA64 mode that has finally made it into WSJTX, but looking at the graphs in Nico's paper: http://microtelecom.it/qracodes/QRACodes-Rev10.pdf it seems that it's almost impossible to copy anything below -31dB or -32dB, even with lots of a priori info for the decoder. What do you guys think? Are the recordings of the contact available? 73, Dani EA4GPZ. -- 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] WSJT-X and gain staging
El 17/08/16 a las 19:57, George J Molnar escribió: > Then, as some suggest, it might be a good time to consider retiring the > slider, while retaining the thermometer. Not a "stop the presses" > change, but it might be a good usability bump. Perhaps even a color > coded indication for the dB-impaired? Just to point out a usage scenario where the slider can be useful: On the HF bands, you can encounter very strong signals or not for each period. If you're using a conventional receiver, you'll need to use its AGC. Otherwise, the receiver will saturate if the RF gain is set too high or you'll lose SNR in the periods where there are no strong signals if the RF gain is set low enough to prevent saturation on strong signals. At least, this is what seems to work best on my FT-817ND. With this setup, the radio will present a constant audio output level whenever there are strong signals. Therefore, you can adjust your soundcard level (and perhaps any attenuation you have in front of it) to make the level, say 90% of maximum when there are strong signals. The soundcard will never clip, because the radio AGC prevents it. When using this strategy, I find that I have to set the slider in WSJT-X quite low to get 30dB when only receiving the noise floor. The level in WSJT-X will only raise to 40dB when receiving strong signals, because the AGC of the radio prevents a further increase. Of course, the slider in WSJT-X doesn't make any difference in decoding performance, but can be used to ensure a good level in the waterfall without having to tweak the waterfall sliders (same effect can be achieved with them, of course, but you have to tweak both the waterfall and spectrum zero points). At least, this is what I've being doing so far with my rig. Perhaps others can suggest a better strategy for a conventional receiver and the HF bands. 73, Dani EA4GPZ. -- ___ wsjt-devel mailing list wsjt-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wsjt-devel
