What's new on findU???


January 28, 2014: Back at it again

When I created findU there was no way to determine the timezone of a user, now there is. wxpage.cgi takes advantage of this Javascript feature and now returns graphs in local time. Let me know if there are any problems. You can also force the timezone, tz=-5 for example is EST.

http://www.findu.com/cgi-bin/wxpage.cgi?call=CW0925&last=24&tz=0

Also I'm starting to work on a display panel

http://www.findu.com/cgi-bin/panel2.cgi?call=K4HG-2&xsize=800


January 5, 2014: Back at it again

Most recent work has been the replacement of the primary server. Thanks to everyone that contributed. The prior server is in my hands (for the first time, I've owned it more than six years and never seen it before) and being cleaned and checked before becoming the new backup server.

Track.cgi work on Google maps, as does the PCSat and ARISS pages.

I haven't done hit counts in a while, last month was over 50 million spread between the three different servers (old primary, new primary, and backup).


April 6, 2013: Back at it

Geez. I can't believe I haven't put any news on here for 8 years! So much has happened in my life findU has gotten the short end of the stick. I was finally forced into action by the deprecation of version 2 of the Google Maps API. So far I have updated find.cgi to work with the latest version of Google Maps. Most of the mapping services I used eight years ago are defunct and need to be migrated to Google maps. The link at the bottom of near.cgi now puts all the station via find.cgi. Next up is to finally get tracks moved.

January 4, 2005: Hit counts and more on Google ads

First, the numbers for December were just shy of 16 million hits.

OK, I admit I'm fascinated by the technology in Google Ads. For the record, even at the initial rate the ads would not pay for more than a small fraction of a new server, and they have fallen off by more than 50% from that initial rate in only 6 days. I suspect it is because Google serves largely the same ads for each user's pages, generic ads of topomaps, aerial photos, humidity devices, and so on. They do not seem to pick up on the town names present on the find page...if they did I'd add a location to the wxpage cgi. I've written them with the suggestion, but as an experiment I added a link to a page containing nothing but the nearest city's name in the title. They generally serve public service ads until they spider the page, but after a variable length of time ads do pop up and fit better than the generic ads. I could put this is a frame, but that would be a lot more invasive. I hope Google looks at the specific needs of my site and adds some sort of support for geo-names...

Also interesting to me is the number of positive responses I've gotten (and the lack of negative ones) on the ad material. The google search box seems to be especially welcome (though in 6 days it has not generated enough for dinner at MacDonalds!).


December 30, 2004: Google ads

This is a trial, for a number of reasons. I do not expect to generate any significant income with this, it is an experiment to see how much Google pays (they won't say, if you are in the program you are sworn to secrecy, all they say is "try it and see"). Second, I want to see what sort of ads Google would place on findU (so far moderately interesting, but I'd like to see more rotation and variety, and would LOVE to see them pick up the lat/lon and place names to pick the ads). Finally, there is the longshot question of whether it can actually generate enough to pay for the next server, this one being a year old already and over 50% loaded. While my retirement has been delayed a year by my ankle fracture, I'd still like to have a hobby that pays for itself. After retirement, it will be mandatory!


December 29, 2004: New York Times!

findU gets a mention in the New York Times (free registration required). Sadly, none of the 45 minute interview I gave the reporter made it into the article. It will be interesting to see if this pumps up the hit counter. I've already had the biggest month ever, just shy of 15 million hits and likely to break 16 million in the next two days...


November 28, 2004: Metric weather graphs

The temp, wind, baro, and rain cgi's have finally been updated to respond to the metric and nautical parameters. There are additional vertical lines at 12 hour and 6 hour increments at smaller time periods. I've also added a new cumulative wind distribution graph to wxpage.cgi. This last feature may not be permanent, let me know what you think.


November 22, 2004: New find.cgi and wxpage.cgi live

Both pages are now using the new layout, let me know if there are any problems...

Also, there is a topographic geo-generating cgi analogous to the aerial photo cgi, valid scale values are 2, 8, and 32.

http://www.findu.com/cgi-bin/plot.cgi?call=*&geo=http://mm.aprs.net/topo.cgi? call=k4hg|scale=2


November 15, 2004: New find layout

I've produced a new layout for the find.cgi. It provides a left link bar showing options for the callsign and external links, and zoom scales for the APRSworld and TerraServer images. Try it at

http://www.findu.com/cgi-bin/find2.cgi?call=k4hg-8


November 14, 2004: TerraServer Images!

Here is a script to grab Terraserver tiles and return an image with a geo file. This works as other geo file cgi's I've done, the cgi returns the geo file, the image is placed in a temp file referenced by the geo file. And as with other geo scripts, this can be used in any cgi with a geo parameter. For example:

http://www.findu.com/cgi-bin/plot.cgi?call=*&geo=http://mm.aprs.net/terra.cgi? call=k4hg|scale=1

The center of the image (and in this case it means the point occurs in the center tile, not at the exact center of the image) is specified wither with a callsign or a lat/lon pair:

http://www.findu.com/cgi-bin/plot.cgi?call=*&geo=http://mm.aprs.net/terra.cgi? lat=24.67|lon=-81.5|scale=64

scale is meters-per-pixel, values accepted by terraserver are 1, 2, 4, 8, 16, 32, and 64.

So far this only returns a 600x600 image, I'll be expanding it to make it work at other sizes.

The tiles are cached on findU, so the first time you load a particular lat/lon and scale, it will take longer (about 8 seconds), after that it only takes a a second to render the map. At some point I'll have to start pruning the cache based on the last time a tile was used, but of course after the first reload it again will be in the cache.

Please give this a good workout and let me know how it works...


November 12, 2004: Updates coming

It has been a long time since I've posted, mostly because I haven't made a lot of changes. That will itself change, I'm laid up with a badly proken ankle, which will require surgery. I'm looking for fresh ideas, if you have any please share them with me.

Also it has been a while since I mentioned the server stats. October set another record (as have most months) with 14,304,641 hits and 631,472 visits. Will it ever end???


February 14, 2004: PocketAPRS maps working

Another flurry of map coding, and I have PocketAPRS maps running on findU:

http://www.findu.com/cgi-bin/plot.cgi?call=*&geo=http://aprsmm.aprs.net/pocketgeo.cgi?map=miami.pdb|range=.2|lat=25.75|lon=-80.25

Some things to clean up in that code, quite a bit of documention, and then I'm on to the librarian interface. There is a SourceForge project now for APRS MM, need to learn how to use SourceForge and then I'll be able to post all this code. There is lots of room for optimization, and both APRSdos and PocketAPRS maps need to draw labels, I'm hoping I'll get some help once I get the stuff up on sourceforge.


February 12, 2004: New Server!

Been a busy afternoon, but I think most things are working on the new server.

For some reason Ploticus isn't installing on the new machine, the only thing it is used for is some of the telemetry cgi's, which are not extensively used. Hopefully I can get this up over the weekend.

I forgot to make sure that the direct entry positions, namely WinLink and email/web were up to date on the backup, and to copy them over to the new server. Any posits from that route in the last three weeks will be lost, at least until I get the old server back from NJ. Sorry, nothing I can do now.

Also, it appears the user database for email and web entry did not update on the backup machine, if you try it and fail, you should try to re-register.

APRS data for the 24 hours the server was down during its trip are in the process of being updated from the backup server, should be complete sometime tonight, filling in the gaps in the weather charts.

Otherwise, I think we are in good shape, let me know of any problems.


February 9, 2004: Map Update

My proposal for the APRS Map Manager (a long term solution to findU's map issue, and with utility throughout APRS) is online here. Work on the prototype system is progressing, I have the code to write a dos map to a temp file and return the geo file working. For example:

http://www1.findu.com/cgi-bin/dosgeo.cgi?map=flsouth.mp&range=5&lat=25&lon=-81

One thing which popped up is a syntax problem, using the dosgeo within the plot cgi doesn't work:

http://www2.findu.com/cgi-bin/plot.cgi?call=k4hg*&geo=http://www1.findu.com/cgi-bin/dosgeo.cgi?map=flsouth.mp&range=5&lat=25&lon=-81

The problem is the parameters to the dosgeo cgi get sent to the plot cgi. Quoting doesn't work, so I've settled on using the vertical bar to separate the parameters in the embedded URL:

http://www2.findu.com/cgi-bin/plot.cgi?call=k4hg*&geo=http://www1.findu.com/cgi-bin/dosgeo.cgi?map=flsouth.mp|range=5|lat=25|lon=-81

The database is being designed now, then will come the pages that access the database.

Help is very much needed, I'd love someone to write routines that can render WinAPRS, palmAPRS, and other maps into png files.


February 7, 2004: MapBlast Problems (Update of 2/5 post)

First a little history. Four years ago when I began findU.com, I emailed MapBlast with examples of what I was doing, and asked for their permission. I never received a response, and since there was no terms of service on their web site prohibiting it, I went ahead and used them. All was well until about 2 years ago, when I noticed terms of service had appeared on their web site. Still, the only thing in violation on findU was the track cgi, which if a geo file was not specified would go the MapBlast and get a map from them to plot on. I removed the offendingcode from track.cgi, and continued to use MapBlast.

About 18 months ago Microsoft announced they would buy Vicinity, the parent company of MapBlast (the deal closed Dec 2002), and about the same time the mapblast.com server switched to encrypted URLs (for an example go to MapQuest.com). It not only would be difficult or impossible to figure the code out, it would also be a violation of the DCMA to try.

Fortunately, the old server on mapblast.com remained up on vicinity.com. I presume this was for legacy apps that could not change to the encrypted URLs, all findU cgis were changed to use this server. I emailed the contact info at vicinity to see if there was any problem, and again got no response. Givene the millions of maps referred via findU.com, it is impossible to believe that they were unaware of my use of them.

Early in 2003, Microsoft changed the domain mapblast.com to point to the MSN map site. Since then, I expected at some point the legay mapblast server would disappear. While it still hasn't disappeared, since Feb 2, 2004 it has been serving most (but not all) maps as error messages. Also, from world maps I've been able to see, it seems they have returned to a US only database. I cannot say if this is temporary or permanent, though certainly after this length of time I'd expect if there was a problem for users of vicinity.com they would have addressed it by now.

For the future of findU, this is bad. The US government has released public domain data for street level maps, and there are sites like APRSworld and the US Census Bureau's TIGER maps, there is no such data or site for the rest of the world. At this point, I feel the only realistic answer is a group of map server combining the US maps from APRSworldwith the custom made APRS maps formats for other areas to produce a means for getting reasonable coverage of the whole world. This will be a gigantic task, and while I can do the findU side of it, I don't have time to do the whole thing. Some say that the mapping engine of APRSworld can do this, I do not know enough about how it works to say either way, I'm hoping someone will take the lead on turning that mapping engine into a world-wide mapping solution.

In the mean time, I have switched the find.cgi and a few of the others to use APRSworld maps, and added links to see street level maps for North America and Europe, and regional maps for the rest of the world from MSN (ironically using the mapblast.com URL!). If anyone has unencrypted URLs that can give maps of other areas, please let me know.

For users outside the US, take a look at the plot cgi on the cgi info page, and the dmap cgi below.

I'm open to any other ideas...


January 13, 2004: More on APRSdos maps

More upgrades to the APRSdos page today. Please, do not send maps! I made the cgi such that it is easy for you to put them on your own server, there are many places where you can get free web space if you do not have it already. This is a list of the maps on the server now, there will not be more!

aprslive.mpfltampao.mpilrfd5.mpmokcity.mpohbooths.mpusaeast.mp
bertha.mpga-atl.mpilsycam3.mpn1qkp-ctnyc.mpoh-mi-wv.mpusa.mp
bummer.mpgakenmtn.mpilwinnco.mpn1qkp-elm.mpPahrump.mpusancen.mp
Cabak_e.mphara.mpla.mpn1qkp-hm.mpsandiego.mpusaseast.mp
CABAK_LV.mpiailinmo.mpLebanon.mpnd-sd-mn.mpsdcty.mpusaswest.mp
Cabak_w.mpilcookco.mpli.mpnelands1.mpsdgo.mpusawest.mp
ca.mpildekco.mpmdannap4.mpnelands2.mpstage1.mpwa-or.mp
caribean.mpildeklb5.mpmdbalto.mpnelands3.mpstage9.mpwashdc.mp
dayton.mpildeksyc.mpmdgburn2.mpnelands4.mptxbaldos.mpworld.mp
europe.mpilleeco.mpmdsouth.mpnelands5.mptxballoon.mpzl2ucxni.mp
flsouth1.mpilnocnty.mpmdstate.mpnelands.mptxstate.mpzl2ucxnz.mp
flsouth.mpilogleco.mpMN-WI-MI.mpneweng.mpusacen.mpzl2ucxsi.mp
The page now handles maplists, which may also be hosted on your server, here is the current (and final) list of maplist files on my server.
calist.txt ilno.txt master1.txt n1qkp.txt nl.txt
dayton.txt mappe.txt master.txt n4neq.txt tx.txt


January 12, 2004: APRSdos maps officially supported!

Some of you may remember the examples I've mentioned in the past of using APRSdos maps within findU, like the Baker-to-Vegas page

http://b2v.findu.com/

There are times when the less detailed maps are helpful for drawing attention to the stations being tracked, so I wanted to make this available in a more general form. I also want this to prepare for the day when MapBlast will finally disappear. Thanks to prodding from Bob, I finally tracked down a bug in the code, so it is now officially released.

http://www.findu.com/cgi-bin/dmap.cgi

All of the maps from javAPRS days are available (the default maps from APRSdos and others contributed over the years) with the suffix .mp because .map has special meaning to web server. I do not want to get into the business of posting maps, so as with geo files, you can host the maps on any server, with this format:

http://www.findu.com/cgi-bin/dmap.cgi?map=http://www2.findu.com/maps/flsouth.mp

These must for now be uncompressed format APRSdos maps. As you may notice with the above example, the default view does not work with all maps, I'll be working on that in the future.

In the future I'll be adding a map list feature (as in javAPRS), and doing some other tweaks. Long range I'm also planning to support other APRS format maps, again as a contigency against the demise of MapBlast.


January 1, 2004: 6 Million hits!

OK, now you guys are scaring me! For the fourth month in a row, web hits jumped by about 500,000. For the month of December the totals were 6,256,910 hits and 4,730,414 page-views. When will it end???


December 28, 2003: New US City location database

The US city names that display on the find cgi (e.g. 19 miles E of Key West, FL) have been updated. The original data came from a file I scavenged off the internet, it included about 500 US cities and 2500 from other countries. There were a lot of problems, and I've been wanting to replace the database. I am now using data from the US Census, with a cutoff of places with more than 7000 inhabitants, 3000 total.

I'd like to replace the worldwide data, and there is a source of the file, but it is huge, and its population files are very incomplete. For example, no VK cities have population data...so the choice is to include everything, which is way, way too big and slow for geographic search, leave out entire countries, obviously not acceptable, or edit manually, which is way to time consuming. If anyone knoes of a better world city database, please let me know...


November 25, 2003: Telemetry cgis added

I have discussed the telemetry cgi's at times on the APRS sig, but never documented them, because tele.cgi is rather lame, and tele1.cgi and tele2.cgi would at times bog down the system badly, so I did not want to encourage their use. Today I figured out the problem... turns out that it was the combination of improperly formatted telemetry packets, and a bug in ploticus (How's that for avoiding blame!). I've re-written the cgis to avoid this bug, so they are now officially released. Read about them on the cgi.html page (I don't feel like re-tryping the whole thing).

http://www.findu.com/cgi-bin/tele-list.cgi


November 9, 2003: Units on track.cgi

Add track cgi to the list...

http://www.findu.com/cgi-bin/track.cgi?call=k4hg-8&units=nautical

http://www.findu.com/cgi-bin/track.cgi?call=k4hg-8&units=metric


November 8, 2003: Units on wx.cgi

The wx cgi now supports units, like wxpage and find.

http://www.findu.com/cgi-bin/wx.cgi?call=k4hg&units=nautical

http://www.findu.com/cgi-bin/wx.cgi?call=k4hg&units=metric


November 2, 2003: Units on find.cgi and wxpage.cgi

One of the most requested features on findU has been support for units other than English. I've been holding off on this until I was able to add this to all affected cgis, however the weather graph cgis are quit difficult, so I thought I might as well do the most popular ones first. Default is still english units (this is actually a change, previously units were left as APRS native, which for speed was knots). Other supported units are nautical and metric.

http://www.findu.com/cgi-bin/find.cgi?call=k4hg-8&units=nautical

http://www.findu.com/cgi-bin/find.cgi?call=k4hg-8&units=metric

http://www.findu.com/cgi-bin/wxpage.cgi?call=k4hg&units=nautical

http://www.findu.com/cgi-bin/wxpage.cgi?call=k4hg&units=metric


November 1, 2003: Over 5 Million Hits!

Looking over the old news, 19 months ago I was bragging about 2 million hits...well, in October findU had 5.05 million, with 3.9 million page views! Thanks for your support!


November 1, 2003: Error pages

Obviously I didn't do well with updating the page more often!

I've been watching the log of my parser for almost 4 years now (geez, is findU really that old???), it contains messages when the parser detects a packet error. I have fretted for a long time about whether to release the information. I went ahead and created a page to display it, and after due consideration (and seeing the same callsigns appearing day after day, perhaps meaning that people aren't aware of their errors), I decided to go ahead.

http://www.findu.com/cgi-bin/errors.cgi

default is 6 hours, you can change it with the last parameter, e.g. for 24 hours:

http://www.findu.com/cgi-bin/errors.cgi?last=24

The page does not display callsigns with a single error, as there are many of these caused by things like mangled packets and unitialized GPSs, my target is persistant errors.

I've written software for too long to ever claim anything I've written since "Hello World!" is bug-free, and after all, these error messages were included specifically so I could hunt for bugs in my code. That said, I am concerned that I will suddenly get a mailbox full of messages complaining that my parser is busted. Please treat this as a chance to learn more about the protocol.

My parser is rather strict, packets that appear fine in some programs will not parse in mine, a side effect of the Perl language and regular expressions...for example, somewhat simplified code for parsing a lat/lon/icon set is:

m/(\d\d\d\d\.\d\d)([NS])(.)(\d\d\d\d\d\.\d\d)([EW])(.)/

after this executes, $1 is lat, $2 is N or S, $3 is symbol table/overlay, $4 is lon, $5 is E or W, and $6 is the symbol. If each and every condition set for in the above regular expression is not matched, then the packet is rejected. This means, for example, using n instead of N for north will reject the packet...as it should IMHO, because the spec clearly states it is N. Other code may implement the parsing differently. For example, in javAPRS, I simply tested for 'S' in the NS position, and negated the latitude if present, which means an 'n' would parse correctly (though an 's' would not). I suspect others take similar shortcuts in their parsers, being rigorous in a language without regex's can be painful, and writing an APRS parser is already plenty painful!

So, if you see something on the page that you think is legal, please be absolutely certain before complaining to me about a bug in my program. I have included the link to the APRS spec on the page, please get the spec and go byte by byte looking for the problem, don't just look at it with another program. Like all the APRS authors, I've had to do manual decomposition hundreds of times, so I just want to spread the fun around!


January 12, 2003: Server Location Changes

Sorry for the long time without updating the page, I'll try to do better. Of course, the big news is the change in server location for findU. The DSL line that has run findU for the last three years is going away, because DirectTV DSL is closing down operations. I turned off most access to that server on January 2, though it still handles mail. The remainder of the findU.com operations (as well as aprs.net, aprs.org, ariss.net, and some others) are hosted on the findU backup server, paid for by the collection Guy Story made among APRS users early last year. Shortly the primary server will be moved to a new hosting site, and the load will be split between the two machines. While the primary server is in transit, findu.com email (including emailed position reports) will be unavailable.

Click here for "Older New" things!

email questions and comments to Steve Dimse k4hg@tapr.org.
APRS is a registered trademark of APRS Software and Bob Bruninga, WB4APR.