Love WINMOR, would like to see all PACTOR stations doing WINMOR as well

This is a good idea.
As a compromise making it possible soon I turn the question upside down.

It may be divided into some sections:

1: Existing pactor only stations may go on as they already do if they wish.
They already make redundancy or "escape routes" to the server seen form the client point of vieuw.

2: New Winmor servers may/SHOULD! be allowed to scan slowly max 3 frequencies at a band at any one time of day 10 sec Dwell time. This will enourmuosly increase the redundancy seen from the client point of vieuw where he in the field may need finding a quieter frequency away form generator or other uncotrolled noice on the same band. The Busy-detect will have time for settling.
 
Then stations owning a P3 modem willing to accept this Winmor regime might add ther pactor 123 TNC scanning the same 3 frequencies ..narrow or wide..

RMS Express must increase its default call session to be 30 sec. About like pactor.

This whole dual scanning system may already be done elegantly using the BPQ32 system. So why not also with Original SW? (exept off course....sw need programming time to be implemented....., or maybe already some hidden plans for kind of integrations of SW are present?) I don't know at all.

Good reliable traffic statistics may also be a serious issue in the "big picture" of such as total SYSTEM as Wl2K is. This may prevent a mixture as mentioned above.

But why invent the wheel twice? if not necessary?

73 de la7um Finn

We have tried in the intial testing of RMS WINMOR to integrate both Pactor and WINMOR into the same server. The results due to scanning requirements and busy channel detection were always unsatisfactory even with much effort. The problme has to do with the time needed for accurate signal type detection and the requirement for channel scanning. Using more stations and having them scan more limited frequencuies (e.g. Time of day scanning etc.) is the only practical solution found to date. The minimal additional cost of RMS WINMOR (no expensive TNC) will in time result in additional WINMOR stations coming on line.

Definition of the word SCANNING is the crucial word here. That's why I suggest SLOW "scan" max 3, maybe only 2 freqs on the same band per rig at anyone time of day for this Winmor "scan/dual" with same slow SW controlled Pactor scan.

1:
Dwelling abt 10sek when "scanning or creeping" within _same band_ makes it possible for the Busy detect to settle quicker than when changing bands.

2:
This option, beeing an option only, makes it possible to utilize better some few dedicated GOOD Qths if site area and fundings are available. Not so now.

3:
A client can always listen and know wether the server is occupied or not.
This way a lot of uneccesary QRM-making callings are avoided. Such callings in vain because the pactor server is occupied on another band out of reach is typically part of what has made quite some bad will towards the Winlink robots.

4:
Without this "creeping scan" it is "dangerous" to establish ANY server on 1600hz channel only. That is because, at least in Norway on the same channel voice SSB qsos are legal and are frequently ongoing. (In the middle of the small segment for unattended digital servers). We NEED 1 or 2 redundant "escape routes". If not: Alternative? I mean statistical probability of what are frequently going to happen?..... Even greater popularity of Winlink or what?

A setup like my suggestion has earlier been confirmed by you Rick, to actually being possible.

The standard defaulted old pactor way, DWELL 3 sek as RMS PACTOR is obviously impossible in a dual way, and this cross band quick scanning has also created quite some bad will towards Winlink. So that maybe should gradually be disencouraged.

Scanning no matter what speed and how many bands insures one thing. Users must "call" sometimes called a "blind call" for at least the length of the SCAN cycle. If three frequencies were used and scanning at 10 sec per frequency that means all connect requests must be at least 30 seconds in length. The required dead time to (to insure that a call is not skipped is about 2 seconds or so for both Pactor and WINMOR. That dead time is time that no connect is possible so on a 10 second scan rate 8 seconds would be available to "listen". But to also use busy detection blocking (preventing answering a call if the channel appears busy) takes approximately 2-3 seconds of quiet time at the beginning of a new frequency. so on a 10 second scan rate only 5-6 seconds of active time/ channel might be available. That would allow about 2 WINMOR connect requests which is really the minimum that should be used. The real problem I see is if the Server is scanning it is very difficult to be able to use the busy detector effectively. Assuming there is a connect request on going when the Server switches to the new frequency it will appear busy prohibiting the server from answering the connect request. While many people have an oppinion on this I have seen nothing in the way of real analysis and/or simulation (this is a classic resource simulation problem) of how it would work. If this sounds like work ...it probably is but not near the work requried to combine RMS Pactor, RMS WINMOR, simultaneousl scanning and Busy channel blocking. We spent at least 2 man months before working on that (with the initial WINMOR server) with no good results.

I am open to this but I think we need to see real analysis with detailed examples worked out to show how it would work and where the most likly problems are. When you allow only one frequency you dramatically simplify this problem though dual Pactor and WINMOR operation is still a bit of a challenge to insure absolute interlocking.

KN6KB

Taken from my posting in Yahoo WINMOR forum.
Rick: You hopefully get this + a little addon as private mail as well.
 
Scan or not to scan: PACTOR,WINMOR,or COMBINED
Some good arguments for both fixed and scan options has been presented in the WINMOR forum the last days. A transition from old experiences running SCS State of the Art Pactor123 scan into a wish for the same scanning running Winmor is understandable. I, amongst others have asked for lots of scan options. After some testings shown below my wishes are moderated to a great extent, though not entirely removed, only modified.

As Rick is swamped and has openly asked for help with extra simulations or even statistics I take the liberty to come here with my observations.


The reasons for modifications of my earlier scanning wishes are mainly because of some observed difficulties establishing a link after only one or 2 WINMOR calling bursts. And the working conditions for the Busy Detect. See the bottom of my posting.

My conclusions are based upon several hundreds of observations made while deliberately imposing different kinds of controlled working restrictions to a Winmor link. Observing the server 80m ground wave 6km distance away from me real time by VNC during the transfers I checked Gear Shifts and WINMOR TNC aggregated memory use while real time listening to the noice during the link.

I sometimes imposed heavy flickering s9(+10?)db Brrrrrrrrrrrrr noice to my client (TV, switch mode powers), and imposed IF shifts gradually detuned. Also imposing a 350hz (nominally too narrow) filter and even detuned that gradually. Testing 1600hz mode, and 500hz mode. Testing robustness and ability to survive.
Signal from the server was ALWAYS s9 (only possible to see with filter. Without filter the visual signals often drowned in the machine gun noice)
Noice seemed to be about s 7 with filter when server was not transmitting.

I also downloaded abt 10 times a 114kb file in 500hz mode and 10 times in 1600hz mode.

Test done mid day, ground wave only, evening and nights with gradually more and more multipath influence.

Tests done normal days and nights and also during heavy RTTY weekend tests.

This did take lots and lots of time, maybe comparable to some of Ricks simulations.
XYL not very happy..........But she is still my XYL (not only a X)

Some of the observations were documented with logs to Rick who is avare of those testings.
 
My private conclusion so far is that I still have whishes for kinds of scanning, but in a quite moderated form, and very much dependent upon what is the main purpose and setup for that particular WINMOR Server and the environment noice.
Scanning settings should be controllable by SYSOP.
But with a clearly written recommendation stating pros and cons.

There is no free lunch so everything comes at a cost.
There is no BEST solution for all cases. Some political choice must be done.

Bottom line first:

1:
Pure RMS Pactors: SCS P123. State of the Art HW. Expensive.
Go on as before: Default Dwell Time 3 sec.
Not all Pactor stations do scan all bands.
Start working in a mixed WINMOR/PACTOR regime could be encouraged.
 
Default calling sequence is abt 30 sec.


2:
RMS WINMORs: Mediocre HW.(PC and Soundcard) Cheap. Emcomm. Poor mans Pactor.
Potentially a lot of clients. Performs surprisingly well, considered HW.
Great potential.

Scanning something like options in BPQ32, but with an easier setup optimized for RMS purpose.
Let the Server sysop choose for himself depending on what, who and the area to serve. Whether he is the ONLY server within reach, noice, etc etc...

Sysop considering how quiet the server listening surroundings are. The whole Caribbien or Atlantic may need several frequencies scanned. A lesser probabillity to get a connect at first try is better for a client than not having a chance because of beeing out of propagation area.

If server listening surroundings are good, little local noice, a shorter dwell period is possible.

Recommended minimum time 10 sec pr freq to let busy detect have a chance.
Remember, it seems to be more difficult to get a link after 1 WINMOR burst compaired to after 1 PACTOR burst. And 1 WINMOR burst is longer than 1 pactor burst. Thus quickly increasing optimal Dwell time.

If more bands are needed, I would recommend a dual instance setup. Lowpass and Highpass filters respectively.
That should cover most important bands with pretty easy antenna installations.

Default RMS Express calling sequence increased to 30 sec about like Pactor.

3:
RMS MULTIMODE: (MIXED RMS WINMORs with RMS PACTOR (and even HF RPR PACKET 600))
Already under testing by BPQ32.

Scanning only 2 freqs Wide and Narrow on the same band. No time of day shift.
Single band Band pass filter. Tuner, ALC, PO, everything adjusted optimal.
Busy Detect do have a chance.
One wide band section. The other narrow band section.
This is offering an escape route for the client if having extreme local noice on one of the 2 possible frequencies.

Dwell time 15 seconds.
During which WINMOR and SignaLink is working through MIC connection 15 sec.
During which HF RPR PACKET listen 11(12) sec, PACTOR 123 listen4(3) sec.
This is doable with one port PTC2EX or PTC2USB. Same connectors for both modes.

An installation like that would really be a optimal Emcomm beast.
Serving Pactor 123, Winmor 500 and 1600 and HF RPR 600.
This last , pretty new, mode is offered in the exellent 19K2, 9K6 and 1K2 SCS Tracker. For either Aprs use, or RMS Packet use, OR HF RPR 600 message transfer.

For greater coverage without increasing blind call time, make 2 server instances. Or only one freq pr band scanning 2 bands.


(The RMS WINMOR could even in the future for price reasons add only the SCS DSP TRACKER in stead of PTC2EX costing about 1/2 or 1/3 of a PTC2 with Pactor.)

Again RMS Express calling sequence in any mode increased to 30 sec like Pactor.
  

SOME STATISTICAL OBSERVATIONS:

1:
Under <good> conds a connect on average was established after one or 2 bursts.

2:
Under <bad> conds (i.e) imposed tv or switchmode power brrrrrrrrrrrrrrrrrrrr, or if or narrow band filter a little out of tune, the connect attempts either succeeded or not succeded even if my ears could identify the tones.

3:
If not succeeded within abt 15 sec it <very seldom> helped with another burst.
To succeed I had to change the conds. _This is an important observation_. How to do that?:
Yes: Reducing local noice with a lot of decibels is often done by tuning a little up or down.
I.E changing between a BW WIDE freq or BW NARROW freq. ( If you cannot just switch off your own tv or extra switch mode power). An emcomm station in the field may not be disturbed by tv, but generator noice or switch mode powers may be out of his control.

4:
Surprisingly quite often WINMOR actually made the link by help from the added Dwell seconds from 10 to 15 sec.
_That is also important_. Telling me that maybe 10 seconds Dwell is sub optimal for WINMOR.

Important is also that when the link was first established, THEN it usually succeeded to the very end, unless I deliberatly worsend the working conds.
500hz has a 6 db greater surviving ability under the older gearshift regime.
If that may be changed so no link is breaking down before 500hz mode is also tried, then WINMOR robustnes will be greatly enhanced.

LA7UM Finn

The newer gearshift algorithm is working wonderfully.
Always trying a 500Hz mode before giving up.
Great enhancement. Included even a better Dsp In WM TNC 1.4.0.0.
Looking forward to the TRImode.
Thanks.