Ihre Kommentare
Wow. I have been sleeping, having not focused on this issue.
I don't see any BCC, only Cc option in AirMail.
If this is really so, it sounds as a very good idea if it is technically easily done in RMS Express or the system itself.
Please make some checking into the possiblliities of this issue in due time.
To my understanding there is a lot other of important issues for WDT to be prioritized.
Robustness and implementations of Winmor into Paclink, and KAM XL HF support in RMS Express are a couple of those.
Even the exiting work with RMS TRImode and slow scan.
73 de la7um Finn
I don't see any BCC, only Cc option in AirMail.
If this is really so, it sounds as a very good idea if it is technically easily done in RMS Express or the system itself.
Please make some checking into the possiblliities of this issue in due time.
To my understanding there is a lot other of important issues for WDT to be prioritized.
Robustness and implementations of Winmor into Paclink, and KAM XL HF support in RMS Express are a couple of those.
Even the exiting work with RMS TRImode and slow scan.
73 de la7um Finn
Please further check out the impact to the credibility of statistics regarding the whole Winlink RMS Pactor system by comparing the whole WORLD 8 P1 all febr. 2011 with LA3F TRUE station log statistics ONE day 9 P1 with web page statistics for LA3F for whole febr 2011 saying 0 P1.
Multiply the number: 9 P1 (unaccounted for) by 28 days in febr = 252 (P1) for ONE RMS Pactor alone.
I have not had time to check logs for all days by summarizing the real numbers.
Multiply the number: 9 P1 (unaccounted for) by 28 days in febr = 252 (P1) for ONE RMS Pactor alone.
I have not had time to check logs for all days by summarizing the real numbers.
Hi, thanks for the new RMS Express 1100 including RPR for SCS DSP Tracker. Might it later be a way for a HF RPR enabled PTC2 controller to do HF message transfers using this mode as well as its default Pactor modes? Or am I missing something? Maybe it's already there?
73 de Finn/LA7UM
73 de Finn/LA7UM
I can only say thanks for the suggestion.
It is mandatory by law for norwegians on 30m.
On other bands it may be "good ham practise" around the world if some p123 enabled RMS pactors are located unrecommended in the IARU ham band sections recommended for narrow band use, but legal according to law.
Then the option for wide band are always present (legal according to law) if real emcomm suddenly is needed.
But unless emcomm the hams may avoid a growing "bad will" against Winlink system when given client option to choose only narrow band when no more is needed.
It is mandatory by law for norwegians on 30m.
On other bands it may be "good ham practise" around the world if some p123 enabled RMS pactors are located unrecommended in the IARU ham band sections recommended for narrow band use, but legal according to law.
Then the option for wide band are always present (legal according to law) if real emcomm suddenly is needed.
But unless emcomm the hams may avoid a growing "bad will" against Winlink system when given client option to choose only narrow band when no more is needed.
I think that maybe can be a US issue.
Not necessarily so around the whole world.
To my understanding under normal conditons WINMOR is doing quite some job.
If my other posting referring to to some extreme examples running WINMOR 1600hz with a slow throughput do inspire someone to avoid WINMOR 1600hz, it was not my intention.
On the contrary. My examples were done under extreme _deliberataly_ imposed bad working conds. Just pointing out some simple means to make the 1600hz mode just as robust as the 500hz mode. Still having the inbuilt ability to recover into full speed when conds is getting better.
Rick has mentioned gearshift thoughts several times, and have encouraged preferably some simulation help, or even just some statistics. That was the cause for my scanning and BW postings.
I also said nothing about the probability of the real world imposing such extreme working conds.
I really am optimistic about the future value of WINMOR around the world.
But it should be possible working with an added pactor 123 tnc as well. Even RPR in narrow band segments.
73 de la7um Finn
Not necessarily so around the whole world.
To my understanding under normal conditons WINMOR is doing quite some job.
If my other posting referring to to some extreme examples running WINMOR 1600hz with a slow throughput do inspire someone to avoid WINMOR 1600hz, it was not my intention.
On the contrary. My examples were done under extreme _deliberataly_ imposed bad working conds. Just pointing out some simple means to make the 1600hz mode just as robust as the 500hz mode. Still having the inbuilt ability to recover into full speed when conds is getting better.
Rick has mentioned gearshift thoughts several times, and have encouraged preferably some simulation help, or even just some statistics. That was the cause for my scanning and BW postings.
I also said nothing about the probability of the real world imposing such extreme working conds.
I really am optimistic about the future value of WINMOR around the world.
But it should be possible working with an added pactor 123 tnc as well. Even RPR in narrow band segments.
73 de la7um Finn
Good point. Loong ago since I checqued this.
I agree with your points of view.
I agree with your points of view.
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
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
Be careful so you do not accidentally destroy a format that may have been /maybe still is useful for manually updating Airmail Hf pactor lists.
I "believe" that I some years ago did a couple of manual updates on a couple of different Airmail installations on some older Airmail versions.
That was why I may suggest making a new completely merged list, keeping the old one for Airmail purposes if this still is useful for Airmail users.
The format is good for making an up to date paper copy including some sysop info.
I don't know if this option is inherent in todays versions of Airmail.
73 Finn/LA7UM
I "believe" that I some years ago did a couple of manual updates on a couple of different Airmail installations on some older Airmail versions.
That was why I may suggest making a new completely merged list, keeping the old one for Airmail purposes if this still is useful for Airmail users.
The format is good for making an up to date paper copy including some sysop info.
I don't know if this option is inherent in todays versions of Airmail.
73 Finn/LA7UM
Read your own website www.winlink.org. Check the right column:
Read and click the 7th line:Radio Mail Server (RMS) frequency list.
Next page header: Public Stations Frequency Lists. Under: read the second line:
That is saying: Frequencies supporting all PACTOR and WINMOR modes are supported.
Now _YOU_ show _ME_ where to find ANY information about WINMOR frequencies (off course withouth clicking on the always present Main Menu).
Is NOT present in the Attachement PublicPMBOs.txt (By the way an outdated header).
Third line in that attachement do state that letter w offers WINMOR connections.
Reading that ascii attachement shows no info whatsoever about any WINMOR station, exept the third line BRAGGING that is does exactly that.
I would suggest that you make a complete list as stated in the page itself.
Then ADD special list without WINMOR relevant for download into Airmail.
Read and click the 7th line:Radio Mail Server (RMS) frequency list.
Next page header: Public Stations Frequency Lists. Under: read the second line:
That is saying: Frequencies supporting all PACTOR and WINMOR modes are supported.
Now _YOU_ show _ME_ where to find ANY information about WINMOR frequencies (off course withouth clicking on the always present Main Menu).
Is NOT present in the Attachement PublicPMBOs.txt (By the way an outdated header).
Third line in that attachement do state that letter w offers WINMOR connections.
Reading that ascii attachement shows no info whatsoever about any WINMOR station, exept the third line BRAGGING that is does exactly that.
I would suggest that you make a complete list as stated in the page itself.
Then ADD special list without WINMOR relevant for download into Airmail.
Customer support service by UserEcho
What I stil miss is the support for Kantronics TNCs on the HF side, and old but reiably KPC4 on the Packet side.
AND the possibility of limiting a Pactor 123(4) session to level 2 pactor 2 for running 30m legally from Norway to many other EU countries.
It may be more difficult changing the WINMOR protocol for this, but he PACTOR LEVELS client limiting options like in AirMail should be a peace of cake. So for NOW we do recommend AirMail as THE pactor SW for NORWEGIAN WL2K Pactor use.
Then we can train for emcomm legally, getting aquantied with working servers. Without loosing our licence when repeatedly breaking the LAW! not the IARU gentlemans agreements.
In real _emcomm_ we might probably open up P3 for all its worth, and ask for forgivnes after the critical event.
To go on the Server Side on RMS Packet, I hope that even older KPC4s having KISS mode, but not HOST mode may use their inbuilt 2 port abiltiy as well, at least I hope so. Off course they need using their radio squelches shut because of that times decode options.
KUDOS and Good Work
73 de la7um Finn