RTTY
[Top] [All Lists]

Re: [RTTY] Digital Operators Band Plan Committee - Current thoughts and

To: RTTY contest group <RTTY@contesting.com>
Subject: Re: [RTTY] Digital Operators Band Plan Committee - Current thoughts and status
From: Kok Chen <chen@mac.com>
Date: Sat, 05 Apr 2014 10:17:45 -0700
List-post: <rtty@contesting.com">mailto:rtty@contesting.com>
On Apr 5, 2014, at 9:03 AM, Peter Laws wrote:

> You're confusing two things here, software development and
> communications protocols.

I agree with Peter.

Personally, I prefer proper engineering documentation of the protocol than just 
be given open sourced code.

Open sourcing allows you to copy the code at will (up to the restrictions of 
the Copyright), but the salient properties of the protocol is often obscured.  
This makes it harder to improve on the demodulator, or produce cleaner 
transmissions.

As example, on one hand I can give you MMTTY code to implement RTTY.  On the 
other hand, I can define Amateur RTTY as "45.45 baud Frequency Shift Keying, 
with 170 Hz shift, and encoded with 5-bit ITA2 ("Baudot") start-stop code, 
using 1, 1.5 or 2 stop bits."    And include a supplement that defines options 
such as how USOS works.

It is much harder to improve demodulator for the first case than for the second 
case.

This is even more true for advanced modes.  If I were to give you a page of 
code that implements Viterbi decoding of a convolution code, the actual meaning 
is lost, compared to the case where I document the actual equations that 
defines the convolution code that is used.  You can then go off and implement 
it by using the Viterbi algorithm, or with a syndrome decoder, or whatever else 
you like.

Many of you own an ST-8000 and has its Technical manual.  Go look through the 
schematics and try to decide how the ST-8000 handles multi-path, and you see a 
bunch of XOR gates.  However, the engineering description makes it clear how 
the circuit corrects multi-path.  Source code is akin to schematics.

So, it depends on your goal.  If it is just to let someone else duplicate your 
code (e.g., to let someone else decode your Pactor 4 transmissions), then open 
sourced code is fine.  However, if you want to allow someone else to improve 
upon what you have done (e.g., to make Pactor 4 operate at a lower SNR), then I 
myself prefer good engineering (or Patent) documentation.

73
Chen, W7AY

_______________________________________________
RTTY mailing list
RTTY@contesting.com
http://lists.contesting.com/mailman/listinfo/rtty

<Prev in Thread] Current Thread [Next in Thread>