Cache Sizes - Feedback Sought

About the Opencaching Site
GOF
Posts:59
Joined:Fri Sep 10, 2010 8:08 pm
Re: Cache Sizes - Feedback Sought

Post by GOF » Fri Apr 20, 2012 2:17 pm

I have a sneaking suspicion that soon there will be a fair number of new opportunities to log BIT caches in our area.

User avatar
TermiteHunter
Site Admin
Posts:1119
Joined:Sun Aug 29, 2010 7:12 pm

Re: Cache Sizes - Feedback Sought

Post by TermiteHunter » Fri Apr 20, 2012 3:35 pm

Back to the size issue of this thread...
Since most of my caches are created rather than conventional containers I use this as a general idea for cache size.

Micro size of a 35 mm film can or smaller
Small leas than 1/2 the size of a typical amno can
Regular app the size of an ammo can
Large 1&1/2 the size of an ammo can

The bison tube, 35 mm film can and the regular ammo can are the only real standard sizes. Every thing else varies too widely to be used as a standard.

On bit caches... I would like to place some but am having difficulty with selecting a location. I don't want to have one dangeling from something or stuck on the back of a sign like graffiti stickers



Any strange spellings or choices of words are the fault of autocorrect

User avatar
DudleyGrunt
Site Admin
Posts:2038
Joined:Wed Aug 18, 2010 1:27 pm
Location:Jessup, MD
Contact:

Re: Cache Sizes - Feedback Sought

Post by DudleyGrunt » Fri Apr 20, 2012 10:07 pm

Thanks for all the feedback, guys!
Dave, OCNA Team Member
For the smiles, not the smilies.
Maryland Geocaching Society

Image Image

User avatar
DudleyGrunt
Site Admin
Posts:2038
Joined:Wed Aug 18, 2010 1:27 pm
Location:Jessup, MD
Contact:

Re: Cache Sizes - Wiki Updated

Post by DudleyGrunt » Tue Jun 12, 2012 9:08 am

iJeep has updated the Cache Parameters wiki page to reflect updated size descriptions.
Cache size

Cache sizes for all caches that have a physical container.
  • Micro - includes "nano", 35 mm film canister, bison tubes, etc., typically containing only a logbook
    Small - decon container, sandwich-sized Tupperware-style container or similar, holds trade items as well as a logbook
    Regular - standard lock-n-lock or similar containers
    Large - larger lock-n-lock style containers or ammo cans
    Extra Large - 5 gallon bucket or larger
FYI, he also updated the Log Password info, slightly, to make remove the discouragement against using them on physical caches.
Log password

A password is required to log the cache found. See the specific cache description for instructions from the hider for obtaining the password. Passwords are required for BITcaches(TM) and particularly useful for virtuals, but can also be used with other cache types. When hiding a cache that will not require a password, leave this field blank. Log Passwords are not case sensitive.
Essentially, the sentence, "Passwords are generally intended for virtual and BITcaches(TM) only, and not recommended to be used for other cache types," was removed.

I use them on some physical caches and know that others find it useful for reducing "arm-chair logging".
Dave, OCNA Team Member
For the smiles, not the smilies.
Maryland Geocaching Society

Image Image

User avatar
KnowsOpie
Posts:248
Joined:Sat Dec 11, 2010 8:39 pm

Re: Cache Sizes - Feedback Sought

Post by KnowsOpie » Mon Dec 19, 2016 6:04 pm

OMG, like this thread is so old! :D

I'm pondering BIT caches and nanos. I never liked Munzee crap because it's pasted to public property and not hidden. I guess almost all geocachers have or use smartphones, and QR codes are common now, so would BIT caches be a good idea? Can you just stuff one in a poly tube, hide it at an interesting location, and call that a BIT cache?

What if there is already a published geocache listed on another site nearby? I don't think that the two would conflict, the BIT cache thingy pretty much explains what it is.
Nutty as a Squirrel Turd

User avatar
TermiteHunter
Site Admin
Posts:1119
Joined:Sun Aug 29, 2010 7:12 pm

Re: Cache Sizes - Feedback Sought

Post by TermiteHunter » Mon Dec 19, 2016 11:34 pm

KnowsOpie wrote:OMG, like this thread is so old! :D

I'm pondering BIT caches and nanos. I never liked Munzee crap because it's pasted to public property and not hidden. I guess almost all geocachers have or use smartphones, and QR codes are common now, so would BIT caches be a good idea? Can you just stuff one in a poly tube, hide it at an interesting location, and call that a BIT cache?
Stuff it, cram it, laminate it, fold it, spindle it, zip tie it, tape it. The scanned code delivers you to the cache page and then requires use of the passphrase printed on the BIT to log. Alternately you can pull up the cache page (in an app or on the interwebs) without scanning the code but you would still need the passphrase from the BIT in order to log.
What if there is already a published geocache listed on another site nearby? I don't think that the two would conflict, the BIT cache thingy pretty much explains what it is.
They will not conflict. A great option when the space is occupied by another cache. With no on site log to sign it is not a typical cache. The different logging technique makes all the difference here.

User avatar
KnowsOpie
Posts:248
Joined:Sat Dec 11, 2010 8:39 pm

Re: Cache Sizes - Feedback Sought

Post by KnowsOpie » Tue Dec 20, 2016 12:16 am

I guess I confused them with Munzee and compared them with nanos that are log only crap. :? So nothing would be wrong with attaching one to a small cache, like taping them inside a dry box or an altoids tin then?
Nutty as a Squirrel Turd

Bon Echo
Site Admin
Posts:374
Joined:Mon Feb 11, 2013 7:39 pm

Re: Cache Sizes - Feedback Sought

Post by Bon Echo » Tue Dec 20, 2016 12:22 pm

KnowsOpie wrote:I guess I confused them with Munzee and compared them with nanos that are log only crap. :? So nothing would be wrong with attaching one to a small cache, like taping them inside a dry box or an altoids tin then?
Please don't cram one into a nano. If a cache is small enough to be swallowed, it should be considered a hazard to children and shouldn't be allowed. Seriously, I could get arrested for trying to bring Kinder Surprise Eggs into the USA but I can stick tiny little magnetic things to places where children play? Putting it in a small cache is a good idea though.

I have a groundspeak cache that is a clear (no paint) PB jar hidden in a retaining wall. I taped a BIT cache to the inside of the container so it can be seen through the plastic. The BIT cache is listed separately from the Groundspeak cache. No one has logged the BIT cache yet but it's there.

I've tried a few things with BIT caches. I have a few that are completely visible and a few that are not. I'm with you, I don't like seeing munzees plastered on wherever and I won't do it with BIT caches. My personal opinion on BIT cache is that you should be able to scan the QR code and read the log password without having to open anything. Otherwise you might aw well just make it a traditional and sigh the logbook. BTW, with the BIT cache the QR code only brings you to the cache page - the finder still needs to enter in the log password and still has to add a narrative (even if it's only TFTC). of course you could use any online QR generator to make a QR code for any cache page. It really doesn't help much though - if someone is using their smartphone to navigate to a cache, they are already "on the cache page" or can log the find using whatever app. But I don't log in the field (no data). what says you Mr.Yuck or others? Do you scan the QR codes on BIT caches to log them in the field?
Most of my "stand-along" BIT caches are attached to things with zip-ties, so there is no permanent damage. I have one stapled to the underside of a wooden footbridge and thought of doing the same to the underside of a picnic table but I don't really like picnic table hides. I'm experimenting with "containers" for BIT caches but decided they are actually as difficult to hide as a traditional, so I might as well stick with traditional caches.

User avatar
TermiteHunter
Site Admin
Posts:1119
Joined:Sun Aug 29, 2010 7:12 pm

Re: Cache Sizes - Feedback Sought

Post by TermiteHunter » Tue Dec 20, 2016 12:56 pm

They would work well inside a container. The container will give some variety to the hide type and possible concealment options while protecting the BIT.

The only drawback I see would occur if this was placed too near an exising cache. If the seeker was looking for the other cache and ran across this container with a BIT and no log they may not scan the BIT and just add a log. Then the nearby cache gets a log online "Hey, I found your cache but there was no log inside, I added one for you TFTC" While the BIT gets no log of the find.

On the other hand, if they take a second to read the BIT info and/or do scan it, we may have gained a new member.

While typing this Bon Echo made his response.

There are a few more that have been added to GS caches I assume. I have added them to a couple OCNA ones as well. Usually moving caches as an introduction. I too have placed them on the inside of clear containers so that they can be seen from outside (along with a regular BIT inside)

Sure if placed in a container it is pretty much the same as a traditional cache in most respects with the addition of the password.
I rather like the idea of putting them in containers. It protects the BIT far better than a laminated tag zip tied and hanging in the open air. Found too many that were placed like this where all I find is the zip tie (or a couple where previous ones were replaced)

You could add a traditional log that would let you know who found it but failed to log online. Might be an interesting experiment. Or list both the traditional and the BIT at a single location. Expect that the traditional will get more logs than the BIT just because it is different or they leave and forget the passphrase.
if someone is using their smartphone to navigate to a cache, they are already "on the cache page" or can log the find using whatever app. But I don't log in the field (no data). what says you Mr.Yuck or others? Do you scan the QR codes on BIT caches to log them in the field?
Most of the time when seeking a BIT I have an app open (c:geo), Find the BIT, take notice of the password, log from the app. Occasionally I will recall or target a specific BIT that I know the general location of (usually urban) and will simply stop by. Then I will either scan the code to open the cache page in a browser and log from there or decide to use an app to pull up the nearest cache (which is the BIT) and log from there. I find it easier to log from the app since it is designed to fit the screen and navigating to the log entry is quicker.

I don't remember for sure but I think most phones allow you to select how to open the scanned code for a BIT. "What do you want to open this with? c:geo or the web browser" depending on your settings.
Scanning the code is probably more likely to be used by someone not familiar with OCNA and BITs and may be the first time they become aware of OCNA

Bon Echo
Site Admin
Posts:374
Joined:Mon Feb 11, 2013 7:39 pm

Re: Cache Sizes - Feedback Sought

Post by Bon Echo » Tue Dec 20, 2016 1:25 pm

TermiteHunter wrote: Scanning the code is probably more likely to be used by someone not familiar with OCNA and BITs and may be the first time they become aware of OCNA
Right, and that is worth something. the first BIT I placed was purposefully set to be very visible. Chainlink fence beside a busy sidewalk at eye level. It's been nearly two years, I see it a couple times a week as I drive by. The cache page has had 2012 visitors but I have no idea if any of those visits were a result of scanning the QR code (and would LOVE to know if that was even possible to track). The number of views is not substantially different from any of my other caches of the same "vintage"
Who is looking at these caches? That is, aside from Google and Yahoo bots? It's like an average of 100 visits per month.Then you have waymarks which often have 0 or 1 visit in 5 years (but the "visit" counter on waymarking is likely as broken as many other features on that site).
Maybe I should add one of those "flag counters" to my cache pages.

Post Reply