From:  Steve Harrison, Ko0U/1 
  
  Subject: [HSMS] MSDSP 0.70 Tips (LONG)

1. Yes, the mouse does move across the screen somewhat slower than you might expect; but at least it's now a consistent speed instead of merely slow within the display area. You will get used to this after a few skeds.

2. The new screen can now be set up for both preferred colors and also for contrast; these parameters can be changed within the MSDSP.INI file, which YOU have to create by using an ASCII text editor to open either MSDSP.INE (for European users) or MSDSP.INA (for North American users). Once you open either of these files and modify the parameters as desired, save the file as MSDSP.INI. Here are tips on setting up your own MSDSP.INI file.

The first parameter you will find is SampleRate; this should be set as high as possible because transmit and receive audio quality are greatly affected. A fast Pentium-type computer (6x86L-PR166+) with at least 8 MB of RAM can probably run the highest sample rate available, 44100. If yours will not, then try reducing the sample rate. All of the sample rates available for standard WAV files are usable here, including 44100, 32000, 22050, 16000, etc., on down to 8000.

Leave the PlayBuffer set to 2048 for now; experiment after you have the program running well.

The PixelDensity can be varied to set the density of the recorded information shown on screen. If you liked the old display of MSDSP 0.51, set this to 200000; the max available value is 300000.

The WaveColor parameters (Red, Green and Blue) can be varied to your liking; the max value is 63, the minimum is 0. If you liked the color of the recorded display of earlier versions, set these three to 0, 63, 63 respectively. I find it difficult to see the default dark red on weak and very short pings, preferring the original bluish hue. Others love the new red color.

Set ForceVESA and FPU as your computer requires.

Some of we old fogeys have slowed down and need more reaction time to hit the space bar; SpaceDelay allows you to set this to a maximum of 9999 milliseconds, I believe it is. I use 2000 most of the time, which is 2.000 seconds.

The function and use of TXSpeed and TXTone is obvious, and also adjustable from within MSDSP by using the left and right arrow keys. Unless you are running really high keying speeds (over, say, 10000 lpm), you should not run TXTone above 2500 Hz because higher frequencies will not pass through the SSB filter in your transmitter, and the keying waveshape will become more distorted.

The use of TXPort, PTTActive and TXDelay should be obvious; but if you have never used a CW or voice-recording computer program before, you may not be familiar with the use of these signals. These are simply output signals which are intended to be used to help synchronize and switch your antenna and other control relays. For example, the old Kenwood TR9130 2m SSB transceiver does not have an internal SSB VOX circuit; so to have MSDSP automatically place that radio into TX mode, you must either key the PTT by hand when MSDSP begins transmitting, or you can use one of these signals to drive an external low-current-drive transistor switch, relay or optoisolator (safest method) which then keys the PTT of the radio directly. I can't go into the design of interface circuits here; but you will find numerous examples shown elsewhere, such as in packet radio computer programs. Some will also be shown in the new manual.

Please note that while the MSDSP Alpha Test Team attempted to test all of the possible combinations, we might have missed a couple. If you find any that do not work, please let the rest of us know about them.

All of the remaining parameters listed in MSDSP.INx (A or E) can also be changed from within MSDSP after the program is started; you can set the default starting value of any parameter in this MSDSP.INI file.

As in the MSPSP.INI file for 0.51, the letter "M" is used in the TX Texts to denote YOUR call, not the letter "C" as the text indicates. You can remove all of the spaces within the various TX text lines to pack as much information into your transmissions as possible, including setting the end-of-line character (left-facing arrow) right after the last letter; then that line will simply loop from the last letter back to the first with no spaces. Some have noted that they have difficulty understanding copied information when the spaces are removed; keep that in mind when you set up for schedules.

My personal preference for the line containing calls and reports is not to repeat the report as shown; instead, I prefer to alternate the report between callsigns, which gives each piece of information the maximum opportunity to be transmitted over very short pings.

Here are some operational tips: 1. When you hear a ping, immediately hit the SPACE bar; BUT DO NOT HIT THE ENTER KEY YET. Instead, wait until the display has filled in completely between the blue lines showing the area of the screen that will be saved to a RX buffer. This will allow you to include any other pings/bursts that occur within that time period. 2. I try to hold off hitting the ENTER key to save to a RX buffer until the last second. If I get a later, stronger ping, then I hit SPACE which brackets that stronger ping; then I save that stronger ping to the RX buffer.

Also, if you keep a paper log of copied information, I find it very helpful to note which RX buffer contains which pings/information. This helps me to decide, if necessary, which buffers I might want to listen to in more detail at later times. I also write down the exact file name in this same place on the log to let me keep track what information was saved to what filename. Generally, I name my files by using first the date (0325 for March 25), the last two letters of the callsign (WN for W8WN, then sequential numbers starting with 01; i.e., 0325wn01. If I later edit the file using CoolEdit, I can indicate the file has been changed by saving it as 0325wna1, for example. Then I know that file is an editted version of the original 0325wn01. If you use all three letters of a call, such file

The best way to avoid doing this that works fairly well for most of us is to, during the first couple of sequences, listen very closely to get a feel for how meteor conditions appear to be. If there seem to be numerous pings/bursts, we usually figure that we will mostly have our pick of pings/bursts to save to buffers. If all pings are very short and weak, then you will want to pick and choose which seem most likely to provide copiable information. Generally, these will be those pings which show high positive and negative spikes on the screen. Pings/bursts which you heard but which do not show up easily on the screen are less likely to yield more than a letter or two, and should usually be bypassed unless there just aren't any others more worthy of saving.

Once you save a section of the main screen to a buffer and are in the transmit portion of your sked sequence, then hit the function key associated with the desired buffer. Then place the mouse pointer just before where the ping begins and press the right mouse key; a green line will appear going downward. Be sure you have already set your desired playback speed ratio and playback tone. Next, press the key "I", which will begin playing from that green line. If there are other pings in that buffer, you can move the mouse to them, right-click, press "I", and play again. The key "P" will play any buffer from the very beginning and is rarely used; learn to use the key "I" to start your playback right on your ping and you will save time during playback. Shel and I have so much experience now that we can usually pick and play back over a half dozen pings each minute; that's a goal toward which you should strive to exceed! Remember that the LATER pings are more likely to contain the LATEST information that your sked partner sent; so choose strong, late pings within a buffer to play back FIRST. Then if you don't get information, work backwards toward the beginning.

If you have other buffers to listen to, hit the function key for them and repeat the above procedure. Generally, you can tell which buffers were the last to be saved because the box under each buffer area will show little dots, indicating the buffer has data.

You will probably note that the display refresh time of MSDSP 0.70 appears to have been slowed considerably; this is true, and is a change from the 0.6x alpha versions, too. Apparently, 9A4GL had to change this refresh time to take care of some other bug. During my sked with W8WN this morning, I found this longer refresh time to be annoying and to cost me 5 or more seconds during each RX playback sequence.

You will also note that although MSDSP 0.70 starts and stops transmitting right on the minute, it does not actually begin recording again for at least 2 seconds while it is automatically switching back to the main buffer and refreshing the screen.

You can erase the old screen by hitting DELETE. NOTE THAT ONCE YOU DELETE THE SCREEN, IT IS GONE FOREVER, along with any pings that were on it!! Until you are really proficient with getting around the screen, I strongly suggest that you not let your fingers stray near the DELETE key (experience are chagrin speaking here!).

Also, if you decide to save a RX buffer to a file by using ALT-S, and you want to trim "dead air" out of the RX buffer to reduce the file size, WATCH VERY CAREFULLY WHAT YOU ARE TRIMMING: once you have trimmed, ALL INFO TRIMMED IS GONE FOREVER!!

When you try to save a file, DO NOT START DOING SO IF YOU ONLY HAVE A FEW SECONDS LEFT IN THE TX PERIOD! As soon as the period is over, you will be bounced back to the main screen from wherever you were and you will have to start over again. Learn to trim your RX buffers for saving and to type the desired file names within the first 45 seconds of the TX period, or you run the risk of loosing data that you wanted to save.

MSDSP 0.70 is a great improvement over 0.51 and earlier versions, and appears to have all the neat features of the alpha versions which have been tested over the last several months. With some proficiency, you will find it easy to set up a sked and be on the air within a minute, calling the other person and recording those ultra-short pings/bursts to work a new grid.

As usual, if you have problems getting MSDSP running with your computer system, you can ask for help here on the reflector. PLEASE mention what your computer system is, including the operating system. And PLEASE remember that since MSDSP is written to run under DOS, it SHOULD run under a DOS session when you exit W95. If may or may not run from a DOS prompt from within either W3.x or W95. If you have problems running from within Winders, try it from a pure DOS environment.

73, Steve Ko0U/1