VARA-modem can already handle KISS connections. Location can be sent for example using Pinpoint APRS or other KISS-compatible software running in parallel with VarAC. Just my two (euro) cents regarding this is that location sending, receiving and having a mapping platform and all the bells and whistles to go with them, is better to have on a separate program which development concentrates on that, whilst VarAC can concentrate developing in conversational development. 73, Erik OH2LAK TF3EY

Whilst VarAC logs the SNR from the conversation (and by requesting it from the VARA-modem?), the main party to 'blame' here is the VARA-HF modem. It should log or indicate the SNR of each received transmission to create a reliable dataset to analyze the conditions over the whole connection period, but now it only displays it in the UI and logs the average SNR of a connection. I'd put in a feature request to optionally report SNR every time VARA-HF sends traffic to VarAC or other connected apps. 73, Erik OH2LAK TF3EY

As VarAC is just a client for the actual VARA-modem, VarAC cannot show what VARA does not send to it. As far as I am aware, VARA-modem does not show signalling or other packets in plain text, only the payload and that as well only it is being error free and completed from its parts. 73, Erik OH2LAK TF3EY

I studied a bit about the existing HF APRS allocations and many recommendations do exist but they all use the legacy AFSK 300bps mode and I don't know how much there is traffic on these globally. Australia seems to have quite active net at least based on their webpage and other online activity. Some seems to be on the "105Network" as well on 14105kHz LSB, and some other activity QRG's exist as well but it would be maybe good to establish globally approved and allocated VARA-modem based HF APRS -frequencies. 73, Erik OH2LAK TF3EY

Works as designed, thanks! I have had VarAC running overnight now for some time and oh what all there has been on the air :/ Need to stay up late some time to get some good DX stations :) 73, Erik OH2LAK TF3EY

Well done, thanks! Where's the Buy Me A Coffee button for you? 73, Erik OH2LAK TF3EY

The canned message contains exactly this; 73 & TU FER QSO! This has happened now two or three times and I think it is related to some exact timing that I select to send the canned message during the 'prompt & report' exchange as above. I don't consider this as a serious bug, more just letting you know as I captured this now. 73, Erik OH2LAK TF3EY

Irad is to tell the final 'truth' but my 2 cents to this is that I've understood the CQ frame is a standard VARA-modem feature and not a configurable sentence. Ie. that VarAC just tells the VARA-modem 'send out a CQ frame with this callsign' I would put the SOTA/POTA/FF information to the INFO field, the QTH field has most space for additional info. Not really seeing VARA as a contest mode as it has never been designed for such. BUT it does not mean a VARA contest cound not be held, it would just be rather slow compared to the expected contesting pace. A contest QSO would be similar to a SNRR or PING request, so about 30 seconds per QSO. 73, Erik OH2LAK TF3EY

I was able to 'reproduce' the issue today with fading conditions QSO with NC3Z. Our QSO got eventually disconnected due to a timeout and a I had a message in the 'Currently being sent' -window, where it remained even I tried to clear the queue with the button. Next, whenwhen G3SJX called me and the connection was established, he got this message from NC3Z QSO first out. I was not able to clear it from the window with clear queue -button (VarAC restart of course would have cleared it) 73, Erik OH2LAK TF3EY

I second this feature request. I currently use Irfanview to reduce images but it would be a great addition to have this feature built-in. In addition it would be good to include some logic that file transfer should only be possible on QSY frequencies. 73, Erik OH2LAK TF3EY

How about 'color coding' the Last heard? Conditions on HF change so CQ/beacon heard a hour+ ago is from some point irrelevant. Green= heard in last 30 minutes, yellow last two hours, black=older? Green is bad on white so maybe some other color but you get my idea for sure :) Or maybe a symbol of some sort 💚(20m) 12:05.00 - OH2LAK 💛(20m) 11:03.04 - TF3EY (20m) 09:42.04 - OH2LAK

Hi Irad. Answers below; 1) Band was selected after QSO. Auto logging also indicates an error message to the VarAC log, the snippet in the first post is actually from the auto logging I believe as it is immediately after the data has been received and before disconnect. 2) No. Seems to be so that both automatic and manual logging result in same error message 3) Band information was filled to the log row manually as it was not filled out automatically. I am using OmniRig (with apparent frequency control), switching frequency from VarAC dropdown list does change frequency on radio and turning radio VFO will change frequency on VarAC. Screenshot of VarAC & Omni-Rig settings here;

Thanks Irad for your explanation. Studying VARA protocol confirmed the fact that there is no real room for unproto mode and for HF it is truly so that conditions vary. I like though I'm not the only one who has given this a thought so lets keep the topic open :) 73 Erik OH2LAK TF3EY

i am using VaraHF v4.5.0 so it should not be the issue. VarAC also seems to get data from VARAHF as the SNR fields do get filled up in both right of the chat window and to the log details. Only thing which does not fill up automatically is the band information, which I have tried to fill up manually but it still complains about about the error. Below is a screenshot of a disconnected QSO but it still has the fields.