Correct.

You probably nailed it. I didn't think about the other station manually making the QSY early.

You can't transmit if the frequency is busy.

Bands other than 20 meters during the day and 40 meters at night might be an option in some locations, but not here. When the calling frequency on 20 or 40 is clogged, my first reaction is to peek at other bands. With over 500 VarAC QSOs logged since July when I started, one each was on 12, 17, and 60 meters with all three being skeds. I agree completely that altering the system with multiple calling frequencies is not viable. My comment was more of a vent than expectation of a solution.

Roland, Thanks for this procedure which also works for me. I was not sure how to retain the correct mode for use by QRZ and change the mode for LOTW. Since Dynamic/VARA HF is an official ADIF mode, I wonder why LOTW doesn't support it? Larry

I was able to create a fairly stable setup with the resamplers on (Force boxes unticked). However, it takes a few minutes for them to initially stabilize or after any configuration change. I also had a few situations where the resamplers would destabilize in the middle of a VarAC QSO requiring they be turned off in order to continue. I use a test setup to connect my ANAN radios to my 7300 using attenuators that enable configuring the receive SNRs at any level. While there may be speech audio benefits to running the resamplers, using my test setup, I found no difference in packet error rate or maximum bit transfer rates while transferring large files. I also saw no difference using different types of Windows sound drivers from the older MME to newer ASIO. Also no difference with different types of virtual audio cables. With regard to SSB speech, I use the integrated audio codec in my ANAN radios to connect headphones and a mic to the jacks on the front. Probably not the best for the audiophile but communications audio is much less demanding than broadcast FM that some seem to want to achieve. I attribute the lack of difference in VARA performance to the power of the VARA modem using its forward error correction and ARQ to deal with minor audio glitches. When all other things are equal, I believe in keeping it simple. I run with the resamplers turned off. When the resamplers are off, the only VAC parameter sill in effect is the Buffer Size which does impact latency a little but not enough that VARA cares. I set mine to 256.

When Jose made the change for the timing issue, he didn't go to a new version number. Take a look at the release notes which have been updated. You can "install" the new version to a different folder on your PC and then copy just VARA.exe from there to your previous VARA folder. Regarding the ANAN VAC, take a look at the recent ANAN forum exchanges with WU20. Every situation is unique so what works for each combination of radio and PC will be different. My experiments show no VARA bit rate or packet error rate difference between VAC resampler on or off. The VARA modem with forward error correction and ARQ will handle small audio imperfections caused by turning off the resampler (ticking the Force boxes). This might not apply to other digital modes or to voice. I like to use metaphors to help explain complex concepts and I think I have one that fits this situation. There was an "I Love Lucy" episode where Lucy and Ethel were working in a pie factory. Their job was to take pies off the conveyor belt and put them in boxes. As the conveyor belt sped up, comedy ensued. Modify the Lucy scenario to include two conveyor belts separated by about 6 feet. Pies come in on one belt evenly spaced and must go out on the other belt also evenly spaced. Since the two belts are running at slightly different speeds, there is a table where pies can be placed to even out the transfers.

How about this? When you post a new line to the Last Heard Log, also send that same text via UDP to 127.0.0.1. I will create my own alert threshold and also use the same information to search for specific DX prefixes or callsigns of interest. I can then send a notification to my watch.

Worse, I have had a few actual QSOs that were just another FT-8 style exchange - CONNECTED, INFO, 73. The beauty of VarAC is its ability to provide error-free conversations with poor conditions, weak signals, noise, and QSB. Although increasing interest and activity for VarAC is great, those operators wanting impersonal computer-to-computer exchanges should stick with FT-8.

After thinking about this for a bit and reading your reply explaining your mechanism, at this early stage in this new mode, more activity, even if just beacons, is good. Like in consumer marketing, a shortage may create higher perceived value and stimulate greater demand.

Thanks.

An .ini file name unique to each setup can be added to the launch command in a Windows shortcut. Same result as your suggestion but easier to implement and execute.

Thanks for your reply and explanation. I wasn't sure what info the VARA API exposes. Shrinking the locked VARA window is a good idea that I didn't think of. I will try that.

Have you had a chance to look at the files I sent? Are you seeing similar results?

New stations not in your log at all or new stations to the band are visually identified differently. The CQ tone is also different. One bong for old and two tone bong for new.

I figured using two VarAC.ini files would be a good approach. You explained how to implement that in an easy way. Thanks.

I use two radios regularly used for digital: Apache Labs ANAN 7000DLE and ANAN 100. Both have Protocol 1 installed and I have seen issues with both PowerSDR and Thetis. I was only having problems connecting to Flex radios. After reducing the size of the audio buffer which probably adds both receive and transmit audio latency, I have not seen the problem as often but still have a few disconnects from Flex radios. I use an IC-7300 for portable digital and have never seen this issue with the 7300.

Since doing this to the 7300 CAT config, I haven't had a problem: * CI-V address - 94h * CI-V Transceive - Off * CI-V USB Port - Unlink from REMOTE * CI-V USB Baud Rate - 19,200. I use 115,200, but use 19,200 for starters as that is what flrig defaults to. Response will be a bit quicker with higher rates, but it will do well at 19,200 also. * CI-V USB Echo Back – On which is from this: http://www.w1hkj.com/flrig-help/ic7300_how_to_page.html

It happens randomly. I don't remember seeing at a first connection. I do not have limited PC resources. CPU usage is generally about 10 to 15%. I do have a work around. Pressing the TRANSMIT button on the upper left of the 7300 will terminate the transmit. I am running 19,200 baud serial connection. Would slower or faster make difference?

Three sample - no spaces and lower case that works, upper case that doesn't work, and with spaces that doesn't work - were sent. Did you receive them?