HOW MAKING WINMOR 1600hz BW MORE ROBUST AND SPEEDY?
Some interesting postings again in Winmor forum last weeks abt bandwith versus throughput pointing in different directions. These contradictions seems partly valid.

First: Diving into some details of the protocol and gearshift algorithms I am getting more and more impressed about the achievements of the Rick/Vic WINMOR baby. And also hoping for some Linux platform in the future.

Do never forget that their goal creating a <poor mans pactor 2,3> forced them fighting the given restrictions using pc and a soundcard. Mediocre HW, by magnitude, compaired to SCS state of the art HW. You can like it or not like it.
 
Nevertheless Winmor is increasing the potential number of clients by first playing for fun, then learning how to operate, then beeing able to serve the community with Emcomm.

Their result is already amazing, and will probably get even better as Rick gets time further elaboratng the protocol.
I firmly believe Rick is working on some gear shift changes, according to his posting in the Yahoo N3ZH_software group. Somewhere I have seen some thoughts.
He has also somewhere mentioned plan for a reset of timer when a 1600hz session for robustnes is reverting to 500hz before timing out.

In the end Winmor can even maybe create new customers for the state of the art SCS boxes as new hams/clients get the opportunity to get accustomed to the Winlink system. Thus beeing a Win Win situation.

MY OBSERVATIONS: (Same as used in the memory and scanning discussion).
Those observations have created some suggestions shown below.

A big number of link tests (some hundreds of connects, many deliberately gradually broken, others left as optimal as possible while real time VNC checking link performance on the 80m server 6 km ground wave distance from me on different times of day also revealed some <strange> throughput results.

I some times repeatedly observed the same file (114kb!!) taking about double time downloading using 1600hz BW session compaired to concentrating the energy running the whole session in 500hz mode. Others seem to seeing elements of this.

Think about it: That means actually more than 6 times the necessary footprint!
A broader BW (as Rick has stated several times) may offer, but does not necessarily give, higher throughput. Especially with simple or mediocre HW compared to the SCS boxes.

But those <strange> observations were valid for me only under some extreme special local noice/disturbance circumstances under the old gearshift algorithm.
It is not simulations, only observations, but such noice could in the field be imposed upon an emcomm client without him beeing able to avoid it. Generators, etc. When locked to a fixed frequency, actions shown below is needed.

Under normal use one could off course get any results in between.

Observation time: Mid day. Noon + 1 (but real sun time Oslo noon + 1/2 hour).
Server LA3F-5 shifts from 500hz to 1600hz session. Tests before and after.

I managed by TV and Switch mode powers to create <about> the same level and type of local noice for both sessions. Brrrrrrrrrrrrrrrr.

Local noice flickering between S9 and +10db. (Hopeless reading this more exact).
Impossible to read S meter from the server signal because of the noice.
But WITH a 350hz!! (yes, too narrow) filter the server could be seen to be S9.
With the same filter the noice was reduced to S 7 and not that <edgy>(seen when server did not tx).
Rig IC 706. What those figures really sais can probably be discussed I think.Hi.
SignaLink USB.

Around this level WITHOUT filter the file download sometimes needed only half the time on 500hz 2 car transmission compaired to 1600hz 8 car transmission. = 6 times footprint using the higher BW. (Upload much quicker since server has better listening conds and all acks are in 2 carr mode).

I guess that the concentration of all energy into the 2 carriers compaired to spreading out on 8 carr made the difference when drowning in this local noice.

I could observe 2carr running 16psk and staying there during 500hz download.
Some 2.3 kb/min in the end on average.
(Since the + 10 db readout is VERY inacurate the signal levels could vary a lot without me seeing or hearing it).

But with the 8 carr it was some 8car 4fsk trying to gear 8car 4psk finding out that % of ack too low and back again. Gearshift down always give some overhead.
Some 1.1 kb/min in the end on average.

I observed situations where the gear shift after 3 or 4 times stopped trying to change gear. This became apparent during the 114 kb file when I after abt 30 or 40 minutes stopped destructive manipulations and left the radio running optimum conditions.
This changing of conds to a better state was never tried out or utilized by Winmor during the next hour until successfully ending in a slower than necessary speed.

Other times of day and without xyl at home = MY controll = NO TV!! I sometimes managed to get some 3-4 kb/min using 1600hz BW even on this 80m NVIS band.
This is observations only. What I <measure> in reality is the hidden variabels, totally random conds, multipath or not and noice. But real life througput given those exogene variables is interesting enough for me.

Since the ACKS are PR CARRIER the 1600hz 8carr mode is kinda more resistant to random moving noice. You easily get 2-3-4-5 carriers acknowledged spread all over. Or none because of to week a signal.

I remember some postings by Marc that in some cases his 20m clients had to wait until he shifted from 1600hz BW to 500hz BW for them to make a successful session.

This corresponds with my observations.
From the very beginning we are informed that 1600hz BW needs 6db better S/N.

The link could break down in a 8carr mode without trying a 2carr mode first as a last resort. A little depending upon where in the negotiations the noice came, or me in a 1600hz session for test did DETUNE the IF SHIFT or imposed the 350hz filter. Which i KNOW do handle the 6km distance into 2car 4psk but not higher.


BOTTOM LINE:
Rick is well informed about my testings so I guess it is just a matter of time before some enhancements are tried out.

Some ways to start making the protocoll a bit more robust and efficient:

1: Always start the link and even the dowload in 2 carr mode like Starting in P1 before going to P3.

2: Never stop checking for a higher or lower gear.

3: Never let it time out in a 8 carr mode without trying back into the 2carr mode first.

A MORE DIFFICULT APPROACH FOR LATER TESTING:
We are now in reality talking about a zig zag between 500hz and 1600hz to make the 1600hz mode more robust, and no more absolutely need a 6db stronger signal than a 500hz mode to <work>.

But when thinking KISS: Server starts in 2carr mode and move to 8carr.
When 8carr is not successful and reverting to 2carr mode: What level of 2carr should then be required before next time again try go into 8carr mode?
A higher 2carr level or always from 2carr 4psk to 8carr 4 fsk?
When to make 8carr try again?

Easiest alternative is aways try entering 8carr 4fsk when 2carr 4 psk % acks is sufficient.
Then possibly further up in 8carr speeds.
If failure in 8carr 4fsk, then back to 2car 4psk and so on.

This algorithm is simple, but does never try out 2car 8psk or 2car 16psk.

This might nevertheless be the smartest first revision of WINMOR TNC, and good enough for normal file sizes and conditions.

Other alternatives coming to my mind beeing in a default 1600hz session:
Stick a litle more to 2 carr mode.
When wanting to gear up in 2 carr mode from 2carr 4psk to 2carr 8psk,
then first check 8car 4fsk. IF failure , then back to 2 car 8psk (not 2car 4psk).

When 2car 8psk % of ack is sufficient for 2carr 16psk, then again try 8carr 4fsk.
If success then go on in 8carr mode. If failure, then revert to 2car 16psk and give that a shot.

If 2carr % of acks 16psk is sufficient, off course again over to 8carr 4fsk.
If failure, then back to highest 2 carr level again 2carr 16psk.
If a new failure, then down to 2carr 8psk.
If wanting to gear up again, always check 8car 4fsk first. Etc etc...
OR !! (When Santa Claus gives plenty of spare time):
TRY MY NEW SUGGESTION, a new 4carr mode.
Food for Rick and Vic.

The modes do overlap. 2Car 16psk = 8car 4psk.
But 8car 4 psk has for me often proven to fail when 2car 16psk do succeed.
Again depending of type of machine gun blanket type of noie, or normal random type moving around.

MY CONCLUSION:
Let the manned client at any time during a session be allowed to manually override the default BW 1600hz algorithm for the session reducing it to 500hz.
Thus forcing the session into a pure 500hz session not wasting any time on all on the tries for 8carr modes. An experienced operater is important here.
Needing a new button in RMS Express.

And being able to undo it again if conds or noice get better during the session.
This manipulations is valuable if operator is experienced and it is a loooong file and he knows from earlier experience what works best.

An option for manual interference could be a repair since mediocre HW and poor mans pactor 2,3. No free lunch. Cheap cars does not have automatic gearhifting.

If operator is not experienced, or lazy, he can just leave it alone, go watch television and the link due to Rick will still survive at some speed costs.

Remember. All gear shifts is creating some extra overhead time. So unnecessary gearshifts ideally should be avoided.

==============================
What about also a 4carr step down or up mode for robustness in 1600hz BW?
This may offer some enhancement potential with a certain probability of sucess.
DOWNSIDE: Some challenge, but more swamping for Rick. Easy for me to suggest :-)
==============================

73 de la7um Finn

For a period it was possible sending from one RMS Express to another getting the EU umlauts correct, not now. They seem stripped to  question mark ?

In subject field some problems has been seen from time to time.

In the text body 8bit "ascii" has earlier been allowed from webmails  using UTF-8. Even if looking bad in RMS Expres the bits where there and became readable again when message was forwarded to another web mail.

Any plan for enabling UTF-8 in and out of RMS Express?

I use a FT9000C on CFARS/MARS. Since there is no setting in RMS Express for Ft-9000, i have to use Airmail (it supports FT9k using a modified Kenwood instruction).  But Airmail doesnt yet support P4 and all my area EMOs use RMS so I'm in a  Catch-22. 

My request is for RMS Express to support FT9000 radio please, so I can use it with my DR78700. Thank you.   VE7OVY

First off, thanks for the beta support of Robust Packet in RMS Express. The DSP Tracker's SABM connect request timing is tied to the initial Frack value used. The default being used currently (as of RMS Exp v1.1.3.0) needs to be shortened to where the connect requests happen faster. This will make hitting a "scanning" site much easier.  A user adjustable value would probably be best, but if it has to be hard coded I would suggest a F value of around 250. At first glance this may seem too short for HF, but remember the RP protocol is adaptive and that value is only used as a starting point.  Thanks for considering this for the RP users.   WA4ZKO

Time (and Windows OS's) march on - New versions of Winlink client and sysop software will require .Net 3.5. With this we leave Windows 2000 (and older OS's) behind.

Supporting older operating systems with our limited development staff and plans for future software versions just isn't feasible.

The link to download RMS Packet shows that it will access 2.1.03.msi setup. According to the Yahoo group, the current and soon to be manditory version is 2.1.0.4

I'd love to have this done automatically, but security at my govt. sites won't allow the anomyous ftp function.

Installed RMS Express 1.1.6.0.
Experienced that RMS WINMOR stations closer than 4000KM does not show up.
Local RMS Packet does not show up.
New Channel update did not help.
RMS Pactor seems ok.
Bug in client or in CMS?

I think there should be the possibility to add a prefix to the Callsign for identification of the station in a foreign country. (ID string) for example DL/OE9FWV/P

We have the suffix, but for legal operation abroad the prefix is mandatory.