AW: [V4Protocol] Re: V4 CHAT, ALPHA Testing, and Ham Use
- Very well said (written)
I remember many starts of new soft (as i was always interested in new soft
and new modes) ... some of them died after some week ... some were just
sleepimg in the background but wer not developed further ...
Time will show how good v4 compares on air against other modes ...
Not other gui`s ... other mode!!! Just make some tests with the well known
sentence from the lazy dog and the fox
Send them a few times in different modes with the same power
Compare the results (faults?)
Would like to make some similar test with the soft ... but everytime when I
have some spare time for testing all others are in bed (I am in dl) ...
Maybe on the weekend?!?
- Yes. Agreed. Just cut and paste some standard bla bla dogs and foxes or cats....send them back and forth several times. Make statistics.
Find some noicy switch mode powers and impose noice, then reducing noice (move away the source of the noice, use filters on and off, make notes abt what you do, and send the same file later.
Compare what other modes are the better in those various "surroundings". This may, or may not turn the results upside down.
Anyway interesting to know.
Do it mid day, greytime, evening, night time.
Listen to the Ground wave if a close co station, listen to the NVIS and Multipath changings when gradually getting darker (f.ex 80m).
This is the closest way an on air client can "simulate" a real simulation. Kind of quasi estimating parameters using statistical methods.
Give the MODE/PROTOCOL a chance to mature.
Bells as whistles (read macros or whatever) may come later, maybe even in other sw just implementing this Virtual TNC.
73 de la7um Finn
--- In V4Protocol@yahoogroups.com, "Siegfried Jackstien" <siegfried.jackstien@...> wrote:
> Very well said (written)
> I remember many starts of new soft (as i was always interested in new soft
> and new modes) ... some of them died after some week ... some were just
> sleepimg in the background but wer not developed further ...
> Time will show how good v4 compares on air against other modes ...
> Not other gui`s ... other mode!!! Just make some tests with the well known
> sentence from the lazy dog and the fox
> Send them a few times in different modes with the same power
> Compare the results (faults?)
> Would like to make some similar test with the soft ... but everytime when I
> have some spare time for testing all others are in bed (I am in dl) ...
> Maybe on the weekend?!?
If people want keyboarding with ARQ using the WINMOR TNC, it has been available for quite some time in Ham Radio Integrator (HRI) software - available in the N3ZH_Software yahoo group's files section. I had already added Macros long ago and was considering some kind of automated file transfers, but the interest was inexplicably not there.
I saw this as very useful to replace Pactor-1 TNCs used regularly in some MARS groups. A high level Mars member in the northeast had some interest, but his members seemed to prefer their Pactor-1 TNCs. Amateur Radio has a plethora of digital modes, but very few which can assure error free transmission.
I was under the impression that Rick/WDT was going to "tweak" Winmor to be better for this purpose. But instead he is creating a brand new protocol. I do not understand this decision, but it is his decision. This is his area of expertise - not mine.
The smaller bandwidth of V4 is a major disappointment to me. And this also makes me wonder why it will be embraced by the Amateur or EMCOMM community.
I had been hoping for an increased bandwidth to at least 2400 hz for Winmor as that is the digital bandwidth one sees on most modern amateur radios. Olivia and MT63 have 2000 hz bandwidth options and these have been regularly used by MARS groups. Perhaps a 2400 hz Winmor mode will rival Pactor-3 throughput? This will increase file transfer speeds both in RMS Express and also in the HRI/Winmor keyboarding where one currently can cut/paste a text file - or perhaps someday automated file transfers.
MARS often has nets that switch between Voice, keyboarding, and guaranteed error-free ARQ file/message transfers.
I envisioned a different path here for Winmor/V4.
However, I do acknowledge the monumental achievement of developing and implementing the Winmor keyboarding mode. And the Amateur Radio and Emcomm world deeply appreciates Rick/WDT's efforts.
the other Howard/N3ZH/AAN3AC
--- In V4Protocol@yahoogroups.com, "W6IDS" <w6ids@...> wrote:
> This forum has become fairly quiet for an Alpha Testing activity.
> Does this mean that we've found all the peculiarities that need attention?
> During the ACTIVE testing, as such, has anyone given any thought at all
> as to usefulness of the protocol for daily comms as compared to the likes
> of RTTY, PSK flavors, BPSK flavors, etc?
> Has anyone given any thought as to promoting the protocol for testing
> above and beyond the small group of ALPHA testers we now have?
> If there's interest in using the protocol for real, any ideas as to how to
> handle it? Is it supposed to be isolated within the confines of a specific
> space or allowed to be used in the same manner as RTTY, OLIVIA,
> I know, I know.... I'm just asking, knowing full well we're still waiting
> for ARQ to be released. That said, who's best to make the decision
> as to how it should be used - experienced PacTOR operators or any
> of us? Is it to be channelized or allowed to be controlled by the VFO
> like RTTY, OLIVIA, PacTOR I and II, etc?
> I ask because I'm sure that WL2K won't want it per se, other than
> ARQ messaging as afforded by RMS Express, etc. OOPS, wait a
> minute. This won't be the same animal I think, so WL2K application
> doesn't fit here <GRIN>.
> So, any thoughts on this? Anyone? Anyone?
> Howard W6IDS
> Richmond, IN EM79NV
- Howard,Thanks for your acknowledgement.All along and thoroughly documented are the different goals of WINMOR and V4. If you haven’t yet you might want to read the 2010 DCC paper on the V4Protocol reflector.WINMOR: A Message oriented protocol (MOR = Message Over Radio) was specifically designed to be a low cost alternative for P1, P2 and P3 in message applications. It was designed to be adaptive to the channel and move message data as quickly as possible for the conditions and the selected bandwidth (500 or 1600 Hz). It was not designed or optimized as a keyboard chat mode and takes up unnecessary bandwidth for slow keyboard communications.V4 was designed from the beginning to be a KEYBOARD QSO protocol. It is “slicker” (less latency) than WINMOR, Takes < half the space and will still deliver 50 WPM typing speed. It will fit into band segments (future?) where only 200 Hz modes are permitted. It is not designed for Message forwarding and would not (even in ARQ mode) be as effective as WINMOR in that. V4 is the result of requests during the WINMOR testing for a mode that was optimized for keyboarding.One of the values of sound card modes is they can easily be adapted or optimized for specific purposes. (Messages, Keyboarding, Low Power beaconing, VHF, etc) No one protocol is likely to be best for all modes and trying to include every possible application as an appendage to the protocol would likely end up with the proverbial Camel (Horse designed by committee!). I chose to optimize V4 with those modulation modes and coding schemes of WINMOR that were most effective for keyboard speeds and adopted them to use minimal bandwidth. The Virtual TNC implementation of both WINMOR and V4 would easily allow an application (client or server) to select and run the desired mode with a minimum of difficulty....just like selecting between two hardware TNCs optimized for different purposes.It certainly is possible to increase the bandwidth of WINMOR BUT you cannot always equate increased bandwidth with increased net throughput. Spreading more carriers over the spectrum reduces the power while increasing the crosstalk in each carrier (assuming a constant transmitter capability) and reduced power degrades the performance of all modes. Increasing baud rate (up to the 300 baud limit) improves throughput at the expense of bandwidth but is more susceptible to multipath propagation. Some modes like MT63 use massive redundancy which result in good FEC performance (broadcasts) but score poor on “RF footprint” (bits/Sec/Hz of Bw) and latency. One of the challenges in approaching Pactor 3 performance is not only the very powerful built in DSP (an order of magnitude or so more than most PCs) and sophisticated algorithms but also the precision hardware (e.g. Sample rate oscillator with 10 ppm accuracy) that far out strips virtually all PC sound cards. Whether you like SCS or not there is little denying it is a well engineered box with well optimized DSP firmware and it is very effective.One thing I think most sound card mode developers would all agree on: It is the very action of designing, testing, and evaluating new modes from which we learn what works, what doesn’t and how to build something better. So even if V4 (only 6 weeks into ALPHA testing) turns out not to be practical or better for some functions it will be a learning tool for all those that wish to participate in its development and testing. Remember in the early 1900’s there were some that wanted to close the Patent Office because “everything had been invented”. I’m not from that camp.73,Rick Muething, KN6KB