I was just giving V6.0.8 a try out - looks quite impressive... One bugette though - I had beaconing turned on and decided to put out a CQ. The slot selection dialogue box opened, I selected a potential slot and hit the "sniff" button to find out if it was clear - a second later, the beacon timer expired and my radio put out a beacon - on the slot that I was sniffing!. It probably should inhibit beacon transmission while the dialog box is open - or switch back to the calling slot for the transmission! Martin (G8FXC)

I'm enjoying VarAC - the functionality is very good and it works well with reasonably strong signals. But the underlying VARA protocol seems to get in the way as the signals drop. I'm an old-time PSK31 and RTTY user - zero error detection and correction. I could manage a QSO under some pretty terrible conditions - it's surprising how much corruption to the data stream you can accept and still work out what the guy at the other end means. I'm finding that many of my VarAC QSOs fail because the signal drops down into the noise floor and VARA goes into a sequence of repeated NACs and retransmissions. If I look at the monitor window, I can see that most of the text is getting through but it's failing the data integrity checks. I would settle for some garbled text rather than a dropped connection! Does the client application - VarAC in this case - have any control over the low level protocol? Are you able to do anything to accept the errors and let the QSO continue? Martin

Not so much a QSO request, but an appeal for information and ideas... I've been using VarAC on HF for a couple of weeks and it looks very interesting. Now beginning to wonder about VHF - is there any 2m activity around the south east of Britain (or near continent)? Martin (G8FXC)