Date
1 - 13 of 13
Possible for Fldigi to decode VARA HF QSOs?
|
David Ranch, KI6ZHD
Hey Dave and fellow Fldigi fans:
I've been playing around with HF today and listening to VARA HF on 14.105 USB. I'm curious if Fldigi could maybe decode what VARA HF for X86 Windows only stations (excluding the use of WINE) is sending. It seems like VARA HF it does: 1. Originator sends an initial packet request in an AFSK mode - maybe a form of MFSK - I wonder if FLdigi could decode this and display similar information to say what Fldigi's RSID does today - Responder sends an ACK in an AFSK mode 2. Originator sends an speed increase proposal packet request in an AFSK mode - maybe a form of MFSK - I wonder if FLdigi could decode this and display similar information to say what Fldigi's RSID does today - Responder sends an ACK in an AFSK mode 3. The Originator sends some test data in the next faster mode - seems like MFSK to me - I wonder if FLdigi could decode this and display similar information to say what Fldigi's RSID does today - Responder sends an ACK in an AFSK mode probably with some detail about bit error rates 4. Step #4 does this several times until I think it hits a max speed up cycle or max bit error rate and then initiates the main payload communication in what seems to be either in MFSK, ODFM, or QAM modes 5. At this point, I imagine that most VARA HF traffic (Winlink 2k, etc) then uses LZHUF compression on the payload so that wouldn't be decoded. I know it's possible as the Pat client supports it but maybe this is beyond say "phase 1" of this effort. Thoughts? Maybe there are other multi-platform programs (I'm a Linux user) out there that can do this today? --David KI6ZHD |
|
|
|
Greg Troxel, N1DAM
"David Ranch, KI6ZHD" <linuxham-fld@...> writes:
I've been playing around with HF today and listening to VARA HF onNot really responsive to your question, but comments that I hope are eventually constructive towards the goal of Free Software interoperatability. The lack of a pointer to a VARA on-air format specification is notable. LoRa, like VARA, does not have a published on-air format specification, as far as I can tell. (This is a separate issue from whether one needs a patent license to transmit, or needs a patent license to receive.) <us-centric> I recently tried read to read Part 97 carefully because of, I think, people talking about APRS over LoRa. As I read the rules, one may use an "unspecified digitial code" but if so an ID must be sent in CW etc. or a specified code. With a specified code, the ID can be contained within it. Therefore I wonder if - part of the code is specified, and if fldigi or something else can decode the ID, or - if this use is noncompliant, or if I have read the rules incorrectly. </us-centric> I note that LoRa has been reverse engineered, resulting in more or less a protocol specification: https://vdocuments.site/complete-reverse-engineering-of-lora-phy-2020-2-19-chapter-1-introduction-ais.html https://www.tlab.gr/reverse-engineering-lora-phy/ Some other questions: - Have I failed to find a published protocol specification (one which is fully sufficient to implement a receiver)? - Do people who use VARA transmit an ID in CW? - Is the use of VARA is acceptable in other jursidictions? Do other countries have similar requirements for ID when using non-published modes? 73 de n1dam |
|
|
|
Kelly, K7HMI
Here is the “published code”, I think this is how they justified the legality in USA. Don’t see a lot of ROS modem on air either.
https://github.com/pengowray/VaraHuffmanNet kelly |
|
|
|
Brian Morrison ,G8SEZ
On Sat, 3 Dec 2022 13:17:59 -0800
"David Ranch, KI6ZHD" <linuxham-fld@...> wrote: Hey Dave and fellow Fldigi fans:It seems that VARA HF requires a licence to run the code, there is apparently no open source implementation and so it has to run in WINE on Linux. These are not good looks for Free Software use at least from my position. -- Brian G8SEZ |
|
|
|
Agreed re. VARA.
toggle quoted message
Show quoted text
It's one of several poor strategic choices made - relative to the Winlink system. Proprietary-anything (non open source) is contrary to the mission. Single-platform (e.g. dependency on a MS version of windows) is contrary to the mission. IMHO, kd4e On 12/4/22 1:05 PM, Brian Morrison ,G8SEZ wrote:
On Sat, 3 Dec 2022 13:17:59 -0800 |
|
|
|
Kelly, K7HMI
I share these concerns, I also know it’s performance is amazing. very problematic. Ha!
|
|
|
|
Sebastian DO2SGF
Hey David,
that's not possible. VARA is a proprietary closed-source modem for which you will find, if at all, limited documentation, about how you attach Winlink Express to it, that it's way faster than 1200 Baud AFSK Packet Radio and how you buy a license. Its license is restrictive, forbidding any attempt on trying to find out how it works by e.g. reverse engineering, from how I understood that license. It's written in Visual BASIC for which no working compiler exists on anything else than Windows, to my knowledge. Maybe the open source .NET SDK from Github has one? The source code for VARA "will be released in the future". (As if...) Aside from ARDOP, for which I assume ARSFI a.k.a. Winlink will soon drop support, AX.25 Packet Radio is the only open mode supported by Winlink. (Except TCP/IP via Telnet) 73 from Germany, Sebastian |
|
|
|
Sebastian DO2SGF
>It would be nice to see open source decoders at a minimum a requirement for any ruling. It’s incredibly frustrating when a signal can’t be ID properly.
https://www.winlink.org/content/fcc_petition_rm_11831_threatens_amateur_digital_operations_winlink https://www.winlink.org/content/open_letter_all_digital_mode_stakeholders So much about Winlink supporting open source. |
|
|
|
Kelly, K7HMI
Very interesting I missed that post thanks for sharing. The compression is fine as long as it’s reversible IMO, same issues as Vara to a degree and thankfully packet is not commercially attractive so we have it till Linux destroys it because “no one uses it”
it all performs very well so it’s frustrating I do hope the issues are ironed out and open source code is released to the community that enables the experimentation for the product to exist in the first place!
|
|
|
|
k9ao@...
I can't see the necessity for open source being mandatory for any FCC mode acceptance.
As long as there is no encryption and are no attempts to obfuscate the message, the format is decodable. VARA isn't built to encrypt traffic. There is a monitor built into it, so you can look at the traffic. Yes, the higher speed options require a license (full disclosure here - I am a VARA HF/FM license holder) but as long as it is available it's not obscuring the message traffic. I am fine with someone doing some great work and getting a small pittance paid to fund it. Not everything has to be free. It's great if it is, but there is no requirement that it is. The family of VARA applications is growing and worth looking at in my opinion. I have a VARA license but all of the HF stuff is at low speed anyway, so it's no advantage really having it. I knew that going in but I was happy to fund the development work. Rick Kunath, K9AO |
|
|
|
Greg Troxel, N1DAM
"k9ao via groups.io" <k9ao@...> writes:
I can't see the necessity for open source being mandatory for any FCC mode acceptance.The point is not an open source implementation, it is about an open protocol spec that anyone can read and implement. |
|
|
|
Kelly, K7HMI
Well put Greg! |
|
|
|
Brian Morrison ,G8SEZ
On Mon, 05 Dec 2022 10:00:41 -0500
"Greg Troxel, N1DAM" <gdt@...> wrote: "k9ao via groups.io" <k9ao@...> writes:Yes, exactly this.I can't see the necessity for open source being mandatory for anyThe point is not an open source implementation, it is about an open -- Brian G8SEZ |
|
|