----------------------------------------------------------------------------- File 'HOWTORUN.TXT' explains how to run the RMS programs (from A to Z). by R. B. Minton, 568 N. 1st St., Raton, NM. 87740 USA. (505) 445-7009 ----------------------------------------------------------------------------- Contents of disk: Program Size Purpose ------------ -------- ------------------------------------------------ BASF.BAT 13 Bytes Invoke GW BASIC and allow 16 open files (max.) BASICA.EXE 70.8 Kb Invoke GW BASIC BASICA.COM 8.3 Kb Invoke GW BASIC CONVRAW.BAS 3.0 Kb Convert/Fix/Shrink file OUT.MIN to OUT.RAW DIPOLE.BAS 4.5 Kb Plot radiation pattern of 1/2 wave horiz. dipole DMM168.BAS 9.9 Kb Collect counts with RS 168 digital multimeter DMM805.BAS 10.6 Kb Collect counts with RS 805 digital multimeter EDIT.COM 413 Bytes General-purpose DOS text editor EDIT.HLP 17.8 Kb Help file for general-purpose DOS text editor GRAPHICS.COM 19.7 Kb Allows graphics plotting on printer GRAPHICS.PRO 21.2 Kb Allows graphics plotting on printer HOWTORUN.TXT 28.1 Kb 7 pages of text on how to run my software OUT.BAT 152 Bytes A DOS batch routine to delete old OUT files OUT.DAY 2.1 Kb Data from DMM program with daily count sums OUT.D11 2.1 Kb Same as OUT.DAY copied to save month # in name OUT.DMP 60.4 Kb A 14-page data dump of OUT.RAW of counts vs. UT OUT.HRS 67.5 Kb Data from DMM program with hourly count sums OUT.H11 67.5 Kb Same as OUT.HRS copied to save month # in name OUT.MIN 403.6 Kb Data from DMM program with 0.1 hour counts OUT.M11 403.6 Kb Same as OUT.MIN copied to save month # in name OUT.RAW 40.9 Kb 6-min OUT.MIN data fixed/converted/shrunk 10X OUT.3DY 4.4 Kb 3 days of input data edited from OUT.RAW OUT.9DY 14.3 Kb 10 days of input data edited from OUT.RAW OVERVIEW.TXT 15.1 Kb 4 pages of text with high-level RMS overview PDP3D.BAS 12.0 Kb Plot 2.375 days of meteor counts PDP9D.BAS 11.1 Kb Plot 9.500 days of meteor counts PDP29D.BAS 13.5 Kb Plot 29.000 days of meteor counts RANGE.BAS 1.2 Kb Compute elevation of 100 Km layer with range SEE.EXE 29.6 Kb Another text editor SOLTIC.BAS 6.5 Kb Compute solar longitude tick marks for PDP29D SUN2YL.BAS 2.6 Kb List 2 years of solar longitudes SUN2YP.BAS 2.6 Kb Print 2 years of solar longitudes ---------- -------- --------------------------------------------- Total size 1.356 Mb Fits on one 3.5" disk weighing 0.68 ounce ----------------------------------------------------------------------------- Overview: Note that computer program names & files are in capital letters, as well as some items that are important. The steps in handling and analyzing meteor counts are summarized below. The step order assumes you are ready to stop the radio meteor system (RMS) and dump the files from it's dedicated computer. Note that steps 1 thru 3 are done on this dedicated computer while it is not collecting counts - try to work fast! The remaining steps are done on another computer. 1 - Stop the computer 12 minutes before 0 hrs. UT - restart at 0 hrs. UT. 2 - Copy the 3 meteor count files with new names, save new data to 2 disks. 3 - Delete the 3 old name OUT files from the RMS computer; restart DMM. 4 - Convert OUT.MIN to OUT.RAW (it does a lot!). 5 - Make 1st run of PDP29D to look at all the raw count data. 6 - Make 2nd run of PDP29D to exclude non-normal dates from diurnal avg. (You may quit here if you wish, or there is no visible meteor activity) (Do steps 7-9 ONLY if you want solar longitudes on your 29-day plot) 7 - Run program SOLTIC to compute solar longitude tick data for PDP29D. 8 - Edit PDP29D to include tick data, and UT dates for plot. 9 - Make 3rd run of PDP29D with solar longitude ticks, and UT dates. 10 - Run PDP3D or PDP9D IF METEOR SHOWER IS EVIDENT on 29-day plot. (3D for 1-day shower, 9D if shower lasts more than 1 day) 11 - Estimated time to do everything, and what to do if you have trouble. ---------------------------------- 1 & 2 ------------------------------------ DMM168.BAS & DMM805.BAS - collects the signals and write counts to 3 files: OUT.MIN - a record is written every 6 min. with counts during that time. OUT.HRS - a record is written every 1 hour with counts during that time. OUT.DAY - a record is written every 1 day with counts during that time. (note that the record is always written at the END of the interval, i.e., the first OUT.MIN record starting at 0 hrs UT will have a time of 0:06) I suggest you run the DMM program for 3-29 days starting at 0 hrs UT. For one living in the MST time zone, this means starting it at 5:00 PM. The UT time will be 0:00 and the date will be the current date +1. My RMS records time as MST/MDT - you may set the computer to UT if you wish. The CONVRAW program and PDP programs assume the first time stamp is for 0 hrs UT. At the end of 3-29 days, stop the program with a 'control-C' or 'break'. The program will stop and BASIC will show an 'OK' prompt. Hit the F10 key to clear the screen. Type 'SYSTEM' to return to the DOS prompt (leave BASIC). If this is your first 29 days (or 'month') of data, copy the 3 OUT files to OUT.M01, OUT.H01, and OUT.D01 - the suffix shows the interval and the month. (The second month would be M02, H02, D02). The H & D files are not used, but are saved in case the 6 min. counts somehow get lost. I urge using an un- interruptable power supply with at least a 60 minute battery time for the critical RMS components (computer CPU, FM radio, multimeter). At the end of 29 days, I suggest you stop the program 12 minutes before 0 hrs UT. You will lose 2 6-minute records, but there is little recourse. Be sure to write down the current .1 hr & 1 hr. lines (top 2) because they will not get written to the file. They will have 10 values with the last few at 0. Example: 3 5 1 0 2 6 4 3 0 0. The count will probably be low if you live in the US because it will be near the minimum of the diurnal cycle. You can listen to the radio for 12 min. and make a mental note of how many meteors were heard. Write down half of this for each 6 min. interval; or just leave the last 2 values zero. Before restarting the DMM program, check the computer date and time and re- set both if not correct. Copy the OUT files (only Mnn, Hnn, Dnn) to 2 disks. Two disks are needed in case one contains a write/read error - this happens. Type 'DIR' to verify all 3 are on each disk. Move the write tab to READ ONLY to prevent writing over them later. Label them something like: <<<<<<<<< FM RMS FILES >>>>>>>> Month: # 1 Ending: 4-11-2002 @ ~5 PM MST Antenna: 1/4 wave Vertical Lightning:_____________________ _______________________________ Rain:__________________________ _______________________________ Suspect:_______________________ _______________________________ Remarks:_______________________ _______________________________ ------------------------------------ 3 -------------------------------------- You now must delete the old OUT.MIN, OUT.HRS, and OUT.DAY files or the DMM program will append the second month to the first month! There is a DOS batch file to do this for you - type 'OUT' and they will be deleted. (The OUT.M01, OUT.H01, and OUT.D01 are spared deletion). Since you have these on disk you can delete them next month after the data has been ploted. ------------------------------------ 4 -------------------------------------- CONVRAW.BAS converts the OUT.MIN file from a size of about 400,000 bytes to about 40,000 bytes. It does this by taking each 6 min. record (10 ea.) and writing 1 record with all 10 values - 1 hour per line. You can print the hourly and daily sums at this time, but if you do you must define the month, day, and # of days in the current month. You can skip the dump, and the con- version will proceed OK. The input file is OUT.Mnn where nn is 01, 02; etc. The output file is OUT.RAW. If you dump sums, the output file is OUT.DMP. After converting, edit OUT.RAW to add the missing line at the bottom. Add the time line above the count line, or you will get a read error at the end. Since CONVRAW opens lots of files, type BASF to invoke Basic with max files set to 16. (If you type 'BASICA CONVRAW' you will get a file error message. After typing BASF, you should type LOAD"CONVRAW, then RUN - but don't RUN this program yet.) I also suggest that you make a new version of CONVRAW for each RMS month, i.e., if the last RMS month was #5 then copy CONVRAW5.BAS to CONVRAW6.BAS and edit version 6 for the current reductions. If the current reduction is month #6, edit CONVRAW6 so that the input file is OUT.M06, DDY is the 1st UT date in the file, CMO is the month # for DDY, LDY is the # of days in the month, and YR$ (a string variable) is the year. CONVRAW line # and editing: --------------------------- 100: program name (change version # ?) 110: date modified 140: need input file name to be current OUT file (such as OUT.M11) 190: DDY is the first UT date in OUT.DMP file 190: CMO is the month # for DDY 190: LDY is the # of days in month CMO 190: YR$ is the year - appended to input file name for OUT.DMP Now run CONVRAW and verify that the UT days and months are listed correctly. In paticular, verify that the first line is the correct UT date and begins at 0 hrs UT. The tabular screen listings (and hardcopy if desired) are for your information only. If the UT times and days are incorrect, the counts will still get ploted as desired - the date/time is not put on the graph until the last program (PDP29D) is run - but it is better to correct mistakes early! Data dump file OUT.DMP is used to determine the times of events to the nearest 6 minutes, and to list the diurnal counts in 30 min. intervals. CONVRAW lists the data to the screen as it reformats and computes sums. It creats the data dump file OUT.DMP every time it is run - you should print it ONLY if there is a meteor shower (14 pages). ------------------------------------ 5 -------------------------------------- Again assuming the old month is 5 and the current month is 6, copy PDP29D_5. BAS to PDP29D_6.BAS. Edit the following lines in PDP29D_6 as follows for the FIRST RUN. The program will be run a SECOND time (and possibly 3rd), but the 1st run will show what days to exclude from the 'diurnal average'. The days excluded will be those days with 'noise'. It is next to impossible to know this before the raw counts are plotted first. PDP29D line # and editing for the FIRST run: -------------------------------------------- 100: add new name for program 140: add new version and date 190: UMO = month (of the 1st UT date in the graph) NDY = # days in above month UTD = 1st UT date in the graph DF$ = file ID (such as month #, disk #, or save #) NG = (short for No Good), this is the # of days to exclude from the diurnal average - set to 1 for the 1st run to plot all 29 days. This will exclude day #30 which does not exist - there are only 29. 210: PLO$ = "RAW" (this means plot raw counts, if "RDC" then remove the diurnal average from the daily counts). 220: DUMP$ = " ". A blank space means do not write the tables, and and an "F" means write 14 pages of tables to file OUT. DMP. These are tables of raw counts, sums, and diurnal averages every 30 minutes. Recommend it be set to "F". 240: DATA = 30 for 1st run, set to a real value for the next run. 940-950: = 3 solar longitudes - use 000 for all 3 for the first few runs, then change to actual values if you run SOLTIC. 970-1050: = year & 6 dates representing the start/end date of each of the 3 lines of plots. Use the old dates for the 1st run, then change them for the 2nd run. 1060: = graph label, edit it for your name and site. 1660: LTH2 = an offset to convert your local time to UT (MST=17). 1670: LTH1 = has same offset as LTH2 - edit if you are not on MST. The program will sum every day for 24 hours starting at 0 hrs UT, divide the sum by the # of days in the plot, and compute the dirurnal average. This diurnal average is useful to show the diurnal variation for the entire period of time. If there is meteor activity, it will exceed this average by some amount ranging from small to large. It is up to the individual investigator to decide if the activity is significantly above this diurnal average to be considered as a real meteor shower or real meteor activity. Set NG=1 for the first run, and the day to exclude as 30. Since there is no day 30 in this 29 day interval, all days will be included. Note that NG is a 'do loop counter', and if NG were set to 0 it might cause a BASIC run-time error in some versions of BASIC. Use this '1 & 30' fix to avoid potential problems. Make a screen print (hit prnt-scrn key) of this first plot of 29 days. This will be useful for marking-up with the correct solar longitudes, and the correct dates. You should also write the UT date in pencil above each day to verify the correct date and number of days. I also mark each day with a 3-letter meteor shower abbreviation (such as PER or LEO) if the shower is obvious, and write a T, R, S above any dates that have atmospherics. It is vital to mark a calendar with these codes to cross-check the data plotted. ------------------------------------ 6 -------------------------------------- If you see meteor activity in days 7 thru 9, then set NG=3; and the data statement to '7, 8, 9' - and this will exclude these 3 dates from the diurnal average. Likewise, if there are THUNDERSTORMS evident on a date, exclude it too. For example, if day # 25 showed lightning noise, and 7 thru 9 were a 3 day meteor shower; then NG=4 and the values are 7, 8, 9, 25. Sometimes, I might refer to the day # in the program comments as the 'cycle number'. Now run PDP29D_6 after invoking BASIC by typing BASF first to open lots of files. The plot will consist of 3 plots, one above the other; and the dates and solar longitudes will be wrong because they are from the previous 29 days. If you get an error message before, during, or after the last day is ploted, it likely means there is a file read error. Check the input file names, and the start and end of OUT.RAW for something amiss. If the last day is missing the last hour, it means you forgot to add the last hour - or did not edit/add it correctly. If you are happy with the plot on your computer screen, do a screen print to create hardcopy. If there is no meteor activity, or you do not wish to bother with further refinements (adding dates, solar longitudes, and ticks) you may quit at this point! ------------------------------------ 7 -------------------------------------- YOU MAY QUIT HERE, BECAUSE THINGS NOW GET MORE COMPLICATED . . . . If you wish to edit the dates and solar longitudes you need to run program SUN2YP.BAS to compute solar longitudes at 0 hrs UT for each day of the year for 2 years. The formulas are from Peter Duffett-Smith's two books: Practical Astronomy With Your Calculator/Computer. The solar longitudes agree with published values to +/- 0.05 degrees which is good enough for our plots. You can run SUN2YP every two years and refer to it as needed. WGN has formulas and tables for computing solar longitudes for any UT to .01 degrees. You now need to compute how much the solar longitude tick marks will be offset from 0 hrs UT. The location of these tick marks are computed by program SOLTIC.BAS and the output data is put into program PDP29D by the user before program PDP29D is run a SECOND TIME. These tick marks change slowly from day to day because the right ascension of the sun does not change by exactly 1 degree per day. The tick mark will represent integer values (ending in .00) of solar longitude, and only very rarely will one occur at 0 hrs UT. Refer to an example plot to see their alignment, and note that the last solar longi- tude tick mark is omitted to leave room for the solar longitude value (such as (254.0). I suggest that you make a new copy of SOLTIC.BAS each time it is run. For example, copy SOLTIC5.BAS to SOLTIC6.BAS, and then edit SOLTIC6 as follows: SOLTIC line # and editing: -------------------------- 100: program name & version 110: date edited 560-640: 9 pairs of solar DATES/LONGITUDES - these can be entered at run-time, but it is risky. It is better to edit the program. (Run SOLTIC, and the program will explain how to do it). The interpolation formula is in the WGN solar longitude tables. Now run SOLTIC. There are considerable user prompts and documentation in the program to assist the user. I suggest you edit the program to avoid making user input errors (typo's) at runtime. If you have entered the dates and solar longitudes correctly, the program will list the number of pixels to offset from the left border of the graph. There should be no strange values, and the pixel values should resemble 48 48 49 48 48 48 49 48 48 48 or some- thing similar. There will be a string of values for days 1-10 (series 1), days 11-20 (series 2), and days 21-29 (series 3). If everything looks OK, then make a final run to print-out and save the data. Type a CONTROL-P to divert the screen output to your printer, RUN the program, and then type another CONTROL-P to divert output back to your computer screen. The SOLTIC output will list 3 major things needed by program PDP29D. It is easy to find these data because there will be arrows ( <----- ) pointing at them: 1: The solar longitude for the first day in each series - this value is inside the parenthesis - such as (354.0), (004.0), and (014.0). 2: The number of pixels from the left border (of each series) to start ploting solar longitude tick marks - such as 43, 45, 50. 3: The 'best string' (of each series) that best represents the bit moves required to draw the solar longitude tick marks - such as 49 49 48 49 49 49 49 48 49 49. Note that SOLTIC computes 10 tick marks for each of the 3 series, but you will only need 9 tick marks in series 1 and 2, and only 8 tick marks in series 3. Ignore the extra values that are computed. ---------------------------------- 8 & 9 ------------------------------------ Edit PDP29D.BAS one last time; including the above data from SOLTIC. This will show the correct solar longitudes (no longer 000.0), and will align the solar longitudes ticks with 0 hrs UT. The following example will illustrate how this alignment aids in analysing the data. Suppose there are 18 mm between 2 tick marks, and the solar lon- gitude of the first mark is 120.0 - remember that the solar longitude is a whole (integer) number. If there is an onset of meteor activity starting at a point 9 mm from the 1st tick mark, then the solar longitude of the Earth at this point in time (UT time) is 120+(9/18) or 120.5 degrees. The solar longitude computations and tick mark placements are precise enough to measure with ruler and pencil to 1/10 of a degree. If you require more accurate measurement, use the UT times from OUT.DMP and the interpolation formulas and tables in WGN. (I recommend computing tick marks if the graph is submitted for publication, or if you have many longitudes to determine). PDP29D line # and editing: -------------------------- 210: Set PLO$ = RAW to plot raw counts, or RDC to Remove the Diurnal Counts. 820: This line contains the number of bit moves required to move from the left border BEFORE ANY tick marks are drawn - think of this as defining the origin for a series of tick marks. It will look like BM XX,25 where BM is the BASIC command for Bit Move, XX is the value from SOLTIC '# pixels from left border', and 25 is the Y-axis value which does not change. 830-920: These lines are the 'best string values' from SOLTIC which represent the spacings for the solar longitude tick marks. Here is an example of SOLTIC output and how you should edit the lines: SOLTIC best string value: PDP29D string variable: ------------------------- ----------------------- series #1, value #1= 48 XW48$ value #2= 48 XW48$ value #3= 49 XW49$ ..... #9= 48 XW48$ series #2, value #1= 49 XW49$ ..... #9= 48 XW48$ series #3, value #1= 49 XW49$ ..... #8= 48 XW48$ Note that we are just assigning a variable name to a string variable that represents the required # of bit moves. Keep the commas between variables or you will get a run-time error. 940-950: Edit the solar longitudes to values show in SOLTIC as 'solar longitudes of 1st tick'. The tick mark is always an integer (NNN.0). ----------------------------------- 10 -------------------------------------- If there is a shower AND you wish to plot it at a larger scale, you can use PDP3D or PDP9D. If the shower lasts more than 1 day, I suggest using PDP9D. This will show all shower dates, and the diurnal variation before and after the shower. If PDP3D is used on a 1-day shower, the shower should be loca- ted on the second day. Regardless of which is used, the user must copy OUT.RAW to OUT.3DY and OUT. 9DY. The user then edits-out the records he does not wish to plot. Make sure the first record is the DATE/TIME record and it represents 0 hrs UT. Make sure the last record is the 10 values to plot. I usually just edit- out all but 3 days for PDP3D, and 10 days for PDP9D. The programs are set- up to read the small excess of records and only plot to the end of the graph width - it should not terminate while reading a few excess records. If it does there are probably to many records, or too few, or the editing was not done correctly. If this happens, go thru the records with EDIT and make sure it is OK. If a lot of data got botched, just make another copy and re-edit. PDP3D is very user-friendly. The input data file is OUT.3DY. The user is prompted at runtime to enter all of the other values it needs IN UPPERCASE. These are the lines the user must edit if he chooses to run the program 'AS IS' ('ASIS' runs the program without user input): 190: DT$ = month and year of 1st UT date in plot. 200: DUMP$ = "T" means list to screen, "F" to file. 220: T2$ = the 2nd line at the top of the graph. Change it for your site, and the name of the meteor shower. PDP9D is not quite as user-friendly - there is more to change. The 9 dates may contain multiple days of showers, and multiple noise sources - all of which should be labeled to clarify the data. The input file is OUT.9DY. PDP9D puts a label over each date, but these labels must be edited in the program. Otherwise, the program prompts the user at runtime for a 24 or 60 minute integration (per X-axis pixel), and whether the user wants RAW counts or RESIDUALS ploted. If the latter is chosen, the program asks for the average hourly diurnal background count for an entire 24-hour period. This is the last value printed at the end of file OUT.DMP. This value is for the entire 29 days used in PDP29D - if you did not remove any noise or shower dates. This value is probably good enough for most illustration and interpretation, but an exact value can be computed as follows. Run PDP29D with the shower dates removed, and all other dates not in the 9-day plot. For example if the 9-day plot has a shower on days 4,5,6 then remove these 3, include the 3 before the shower; and include the 3 after the shower. Exclude all others in the 29-day interval. These variables are not changed via user input at runtime, and must be edited before the run: 100-140: Change the program name, version #, and date to the last revision. This sounds trivial, but will be important when time passes, and you have many versions to match many sets of data. 800: TICNO = (I+7). Change the '7'. It is the first UT date # ploted on the X-axis - THIS & LINE 810 ARE IMPORTANT. 810: IF TICNO > 31.... Change '31' if the month in the plot does not have 31 days in it (i.e.; use 28, 29, 30, or 31). 1000-1060: T3$ thru T9$ are the shower and noise long/short names. Note that any day with no showers or noise gets a short label of " "; so that blanks are written above the data. Just change the T-string variables to write something else. Edit the shower and noise long names and short names as the shower and noise names change with time. You may need to remove or add more names as the data changes. "Remove" a line by identifying it to BASIC as a 'REMARK' line. Prefix the start of the line with 'REM '. This leaves it in place so that you may use it latter. For example, if you need lines added between 1060 and 1070, just type at the bottom of the screen below the 'OK' prompt as shown below: 1062 T10$="Geminids": T11$="GEM" 1063 T12$="Cygnids": T13$="CYG" 1064 T14$="Other electrical interferrence": T15$="OEI" If you run out of line numbers between 1060 and 1070, just type RENUM and BASIC will renumber the whole program - read your BASIC manual. Move the legend lines right or left if they get in the way of the data plots. Modify the plots to suit the data, and your individual needs. I suggest you use 3 characters for the noise and shower short names - with the 3-letter shower names in uppercase. See the lists of meteor showers and their 3-letter ID's in the quarterly issues of the AMS Meteor Trails, and the IMO's WGN. ----------------------------------- 11 -------------------------------------- It might take 4-8 hours to do the editing and make the runs the first time you do this. It should take 1-4 hours thereafter; depending on how deep you go into the ploting and analysis. My rule of thumb is that the ploting should continue until the data is shown at it's best. Never change (edit) the raw data to remove noise or 'make a shower stand-out better'. Try vary- ing the pixel integrations (1, 3, 5, or 10) to smooth the noise. Try remov- ing the diurnal counts - use the 29-day average - try a 3 to 9-day average. If there is noise then label it as such, and let the reader decide it's consequences to the real data (the shower). Be honest to yourself and you will be honest to the readers. Retain your professional integrity - it's harder to establish than to lose. If you have lots of trouble and hit a lot of snags, send me a HD disk of your OUT.RAW data file (the big one), and I can help you with it. I can also reduce the data myself and send you the disk back with all the files edited as they should be - ready for you to run, plot, and analyze. A HD disk and 2 pages of paper only requires one first-class postage stamp!