about.htm


Animated Flags Courtesy of: Animation Factory

      ======================================================
                  WTS (WHERE'S THAT STATION) V. 1.0
      ======================================================

	December 24, 2000

	GREETINGS:

	Eric Force, WTS's programmer, chief bottle washer and sanitary engineer
	here. WTS represents my first stab at programming in WinRADIO's RBASIC
	environment. I hope you enjoy using the program as much as I did
	programming it - I almost feel guilty since I DID have so much fun using
	RBASIC.

	Also a ton of thanks to the folks at WinRADIO for creating RBASIC in such
	a way that it could be used with WinRADIO running in DEMO mode. Once I've
	saved up my pennies, I hope to purchase a working WinRADIO for actual use
	with WTS. In the mean time, WTS fills the need while listening to my
	(sigh) standard receiver.

	INSTALLATION and RUNNING

	For WTS to work, it needs two basic things: YOUR geographical coordinates
	and a home for it's databases and auxillary files. If you don't know what
	your Latitude and Longitude is, point your Web browser to:

	Lat/Lon Resources

	for links to several online resources. Remember, WTS requires DECIMAL
	degrees for the values. Be sure to retain the negative (-) sign(s) for
	your particular location. i.e. if your Longitude is West, then the value
	will be negative. My coordinates look like:

	 40.97845 (North Latitude) North = Positive (+), South =Negative (-) Values
	-78.90939 (West Longitude  East = Positive (+),  West = Negative (-) Values

	Next, you'll need to put all the files included in the distribution file
	(WTS10.ZIP) in a specific directory (folder). In my case, I found it easiest
	to create a new folder on my C: drive called WTSRB i.e.

		C:\WTSRB

	and stored all files EXCEPT the actual RBASIC code (WTS10.rbp) which I put
	with the other RBASIC files were placed during RBASIC's installation, In my
	case:

		C:\Program Files\WiNRADIO\RBASIC programs

	Once you have everything tucked away, then load WTS10.rbp and read the comments
	at the beginning of the program code. It will guide you through the changes that
	need to be made before running the program.

	Since WTS is a "work in progress" I hope to enhance it significantly over
	the coming months. I've noted some of the potential enhancements I'm
	thinking about in the final paragraphs of this note.

	COPYRIGHT NOTICE:

	I hereby place "WTS10.rbp" in the PUBLIC DOMAIN. Feel free to do anything
	you want with the RBASIC code.

	HOW WTS CAME TO BE:

	While most of my radio activities are SWL and Scanning related, I also
	enjoy MW DXing. (Long Range reception of AM Broadcast Stations in the
	Medium Wave, 540 - 1705 KHz frequency range). To make that activity more
	enjoyable, I wanted an easy way to obtain specific information about a
	given station relative to my QTH (location). In particular, the station's
	geographical location and how far away it was. While that information CAN
	be obtained via the Web, it's quite time consuming and requires a lot of
	manual input plus jumping from one site to another to get "everything".
	And, of course, it assumes the 'net will cooperate by permitting access
	to the Web sites in the first place. No, I wanted something that would
	provide the needed information "instantly" and independant of the Web.
	WTS seemed a logical to handle it using the FCC's (Federal Communications
	Commission) publically available databases as the raw material. So what,
	specifically, does WTS do? Read on.

	BASIC FUNCTIONALLITY:

	WTS v1.0 uses "home brewed" databases (extracted data from the FCC's main
	AM Broadcast databases) to provide the following information upon the
	user's input of a Station ID: (e.g WPEN, WCAU, KYW, etc.)

	Main RBASIC Console Display after query is initiated:

	1> Transmitting Frequency, in KHz

	2> Geographical location of Station (City, State/Province, Country)

	3> Distance from user's QTH to the transmitter in Statute Miles, Nautical
	   miles and Kilometers.

	4> Latitude and Longitude of station.

	5> Relative bearing from the user's QTH to the Station in approximate
	   compass points (North, NNE, ENE, East, etc) and decimal degrees.

	6> info.htm URL for you to view in your Web browser (info.htm will be in
	   the same directory as you specify as your BaseFile$ in the code. Your
	   "Station Web Page"

	Additional Query Information via Web Page:

	Yes, I said Web page. In addition to outputting information to your
	RBASIC console, WTS also creates a unique Web Page (stored on your PC)
	each time a station's ID is entered and retrieved. It's called info.htm.
	This HTML file is overwritten each time a new station is found to
	conserve disk space but an option permits the information to be saved
	(if desired) to a separate HTML file. (e.g. KZZR.htm) A sample info.htm
	and KZZR.htm is included with the distribution of WTS so log on to the
	net, fire up your Web browser and take a peek. info.htm will be located in:

	for example, C:\WTSRB if that's the folder you created.

	When viewing info.htm in your Web browser, you'll find links to online
	resources for even more information. Some of the things currently
	implemented are: (Naturally, you need to be "online" for the links to
	work)

	1> Icons at top of page: Links to the home pages of WinRADIO and RBASIC
	   plus a link to my WTS page (Being built now) where updates and other
	   useful info can be obtained. The site should be functional by the
	   middle of January, 2001.

	2> A link that preloads the U.S. Census Bureau's Tiger Map resource with
	   specific information about the station just retrived. If you click
	   this link, a full screen map of the United States will be displayed
	   with markers indicating yours and the Station's location. It functions
	   just as if you had visited the site but eliminates the TEDIOUS work
	   of entering specific bits of information to get the map to display
	   properly - at least with respect to the location markers.

	3> A link to RadioInfo.com where you should be able to obtain contact
	   information (Phone numbers, mailing address, etc) for the station in
	   question. This is particularly handy if following up with a QSL
	   request. Unfortunately, they appear to have only United States'
	   stations in their database. If you know of any other "QSL" type
	   resources, please let me know.

	4> A link to the FCC's AM Broadcast Station Lookup resource. It's also
	   preloaded by WTS so you should be taken to the OUTPUT side of the
	   lookup where detailed (Technical) information about the station can
	   be viewed and/or printed. There you'll find information about the
	   station's license, antenna system, operating parameters, etc.

	5> A host of other resource links you should find handy.

	SOME GENERAL RBASIC COMMENTS

	While RBASIC is indeed a robust and EXTREMELY easy to learn language it
	can't do some things as well as other languages - if it did, I can
	guarantee the steeper learning curve (because of increased complexity)
	would probably drive most casual programmers (like myself) away. I'm also
	pretty confident it couldn't be provided for FREE! That's not to down
	RBASIC in any way. It is ONE amazing application and my hat's off to the
	folks at WinRADIO for making it available to us. The potential is there.
	All you need to do is pick up the ball and run with it. If you've haven't
	already, you should really try RBASIC. With few exceptions, you should be
	able to easily program just about anything you need with little difficulty.
	If I can, you can! And, best of all? YOU ARE IN CONTROL! You can create
	and change your programs easily to suit *YOUR* needs - NOT what some other
	programmer thinks is best for you.

	Having said that, WTS is an example of an application that I normally
	wouldn't use RBASIC for since, by it's very nature, it has to process
	(potentially) a fairly large number of records - hopefully, in a manner
	that will yield results quickly. That's usually not a good scenerio for
	an "Interpreted" program limited to sequential TEXT searching.

	Regardless, I decided to give RBASIC a try for WTS for two reasons: 1> I
	wanted to jump into the competition for a WinRADIO (heck, there's no
	chance of winning if you don't submit an entry) and 2> RBASIC seemed a
	great way to share the WTS programming with others on a common, (and
	FREE) easily learned platform. I can happily report that RBASIC was up to
	the task and WTS.rbt v1.0 is now a reality. By way of example, (albeit,
	certainly not the world's best example of programming) I also hoped the
	WTS code might help you in writing your own RBASIC database type
	applications.

	It also goes to prove just how easy RBASIC is to learn and use. I had
	never heard of RBASIC until late (about 11 PM) December 19, 2000 when I
	visited the WinRADIO site to drool over their products. It's now
	about 8 PM on December 23 and I'm just about through with this initial
	release of WTS. I should also note that a SUBSTANTIAL amount of the
	overall time was spent in writing things like this READ1ST file and
	building a station database that would be compatible with the RBASIC
	program - things that had nothing to do with the actual RBASIC coding!

	FUTURE ENHANCEMENTS

	Here are some of the things I'm thinking of working on to enhance WTS.
	Note: The order in which these ideas/concepts appear are not necessarily
	the order in which they will be worked on. If you would like to work on
	any specific items(s), please let me know so we can coordinate our
	efforts. As with anything like this, the more interest there appears to
	be the more incentive there is for me to "make time to do it". :-)

	- Ability to import raw data from the FCC public databases and create
	  suitable db files for WTS. For the time being, I hope to create
	  updated databases and post them for download at the WTS "support"
	  site. It will be the end of January, 2001 (at the earliest) before
	  I can work on that one though.

	- Ability to determine the LOCAL station time for the station being
	  queried. This will be a tough nut to crack given how times zones are
	  designated. They tend to be political boundries rather than actual
	  geographic. If one could count on 15 degrees longitude being one time
	  zone, it would be a piece of cake.

	- Power figures for stations - to automatically reflect whether value
	  displayed is daytime, nighttime or critical hours value. Above timezone
	  enhancement would help with this one. An alternative might be to pull
	  the raw numbers from the FCC database and just display all power figures
	  as they apply to a particular station.

	- Include station genre (i.e. Format such as News, Talk, etc). Another
	  tough nut to crack given the research needed to be done - at least for
	  one individual. Any volunteers to help? Ideas on how to obtain that
	  information.

	- Ability to include QSL information in query - i.e. Station contact
	  information including phone numbers and mailing addresses. Note: The
	  FCC database contains contact information, including mailing addresses
	  *BUT* in for the party(s) that holds the station license, NOT necessarily
	  the physical location the station. An exmple might be: a station might
	  be located and transmitting from Philadelphia, PA but the FCC contact
	  info would show the licensee located in Northern New Jersey.

	- Ability to do searches based on: frequency, bearing, genre, etc. The
	  "stations on same general bearing" is an interesting concept which I've
	  used manually to DX when the atmospheric conditions are condusive. For
	  example, once I find a distant station, I note the bearing then look
	  for other stations (on different frequencies) along the same bearing
	  line and/or same general location. The premise is that the signals from
	  the same general area will tend to bounce off the ionosphere at similar
	  angles which permit reception at my QTH if I'm quick enough to be able
	  to find stations in the same general area before the atmospheric
	  conditions change. Since finding those stations "manually" is a
	  relatively slow process, I haven't been able to prove one way or another
	  whether that premise is valid. I have snagged a few stations that way
	  so I'm optimistic that an automated procedured would be worth the
	  programming effort.

	- Ability to calculate station antenna patterns. Many stations switch to
	  directional broadcasting or change their direction at different times
	  of their broadcast cycle. Basically, having this type of information
	  would permit pre-screening of stations that you wouldn't have a snow
	  balls chance in hades of receiving. For example, you are located on the
	  East coast of the U.S. and find (from the preceeding potential enhance-
	  ment that station XYZ lies in the same general area as the station you
	  just received - you use your "on the same bearing" function and find
	  XYZ should be a good potential target. By using THIS enhancement,
	  you find that XYZ switches to reduced power and a highly focused to the
	  WEST pattern - unless the laws of physics change, forget about that one.
	  Any Broadcast Engineers out there? For me, the required calculations
	  look pretty daunting. :-)

	- A type of "soundex" search. *MY* ears aren't what they used to be so
	  at times, I have difficulty in knowing whether I heard say, WECZ or was
	  it WZCE or perhaps WCEZ or was it ... you get the idea. This enhancement
	  would provide a display of ALL stations with ID letters that sound
	  similar - as I'm writing this, I think included should be a filter that
	  provides ONLY those stations licensed for the SAME frequency that you're
	  currently tuned to.

	- Ability to create links (on the info.htm page) directly to stations
	  with a web presence. Another LARGE database and nightmare to research,
	  collect and assemble data and then ... long term, maintain for a single
	  individual with limited time and resources. Even WITH lots of time and
	  resources, it would still be a "pill" to do.

	- Automatic generation of a QSL letter as a runtime option.

	- Automatic logging of received stations as a runtime option.

	- Direct "Click On" links to ONLINE HTML pages. This has more to do
	  with possible enhancements of RBASIC rather than end user programming.
	  i.e. TCP/IP support would need to be built in to RBASIC. TCP/IP
	  (protocols) is another ball game in itself so doubtful that RBASIC
	  would ever directly support it - but you never know.

	- ??? ... Probably tons of other things - email me with your ideas.

	Well, I've flapped my gums enough for Christmas Eve ... gotta get ready for
	Santa so thanks for your interest. I hope you enjoy WTS10.

	Best Regards!

	Eric Force
	December 24, 2000
	Punxsutawney, Pennsylvania, USA