In an operations setting, such as an EOC, where two operators each have an instance of VarAC running, however, are both using the same callsign, the operator that did not originate the broadcast doesn't receive it. I tested this in a two site test, using the same callsign at both, and the receiving station didn't display the broadcast, though VARA FM logged the reception. For my two site test, I used AL0R at both sites. Since this isn't an ARQ session, I'd expect any broadcast received to be displayed if addressed to ALL. I somewhat assume this is done to prevent the broadcast window from repeating broadcasts that transit digis?

Stu, I thought I'd add a comment on "tactical" calls. VARA itself, not VarAC, doesn't have an alias function like packet, thus there is no way to identify the transmission with a legitimate callsign if you use a tactical call. It's a rough issue and it's been talked about with Jose (VARA author) several times. Thus using a tactical call means that there is no FCC compliant identification. Matt AL0R

FWIW, regarding frequency change, VARA FM does not have frequency control, regardless of the radio make/model. The freq control is via VarAC/CAT and works fine.

FWIW, USB can be set to 3200, but USB-D is limited to 3000 (on a 991A). Using the narrow syntax you provided, my radio changed to a 150Hz width. Note that SH doesn't show support for USB-D and 03 is the 150Hz parameter for CW. It appears there may be a bug in the CAT for MD0C, as all values apply the CW settings (to include wide rather than narrow). Thus you could compromise by setting NA00;SH011; for an 800hz filter.

I'd love to hear about "too many variables" when using WL P2P. Other than choosing peer to peer in the session type and message, what other variables are there? It uses the same radio and same vara.

I've asked once for a squelch type function and been denied. Having the ability to set thresholds for responses would be one way to avoid level 1 throughputs on the CF.

Right. A long time ago... lol.... really, it can be "so busy" now, that having an 18bps qso isn't something I look forward to. Being able to set a higher threshold means you don't need to guess as much on who you can hold a higher rate qso with. Likewise, I hear a lot of folks say they can hear but not be heard, setting a higher threshold, if wanted, would level the field in some cases. I for one, often see cq's in the 20s, but I can rarely contact them.

varahf 4.6.1

Yes and yes. When I use Winlink with an RMS on 7105 (which I avoid now that VaraC is on this frequency, VARA just pops a message and asks if I still want to transmit, but doesn't prohibit me from doing so.) I've also noted rtty and psk31 will set a channel busy for VARA as well.

I attempted to clear it, but as you noted above, once it is in the buffer we can't do anything. As soon as he reconnected, it moved from queue to buffer. I'd prefer that if disconnected, the queue be purged. Else that means an ever growing amount of redundant messages build up. Given the "expected behavior" I'll now have to kill an incoming request to clean up the messages, then reinitiate.

How about this? Today, a station connected to me but the link was marginal, thus my info string was in the buffer. He disconnected and immediately reconnected, adding a second info string, he then disconnected again, and reconnected. At this point, I have 3 info strings in the buffer. The datastream shows he disconnected each time, thus I'd think the buffer should clear, but it didn't. Bug? Or expected?

It looks like my post happened just a few hours before yours :-) Indeed!

Yes, and I've done that already... so then the request would be, can we highlight the calling freq.... otherwise the drop down gets BIG....

I'm looking at it from the perspective of the coming file transfer feature... and use on other than hf.

Since we are using VARA... will 2750 be supported?

ok, I've just seen some wide bw stuff while on 500. Just used to things like FreeDV where you choose a mode, but it will decode all the modes, so you can hear a CQ regardless of mode.