[digitalradio] Re:WINMOR Server Busy Detect- report
Andy, Skip, Andy that appears to be a good test and (assuming the N0 station was hidden from the calling European RMS Express station) an indication the busy detector does work to block the connect and help address the hidden transmitter problem often referenced. Some facts for Skip and others that may be less familiar with the busy detector and RMS WINMOR: The RMS WINMOR station of course automatically keeps a log. In fact every session is logged and every contact (UTC Time, call signs, frequency, bytes sent/received) is captured to the master data base for analysis. If the RMS WINMOR also has the debug log enabled it can also capture (UTC time tagged to 10 ms resolution) the intimate details of the connect request timing, busy detector output, blocking function, and a wealth of other internal details of the decoding process. The busy detector does now have a squelch adjustment. This was requested and necessary for fine tuning in higher noise environments (where a continual busy detection might occur). The squelch does not adjust the sensitivity to amplitude.that is always automatic.but the trip points for the wide and narrow ratio detectors that make up the busy detector. The busy detector for the RMS WINMOR (server) can be disabled by the sysop. Two reasons for this: 1) It is still experimental and being optimized but as Andy noted it does work fairly well and is being adopted. The first RMS WINMOR stations were brought on board in January. 2) In case of emergency it is prudent to give the sysop control over this function. The busy detector for the RMS Express (client) cannot be disabled but only causes a pop up warning to the operator that the channel appears busy. The operator could over ride this if required (again an emergency feature giving the operator some discretion). The busy detector only operates over a selected frequency range of interest (e.g. the bandwidth of the session + guard bands) so it is normally not necessary to IF pre filter it. Pre filtering does of course help to suppress receiver AGC capture by signals outside the desired pass band just as it would with any mode so pre filtering is helpful to reject strong adjacent channel signals but it does not affect the busy detector itself. I think the question that goes begging here is not is it possible or does it work.Andy's test shows at least one good example it can work. The question should be Why don't other modes or clients implement a busy detector too? The code is not complex and is not mode specific. If you wish I'll post the VB.NET source which could of course be translated easily into any other language. Its 66 lines of code including comments. The only DSP utility required is the FFT to get the frequency bins. I'm sure if we had more skilled programmers working on it we could make it more effective and reliable. These busy detectors aren't perfect.can't be perfect for all modes and all conditions. but they help and in many cases they are more reliable than the human initiating the connection. At the least they can and should serve as an aid to the human operator. With today's DSP digital modes there is really no reason not to implement them as a tool to augment the operator's ear.especially important for new and untrained operators. Let me know if there is interest in the source code and I'll package it up for posting along with some description of its operation. Rick Muething, KN6KB
[digitalradio] Re: Unattended narrow mode transmission protection
Dave, Using the WINMOR busy detector for Pactor sounds like a workable idea. The WINMOR busy detector hasn't yet been integrated into other WL2K Pactor Servers but it could be. The basic WINMOR TNC application (the virtual TNC) has the function but would need to be integrated into the Pactor driver for the SCS. When Vic gets back from vacation I'll talk to him about this and when we might be able to do that. 73, Rick Muething, KN6KB
[digitalradio] Re: Unattended narrow mode transmission protection
All, I have been busy with WINMOR but do monitor the group and thought it might add some balance to put forth some facts and observations. 1) The majority of WL2K users are not 30 day wonder hams on expensive yachts. Marine mobile users are probably 20% of all registered WL2K users (about 15,000 total current active users). 2) Those that are Marine Mobile have (on average) the same radio skills as the average ham.some much better. Getting digital radio to work at all on a small sailboat (most MM users are not wealthy and have yachts of 35 feet) when you are sitting in a plastic boat inside the antenna near field is a challenge. I have seen and helped set up over 100 such installations. 3) Certainly there are a number of operators that fail to listen first or don't use the tools and procedures recommended to connect. E.g. AirMail limits the calling cycle to normally 20 seconds for most stations. Unfortunately bad operators and procedures exist in ham radio in every mode. 4) Marinas by and large don't do or sell radio installations (I have NEVER seen even one). They sell GAS/Diesel, dockage, supplies, beer and bait. In fact most marine radio service companies have minimal experience with ham radios or HF digital modes. 5) Scanning has been used in the past to improve the utilization of HF Pactor server stations but can be an issue. Pactor has some but limited busy channel detection capability. WL2K is now looking at and testing alternatives to the conventional scanning used in Pactor. The new WINMOR protocol allows more options and experimentation. a. RMS WINMOR server stations [Beta operation started in January 2010] operate on ONE frequency which can be changed (on the hour) during the day (most use 1 - 3 frequencies over a 24 hour day). The frequency list clients use indicate which frequency is in use on which UTC hour. The client software (RMS Express) shows users ONLY those frequencies in current use along with the propagation prediction to the remote server stations. Users can refresh their server station list over the air or over the internet if available. b. WINMOR uses an effective channel busy detector to warn users if a channel appears busy in the bandwidth of interest. The detector isn't perfect (neither is the human ear!) but it can detect most modes even in weak conditions (SSB, CW, PSK, Pactor, Olivia, WINMOR etc). c. The RMS WINMOR stations (servers) also have a similar DSP based detector which can block a reply to a connect request. This will prevent for example answering a connect request over an existing session/QSO not audible to the station originating the connect request (hidden transmitter situation). We're still experimenting and refining this but it definitely helps avoid accidental interference. To summarize: Painting all Winlink users with a broad brush of wealthy yachties with limited radio skills is no where near the truth and is an obvious attempt distort the facts to promote some agenda. If given the flexibility to work on and experiment with these digital modes it is possible to address issues and make progress improving our hobby. If we try and legislate every detail we end up generating rules or band plans that become obsolete quickly. This discourages experimentation (I still hope that is part of our hobby.) and progress. I don't have the time to get into flame wars or extended blogging ..If you have a legitimate technical question on WINMOR or a question about WL2K I will try and answer it with accurate facts. 73, Rick Muething, KN6KB
[digitalradio] WINMOR Software and specs
All, WINMOR was designed to be an open alternative to Pactor. The WINMOR protocol spec is fully documented and released for public distribution and use. It is available at: http://groups.yahoo.com/group/WINMOR and http://groups.yahoo.com/group/Winlink_Program_Group and http://www.winlink.org/WINMOR and http://www.arrl.org/FandES/field/regulations/techchar/WINMOR.pdf A Google on WINMOR will turn up these and other references. There is also a helper application Virtual WINMOR TNC which can be used by other applications to create, clients, monitors, keyboard to keyboard utilities etc. This helper app is used by RMS WINMOR and RMS Express and has already been used by at least 2 other programmers to create non Winlink WINMOR supported applications like BPQ32. The Virtual WINMOR TNC has a complete spec for the application interface. Because it is both ARQ and normally sends messages using compressed binary transmission it is difficult to monitor content when not connected. It is not a question of missing a few frames because even a single missed frame in a message normally makes the decompression fail. Monitoring the compressed code is pure gibberish. This is the same situation that exists when monitoring any B1 or B2 compressed FBB forwarding session in Pactor or Packet. RMS Express does have a monitor function that logs Call signs and Grid square ID frames as well as CWID at the end of a session. ID frames are sent at the end and every 10 minutes during a session. The WINMOR FEC mode which is designed for keyboard to keyboard or broadcast is not compressed but used very robust Viterbi +RS encoded 4FSK so can be monitored very easily using the WINMOR Virtual TNC. The next version of RMS Express will support both connected and FEC Broadcast keyboard modes using uncompressed data. Normal FBB/Winlink B2 forwarding sessions will continue to use only compressed data since it give approximately a 2:1 improvement in throughput and handles attachment and multiple address encapsulation. The programs RMS Express and WINMOR TNC are available at either of the two yahoo group sites above. There are no plans to release the source code of RMS Express or WINMOR TNC but the protocol is fully documented and open to anyone who wishes to write a DSP TNC module and test it for conformance to the spec. If there are any questions or issues please contact me at rmuethingATcfl.rr.com 73, Rick KN6KB No virus found in this incoming message. Checked by AVG - www.avg.com Version: 9.0.733 / Virus Database: 271.1.1/2681 - Release Date: 02/12/10 14:35:00
[digitalradio] Re:WINMOR more
Andy, I like your description of those that use WINMOR WINMORons ! Certainly describes me for putting in so much time on this full-time hobby. We continue to make incremental improvements in robustness and throughput..(Rome wasn't built in a day!) but you are correct in the comparisons against Pactor 2 and 3 which has some powerful hardware and 15 years of solid effort with good talent behind it. If we approach even 50% of the P2/P3 performance under similar channel conditions I will consider it all a success. Once the WINMOR protocol settles out I will again make some apple-to-apple comparisons with P1, P2 and P3 across several channels on the HF simulator. The motivation for WINMOR was as you said to provide a viable HF ARQ mode and Radio Email client available to those agencies and individuals that could not afford or justify the investment in a high performance HF modem. I am currently testing the next release. It has a few added features and some boost in throughput and robustness. Here is a log snippet I ran with VE1YZ (Florida to Nova Scotia) last evening. 7K byte file (after compression) on 18107.5 MHz, 60 Watts, Trap Dipole antenna. It includes a new metric that measures the peak 1 minute average throughput as well as the session throughput which includes proposal and link turnover overhead. For comparison the peak throughput with P3 (which is ~50% wider bandwidth than WINMOR's 1600 Hz mode) is about 11K bytes/min so on this link WINMOR was running about 80% of the Bits/sec/Hz of P3. 2009/11/01 21:25:36 0.3.1.2 *** Connected to: VE1YZ @ 1600 Hz at 2009/11/01 21:25:36 2009/11/01 21:25:36 0.3.1.2[RMS Express-0.3.1.2-B2F] 2009/11/01 21:25:36 0.3.1.2; VE1YZ DE KN6KB (EL98PF) 2009/11/01 21:25:52 0.3.1.2 [RMS Express-0.3.1.2-B2F] 2009/11/01 21:25:52 0.3.1.2 ; KN6KB DE VE1YZ (FN84BQ) 2009/11/01 21:26:09 0.3.1.2 FC EM 49F3NSDBH1FA 42046 7172 0 2009/11/01 21:26:09 0.3.1.2 F 2A 2009/11/01 21:26:09 0.3.1.2FS Y 2009/11/01 21:27:44 0.3.1.2 *** 49F3NSDBH1FA - 42044/7172 bytes received 2009/11/01 21:27:44 0.3.1.2FF 2009/11/01 21:27:57 0.3.1.2 FQ 2009/11/01 21:27:58 0.3.1.2 *** Disconnected at 2009/11/01 21:27:58 2009/11/01 21:27:58 0.3.1.2 [Session Stats:] Duration: 2.37 min Bandwidth: 1600 ISS Mode Shifts: 0 Decode Attempts: 130 Weak R-S Decodes : 98Weak R-S Sums: 0 Strong R-S Decodes: 14Strong R-S Sums:0 Bytes Sent : 62 Bytes Received:7345 Throughput(bytes/min) Session Avg: 3119 Max 1 min Avg: 6082 Estimated Sample Rate Offset (ppm): 91 This release should be out this week. I am still working on some nagging bugs and beginning the port effort to the RMS HF Winlink gateway. Thanks for all your support and help during the beta testing effort. 73, Rick KN6KB
