Olaf Goette

Ok, we didn’t celebrated our 10th one. Maybe because About Lasers has two big problems: The first is that I’ve finished it (and even the listing) mid of April 2016 and I’m still (end of November 2016) looking for the right place to hide. And the second is that you didn’t built it up to now.

But our 20th one should be something very special. That’s real a must! Any ideas are welcome. (Thinking is still possible when arms became too short because of Thanksgiving dishes… - Only Tim will understand…)

Update: 11/28/2016

Some days ago you came up with an idea similar to Reverse GPS. The cacher has to run to a quite near location or to walk to a much more far one. His progress should be checked by a GPS module inside the box, the cacher has to keep. My concern was that like with Reverse GPS the cacher has to go back to the station, where he picked the box. So this cache would be quite similar to Reverse GPS. 

But I wouldn’t be your friend, if I would have just skipped your idea. Here’s now a modification of your idea:

• The cache has 2 stations
• both are with a RTC (real time clock)
• The cacher has to find the first one, putting his batteries in and he’ll receive 
  • a hint, where to find the second one 
  • a time limit to do so and
  • a code, he has to key into the 2nd station
• He needs to find the 2nd one and to key in the code.

The trick is that the code, the first station is offering, has a hidden time stamp. So the second station is able to investigate, if the cacher did it in time or not.

I’ll post at Geocache Inventors group on Facebook (Did I already said, I’m hating FB and MZ in special? Yes, I think, I did!), asking them about the idea… I’m already so enthusiastic that I’ve just ordered some RTC… Let my bank account cry! I’m deaf and Christmas is near!

Update 11/29/2016

It seems my friend is still keen to give the cacher the choice to make a short but fast run to the next station or a long but slow one. He asked, if it’s possible, to track, which way (the short or the long one) has taken. I discussed with my colleague this morning and our first answer was „No!“. We thought, if we want to track the distance, the cacher must take a box with a GPS inside with him. The big disadvantage would be that at the end the cacher has to bring back the GPS box to station 1.

I went to cold (21°F at 6:30 am) outside for a cigarette and a flash stroke through my old (but as you said quit big) brain:

• Let’s assume, station 1 will show 2 codes (not readable, because decrypted)
  • 1st one (code 1) for the short distance, must be keyed into station 2 within e.g. 10 minutes
  • 2nd one (code 2) for the long distance, must be keyed into station 2 within e.g. 60 minutes
• If the cacher decides for the short one, 
  • he just has to find the 2nd station and to key in code 1.
• If the cacher decides for the long one, 
  • he needs at least to find one intermediate station, 
  • where a number is hidden.
  • He needs to calculate the given code 2 with this number to make code 2 a valid one
  • Now he needs to go to to station 2 and to key in the „modified“ code 2.

What do you think about???

Update 11/30/2016 - A lot of mathematics - starting with Excel

I used some time in the evening to start designing the logic. It became more complicated, as I initially thought. So I started with Excel:

If you don’t want to understand precisely how it will work (shame on you!), you can skip this brown part.

The box on the top is containing some constants like how many seconds does a minute have and how many minutes an hour. In addition there’re also the time targets for the short and the long run. Why not only maximum values? I want to avoid 2 cachers coming, finding the 2nd station too late. They’re equipped with mobile phones (or walks talkies) and one is going back to station 1, starting again and is phoning the code to the second cacher, who’s waiting at station 2.

The middle box is showing all the calculations done at station 1. Cell G11 is simulating the decision of the cacher to go the short or the long way.

Line 12 is showing the actual time at station 1 (it’s handy 24 hours h-m-s format!). So the time is set to 08:10:05 (light blue cells). This time converted to seconds giving 29,405 ( 8 * 60 * 60 + 10 * 60 + 5). Because I’ll „shuffle“ the figures later to decrypt them, I need to ensure that the figure has the same length every time. So I’m adding 100,000 to it and the result is 129,405 (G16). Cell H16 seems to show the same, but here the number is converted to text! 

Line 17 is showing, how the digits will be shuffled. The forth digit will become the fist one, the 3rd the 2nd and so on.

Line 18 is showing the decrypted time stamp of station 1.

The bottom box is showing, what’s going on at station 2.

Not shown: At the beginning the cacher will have to key in the „proof value“ from the intermediate station, if he has chosen the long run. If he did the short run, he will just key in a „0“. After that he has to key in the code, given at station 1 (Line 21). Line 22 is showing how the code must be shuffled again to be encrypted. This is done in Line 23. In Line 24 the 100,000 are subtracted and you can see, that the time stamp was sucessfully decrypted. 

With some operations in lines 25 and 26 the time stamp is converted back to h-m-s format in line 27.

Based on the decision whether the short or the long run was taken (G11), lines 29 and 30 are defining the valid time interval. This figures are meaning, that the cacher has to reach the station 2 max. 90 minutes after he got the code at station 1, but not earlier than 45 minutes after that.

Lines 31 - 36 are showing, how the 2 values (G33 and G36) are calculated. The actual time at station 2 must be between this both values (line 38).

Rough description: In G11 you’ll see that the chacher will use the long way. C12, D12 and E12 are showing the actual time at station 1 and G18 is showing the decrypted time stamp. C27, D27 and E27 are showing that station 2 has encrypted the time stamp successfully  Lines 29 and 30 are showing the maximum time difference and the minimum one (the reason for the minimum one I explained above!). Line 33 is showing the maximum time, until the code must be keyed into station 2 in h-m-s format and in pure seconds too. Line 36 is showing the same for the minimum time also. Lines 37 and 38 are showing the conditions as they will be done later by the Arduino.

The picture above is showing exactly the same. I only „set the clock“ to a different time and the short turn was chosen . 

This third picture is showing a special case: Cashing during midnight! When discussing with my colleague he said, I’m totally stupid to take care about that possibility. Noone will do this cache during midnight! But I wouldn’t be me, if I wouldn’t have integrated a solution for a problem, which quite probable will never happen. Look to the time, I used. It’s 23:00 (11:pm). The cacher has chosen the long distance and so the minimum time is a quarter prior midnight, while the maximum one early next day. Now the maximum value is smaller than the minimum one. But it’s not only that: While at „usual times“ the clock of station 2 must between the both limits, now it must be outside: 

• valid time 1: between 0 and max ( 0 - 1805)
• not valid time: between max and min (1805 - 85505)
• valid time 2: between min and 86399 (85505 - 86399) (86399 is 23:59:59 in seconds)

If someone is interested to study the Excel file, it can be downloaded here.

Thoughts about the hardware:

I think, both stations will have a 4x20 LCD. At the moment I didn’t decided about a button to select the short or the long way or just showing both at station1. Your suggestions are welcome! Station 2 will need a keypad (already in my local stock from the Arduino starter kit):

The library of such a keypad is already inculded inside the Arduino IDE.

Last and least - for today - 1 RTC (real time clock) must be integrated in both stations: Today just arrived 2 a little bit expensive ones and a bulk of 5 quite cheap ones (not offered at Amazon.com, so here’s the link to Amazon.de). Let’s see, how they work. But again, up to now, I wrote no single line of code...

How to go on?

I hope, I’ll have time next days to start coding. I’ll do it step by step:

• setting and reading the rtc (real time clock)
• the decryption & encryption of the time stamp
• using the key pad
• and than bringing it all together…

I still haven’t decided to write 2 separate sketches for station 1 and 2 or one with a flag to decide which station it should be. The advantage for a combined one is that software maintenance would be quite easier. The disadvantage that the combined code will need much more memory than 2 separate ones. But because our welcome screens already will need a Mega, we might have memory enough...

Update 12/1/2016 - Just ordered an Ethernet shield…

For what I need that? The first time the timer of the RTC must be set and also after each change of the batterie. For sure that could be done manually. But is it not much more sexy, to connect the RTC with an Arduino, which is connected via an Ethernet shield to the internet and getting the time from a time server as our Macs (M$ Windows devices as well…)? Yes, it is! No real need for our cache, but a challenge. The shield will arrive tomorrow and the sketch is ready to be tested…

Update 12/3/2016 - RTC sucessfully set from Apple NTP server via internet

It’s done by today and you can read & see more about here...

I know: I could have set the RTC by hand. But this way is even more expensive and much more sexy, or? And I’ve learned a lot again (even if there’re still some niches, where I’m stepping in the dark…).

Update 12/4/2016 - Thinking about the principle more deeply

Prior starting with coding the sketch, I want to share my ideas on the principle with you. The following is an example to precisely show my ideas, not the real location. First have a look to an area, a little bit north of your nice property:

As ever: Click on to the picture to see it full screen

That’s a nice area and up to now there’s no cache located. Maybe because there’s no public access? Doesn’t matter! It’s fine to explain my thoughts:

Start

1. Station 1 is the Start. The cacher has to put his batterie into the cache and will have to read some welcome screens.
2. He has to decide to do the short run to the final (2 = Final) or the long way. For this he has to press a button (e.g. pressed = short, not pressed = long).

Short run:

3. If he’s deciding for the short one, he’ll receive at (1) the coordinates for station 2 (2) and the encoded timestamp of the current time.
4. This timestamp will not only contain the current time at station 1 but also the decision he has taken about the short or the long way.
5. When arriving at (2) he has to key in the encoded time stamp. There won’t be a lot of welcome screens.
6. Let’s assume he wouldn't be able to go from (1) to (2) in less than 10 minutes. We’ll set t_max e.g. to 15 and t_min to 7 inside station 2 (2).
7. Station 2 will discover, whether  actual_time is > timestamp + t_min and actual_time is < timestamp + t_max.
8. Because the timestamp will say, it was the short run, there’s no need to key in someting in addition.
9. If time was within the interval, the cacher will be able to reach the log.

Long way:

10. If he’s deciding for the long one, he’ll receive at (1) the coordinates for (a), (b), (c) and (2). The advantage is, there’s no need to hide at the intermediate stations any coordinates for the next stations. But, of course, it could be done so.
11. He will get the notice, that at each intermediate station he must find a one digit figure (e.g. „2“ at (a), „4“ at (b) and „3“ at (c). This 3 figures he need to sum up (to „9“) and will need this at the final station (2).
12. At station 2 (2) he has to key in the timestamp. There won’t be a lot of welcome screens. The station discovers the long way and so t_min und t_max are different from the short run.
13. Let’s assume he wouldn't be able to go from (1) to (2) via (a), (b) and (c) in less than 60 minutes. We’ll set t_max to 90 and t_min to 50 inside station 2 (2).
14. Station 2 will discover, whether  actual_time is > timestamp + t_min and actual_time is < timestamp + t_max.
15. Because the timestamp said, it was the long, the cacher now has to key in the sum of the figures of (a), (b) and (c) („9“).
16. If in time was withinthe interval and the sum („9“) is correct, the cacher will be able to reach the log.

If you have any requests to change that principle, that must be agreed between us in advance prior answering the following questions.

To decide prior starting to write the sketch:

30. How many intermediate stations?
31. Long way: All coordinates of (a) - (c) shown at station 1? Or at station 1 (a) shown only, at (a) the coordinates of (b) only … and at (c) the coordinates of (2) only?

To decide later (after built of the cache and final location):

40. The coordinates of all locations
41. The 2 sets of min and max time for short run and long way
42. The valid „sum“
43. If lock used, the key to open it.

So, my friend, now it’s up to you to tell me any changes of the principle and your view on questions 30 - 31. I know that you have a different area in mind. But that doesn’t matter. I only wanted to agree on the principle with you!

I’ll write an eMail now to you asking to start thinking...

Update 12/14/2016 - On hold...

Meanwhile Tim and me had some discussion on it. While I’m quite happy with my idea, he isn’t, because he doesn’t like multies. I tried to change his mind by pointing to the fact that 2 of his quite famous ones (Altitude, Reverse GPS) are multis. On the one hand he didn’t refused that but unfortunately he didn’t changed his mind.

I’ll try after Christmas again. At this moment he’s very busy on the Christmas gift, because Marsha and he are building most of them by their hands. A great tradition!!! On my side there’s also some trouble. So I don’t think, here’ll be progress up to next year…

Update 12/26/2016: Prototype 99.9% finished and new idea

I have the prototype 99.9% finished and a new idea to place it. I’m still trying to convince you, this would be a fun cache…

Here’s a picture already to explain it: 

The idea is like this: The two stations are located on each side of a river. The river is only some few inches deep, just enough to have your shoes and trousers wet, when crossing. Swimming isn’t needed. From station 1 you can see a bridge crossing the river. The choice is between the direct way with wet feet (and shoes and trousers) and the long way using the bridge and keeping the feet dry. Best would be, if on both sides of the river there would be at least a path way…

Update 12/27/2016: video taken

And here’s the video… Don’t forget to switch your loudspekers on, because at the beginning I’ll explain the decryption and encryption of the time stamp using my Excel file and also a little bit of the code (sketch). At the end you’ll see the protoptype running...