- Hi Rick, I do appreciate your situation, and the priority you give to supporting other software. When I tried V4, I did everything as you suggested andMessage 1 of 11 , Jun 19, 2013View SourceHi Rick,
I do appreciate your situation, and the priority you give to supporting other software.
When I tried V4, I did everything as you suggested and recorded the session using the Debug logs at both stations.
The stations' clocks had to be sychronised to within 1 second (or better) in order to see exactly what was happening
when comparing the logs. I then spent about two weeks examining the logs, but without the fine details of your software
design and specifications, it proved impossible to discover how the process got locked up, and even worse,
why there was no apparent recovery path except by session time out.
While being prepared to assist in any way I can, I am a system designer and not a computer programmer,
so have to leave it to you.
I do follow activities on the V4 Protocol reflector, and was pleased to see now that some users have had success
working with this mode. This led me to wonder how they implemented V4... possibly a different version is now available?
Vy 73 de Robin, 9H1ZZ
Date: Tue, 18 Jun 2013 20:17:28 -0400
Subject: Re: [V4Protocol] Re: [WINMOR] Test version 220.127.116.11 of WINMOR TNC posted on Yahoo and Winlink User FTP
Robin,I am the author but I have a lot on my plate. I just spent several months working on the WINMOR TNC (which I also authored) and the RMS Trimode server and just don’t have enough hours in the day to put in any more right now.There really shouldn’t be any timing bugs if the latency measurements at each end are within spec. But analyzing the timing takes the following.The V4TNC Debug logs must be enabled at each end...not just one end. A clean capture of the session needs to be made. And then I would need probably 3 –4 days of detailed analysis to get a handle on IF there is a problem and what it might be. Time Right now I don’t have. There is a lot of effort that has to go into develping a protocol and coding it. For example the WINMOR protocol probably has close to 3 man-years effort at this time. V4 maybe half of that (some of WINMOR is included in V4 ).I wish I had more time on this stuff but I don’t.73,
Rick Muething, KN6KBThanks for the hints, Finn.
My antennas are resonant (at transmit frequency) dipoles with baluns.
Antennas are situated 50 meters from the shack.
All audio cables have RF toroid suppressors.
So, I don't think I have RF interference.
The problem is once the ARQ session is established and after the first data exchange, both stations get locked in Rx mode (a disallowed state).
You cannot get data from the Tx buffer of either station then. No matter what code(s) for a data move you choose (I tried them all!).
After which you will get a session timeout (I also chose 180 seconds).
I (and my partners) are all using the same release of the software V4Chat 18.104.22.168 with SW TNC 22.214.171.124
I agree V4Chat should be a good mode (theoretically) but there must be a timing bug somewhere.
At least the problem is reproducible, so I am expecting the software author should be able to find it
with the session debug dumps I sent him last year.
73 Robin, 9H1ZZ
Date: Tue, 18 Jun 2013 21:06:56 +0000
Subject: [V4Protocol] Re: [WINMOR] Test version 126.96.36.199 of WINMOR TNC posted on Yahoo and Winlink User FTP
Robin. RFI is destructive. Balanced antenna, and less is more...
Else: Main error for timeouts is clients not moving what they type into tx-buffer, or messing too much within.
Let them hook for <CR or Double Space> as a means of moving data to transfer. The Double Space is genious for forcing text into TX buffer without changin line.
I removed the: Enable Full Duplex on FEC.
Did not understand that to work.
I use ARQ timeout (seconds) 180.
Do NOT use the first option Ctrl CR for moving letters into tx buffer.
It is a killer. The session is idling indefinitely when the operators does not know how and why it works.
It MAY be elegant since you can "post edit" back several lines since they are not ready for TX, but you waste link time.
I have had successful QSOs across the atlantic from Norway to Canada.
My gear: G5RV, IC706 original, SignaLink USB. Nothing special.
The MODE IS good. Is worth further polishing.
For pure broadcast MFSK16 may be better than V4Chat FEC, but you don't have any ARQ in MFSK16, and it would not be so "slick" or quick in turnovers.
When Skipping the CAT RIG control I can have RMS E/WINMOR, V4Chat and FLDIGI running in parallel. No portconflicts.
When getting a link or session I just shut down the other programs for freeing memory.
From Oslo to UK, Italy, Germany, Austria
From Oslo 60 deg north to Finmark top of Norway 70 deg north. And to Finland.
Locally 6 km in noisy 80m surroundings.
The last one was across Norway to Bergen to a retired Military HF guy having been through it all from RTTY to AMTOR, and Pactor 2 and 3.
He was amazed when I talked him into what to do and we did the qso.
Just like old Amtor, only without errors......well errors whenever he used the three norwegian letter. It always comes two completely other pr each letter.
So ALL Europeens have "trouble", or must write like old AMTOR / RTTY limited characters/letters.
UTF8 is the EU Standard, and is highly wished. Ascii is "stone age".
--- In mailto:V4Protocol%40yahoogroups.com, RICK WESTERFIELD <r_lwesterfield@...> wrote:
>with V4 has been completely different though I find it to be sensitive to RF in the shack. Once I put up a few more resonant dipole antennae, things got a lot more dependable. I can say the same about RMS Express - better antenna, better connections.
> My experience
> Rick KH2DF
> AFA6RW MARS
> Sent from Yahoo! Mail on Android