Re: [wsjt-devel] Repeated crashes with large number of decodes
Bjorn, Ref your recent question - "Has anyone else experienced this?" Short answer - no. I recently returned to Virginia from spending time in Hawaii. I was on the Big Island and had unbelievable six meter band conditions which repeated for four or five days in a row in March. [great February conditions too with multi-day 6M openings] My WSJT-X screen was sometimes solid red on both sides with calling stations. I worked FT8 and FT4 for hours without a problem. FYI - the all-dot-txt file contained over 27,000 lines of 6M data from mid-to-late February to late'ish March ... with breaks in operation. Everything was A-OK. The number of decodes is unknown of course. Do not recall the number of stations worked, but maybe 500 or 600 unique calls or so. Just a SWAG [scientific wild ass guess]. [[as you know, the all-dot-txt file records everything the radio hears ... not just me ... ergo the 27,000 lines of data.]] Joe - that is a great historical file! By the way, I use an older WSJT-X version because it seems some of the newer versions cause various issues. Sorry Joe. But Joe, on the other hand, this is also a testimony on the robustness of WSJT-X. Regards, Danny AH6FX - Hawaii ... aka W4/AH6FX - Virginia On Tuesday, May 2, 2023 at 04:18:22 PM EDT, Joe Taylor via wsjt-devel wrote: Hi Björn, Thanks for your report. Of course you are correct about the cause of this bug. The issue was reported in January, and supposedly corrected in bug release 2.6.1. Alas, it was corrected in only one of two necessary places. It will be fixed in the next release. -- 73, Joe, K1JT On 5/2/2023 1:51 PM, Björn Ekelund via wsjt-devel wrote: > Decoding the DX0NE pile-up repeatedly crashes WSJT-X 2.6.1. There are a > lot of decodes. From what it seems, over 100. > > My guess is that the array mentioned in the crash report simply runs out > because nobody thought there > would ever be more than 100 decodes in a cycle. > > Has anyone else experienced this? > > Björn SM7IUN > > Subprocess Error > Subprocess failed with exit code 2 > > Running: C:\WSJT\wsjtx\bin\jt9 -s WSJT-X -w 1 -m 3 -e C:\WSJT\wsjtx\bin > -a C:\Users\SM7IUN\AppData\Local\WSJT-X -t > C:\Users\SM7IUN\AppData\Local\Temp\WSJT-X > At line 222 of file C:\JTSDK64-Tools\WSJTX\BBdevelop\lib\ft8_decode.f90 > Fortran runtime error: Index '101' of dimension 1 of array 'allsnrs' > above upper bound of 100 > > 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 > > > > > > ___ > 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 ___ wsjt-devel mailing list wsjt-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wsjt-devel
Re: [wsjt-devel] [Moon-Net] FH 6m EME DXpedition Update
Lance, Good luck on your DXpedition. I will be looking for you. I share your frustration with "non-standard" call signs. Actually they are standard in the ham radio world, even per Part 97 ... but non-standard for WSJT-X. That is another issue for another day. My call is AH6FX and I am in Virginia now. For WSJT-X purposes I configure or set-up WSJT-X for W4/AH6FX. However if I configure as AH6FX/W4 various reflectors pick me up as Hawaii and I likely get logged as Hawaii too. To control expectations, I always configure as W4/AH6FX while in Virginia and my grid shows properly as FM18. [[note: in Virginia when working SSB I always sign as AH6FX/W4 to control expectations.]] I return to Hawaii next month and will configure as AH6FX - stand alone - normal. But when I return to Virginia -- it is back to the "non-standard" call. [[note: look for me on 160 FT8 in early-to-mid April from Hawaii] This is what you must be aware of when operating "non-standard." A "non-standard" can not work a "non-standard." Therefore W4/AH6FX can not work FH/W7GJ without reconfiguring. To work you, I would reconfigure as AH6FX and then shift back to W4/AH6FX after completing our FT8 exchange. My recommendation to you when working FH/W7GJ ... ignore the "non-standards" calling you unless you have the time to reconfigure your call sign set-up. But the moral of the story is ... as Joe suggested ... get a type 1 call to satisfy more people and operate as seamlessly as possible. Have a good trip. Danny AH6FX/W4 -- Virginia On Saturday, March 19, 2022, 12:14:50 PM EDT, Lance Collister, W7GJ via wsjt-devel wrote: Hi Charlie! MNI TNX for your email! I made sure to get a dedicated Type 1 callsign because Joe told me that it is always better than using a compound callsign such as FH/W7GJ. But you raise a very interesting question. I no longer see the ability to enter non-standard prefixes in WSJT-X the way we did in WSJT10 and you sure are correct in that neither TO nor TX (both prefixes widely used by France for special callsigns) are in the list of accepted standard Type 1 prefixes. I did seem to be able to use Q65 to make contacts from TX7MB last fall, but now I wonder if some of the problems I had with decodes might have been because TX is not in the list of standard Type 1 prefixes. I just tried an FT8 contact between my two computers, and it appears TO7GJ was decoded OK, but I don't know if it may not work properly in the AVERAGE with weak Q65 signals, or might for some other reason appear to decode less easily when signals are very weak. I have copied this email to K1JT and the developer group in the hope that someone could shed some light on this issue. I also hope that some of my suggestions from last fall regarding how the AVERAGE function behaves, and a CALL3.TXT lookup in DEEP SEARCH could be implemented into Q65 (to automate my manual guessing and/or "internet cheating" as to what station I should enter into the DX CALL box to activate the Ap sensitivity) before the next 6m EME DXpedition. I want to make sure I have the best tools at my disposal before I go halfway around the world to rely on them ;-) TNX again for bringing up this question! I will be sure to share any information and guidance received. GL and VY 73, lance On 3/19/2022 10:08:33, Charles wrote: > Hi Lance > > I don't see TO as an allowed type 1 prefix in WSJT-X. > > I'm not sure what this means for Q65 QSOs (if anything) - maybe a good idea > to > check with Joe? > > It doesn't throw up the <> around he callsign when generating standard > messages, so > I probably worrying unnecessarily! > > 73 > > Charlie > > On 16/03/2022 06:00, Lance Collister via Moon-net wrote: >> The callsign TO7GJ has been granted for the September 6m EME DXpedition to >> Mayotte. The link to the planned operating schedule and all the other >> details are >> available on the new website here: >> >> http://www.bigskyspaces.com/w7gj/Mayotte%202022.htm >> >> You have 6 months to gear up to work this rare DXCC! Please spread the word, >> and >> don't wait until the last minute - I will NOT be operating when the moon >> isabove >> 65 degrees elevation ;-) >> >> GL and VY 73, Lance >> -- Lance Collister, W7GJ(ex WA3GPL, WA1JXN, WA1JXN/C6A, ZF2OC/ZF8, E51SIX, 3D2LR, 5W0GJ, E6M, TX5K, KH8/W7GJ, V6M, T8GJ, VK9CGJ, VK9XGJ, C21GJ, CP1GJ, S79GJ, TX7MB, TO7GJ) P.O. Box 73 Frenchtown, MT 59834-0073 USA TEL: (406) 626-5728 QTH: DN27ub URL: http://www.bigskyspaces.com/w7gj Skype: lanceW7GJ 2m DXCC #11 - 6m DXCC #815 - FFMA #7 Interested in 6m EME? Ask me about subscribing to the new Magic Band EME email group, or just fill in the request box at the bottom of my web page (above)! ___ wsjt-devel mailing list wsjt-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wsjt-devel
Re: [wsjt-devel] Bill Somerville, G4WJS, SK
Joe, Thanks for informing us about the death of Bill –G4WJS. We all will miss him. There was perhaps not one WSJT-X question hecould not answer. My condolences to his family and friends. DannyAH6FX/W4- Virginia On Sunday, December 5, 2021, 10:37:21 PM EST, Gary Lane via wsjt-devel wrote: Very sad news, my condolences to Bills friends and family…. Gary VK4OO > On 5 Dec 2021, at 19:15, John Nelson via wsjt-devel > wrote: > > Joe, > > I am saddened to learn of your news. This is blow to the WSJT-X community. > > In the early days of Bill’s involvement with WSJT he often logged into my > Macs at home to test his software modifications on a Mac until he got a VM > working. He and I had numerous discussions while testing new versions on > various Mac OS. He was generous with his time in helping folks with problems > either running the codes or attempting to build the software on various > platforms. The multitude of emails to the development list is a tribute to > his commitment to ensure that the various programs operated flawlessly. > > His involvement with the development of WSJT-X code especially with > modernising the structure of the whole program has been immense. I will > certainly miss his advice. > > A sad day… > > — John G4KLA___ > 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 ___ wsjt-devel mailing list wsjt-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wsjt-devel
Re: [wsjt-devel] exporting from adi
Jim, I can do as you suggest or I can even interface WSJT-X with Log4OM and do it seamlessly. I chose to do it as described to Murphy-proof things as much as possible and follow the KISS principle. Thanks for the comment Jim. Have a great day. Danny AH6FX/W4 - Virginia On Friday, May 22, 2020, 4:39:35 PM EDT, Stephen VK3SIR wrote: Hi Michelle, By far the best way to avoid duplicates in logs is to not set "Settings\Reporting\ Log automatically..." . If you come back with a RR73, auto log, and then a station comes back with a R-XX (what I term a "RR/73 Loop") then both communication and logging can lead to duplicates in logs. Each logged entry should be manually approved (so do not check "Log automatically"). Some software loggers and bridges such as JTAlert (that I use and recommend heavily) also are not perfect. I use JTALert with DXLab's DXKeeper. No matter what I do sometimes (and erratically) a duplicate is logged to eQSL. These are issues for their support forums. Despite this forewarning would strongly echo Jim's post and recommend JTAlert's use to you ! JTAlert can be found at https://hamapps.com. DXLab can be found at https://dxlabsuite.com . None of these products are viruses if your AV scanner goes into overdrive and its safe to add these programs (and their destinations) as AV over-rides. I personally use DXKeeper as the central logging tool and use its "Export QSO's" function to "Export standard ADIF" back to the "wsjtx.log" file (found in the location accessible by "File/Open Log Directory"). DXKeeper has great tools for managing duplicates. When all duplicates are removed periodically write them back to WSJT-X over-writing previous "wsjtx.log" instances :-) More info on how to do this and set up products can be found on each product's support forums :-) 73 Steve I VK3VM / VK3SIR -Original Message----- From: Jim Preston Sent: Saturday, 23 May 2020 1:15 AM To: DX Jami via wsjt-devel Subject: Re: [wsjt-devel] exporting from adi Danny, Why not just have JTAlert (if you use it) or WSJT-X log directly to Log4OM? Then you wouldn't have to go through the adif import routine. 73, Jim N6VH On 5/20/2020 6:45 PM, DX Jami via wsjt-devel wrote: > Michelle, > > My logging program is Log4OM ver2. I routinely import my WSJT-x adi > files into Log4OM with no problems. Most logging programs import only > current loggings. Ensure you click something like “do not import > duplicates” in your logging program as you download and you should > have no problems. > > Good luck. > > Danny > > AH6FX/W4 - Virginia > > Sent from Mail <https://go.microsoft.com/fwlink/?LinkId=550986> for > Windows 10 > > *From: *Michelle Sack via wsjt-devel > <mailto:wsjt-devel@lists.sourceforge.net> > *Sent: *Wednesday, May 20, 2020 9:21 PM > *To: *WSJT software development > <mailto:wsjt-devel@lists.sourceforge.net> > *Cc: *Michelle Sack <mailto:ms...@verizon.net> > *Subject: *Re: [wsjt-devel] exporting from adi > > I'm new to FT8 and WSJT software. Is a way to export from the log only > the recent contacts? This way I don't make duplicates in my logging > programs but still keep contacts in the WSJT log for notifications of > new (preventing duplicate contacts in FT8). > > Thanks > > Michelle N3YRZ > > > > ___ > 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 ___ 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] exporting from adi
Michelle, My logging program is Log4OM ver2. I routinely import my WSJT-x adi files into Log4OM with no problems. Most logging programs import only current loggings. Ensure you click something like “do not import duplicates” in your logging program as you download and you should have no problems. Good luck. Danny AH6FX/W4 - Virginia Sent from Mail for Windows 10 From: Michelle Sack via wsjt-devel Sent: Wednesday, May 20, 2020 9:21 PM To: WSJT software development Cc: Michelle Sack Subject: Re: [wsjt-devel] exporting from adi I'm new to FT8 and WSJT software. Is a way to export from the log only the recent contacts? This way I don't make duplicates in my logging programs but still keep contacts in the WSJT log for notifications of new (preventing duplicate contacts in FT8). Thanks Michelle N3YRZ ___ wsjt-devel mailing list wsjt-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wsjt-devel
Re: [wsjt-devel] ICOM IC-7300, no luck connecting from either a Windows machine or a Mac
On Saturday, April 11, 2020, 10:01:08 AM EDT, DX Jami wrote: Elliott, Concur with what the other guys said. The internet is your friend on this problem. K0PIR has a series of very helpful videos. Check out: Try this video first. It is the WSJT-X / Windows 10 troubleshooting video ... ignore the HRD stuff is not appropriate to you ... WSJT-X discussion begins at the 12:30 minute mark and perhaps the answer to your problem begins at the 14:30 mark. Not sure if K0PIR mentions it ... but perhaps your IC-7300 --- WSJT-X --- com port settings are not the same - check 'em out. https://www.youtube.com/watch?v=AngV0gLW5HY or try this one for basic set up:https://www.youtube.com/watch?v=z-KQBlqA2wI [[ignore the DM780 portion near the end]]] or try this https://www.youtube.com/watch?v=klZPXbh6cPg=desktop [[ignore the last half if you do not run HRD]] Hope this helps. Good luck. Danny AH6FX/W4 - Virginia On Saturday, April 11, 2020, 8:34:06 AM EDT, Frank Birch wrote: Ensure the Baud rates are the same. I’m able to run at highest. Are you connecting direct to the USB port - no hub. Stay safe, be well 73 Ve4fbz > On Apr 11, 2020, at 8:13 AM, sourceforge@from.ec wrote: > > Hi, all. I'm trying to get my ICOM IC-7300 connected for rig-control and > digital modes. > > I've installed the drivers (from SiLabs on my Mac, and directly from ICOM on > my Windows box); but on both machines, with just about every combination of > configuration options I've tried, I get this error: > >> Rig failure >> Hamlib error: Communication bus error while getting current frequency > > On my Windows machine, the ICOM shows up as "COM3" (i.e. that's the only menu > option); and on my Mac, it shows up as all four of /dev/cu.SLAB_USBtoUART, > /dev/tty.SLAB_USBtoUART, /dev/cu.usbserial-4224411, and > /dev/tty.usbserial-4224411. (i.e. all four of those disappear when the radio > is disconnected.) > > Here's a screenshot of my Windows configuration, as well as some pics of the > ICOM's settings (all reset to factory-settings, and I've tried every > combination I can think of ...): https://imgur.com/a/mg9BcAd > > I'm a fairly competent(?) programmer, but this has completely baffled me. > I've tried everything I can think of, so any help is very welcome. Happy to > attempt any debugging-steps that y'all can suggest, too! > > ~ Elliott Cable, KL4JC > > > ___ > 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 ___ wsjt-devel mailing list wsjt-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wsjt-devel
Re: [wsjt-devel] ICOM IC-7300, no luck connecting from either a Windows machine or a Mac
Elliott, Concur with what the other guys said. The internet is your friend on this problem. K0PIR has a series of very helpful videos. Check out: Try this video first. It is the WSJT-X / Windows 10 troubleshooting video ... ignore the HRD stuff is not appropriate to you ... WSJT-X discussion begins at the 12:30 minute mark and perhaps the answer to your problem begins at the 14:30 mark. Not sure if K0PIR mentions it ... but perhaps your IC-7300 --- WSJT-X --- com port settings are not the same - check 'em out. https://www.youtube.com/watch?v=AngV0gLW5HY or try this one for basic set up:https://www.youtube.com/watch?v=z-KQBlqA2wI [[ignore the DM780 portion near the end]]] or try this https://www.youtube.com/watch?v=klZPXbh6cPg=desktop [[ignore the last half if you do not run HRD]] Hope this helps. Good luck. Danny AH6FX/W4 - Virginia On Saturday, April 11, 2020, 8:34:06 AM EDT, Frank Birch wrote: Ensure the Baud rates are the same. I’m able to run at highest. Are you connecting direct to the USB port - no hub. Stay safe, be well 73 Ve4fbz > On Apr 11, 2020, at 8:13 AM, sourceforge@from.ec wrote: > > Hi, all. I'm trying to get my ICOM IC-7300 connected for rig-control and > digital modes. > > I've installed the drivers (from SiLabs on my Mac, and directly from ICOM on > my Windows box); but on both machines, with just about every combination of > configuration options I've tried, I get this error: > >> Rig failure >> Hamlib error: Communication bus error while getting current frequency > > On my Windows machine, the ICOM shows up as "COM3" (i.e. that's the only menu > option); and on my Mac, it shows up as all four of /dev/cu.SLAB_USBtoUART, > /dev/tty.SLAB_USBtoUART, /dev/cu.usbserial-4224411, and > /dev/tty.usbserial-4224411. (i.e. all four of those disappear when the radio > is disconnected.) > > Here's a screenshot of my Windows configuration, as well as some pics of the > ICOM's settings (all reset to factory-settings, and I've tried every > combination I can think of ...): https://imgur.com/a/mg9BcAd > > I'm a fairly competent(?) programmer, but this has completely baffled me. > I've tried everything I can think of, so any help is very welcome. Happy to > attempt any debugging-steps that y'all can suggest, too! > > ~ Elliott Cable, KL4JC > > > ___ > 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 ___ wsjt-devel mailing list wsjt-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wsjt-devel
Re: [wsjt-devel] 7 Digit Callsigns
Reino, Respectfully -- that is not a good answer. You addressed the WSJT-X issue while WSPR was the problem. Having said that - constructively, WSJT-X must accept what are now called non-standard calls. They are non-standard only to the WSJT-X programmers and not the ham radio world. They are authorized and recognized by the FCC and perhaps also by worldwide communications governing bodies. MANY people use "non-standard" call signs, including several DXpeditions. I hope the WSJT-X programmers find the coding "real estate" to normalize all call signs. I know your programming issues behind the problem. You all are going a great job - keep up the good work. Danny W4/AH6FX ... or AH6FX/W4 ... et al On Friday, February 21, 2020, 7:36:44 AM EST, Reino Talarmo wrote: Bill, Thanks, for sure. I should have read more carefully, hi! 73, Reino oh3mA From: Bill Somerville [mailto:g4...@classdesign.com] Sent: 21. helmikuuta 2020 11:59 To: wsjt-devel@lists.sourceforge.net Subject: Re: [wsjt-devel] 7 Digit Callsigns Reino, Matt's query is abut WSPR mode, there are no CQ calls and the structured messages are much simpler since they are beacon transmissions. The handling of non-standard calls is also different from QSO modes. 73 Bill G4WJS. On 21/02/2020 06:39, Reino Talarmo wrote: Hi Matt, You should be possible to send CQ message without grid square locator and make contacts with the help on hashed call sign using automatic message generation. There strong limits what can be included into a single message, when the basic call sign is 7 characters long. As a workaround you could use free text messages for your grid square locator such as ‘VK3FDLL AB12’ or ‘AB12 VK3FDLL’ and broadcast that message now and then, or send as the last message of a QSO ‘LOC AB12 73’. Other station can see that is belongs to you from the frequency. That kind of method is used in the EU VHF contest messages as a part of the protocol. Note that free text maximum is 13 characters including space characters. 73, Reino oh3mA From: Matt VK3FDLL [mailto:matt+vk3f...@geekle.id.au] Sent: 21. helmikuuta 2020 7:08 To: wsjt-devel@lists.sourceforge.net Subject: [wsjt-devel] 7 Digit Callsigns Hi there, I'm using WSJT-X (WSPR Mode) for quite a while for receiving and now I've attempted to transmit. I am a Foundation Licence holder in Australia (VK), which means I have a 7 digit callsign - VK3FDLL With various tests, I can hear my WSPR transmissions away from my station and WSJT-X can even decode my transmissions. However the decoding only occurs on transmissions where my callsign is hashed (Type 3 message, I believe?) Transmissions where my full, 7 digit callsign (and 4 digit grid square locator) is transmitted are not decoded by WSJT-X Are you able to point me in the right direction as to how I can achieve being decoded correctly? Or does the software and/or protocol simply don't support a 7 digit callsign? Regards, Matthew Jones - VK3FDLL ___ 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] Spooky!
Artie, Japanese stations operate split on 1905 during 160 meter band operations. Maybe you were attempting to work a JA and clicking his CQ took you to 1905 ... or simply a JA station posted "QSY 1905" to send you and other stations there so they could get some good DX action. I use an IC-7300 also, and it happened to me a few times. Danny AH6FX/W4 - Virginia On Friday, January 17, 2020, 2:18:58 PM EST, Artie Langston wrote: I'll reread the manual. Sometimes, I think I've "read" documentation, without comprehending everything I've thought I've "read". I was just a bit taken aback, as this was my very first encounter, even after WAS and DXCC on FT8. Pretty great feature! Thanks! Artie KD0GY On Fri, Jan 17, 2020 at 1:06 PM Alex wrote: Thanks. I will check it out. Maybe I'll get to utilize that this weekend (if the ice will stay away). 73, --Alex KR1ST On Jan 17, 2020, at 1:44 PM, Joe Taylor wrote: On 1/17/2020 1:21 PM, Alex wrote: On VHF and up that would be an interesting function to have, as long as the only the intended station QSY's and not everyone who receives the message. :) Although that could be fun, too. ;) 73, --Alex KR1ST It's described in the manual. Mainly intended for meteor-scatter operation using MSK144. Also useful (for example) for working JAs in 160m, as XE2YWH was doing in the example screen shot. -- Joe, K1JT On 2020-01-17 13:04, Artie Langston wrote: I just had a strange experience working FT8 on 160M. I received a magenta bar in the RX window and a message that said QSY 1.908, to which the IC-7300 gladly obliged - without any action on my part, proceeding to change frequency all by itself! xxx.png Is my shack haunted? I can't think of a silent key I owed money to. Time to schedule a seance? Artie KD0GY 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 ___ 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 ___ wsjt-devel mailing list wsjt-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wsjt-devel
Re: [wsjt-devel] WSJT-X bug report
Thanks Saku. I understand the work-around and use various versions myself. My point is WSJT-X should allow "non-standard" call signs. Those non-standard calls are only non-standard for WSJT-X and A-OK for the rest of the ham radio world. Many DXpeditions have similar problems as does almost any station signing /something or something/. My standard set-up shows W4/AH6FX which does not show grid ... but it does show USA in the scrolling list in the Band Activity portion. If I set-up AH6FX/W4 using my grid FM18 ... my DXCC entity shows Hawaii - not Virginia or USA. Can't win ... some contacts gripe about no grid ... and when configured the other way they gripe about Hawaii. No problems tho when I operate from Hawaii but in Virginia most of the time. Danny AH6FX/W4 On Thursday, December 26, 2019, 12:21:51 PM EST, Saku wrote: DX Jami via wsjt-devel kirjoitti 24.12.2019 klo 15.26: > Another shortfall with non-standard calls is signing like me - > W4/AH6FX. The "real estate" shortfall does not allow passing my grid, > so that is very bothersome to some folks. Hi! There is a good practice for this used by F5MYK/MM. For every now and then he sends free text message like "F5MYK/MM OJ12". It is easy to follow that way and also easy to implement to companion programs like I did to Cqrlog wsjtx-monitor. If first word of free text is same as set in followed callsing and the second word is true 4chr locator then free text is captured for easier finding from all decoded messages. Several rare open sea grids already worked here... -- Saku OH1KH ___ 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 bug report
Zoli, That is a shortfall within WSJT-X. There is not enough "real estate" in the programming framework to allow two non-standard call signs to trade exchanges. Another shortfall with non-standard calls is signing like me - W4/AH6FX. The "real estate" shortfall does not allow passing my grid, so that is very bothersome to some folks. Plus I often, not always, can not conduct exchanges with other non-standard call signs such as yours. Merry Christmas, Danny - AH6FX/W4 On Monday, December 23, 2019, 12:14:43 PM EST, Zoltan Vodinszki via wsjt-devel wrote: Thank you all for the response! Shouldn’t there be a way to not let one user with a special call-sign call someone else with the same type of call-sign. I had to wait for quite a while for someone to let go trying and continue working as he was locking me by calling me. All the best!Zoli Sent from Yahoo Mail for iPhone On Monday, December 23, 2019, 4:32 PM, Reino Talarmo wrote: Zoli! You got a nice work-around for working non-standard call signs. The Users Guide states in clause 7.5 Except for the special cases involving /P or /R used in VHF contesting, WSJT-X 2.1 offers no support for two nonstandard callsigns to work each other. Good luck and 73, Reino oh3mA Zoli! Use free text and give his call sign and report 73 Keijo OG55W ___ 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 ___ wsjt-devel mailing list wsjt-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wsjt-devel
Re: [wsjt-devel] FT8 ghost signals
Rich, I hear what you say about the Doppler effect, and I recall our conversations on HF about it. I do not challenge the theory and facts behind the Doppler effect, but I believe there is more to the propagational phenomena we attribute to the Doppler effect. Being one who often challenges conventional wisdom ... here is a question I have been pondering. For hams, we consider the Doppler effect of radio wave bouncing off airplanes, and this causes unique radio conditions. My question is since the number of airline-only [excluding worldwide military and private] flights increased from 23.8 [2004] to 39.4 [2019 to-date] MILLION why do we not experience more Doppler effect situations on ham radio? Another data point in that equation is the number of commercial [only] flights per day in the US ... which is about 87,000. I recall us talking about the unique sound of the Doppler effect, and sometime attribute it to my/our proximity to Dulles International Airport. I am very close to the take-off and landing approaches to Dulles, and I am even closer to those of Manassas International which has a lot of private & business traffic. So my chances of being affected by Doppler should be greater. However, I have not experienced a proportional increase of Doppler related conditions. What's going on? Why do we not have more "Doppler propagation instances ... or do we and just not realize it?" BTW - sorry for this being somewhat outside the scope of WSJT-X. Ciao, Danny AH6FX/W4 Nokesville, Virginia On Sunday, July 7, 2019, 5:31:38 AM EDT, Martin Davies G0HDB wrote: On 6 Jul 2019 at 16:06, Rich Zwirko - K1HTV wrote: > Here in the Mid-Atlantic, a number of 6 Meter FT8 DXers have observed > backscatter signals that appear as a 2nd or even a 3rd signal on the WSJT-X > Wide Graph window. The Doppler shifted frequency is usually lower than the > direct signal. In addition to the directly received FT8 signal appearing on > the waterfall display, at times both direct signal as well as one or more > of the reflected backscatter Doppler shifted signals can be decoded. The DF > between the main and ghost signals is usually between 40 and 130 Hz. The > average appears to be around negative 70 Hz. > > When these ghost signals are observed, they are usually noted on multi-KW > FT8 signals produced by stations in the Mid-Atlantic region that are > beaming towards highly ionization Es regions. These extra waterfall signals > can last a few minutes then quickly disappear. I have not observed them > when there is no Es opening. They don't appear to be the result of signals > being reflected off aircraft. Hi Rich, why do you believe the 'ghost' signals that are being observed aren't caused by reflections off aircraft? I very regularly see, and FT8 will decode, a second and sometimes even a third signal from nearby stations that are within a few miles of my QTH; on my waterfall I can see the direct signal and also the secondary signal(s) that almost always have a clearly discernible slant on them, indicating that the cause of the secondary signal is Doppler shift from a moving object. In my experience the secondary signal(s) can be either higher or lower in frequency, by some indeterminate amount, than the direct signal so they're not artefacts resulting from 50/60Hz power-line modulation of the FT8 audio signal, and the +ve or -ve offset of the secondary signal(s) from the direct signal will presumably indicate the direction of travel of the moving point of reflection. IMO there's no almost doubt that such 'ghost' signals are caused by reflections off aircraft; I suppose it's theoretically possible that a very fast-moving cloud of Es ionisation could cause the same effect but I would guess that such clouds don't move at similar speeds to aircraft! --- Martin, G0HDB --- This email has been checked for viruses by Avast antivirus software. https://www.avast.com/antivirus ___ 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 Audio Input Loss
Peter, Flex has its own set of unique problems and fixes. Suggest you post your question on the Flex forum page. Good luck. Danny AH6FX/W4 On Wednesday, July 3, 2019, 3:11:48 PM EDT, Peter Putnam wrote: Greetings, I have been using WSJT-X quite successfully for several years during June VHF Contests. I experienced a failure of the WSJT program to accept received audio input after several hours of proper operation during the recent Field Day exercise. I'll provide a brief outline and reply with more detail, should it be needed. My computer is a Dell Optiplex 780 running Win 7 Pro SP1, 64-bit. The WSJT-X software version is 2.0.1 7ddcb7. My receiver is a Flex 6500. It passes data to a Flex-supplied "DAX" program that interfaces various applications that wish to receive the audio stream. WSJT accepts the stream and displays results on the Wide Graph and a small audio signal-strength window. Activity proceeded normally for the first three hours of Field Day, until both the Wide Graph and the audio signal-strength stopped showing any incoming audio. I can't offer any help on what might have caused the problem. It was abrupt and seemingly unrelated to any other system actions. I am unable to reproduce the problem. Several operators spent several hours speculating about what a solution might be. Program restarts and computer re-boots (time-tested favorite of generations) changed nothing. The only useful clue was that the DAX audio output stream was present and could be re-directed to Fldigi, but not to WSJT-X. I was able to restore operation for a brief period by stopping WSJT, renaming WSJT.ini and restarting WSJT. That fix lasted for a half hour. Repeating the procedure provided operation for the rest of Field Day. The two .ini files that were renamed are available for your inspection, along with the one that continued to function. Any suggestions you can offer to prevent a recurrence would be greatly appreciated. Regards, Peter NI6E ___ 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] FT8 calling CQ
Dwight, I log everything to the WSJT-X log and periodically export the adi file to Log4OM which is a Windows based program. There I can import the log to any of my four call-sign logs. When on DX-vacations I run a MacBook Pro and do the same thing - export that file to Log4OM. Having said that I use MacLogger DX on the Apple MacBook Pro. Log4OM populates many of the missing data elements such as grid when I run the update utility. FYI - waving the flag for Log4OM ... it was developed by the same guy who was the brains behind HRD. He sold HRD and later developed Log4OM, which is simple but still has many basic features we seek in logging programs. It is free - but many folks contribute to help keep its excellent support going. I know I can set up WSJT-X to interface with those logging programs, but I choose to keep things simple and Murphy-proof as much as possible by doing the extra steps. I realize too that logging programs may provide the missing grid too, but ... Danny W4/AH6FX - Virginia On Saturday, April 13, 2019, 10:43:50 AM EDT, dgb wrote: If it's a new call I haven't worked, my logger automatically looks the call in qrz or if it's previously worked, it grabs it from the old log entry. What logger are you using, mine is DXLabs? 73 Dwight NS9I On 4/13/2019 9:13 AM, DX Jami via wsjt-devel wrote: Dick, Agree with you Dick. It is a big pain to log an "abbreviated" FT8 QSO which omits the grid square. I used to use http://www.levinecentral.com/ham/grid_square.php to look up missing grids. With the grid square competition now history ... grids to some are less important. Altho I am not a grid square collector - I always looked up the missing grid square because my "logs" required them. Of course we can not log an FT8 contact into the grid square database without a valid grid square. However, we can log an FT8 exchange into our "FT8 contact" log without a grid. It simply has no entry for the grid square data element. This is not a big show stopper because my logging program updates certain missing fields when I import the WSJT-X log.adi file. But fundamentally Dick, when working as a DX station, I simply ignore stations which do not go thru the entire FT8 exchange sequence because many of them are QRMing my in-progress QSO and simply being rude, like I said previously. I hear several people talk about speeding up FT8 exchanges by eliminating certain parts of the FT8 sequences. For the most part, I reject that argument. Maybe we all have a lot of time on our hands even if we are working FT8, and working one more redundant DXCC entity is perhaps no big deal. Have a good day. Danny W4/AH6FX - Virignia On Friday, April 12, 2019, 5:38:40 PM EDT, Richard Solomon wrote: As fast as FT8 is, there are folks who want a QSO completed faster. It's a real pain, especially if I have to look up the guys call to get his Grid Square. And, if it's a portable operation, it's even more difficult. 73, Dick, W1KSZ Sent from OutlookFrom: Timothy Hickman Sent: Friday, April 12, 2019 11:44 AM To: wsjt-devel@lists.sourceforge.net Subject: [wsjt-devel] FT8 calling CQ I have noticed lately that when I send CQ on FT8 A few stations start their respond with the signal report not their grid square. Is there something here I do not understand? Tim N3JON ___ 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 ___ 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 ___ wsjt-devel mailing list wsjt-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wsjt-devel
Re: [wsjt-devel] FT8 calling CQ
Dick, Agree with you Dick. It is a big pain to log an "abbreviated" FT8 QSO which omits the grid square. I used to use http://www.levinecentral.com/ham/grid_square.php to look up missing grids. With the grid square competition now history ... grids to some are less important. Altho I am not a grid square collector - I always looked up the missing grid square because my "logs" required them. Of course we can not log an FT8 contact into the grid square database without a valid grid square. However, we can log an FT8 exchange into our "FT8 contact" log without a grid. It simply has no entry for the grid square data element. This is not a big show stopper because my logging program updates certain missing fields when I import the WSJT-X log.adi file. But fundamentally Dick, when working as a DX station, I simply ignore stations which do not go thru the entire FT8 exchange sequence because many of them are QRMing my in-progress QSO and simply being rude, like I said previously. I hear several people talk about speeding up FT8 exchanges by eliminating certain parts of the FT8 sequences. For the most part, I reject that argument. Maybe we all have a lot of time on our hands even if we are working FT8, and working one more redundant DXCC entity is perhaps no big deal. Have a good day. Danny W4/AH6FX - Virignia On Friday, April 12, 2019, 5:38:40 PM EDT, Richard Solomon wrote: As fast as FT8 is, there are folks who want a QSO completed faster. It's a real pain, especially if I have to look up the guys call to get his Grid Square. And, if it's a portable operation, it's even more difficult. 73, Dick, W1KSZ Sent from OutlookFrom: Timothy Hickman Sent: Friday, April 12, 2019 11:44 AM To: wsjt-devel@lists.sourceforge.net Subject: [wsjt-devel] FT8 calling CQ I have noticed lately that when I send CQ on FT8 A few stations start their respond with the signal report not their grid square. Is there something here I do not understand? Tim N3JON ___ 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 ___ wsjt-devel mailing list wsjt-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wsjt-devel
Re: [wsjt-devel] FT8 calling CQ
Tom, Roger Tom. As a DX station, you know that many stations move to your transmit freq and call. Then it becomes bad as the deliberate QRM starts. Sometimes it is amazing how many stations needlessly get on a DX station's transmit freq. Danny W4/AH6FX On Wednesday, April 10, 2019, 12:59:07 PM EDT, Tom Ramberg via wsjt-devel wrote: It doesn't make qrm unless you start calling on the DX's frequency. But in that case it's a nuisance. I have no problem with lots of stations calling me as long as the stay off my tx frequency. 73 de Tom JW6VDA Sendt fra min iPad Air 2 10. apr. 2019 kl. 16:24 skrev DX Jami via wsjt-devel : Tim, Everything the others have said is true. But it is a matter of perspective too. Sometimes people click on a DX or desired station whenever they see it pop on their Band Activity screen. This station [the "clickee" :-) ] often appears without showing its grid square. Sometimes the "clicked" or DX station may be doing an FT8 exchange with another station. In my opinion, we do not want to click on a station ... DX or not while they are in QSO with another station. Besides being rude, that practice sometimes generates deliberate QRM on the freq and nobody makes a QSO then. I am sometimes a DX station when operating from Hawaii, and that practice not only slows the process down, but it also can bust a number of QSOs. Often, I will not respond to an FT8 station who breaks in like that, and I know other DX operators who share my thought. Having said that, it seems like some stations call after a final "73" concludes the previous FT8 contact. That is probably OK and the "responding" or "clickee" station's grid is sent unlike when a station simply QRMs and attempts to break in. 73, Danny W4/AH6FX On Tuesday, April 9, 2019, 3:02:37 PM EDT, Bill Barrett wrote: Tim-They are simply trying to get the Q over a little faster.DXpeditions like callers to start with S.R. so their Q rate/hour is maximizedBill W2PKY On Tue, Apr 9, 2019 at 2:29 PM Timothy Hickman wrote: I have noticed lately that when I send CQ on FT8 A few stations respond with the signal report not their grid square. Is there something here I do not understand? Tim N3JON ___ 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 ___ 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 ___ wsjt-devel mailing list wsjt-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wsjt-devel
Re: [wsjt-devel] FT8 calling CQ
Tim, Everything the others have said is true. But it is a matter of perspective too. Sometimes people click on a DX or desired station whenever they see it pop on their Band Activity screen. This station [the "clickee" :-) ] often appears without showing its grid square. Sometimes the "clicked" or DX station may be doing an FT8 exchange with another station. In my opinion, we do not want to click on a station ... DX or not while they are in QSO with another station. Besides being rude, that practice sometimes generates deliberate QRM on the freq and nobody makes a QSO then. I am sometimes a DX station when operating from Hawaii, and that practice not only slows the process down, but it also can bust a number of QSOs. Often, I will not respond to an FT8 station who breaks in like that, and I know other DX operators who share my thought. Having said that, it seems like some stations call after a final "73" concludes the previous FT8 contact. That is probably OK and the "responding" or "clickee" station's grid is sent unlike when a station simply QRMs and attempts to break in. 73, Danny W4/AH6FX On Tuesday, April 9, 2019, 3:02:37 PM EDT, Bill Barrett wrote: Tim-They are simply trying to get the Q over a little faster.DXpeditions like callers to start with S.R. so their Q rate/hour is maximizedBill W2PKY On Tue, Apr 9, 2019 at 2:29 PM Timothy Hickman wrote: I have noticed lately that when I send CQ on FT8 A few stations respond with the signal report not their grid square. Is there something here I do not understand? Tim N3JON ___ 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 ___ wsjt-devel mailing list wsjt-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wsjt-devel
Re: [wsjt-devel] Proposing Fox & Hound Operation on 1810kHz for A35JT - can JA access direct?
Grant, I know some US operators configure for split operations and work JA's on 1.905. US stations transmit within the 1500 Hz to 2500 Hz range. So US guys will transmit on 1.840 and receive on 1.908. Good luck with your Tonga operation. Regards, Danny AH6FX - Hawaii ... W4/AH6FX - Virginia On Sunday, April 7, 2019, 7:29:11 AM EDT, Bill Somerville wrote: On 07/04/2019 06:14, Grant VK5GR wrote: I am proposing to use a somewhat unorthodox frequency for F/H mode on 160m from Tonga in September in order to allow both JA and the rest of the world to call us in F/H mode. My current thinking is to use 1810kHz dial (USB). This means that the fox transmissions will be between 1810.3-1810.5kHz and the hounds will be above 1811kHz. However, my question is – can Japanese amateurs transmit digital modes in that part of 160m? Hi Grant, looking at the latest JA band plan from the JARL web site, it would seem the answer is no. https://www.jarl.org/English/6_Band_Plan/JapaneseAmateurBandplans20150105.pdf 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] Behavior during QSO between 2 long calls
Bill, Thanks for your response. The compound call issue is shared with me by many as we see. As you mentioned ... after an FT8 exchange, I often send something like "Aloha fm Virginia" and sometimes I send the grid too. There are some considerations about that though. Number one - perhaps not all people pay attention to the extra transmission ... and are perhaps scrambling to find my grid on-line or more likely searching for other stations. Number two - sending the extra info takes a lot of effort especially when on the air for a few hours and we start getting fatigued. Number three -- compound calls should be handled without problems. They are "legal" call signs allowed by many countries ... plus they are "authorized" under international treaty ... in most cases under CEPT, via the provisions of IRAP [International Amateur Radio Permit ] agreements, or under other reciprocal ham radio permit arrangements. As for us in the U.S. and territories, the FCC authorizes compound calls under the provisions of the US law regulating amateur radio, Part 97, Code of Federal Regulations. Let me know, I will send you an extract if you desire. I understand the technical limitations you described about this issue. Your idea about a public domain database providing grid info sounds interesting. I use Amateur Radio Ham Radio Maidenhead Grid Square Locator Map but unfortunately it does not do most compound calls. With the lack of a usable database ... why doesn't WSJT-X generate one itself ... a self-generating database. For instance ... as someone enters a compound call in set-up ... the required information is transmitted to the big WSJT-X compound database in the sky [perhaps with user permission obtained from a pop-up], and integrated accordingly in the FT8 execution script. [I recognize not all compound call users have internet access to do that ... but perhaps it could be done in preparation for DXpeditions and those taking DXvacations, etc.] Of course we are up against the 77-bit limitation ... but you had an idea about databases - that is an option. Another option in dealing with the 77-bit limitation is dividing the FT8 transmission into two seamless execuables. For instance ... two .bat files execute various lines of the FT8 transmission ... something like .bat1 executes FT8 lines Tx1, Tx2, and Tx3 ... .bat2 executes Tx4, Tx5, and perhaps Tx6 [maybe Tx6 does not demand some of the 77-bit allocation ... ???] By executing the two .bat files, perhaps your programming can piggy-back two seamless executions as though they are one standard FT8 transmission. Of course the compatibility issue may come into play ... hopefully your solution will be compatible with version 2, et al. Another option is to do whatever you did for KH1/KH7Z. I am guessing you used city.dat to overcome that issue. Not an option for someone like me who semi-routinely operates from two different DXCC entities - but might work for everyone else. One more option ... perhaps do the compound calls as a special operating activity such a fox / hound ... or a contest, etc. Now sure if you can overcome the 77-bit real estate issue and resolve the other technical issues here or not. Just a thought ... In closing, Bill - I want to say I appreciate the great effort by you, Joe, and the entire WSJT-X team. It is an understatement to say your work has changed ham radio for the better. With all due respect, I say the compound call issue must be overcome. If you spend time on the bands playing FT8 ... daily, you will see various stations using compound calls and sometimes you will see calls from the two "overseas" US states [HI & AL], the US territories, and the Commonwealth of Puerto Rico seemingly out of place by transmitting from someplace else like Virginia or Massachusetts. There a several stations on now operating under CEPT and other reciprocal permits. I worked a few within the past few days and saw some this morning. Of course there will be many other CERT calls on the bands when the spring and summer vacation season begins, and when this year's DXpeditions and DXvacations get up and roaring. Looking forward to you all overcoming the compound call issue. 73 and Aloha from Virginia, Danny W4/AH6FX | | | Amateur Radio Ham Radio Maidenhead Grid Square Locator Map Amateur Radio Ham Radio Maidenhead Grid Locator in Google Maps | | | On Wednesday, January 9, 2019 8:36 AM, Bill Somerville wrote: On 09/01/2019 12:05, Bill Somerville wrote: > If you are in this situation then you must either send you gridsquare > post QSO in a free text message if you want to give your QSO partner a > chance to recognize you are not in HI, or use a compound callsign that > indicates your location like /W4. Hi again, a correction to the above. "If you are in this situation then you must either use a compound callsign
Re: [wsjt-devel] grid square & nonstandard callsign
Mike,I share your concern about your compound call sign. Just replied to Phil - F5??? about his compound call receive problem. [please see that response - too lazy to retype the details] We all share ... and many in the FT8 world share the programming issue of ver2 not including your grid when sending or receiving a compound call sign. Sooner or later anyone who works a station like us or a DXpedition using a compound call will experience some problems ... either logging issues - missing data ... wrong DXCC - upload issues, etc.I am guessing your logging issues relate to that shortfall and the mis-IDs ... and the grid missing. Aloha and a late Mele Kilikimake, Danny W4/AH6FX - Virginia On Monday, December 24, 2018 5:23 PM, "kh...@arrl.net" wrote: As a KH6 who operates most of the time in W1, I use a W1/ prefix in FT8, otherwise I show up (incorrectly) in the scrolling list of stations as “Hawaii”. Even though I specify my call as W1/KH6HZ, at least 20% of my contacts are not logged, the W1 gets dropped by the remote station, so I get tons of automated rejections when remote stations upload their logbooks and try to match kh6hz against w1/kh6hz. I will not confirm a contact w/o the w1 qualifier unless I’m at my home qth on Oahu. It seems 90%+ of the time I call CQ and have someone answer, the exchange gets logged correctly (I’ve never been able to figure out why it happens the other 10% of the time). If someone else calls CQ and I click on to respond, then my call isn’t prefixed with W1, and these exchanges are almost 90% of the time logged incorrectly. I wish FT8 would use my whole callsign in each portion of the exchange, rather than using the full call in parts if it. ___ 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] Behavior during QSO between 2 long calls
Phil, I share your concern. Your problem your QSO station using a compound call sign ... which is what I do both when using FT8 and SSB. On FT8 I use W4/AH6FX and when doing so, the WSJT-X software BY DESIGN does not transmit your grid - which perhaps is your problem. The current Quick Start Guide says the non-grid for those with nonstandard calls [[like your QSO stations ... like my W4/AH6FX ... like W1ABC/MM etc etc]] is built into version 2 because of "real estate" problems. All previous FT8 versions worked ok for me - altho had to overcome a few problems initially ... and I used WSJT-X both in Virginia and Hawaii. Ver2 has a 77 bit message "payload" limitation and nonstandard calls require more ... so there is no programming space for the grid. This causes HUGE PROBLEMS and is VERY frustrating to me because if I use W4/AH6FX or AH6FX/W4 my grid FM18 does not show. If I use AH6FX my FM18 grid shows but the DXCC entity shows as Hawaii. I can not win either way and some people send me nasty emails or nasty JT Alert text messages. So your WSJT-X version 2 auto sequencing is perhaps working ok and it is not forgetting to send you information - that is by design -- a faulty design in my opinion. So when it comes to logging FR/F1TCV, ZS/SP3CMX, E51DOM/MM, and others with compound calls ... you will have to manually look up their grids. You can still log them - just manually enter their grids - smile - and move on. FYI - for more info on this problem ... see a few of my forum emails. Go to the WSJT Developers Archive [ https://sourceforge.net/p/wsjt/mailman/wsjt-devel/?viewmonth=201812 ] and look up these emails dated 12/21/2018 at 16:57:14 or 12/23/2018 at 17:48:22 or 12/23/2018 at 18:30:06. Good luck Phil. Aloha from Virginia, Danny W4/AH6FX On Tuesday, January 8, 2019 9:56 AM, "t...@gmx.fr" wrote: Hi everyone, I use the call ZS1/F5FDV during my stay in the Western Cape. Last year during a my previous stay I had no problem using this call with stations having long calls like mine. I use now wsjt-x 2.0 on a MacBook, last year it was rev1.8 if I remember well. Recently I figured out that when I try to respond to a call like FR/F1TCV, ZS/SP3CMX, or E51DOM/MM, the auto sequencing is not possible and the report message, which is present in the genmsg window, is trunked when displayed in the Rxfrequency window.The QSO is therefore impossible, probably due to missing information in the response message sent. I attached 3 screen copies of QSOs and 1 copy of my logbook of last year with long call QSOs properly logged. Regards, PhilF5FDV ___ 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-devel Digest, Vol 58, Issue 306
Thanks Rick. Bill, G4WJS and Gary, AG0N, may have said that would not resolve the problem especially when I operate from the two different DXCC entities - USA and Hawaii. Still looking for a solution. Danny AH6FX/W4 On Sunday, December 23, 2018 2:33 PM, Rick wrote: Good afternoon all, A rather simplistic solution might be to have your location (by callsign) identified in the city.dat file as "CHECK THE GRID". This would work for anyone that is roving (whether in the local geographical area, or across the Pacific). 73, Rick NM3G > ... It was funny -- I recently worked someone on 160 who told me that he > "soiled his adult diaper when he heard my AH6 call sign."? That pretty well > sums up the call issue. > ___ 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] grid square & nonstandard callsign
Jim, Our calls are valid anywhere worldwide ... but I understand your point. Respectfully - a K9 or any standard CONUS amateur call is rather vanilla. Probably wisely so, the FCC does not require "call by call area" any longer as you well know. With our mobile society ... we all have heard a hog-podge of calls not matching actual locations. On the east coast, it seems like half of the New England ham population now lives in Florida ... and I am sure things are similar elsewhere. There is little need for most US "vanilla" stations to accurately ID exact call area or location - grid; maybe a different situation. The ARRL DXCC - USA is not a greatly sought after, rare DX entity. Hawaii, Alaska, Guam, Puerto Rico to an extent, etc are somewhat different. They may not be rare ... but they are sought after by some for various reasons. It was funny -- I recently worked someone on 160 who told me that he "soiled his adult diaper when he heard my AH6 call sign." That pretty well sums up the call issue. The situation is much different when working DX. For me, it is almost a "must" to accurately ID call and location ... which is easily done by using a non-standard compound call sign. You would be surprised at some of the hate FT8 anonymous comments I sometimes receive because of my call. It is easy of course to track down these folks by tracking the nasty response frequency back to a previous transmission when the station used a call sign. So respectfully Jim - no ... operating K9 from K6-land is not like operating AH6 from W4-land. In case you did not see my latest response to Bill and others ... here is an extract of my most recent email / posting related to that issue. But in closing -- checked out your QRZ page ... used to listen to WLW - a landmark station on AM ... and visited the R.L. Drake factory shortly after the tornado wiped out Xenia several years ago. My first really good SW receiver was the Drake SW-4 - fantastic. Now the extract. Best Regards, Danny W4/AH6FX On SSB and RTTY I always sign asAH6FX/W4 to control expectations. When using versions 1.8.* and 1.9.* I signW4/AH6FX on FT8 to, again, control expectations – people seem to recognize theW4/ first and recognize my locations. Butexpectations are sometimes hard to control as you can imagine. I do notwant anyone thinking they are working Hawaii when I am in northern Virginia. Although the FCC does not requireUS stations to sign /[slash] portable, etc … the FCC does not prohibit us from doing so. I use an “adapted”call sign protocol specified in CFR Part 97. Say I was a Canadianstation operating in Virginia … FCC says that station should sign as, forexample, VE1ABC/W4 Nokesville. I have never heard a foreignstation include the nearest town, as required by the FCC, but I certainlyhave heard them properly sign VE1ABC/W4 or whatever. That is the problemI often have, and stubborn me - I am adapting the FCC guidance to my situation. Although I am not a foreign station operating in the USA, tomany hams I am DXCC-Hawaii when in fact I am DXCC-USA … Virginia to be exact. My adaption of the /W4 or W4/ is my attempt to inform folks in am inW4-land. ... On Friday, December 21, 2018 2:07 PM, Jim Brown wrote: On 12/21/2018 8:44 AM, DX Jami via wsjt-devel wrote: > nonstandard call signs such as mine - W4/AH6FX ... or AH6FX/W4 Hi Danny, US callsigns, with no / identifiers, are valid anywhere in the US. While using one is legal, it is completely un-necessary. Your call is AH6FX anywhere in the US, and I view it as a nuisance. I live in California, and my call is K9YC anywhere in the US. The only time that you or I have a good reason to sign /anything would be if we were operating in a contest from a different DXCC entity than our prefix implied. 73, Jim K9YC ___ 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] grid square & nonstandard callsign
Roger - understand Gary. But what are the other viable work-arounds or fixes. After all, not a big issue with versions 1.8.* and 1.9.*? Danny W4/AH6FX On Friday, December 21, 2018 2:05 PM, Gary McDuffie wrote: > On Dec 21, 2018, at 09:44, DX Jami via wsjt-devel > wrote: > > can extra bits be obtained by omitting the worked station's call sign? This can really cause problems when trying to confirm that the report is from the station you think it is from. The idea is to make sure you don’t get a bogus report. This is especially important when working MSK144 as often there are several stations o the same frequency at the same time. Integrity of the exchange comes into question when you leave the “from” field out of the report. Gary - AG0N ___ wsjt-devel mailing list wsjt-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wsjt-devel
Re: [wsjt-devel] grid square & nonstandard callsign
Bill & Others, Thanks very much for yourresponses. Too bad AD1C’s CTY.DAT
fixwill not work since I go back and forth to Hawaii. Shucks – nothing is
simple these days. Please keep in mind I am not the only personwith this
problem. Just wait until theDXpedition and DX-vacation season picks up after
the holidays. The /W4 option as suggested is not good for manyreasons – the
ones in my previous email/forum posting ... and these below whichsum up the
overall issue. I am one of those guys who just cannot give up his Hawaiian call
sign which I have had for over 35 of my 40years as a ham. Many people believe
I amoperating from Hawaii when I call CQ because "Hawaii" shows up in theDXCC
column of the Band Activity screen, despite my FM18 set-up entry[pre-version 2
situation mostly]. Version 2 corrects some of this problembut the new version
2 presents new problems as defined in my initial message afew days ago –
W4/AH6FX compound call not showing grid ... or AH6FX indicatingHawaii to some
despite FM18 grid. This problem not in versions 1.8.* and 1.9.*.
If it was not for the ARRL DXCCentity list, everything would be ok; but Hawaii
and USA are separate DXCCentities ... unlike FCC's view of all call signs being
USA. [Having said that,an inordinate number of foreign hams think I am in
Hawaii regardless ... althosometimes I am.] I prefer to follow the “DXCC-ARRL
‘inferred” CFR Part 97guidance and sign my call W4/AH6FX [like a foreign
station ... or in this case,a non-USA DXCC entity station {{AH6FX}} operating
as a USA DXCC entity {{/W4}}]to illustrate operating from W4-land and not
Hawaii. With the new version 2, MANY people believe Iam in Hawaii because they
do not see my FM18 grid ... not that everybody looksfor that stuff. Also many
folks seem notto have the “Show DXCC entity and worked before ...” box checked
and do not seemy operating entity. On SSB and RTTY I always sign asAH6FX/W4 to
control expectations. When using versions 1.8.* and 1.9.* I signW4/AH6FX on
FT8 to, again, control expectations – people seem to recognize theW4/ first and
recognize my locations. Butexpectations are sometimes hard to control as you
can imagine. I do notwant anyone thinking they are working Hawaii when I am in
northern Virginia. Although the FCC does not requireUS stations to sign
/[slash] portable, etc … the FCC does not prohibit us from doing so. I use an
“adapted”call sign protocol specified in CFR Part 97. Say I was a
Canadianstation operating in Virginia … FCC says that station should sign as,
forexample, VE1ABC/W4 Nokesville. I have never heard a foreignstation include
the nearest town, as required by the FCC, but I certainlyhave heard them
properly sign VE1ABC/W4 or whatever. That is the problemI often have, and
stubborn me - I am adapting the FCC guidance to my situation. Although I am not
a foreign station operating in the USA, tomany hams I am DXCC-Hawaii when in
fact I am DXCC-USA … Virginia to be exact. My adaption of the /W4 or W4/ is my
attempt to inform folks in am inW4-land. It would be unwise for me to say
theW4/AH6FX - thing is perhaps a “receiving ham’s” problem of not
payingattention to detail. I believe I have a major roll in properly
IDingstation and location. So I occasionally send littlereminders like “Aloha
fm VA” from the TX5 “free play” line. Then I still get emails from stations
wanting me to QSL Hawaii, etc., etc. I will say I can change my callsign … but
I return to Hawaii several times each year. Thank goodness JT Alert helps sort
out theCONUS station locations, but not everyone uses JT Alert. Sooo … back to
my originalquestion - how can I show my compound call sign W4/AH6FX or AH6FX/W4
in FM18? Thanks and Season’s Greetings to Youand Yours, Danny
W4/AH6FX– Nokesville, Virginia, USA
On Friday, December 21, 2018 12:30 PM, Bill Somerville
wrote:
On 21/12/2018 16:57, Bill Somerville wrote:
> I am not fully up to date on FCC regulations but I believe you don't
> need to sign /W4 with your call.
Hi Danny,
having read your bio on QRZ.COM I do see that my suggestion may not be
such a good idea with Jim, AD1C's, CTY.DAT database as you do operate
from Hawaii occasionally, nevertheless sending a grid without the /W4
suffix may still be the best option if it is legal to do so.
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
[wsjt-devel] grid square & nonstandard callsign
Hello, Joe, you and I corresponded a few months ago about a similar nonstandard call sign problem - which was overcome. I recently encountered and researched my problem of grids not showing in the new WSJT-X ver 2 for nonstandard call signs such as mine - W4/AH6FX ... or AH6FX/W4. Got dangerous and read the November 26, 2018, Quick Start Guide and postings from this forum. I understand non-grid for those with nonstandard calls is built into ver 2 because of a real estate problem - the 77 bit message payload limitation. I am hoping you all will fix the issue in some way. I understand the bit allocation and limitation. Wondering if you all considered trade offs to allow non-standard calls to show grids. Are there any unnecessary QSO exchanges? For instance in TX3, can extra bits be obtained by omitting the worked station's call sign? Or maybe truncate the call to its prefix. After all, the QSO handshake has been made so why transmit the other station's call again [just for nonstandard calls]. Maybe there are other areas for trading bits. Also, perhaps including nonstandard call sign stations in the Advanced tab under Special Operating Activity. Perhaps a unique, but permanent, block can remain checked allowing "special" message formatting such as those for contests, field days, et al? Wonder if KH1/KH7Z would have a non-grid problem ... or does fox & hound resolve that issue? [perhaps it is important to allow the "nonstandard call" box to remain checked when also checking "Hound" or "ARRL Field Day," etc.] Lastly ... maybe something can be done on the receive side for real estate management purposes. Perhaps a database of nonstandard call types may be linked to the grid square pop up, log, and logging screens showing the grid. For instance, P5/K1ABC appears as grid PN30 in North Korea. [[granted - maybe the database generates a "center of mass" or capital city grid ... but the correct grid may be user-obtained from QRZ and substituted for the "placeholder grid."]] The shortfall here would be the grid only visible in the grid square pop up log and QSO log ... and not displayed in the standard message sequence portion of the Band Activity screen. But maybe that shortfall can be overcome too by making everything seamlessly normal for nonstandard call signs. Most of my P5 comments seem to relate to the receive station ... the sending P5/K1ABC station ideally includes the grid in his transmission sequence - but the receive side work around is intended if there is no fix for nonstandard calls generating grids. Just a few thoughts. I am sure I am not alone with this problem. My challenge on the east coast with a Hawaiian call is controlling expectation. Even with versions 1.8.* and 1.9.* working perfectly ... I still have hams emailing me for Hawaiian QSLs, or insisting I was in Hawaii. I am dealing with that. Also as version 2 is currently programmed, everyone must lookup my grid in QRZ or just slam in a fake grid just to save the QSO to a log. Thanks very much for your consideration. I am very appreciative of what you all have done for the ham radio community. Season's Greetings, Danny AH6FX/W4 ___ wsjt-devel mailing list wsjt-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wsjt-devel
