RabbitEars Search Map Enters Public Beta
By Trip Ericson on Sunday, July 21 2019, 21:03 - Site Updates - Permalink
I'm pleased to launch the RabbitEars Search Map into public beta. I mentioned in my previous site update that I wanted to do it, but it stuck in my head and I decided to buckle down, dedicate most of my evenings and weekends to it. It's paid off, and I think it will work out really well.
So here's where to go see it: https://www.rabbitears.info/searchm...
It gives multiple means of choosing a location, the results have a handy link to a page that anonymizes the results, it's a ton faster than the existing search code, and there are nifty maps and diagrams to help understand what is going on in specific situations. Please feel free to provide as much feedback, good and bad, as possible. I want to know what I got right and what I got wrong. If I got things wrong, I can probably adjust them.
Beyond that, there are a few things I want to note about it.
First, if you have questions, please be sure to read the instructions. If they're not clear and/or don't answer your question, please let me know. I want them to hold the answers to all the questions people have, if possible.
Second, the terrain path profiles remain under construction. If at some point you look at it and it looks wrong or doesn't work, wait a few minutes and try again. I'm probably working on it. If it lasts a long time, let me know as I may not have noticed that I broke it, or you may have found a corner case that I need to investigate. But the key thing I'm still working on is trying to make it possible to either adjust the height of the display or, preferably, automate the resizing of the height. It's proving more difficult than I expected, and I decided not to hold the release of the whole tool over that one item.
Third, unlike other things on the site, the underlying database is a snapshot of the RabbitEars database as computed each morning. This was done to help speed things along; by dumping the database once into a simplified format, rather than having to parse all the LMS tables each time a search is run, the speed was drastically improved. Additionally, in the interest of consistency, these rows are stored along with the results for a study, so the information in the result link should remain consistent even if the database changes. The only exception is the repack data column; that is tied to live data because it may provide an insight into what's going on for someone who is confused about the current status of things.
Fourth... I feel like I'm forgetting something. I may update this post in the next few days if I think of more comments I wanted to make.
Finally, I'd like some people to check behind me on some of the math. I'm reasonably confident in it, but having additional eyes on it would make me feel a whole lot better. There are three things, specifically, that I am concerned about.
1) The formula for converting from dBuV/m to dBmV in the unit conversions. (The dBmV is then converted to either dBm or dBuV if necessary--those conversions are fine.) I derived the formula from two other formulas with common elements, but I'm not entirely certain I applied them correctly or even that my result makes sense. I don't do a lot of these types of conversions. My end result was:
20 * LOG10 ( ( POW ( 10, ( s.field / 20 ) ) / ( .021 * s.freq ) ) / 1000 )
Where s.field is the field strength in dBuV/m, and s.freq is the center frequency of the station in question. If someone has a different formula that is more correct, please let me know.
2) The formula for earth bulge as used in the terrain path profiles. I already changed it once.
( ( 1000 ) * ( 1 / ( 2 * 6370 ) ) * ( $dist * ( $terrain_len - $dist ) ) ) / ( 4 / 3 )
Where $dist is the distance from the beginning of the profile, and $terrain_len is the total length of the profile.
3) Also in the terrain path profile, I'm a bit concerned that I am oversimplifying the geometry. I'm just applying the earth bulge formula to the terrain path profile and that's it. Does anyone think it makes a significant difference whether or not I factor in the full geometry at the transmit and receive ends, or is this good enough?
Comments
It would be great if you could provide a search according to address.
The topo mapping is a excellent feature
Address search is right there. See the text immediately beneath the map.
Excellent!
Wow, Trip. EXCELLENT JOB on the "Search Map." Of course, I'm going to give my two cents.
Column 1: Since you have the space, add "(RF)" under the word "Channel." Just in case a few users don't understand the duel listing. BTW, good job on adding all the missing shared channels in the current stations list.
Column 3: Somehow, try to list the correct networks for shared stations. WNBC should be listed as "NBC," not "// WNJU." I believe you told me years ago that this was due to a flaw in your program.
Column 9: Do you need "Direction (Magnetic)" in addition to "Direction (True)?" You can show the deviation up top, near the station plot, to save space. I would rather you use that column for "Path" (LOS, 1 edge, 2 edge, Trop). The narrower column 9 will enable many more people (myself included) to use "Portrait" to print out the reports. On my computer (and another I checked), the table is a tad too wide for portrait mode.
Lastly: Somewhere in your disclaimer (maybe the second sentence) you should say something like "Local conditions (ie. interference, Dx) can affect the results listed above."
Overall: GREAT JOB!
A great tool for finding stations. Only took a couple of minutes to find my way around the app.
Mario and Rick, glad you like it.
Brian,
1) The instructions explain what the number in parentheses is for. Because it's not in a separate column, and all the other parentheses are descriptions of the data and not of a certain piece of it, I don't think it will actually clarify things.
3) On my long-term to-do list is an overhaul of the subchannel code site-wide. That will ultimately resolve this issue, but I doubt there's much I can do about it at this time. I will poke at it a bit anyway and see if I come up with something.
9) Yes. It was a requested feature and took a lot of work. The path information does not come out of TVStudy, so I don't have a way of listing it or it would already be listed. To the extent that it's too wide, what resolution screen are you using? I had considered ditching the "margin" column but got pushback from my closed beta testers. The fields that are probably least necessary are actually city and state, which is pretty much irrelevant, I would think. Thoughts?
Disclaimer) Not going to make a disclaimer on-screen for it, but will put something along those lines in the instructions. Thanks.
Brian,
3) I came up with a work-around.
Trip, nice work.
Surely to be appreciated by everyone interested in OTA at any appreciable distance.
Particularly, like the terrain profile graphics and the 110-mile option.
The terrain profile provides a deeper insight into 2-edge, tropo, etc. It saves much time & effort compared to previous methods of obtaining such information.
The profiles could be very helpful in determining the probability of success for receiver location modifications (height and azimuth).
Thank you.
Good points, Trip. As for the table being too wide to print in portrait mode, that was just on my computer (purchased 2010) and a five year old one at work. I'm planning to buy a new computer this fall, so that might change things for the better. Unfortunately, your work-around in the "Network" column made the table even wider (I should of kept my mouth shut on that;). I guess, when the repack is over, you can convert the last column from "Repack Info" to "Path." As you can probably tell, I liked that column.
Ah. I Just realized that your "Network" and "Community of License" columns are variable width. The longer the entry, the wider the column. Is it possible to give these columns a set width like the others? Would it be so bad if you only see "MIDDLETOWN TOWNS" (for WJLP) in the table? Just a thought.
Brian,
I think you missed my point. The path information is unavailable, so there's no data to add a column for it. If it were available, I'd already have it in the table. Doing it one-off in the terrain path profiles is one thing, but it's computationally intense enough to do it manually that way that I won't put it in the table or it would drag the whole thing to a halt.
All of the columns are technically variable width, just that only the community of license and network columns actually vary in length enough to make it noticeable. I'll think about it a bit, but without knowing what your resolutions are, I have no idea what the target should be or if your screen is worth targeting. Please let me know.
I've made a slight change to the calculation code. If a station is mechanically tilted and has a distorted pattern filed in LMS, and I happen to have the untilted pattern noted on RabbitEars, I'm now using the untilted antenna to calculate the signal strength rather than the tilted antenna. This change should make some of the Los Angeles area stations, as an example, more realistic. KPXN in particular gets a big boost out of it, more closely reflecting their actual signal level.
Great looking tool, Trip. Will compare with my results when I get home, but generally looks accurate in my location south of L.A. I notice the Mag direction is listing values greater than 360. True direction to Mt. Wilson for me is 357.
I didn't know that including a "Path" column would "...drag the whole thing to a halt." Oh well, never mind.
Like I said before, I'm getting a new computer soon. I'll let you know then if I still have my problem. Overall, I think having set widths to each column makes good sense for users who want no surprises when they print out your tables. I'd be curious to know how many people can print out their result tables in portrait mode without having any data cut off on the sides.
Wow. It covers pretty much everything I'd want to know and is blazingly fast.
lotto_pi, thanks for catching that. I've implemented a fix. Newly run studies now check if the magnetic value is greater than or equal to 360 and, if so, subtracts 360 from them. (I had a check for less than 0, but not greater than 360. Go figure.)
Brian, I've not actually tested it, but I know how intensive the code is to do it on the one-off basis in the terrain path profiles. Since TVStudy doesn't output the path, I don't have it available to me any other way, and I'm not even confident that the terrain path profile code for that is 100% correct either.
Doug, glad to hear it! Speed was one of the reasons I did a full rewrite rather than adapting the existing code.
Trip,
Love having a tool using current data. A couple more comments / bug reports. My results here for reference - https://www.rabbitears.info/searchm...
As far as accuracy of the list goes, it's tough to judge in the LA market - most everything comes in booming. My cutoff is right at the bottom of the "fair" range, with only KFLA on RF8 giving me troubles, coming in only about 50% of the time. Oh, and my antenna is high-VHF/UHF only, so I don't see even a hint of signal on RF2 or RF3. KBEH on RF4 comes in well, though, and KVCR on RF5 probably would come in, but it's over the mountain for me, so no go.
I think your intent is for each guest station to be listed immediately below its host station. Well, most of them aren't. And when I click over to the Post-Repack Search List, most of the guest stations aren't even listed.
Also seen on the Post-Repack results list is several stations list their transmitter location (i.e. Mt. Wilson) in the Community of License column.
I notice on the main listings page that KZNO on RF6 is an analog station. Maybe you could list it on the results page here as channel 6-0 to differentiate it from the digital stations.
Can't do a print preview in Firefox. Could be a firewall thing here at work, although Internet Explorer print preview works fine.
Background colors don't print, mostly missing the pink on the right to indicate stations not on the air.
Finally, I have to ask, is there any way you could apply your talents to a replacement for the equally outdated FMFool?
Sincerely,
Yes, I'm commenting again. While playing with your search map, I've noticed that the "Antenna Height Above Ground" field will not accept the digit "5" after clicking the "Go" button. For example, "15" becomes 13, "25" becomes 23, and "50" becomes 49. This is something you may want to check out yourself. Hopefully, it will be an easy fix. Otherwise, everything else I've fiddled with seems to be working like clockwork.
Brian,
Please, comment as much as you want. I'd rather know things are wrong if they are. In this case, it was an issue with the unit conversion code. TVStudy requires meters and I wanted to accept feet, and my conversion code was doing an intval() when converting to meters. I now have it rounding to two decimal places, so the height measurement should look better now on new studies.
lotto_pi,
I'm aware of the channel sharing station issue. It's a problem with the way LMS handles channel sharing stations, and I think I have an idea for a solution but it's a bit convoluted and I've not gotten to trying it yet. And I don't think I have a work-around for the post-repack list, but I'm pondering that too.
The location information is to help differentiate the DTS transmitters for DTS stations. So should KSCI ever build the DTS it proposes, the difference in "community of license" is designed to help you figure out which transmitter was being evaluated on that row rather than having to reverse-engineer it from the azimuth and distance.
Analog facilities are not included in the RabbitEars technical data, so it's pulling the digital records in. Perhaps I should exclude all analog facilities from the "Current" search list.
Print previews work for me, both here (Waterfox, Chrome) and at work (Firefox). Not sure what issue you're having, but I can't replicate it. I believe the lack of background color is a printer-friendly thing that the browsers do, as it's not unique to this page, from what I've observed elsewhere on the site.
I've considered doing an FM mode as well, but I can't even consider it until the FM data is pushed to LMS in full. Although it is present, there are problems with it that make it not usable right now. The bigger problem is that the determination of "Current" versus "Post-Repack" is something that I hand-manage, and I'm not willing to do that hand-managing for FM stations, so I'd have to come up with some alternative.
Lotto_pi, there are already some good FM information websites on the internet. The WTFDA has their North American FM directory, and Radio-Locator not only has a directory, it also has many of the bells and whistles similar to this site, including coverage maps (AM & FM). Unfortunately, they will only let you use their website for a certain amount of time each day.
Don't spread yourself too thin, Trip. Next someone will want you to add AM stations.
In Searchmap.php, when calculating Signal Margin (dB), what are the assumptions for Antenna Gain [in dBi or dBd?] and Total System Noise Figure (presumably Balun/Coax Loss + Tuner Noise Figure)??? FYI: In TVFool, assumption is 0 dBd (or is it 0 dBi) Antenna Gain and [about] 6 dB Total System Noise Figure with zero Loss in Balun/Coax/RF-Splitters....and NO Preamp, like many of us actually use: https://www.tvfool.com/index.php?op...
Brian,
AM I definitely can't do. I don't have the expertise on that.
FM is probably doable but will require different assumptions. I don't know if I'll go through it or not, for the same reason I've never bothered to put together an FM listing--it's a much bigger lift with more stations and harder data to collect. And you're also right that there are other sites that contain at least the information, if not the signal level predictions, that an FM listing would contain. I've pretty much decided that it's not worth my time to do an FM listing; the remaining question is whether it's worth doing an FM version of the search map.
holl_ands,
The signal margin number comes from OET Bulletin 69, pretty much. It uses the same set of assumptions that OET Bulletin 69 uses, then subtracts the threshold value from the calculated field strength value. I'm not sure it's a terribly useful calculation, but others told me it was useful to them even after I explained it, so I left it there.
Alright, with a few exceptions where I'm still working out wrinkles in the data, the Canadian stations are now present in the Search Map, the TV Query, and are now coming from the LMS tables, not the CDBS tables, in the main listings.
As far as said wrinkles go, I am aware of the absence of CHWI-60 on its new channel and CJPC entirely, and the bad contours on CKWS and CBUT. All are on my to-do list today. If you spot anything else missing or in error for the Canadian data, let me know, but know that I'm still working on generating new maps in places where my map data was missing or outdated. I've not touched every record yet.
Okay, a few things.
1) Canadian stations should be mostly sorted out at this point. CJPC is still missing, but CHWI-60 is now in place. Some of the rural translators still need to be touched and I need to clean up a few of the London stations.
2) I've attempted a fix for the channel sharing stations. The code is now much neater and the channel sharing stations should appear correctly. Aesthetically... I don't really like it, but I'm not sure what else I would do with it, exactly. Opinions GREATLY appreciated.
Here I go again with another opinion for you. You're right about the bad aesthetics of the sharing stations in the table. If you could have gotten the first column (Channel) to "squeeze in" the multiple lines of data like you did with columns two thru five, it would have looked great. I would rather you put it back the old way (including the gray for guest stations) if that flaw can't be fixed. Looks count for something.
Brian,
Your opinions are very welcome! I'm not sure what you mean about the first column. Could you send me a screenshot of what you're seeing? This is what I see: https://imgur.com/a/4CoTjvZ
I can't really put it back without going back to the broken method of handling channel sharing stations which didn't really work half the time. But then, I don't know what it is you're asking me for, as it sounds like a minor issue that should be fixable.
I've also been on a tear trying to adjust the network affiliation column so it's not so wide, by adjusting the network affiliation column's content so it doesn't have things that are lengthy. Is that looking better?
The way the table looks in your screen shot is great. For some reason, my table's first column has the same width between lines (the channel numbers) whether they are sharing or not. With more than two stations sharing, the entries look kind of weird. Not a HUGE deal, though. When I get a new computer, the problem might go away.
Thanks for cutting down on the length of the "Network" column. It fits a little better when I print (in portrait). When you have time, you can convert the text in the "CoL" column from ALL CAPS to mixed case. That should save more room when printing. No need to hurry though.
Brian,
Do you mean that it's wrapping the text, and putting the RF channel on a separate line? If so, I've implemented something that I hope will fix it. Let me know if it does. But even if you getting a new computer helps you out, that doesn't mean that other people can't have the same problem, so I'm still interested in trying to fix things that you see even if you think they'll go away with a new machine.
The COL comes that way from the FCC database in most cases. There is code that will automatically mix the case on the fly, but it's not something I've considered because there are definitely cases where you would get an incorrect capitalization that way, such as for KCDT in Coeur d'Alene, Idaho. I'm still weighing ridding myself of the community of license/state columns entirely. It's something TVFool didn't have and I don't know that it really adds anything of value here. I'm also considering replacing the // notation for translators to have the network, and a hover-over showing the station it translates, to make it more useful to people who aren't experts.
Opinions, and not just Brian's, are appreciated.
No, it's not wrapping the text. In the rows of data for shared TV stations, the data rows in columns two through five are squeezed together like in your screenshot, but the data rows in the "Channel" column are not. I wish I knew how to show you what I'm seeing (do you still own a fax machine?;). It's just a minor nuisance.
As for the CoL & state columns, please don't remove them. Just because a number of broadcasters seem to pick their CoL out of a hat, doesn't mean they are all worthless. I'd say about 3/4 of TV stations have CoL's that are accurate when it comes to studio and/or transmitter location.
Lastly (or maybe not), I think your idea for translators is excellent. The "Search Map" tool is for everyone.
Trip,
My results look like your screenshot and I think it's great. Look for an email from me with minor corrections needed to the LA market stations.
Brian,
I wonder if what you see is a result of your computer or a result of your results. If you open my results here -
https://www.rabbitears.info/searchm... do they look good for you?
And thanks for the pointers to the radio search sites. I'll give them a look.
Unfortunately, lotto_pi, when I click on your link, all I'm getting is the Rabbit Ears logo with blank whiteness underneath. I'm beginning to think that it is definitely my computer. Like I said earlier, It's nine years old.
As for the radio websites, I use them myself from time to time. They're neat.
Brian in CT,
I clicked on the link too and got the same results. A bunch of white space underneath the logo.
lotto_pi's link doesn't work because it has a comma at the end of it. Try this:
https://www.rabbitears.info/searchm...
And lotto_pi, I did get your e-mail. Been absolutely slammed with the end of Phase 4 and then went out of town for the weekend. I will get to it.