Long walk with geolocation

[ruru67]

There was this thread where we talked about using NFC tags or QR codes to indicate when waypoints were reached for a 'long walk" or training session.

Now, for a long outdoors walk, it's not a lot different to pre-placing a key at a remote location, and going out bound to retrieve it. And that comes with the unknown of whether the "key" is going to be there when you arrive. Also, you need to go and place the key/tag/QR ahead of time.

But the whole point is that you need to "prove" you reached a point or series of waypoints ... and, well for longer distances, isn't that what geolocation can do?

Long story short, I put together a "game" on my little lock box (I have a number if these) - the game has a list of possible waypoints in a text file, which you can select from a map (I put together a JavaScript app, calling Leaflet to do this); once you have a route selected, you hit "go" and it locks the box.

Then a second JS app, intended to run on a mobile device, monitors the geolocation. It's given the next waypoint and a radius it must be within, and shows the distance and direction to reach that waypoint from your current location. When you reach a point inside that radius, and if the accuracy of the geolocation is good enough (I used 50m as a cut-off to avoid spurious activation of a distant waypoint), it calls back to the lock box to get the next waypoint, or if it's back home, to unlock the box and finish the game. The game also has a selectable time limit after which it will automatically unlock.

I ran a few tests to be sure it all worked. I learned a bit about geolocation and about mapping apps. Google Maps is truly crap for planning walking routes (Apple Maps is better, but only a little). But OpenStreetMap has a really good database of walking tracks, showing the nasty zig-zags some of the walking paths around here take in great detail and allowing good estimates of distance and time taken. It also doesn't demand setting up API keys (with billing!) to do anything remotely interesting like Google does ... allowing things like Leaflet to just work. The downside is that OpenStreetMap is map only (no satellite/aerial view), but the map is detailed enough that I can live with that. (That said, I tend to use Google for identifying waypoint coordinates - you just centre the map on the point you want, zoomed in as far as it will go, and copy the resulting URL from the browser URL bar. My app extracts the first thing in a pasted text string that looks like a latitude/longitude pair, and uses that as the waypoint location, so you can paste pretty much any location URL from pretty much any mapping site in there and it'll just figure it out.)

Now, I haven't done a long walk for a long time, and since the app is new I did want to allow for failure. I set the box to lock until the small hours of the morning (or until the game was completed), which would be annoying, but allowed for a just-go-home-and-wait-it-out abort if something went wrong.

I chose a route that was about 5km, or about an hour's walk. I realised that while that was a good walk normally, the route did have some hill climbing, and I wasn't going to be unencumbered. Well, in for a penny...

For this first "real" run I didn't want to get too ambitious. My outfit was as follows:

• A long, stiff corset. Not too tight, but enough that deep breaths wouldn't be a thing. I put this on over a tight singlet.
• A steel wire belt with a loop securing it.
• Mid-calf, high heeled boots, with locking straps. These weren't too high but when I got them they were a bit small. I put in raised heel insoles, which added 2 cm or so to the 7-8cm height (5-6cm rise) of the existing heels. Now these boots don't have very obvious heels - they're an internal wedge, with a fairly flat looking external sole. The sole is also quite soft, as are the insoles. But still, they are high heels, with the effect of reducing stride and making downhill walking more difficult. I wore these with socks.
• A pullover hoodie. This has three slits cut in it, one on each sleeve just above the cuff, and one in the centre, inside the through front pocket.
• Metal wrist cuffs padlocked to a short plastic link (made from piece of a large cable tie, with the ends folded onto themselves and riveted to form loops). I put the loop from the wire belt into the pocket through the slit, and threaded the cuffs and links through the slits in the sleeves, and through the pocket and the belt loop (locking it in place). My wrists now were trapped, but even if I pulled a hand out of the pocket to handle my phone, no-one could see the cuffs.

I took a spare battery and cable in case I'd underestimated the power requirements of running the app/geolocation, and left the house. I had nine waypoints (including the final "home" waypoint).

The outfit was pretty effective; I had corset, heels and cuffed hands, but you really couldn't tell. And I did this fairly late.

So what I found out was ...

I don't think my socks were doing me any favours. The toes of the boots caused blisters on the tops of my little toes, but I also had them on the balls of my feet by about the half way mark. That was getting a little annoying ...

The "need a good fix" requirement meant that sometimes I had to hang around a waypoint for a while while the phone figured out exactly where it was. It always sorted itself out, but I was wondering if the app needed a feature were if it had been registered in the general vicinity of a waypoint for an extended time, say 15 minutes, it would relax its requirements and call the waypoint reached. That might help if, say, a waypoint was found to be unreachable - civil works might keep one from the 20-40m kind of distance I had programmed, but relaxing that to, say, 100m after a time might allow one to just hang around for a bit to tick off an otherwise blocked-off waypoint. Need to think about that some more.

(Techy detail: phones use a bunch of technologies for geolocation, but it's mostly done by triangulating off cell towers, because that works inside buildings, even if it's not super accurate. GPS is much better, but it needs to be able to see quite a lot of sky to work - the satellites orbit at altitudes of about 20,000 km, so the signals reaching the ground are weak and don't go through obstructions like roofs or vegetation, and even if enough GPS satellites can be "seen", it takes time to get a good fix. I'd selected waypoints in fairly open areas for that reason, and made the approach radii of more sheltered locations larger. Sometimes it took a few anxious minutes hanging around a waypoint waiting for it to get a good enough fix to report it reached, especially if the route to the waypoint had a lot of trees obscuring the sky.)

With the heels and hill climbing, my calves were a bit unhappy, but not too bad. I, uh, might be a bit out of shape.

Doing this on a Monday night, I saw ... nobody. At all. No pedestrians, no cars that I recall. I'd selected a route that used primarily off-street walking/cycling paths for most of its length to avoid being seen from cars (not that it was really needed). Midnight in suburbia on a weekday is quiet.

Longer term plans: I'm thinking about doing this gagged and with knees restricted. I'd use a calf-length skirt to hide the knee bindings, a face mask to hide the gag, and a shoulder length, fairly curly wig to hide the sides of the mask, and the fact I'm not of the traditionally skirt wearing gender...

Any other suggestions for things to make the trip more ... interesting?

[Kinbaku]

Wow, what an interesting challenge and a lot has already been added.

When you connect a vibrator or DG-lab like I once did during a night walk (at night an area is sometimes completely different than during the day ), that could be an interesting addition.

And you're right about Google Maps: in Japan I sometimes used it to know my position or to know which direction to go to reach certain places, but sometimes it happened that I changed position 5 times in 5 seconds 4 km (2.5 miles) further away from where I was.

[pledgeay]

This is so good. very cleaver to be able to creat something like this. Sb game must be so much more creative for you when you’re able to be so creative with technology.
I wish I had the knowledge to build things like this.


Could you add a on off the the location which would turn on or off a toy.
Or if you don’t get there in a set time, a hard zap.

[Riddle]

Thank you for sharing this story with us and for including so much detail about the building and the using of it. I enjoyed reading this.

[ruru67]

I added and tested the "loiter" feature - basically, as long as I'm within 100m (according to the phone's location service), regardless of the accuracy of that measure, it runs a timer. If the timer reaches 15 minutes, the waypoint is considered reached. So if the location accuracy is playing silly-buggers, I just need to wait it out until it either gets its marbles together and gives a good fix on the waypoint, or that 15 minute time is reached.

(Now, I've seen the location service get really confused and put me hundreds of metres away, but that doesn't usually last too long, and while the timer will stop if the "fix" is no longer within 100m, it'll pick up again from where it left off when it gets "back" in range.)

One real problem with coding stuff like this is that if you know how it works, you know how to break it. I'd like to be able to "prove" that the phone really is where it says it is, but there's nothing truly stopping me spoofing the responses - there's no magic that says the coordinates provided really truly came from a location service running at that actual location - the coordinates are just a pair of numbers. I put some obfuscation in the code to make it less trivial to spoof - each code download to the phone is different, and produces a different response - but it wouldn't be all that difficult to take the downloaded code, simply change the call to the location service to return the target coordinates rather than the real ones, and apply the same obfuscations as that - the location service simply isn't secured. (I supposed a real honest-to-goodness app rather than a webapp could make that more secure, but I don't have the tools or inclination to get into mobile programming.)

(That is an advantage of using physical objects to prove when a waypoint is reached, be they actual keys, NFC tags or QR codes - these are not reasonably spoofable if you don't have access to the key or the contents of the NFC tag or QR code.)

When the webapp does reach its waypoint and "phones home", it does it in two stages. Each time the webapp loads, it's given a "cookie" - a random string - that is returned along with the location and must be correct for the submission to be recognised. If the app submits more than 15 seconds after the page was sent, the host simply ignores the waypoint submission and re-sends the same page (with a new cookie - and new obfuscations); the same conditions (i.e. location) will be present, and the webapp will submit pretty much immediately, this time (hopefully) within the time limit. That limits the time one can spend on spoofing the result, which makes it pretty much impossible to do it manually (but it could be scripted as noted above).

I may tighten that timing - while I often find location service takes a while to get its marbles together when first used, it seems to give just-as-good fixes right after the submission and reload, so the resubmission happens pretty quickly. But I'm also worried about network delays so maybe I'll just leave well alone ...

So the idea is to make it hard enough to spoof this thing that it's not really worth it. There is one particularly effective countermeasure in place, and that's a minimum travel time restriction. At the start, and at each waypoint, an estimated time of arrival at the next waypoint is calculated, and it simply won't accept a submission prior to that time. At the moment I'm calculating that as 5 km/h as the crow flies so the ETA will be early if it's a zig-zag or difficult path. That doesn't matter a whole lot; the point is that since one has to wait some amount of time before trying each waypoint, one might as well be out and about playing the game instead of huddling over the computer in bondage trying to spoof the code to get out early ...

(Note that the loiter timer noted above won't start until the ETA is reached.)

Still, accurate travel times would be a nice to have, partly to better indicate progress, and partly to make the wait time as long as possible without leaving one stuck at a waypoint waiting for an overly generous ETA to be reached. I'm toying with the idea of using GraphHopper Directions API to compute the actual distance and travel time between waypoints. (Or just manually looking up the wigglier paths in OpenStreetMap - which uses GraphHopper - and hard coding the path lengths into the waypoint data.)

[ruru67]

Since one person has already asked ... can I make this stuff available?

Uh, I wish this was trivial. I'd like to, but there are some problems.

First, the lock box that this runs on is a bit of an orphan - I built it a while ago, using a surplus Soekris single-board computer (SBC), a serial 4-relay control board and case lock solenoids from some old Compaq desktop computers. The SBC runs a cut-down FreeBSD installation that dates from when a "large" CF card was 64MB. It's had some updates, but the OS environment is ... let's just say, very light weight, to suit a fairly slow mid-2000s computer.

Then there's a whole locking, timer and web interface layer built onto that, that frankly I don't really want to share. It's not that I don't want people to have it, it's just that I don't want to support it outside my own use. Even if I provided everything, there's just no way anyone is going to be able to drop it onto new hardware without lots and lots of questions about how it works and what it does, and I am not signing up for that.

The second major problem is that the Internet sucks.

Specifically, the Internet long ago moved away from the idea that anything could (if permitted) talk to anything else, into a model of client devices making only outbound connections to servers built on server-specific infrastructure. The tech industry likes to call this "the cloud:", but as a long time Internet technologist myself, I have to let you in on a secret:

There is no cloud.

All there is are other people's computers. And frankly, those other people do not have your interests at heart. The direction of the industry means that making a computer available to act as an Internet server is hard. You need:

• an Internet router that can take connections from outside and pass them through to a computer inside your network; this used to be a feature of every router, but these days it's something you need to shop for,.
• Static IP addresses so that router (and computer) can be reached on the Internet. A lot of Internet connections these days are behind carrier NAT; the address your router is given is simply not reachable from anywhere.
• DNS domain names so that IP address can be found;
• SSL certificates so that the connections from remote devices can be secured; Geolocation services don't work on "insecure" pages.

The last one can be done using LetsEncrypt, and domain names can be purchased, but the others are increasingly not supported at all on domestic Internet services. Because of my background, I do have all of these things at my disposal; as well as the lock box itself, I have an SSL proxy (the SBC's current config lacks HTTPS capability) running on another server, domain names, an Internet connection with static IP addresses and a router to handle all that.

The other option of having the application run on a server outside your home network (say on AWS or something) leaves you with the problem of having that app talk to your lock device inside your network. Typically, that means having your device maintain some kind of telemetry link, or periodic polling, to the app server so that it's making an outbound connection to the server, rather than trying to get the application to reach in.

While that's certainly a way to do it, it's not how I've built my system. I may yet re-engineer the hardware to replace the Soekris SBC with something more modern (e.g. a Raspberry Pi or similar), and perhaps an Arduino based controller to operate the locks, read the external buttons and perhaps a few other jobs, but while that would make the thing faster and more capable (including removing the need for the SSL proxy), I wouldn't change the basic architecture. I like the fact the application is physically locked inside a box that I fully own and control, and that the box can operate autonomously (and UNLOCK) even if the Internet goes away. Most of the games on the box do not need connectivity outside of the house, and if it's just counting time to unlock, it doesn't need connectivity at all.

(Also, I truly hate the idea of giving money to the companies that are making the Internet suck.)

Now, it might be possible to make the JavaScript mobile facing portions of the code available; if people what to take that and build new back-ends for it. I'm still messing with it, so I won't want to do that soon, and it'll need some changes to make it, well, less of a bodge. (I am not a JavaScript programmer!)

[Keyless]

Wow. Great piece of work. I had a system to do something a bit like it. I used an arduino with GPS shield to log my route and a computer program to analyse the log and allow me to open a lock box if I had visited all the way points. I found it made the trip more pleasurable if I knew from the start that I could not give up or take a different route without some penalty. I’m not sure I understand the details of your method, not being an expert on the internet, but it sounds great. I do like the idea that the lock box is directly controlled by the system.

I used my system a lot. I did have one further idea, which I did not get around to finishing. I thought I would be useful to be able to commit to make a trip several days in advance. My system did have the facility to set a time window within which the trip had to take place. One scenario was put on my one piece cycle suit, lock it at the neck and leave the key in the house. With my logger attached to my bike and my computer in an outbuilding together with the lock box, I would lock myself out of the house, put the keys in the lock box and lock the system. Like you, the system had a timer, which would eventually allow me to open the lock box without doing the trip. My further idea was to have two lock boxes, one would be used just before the trip, as above. The other would be used to contain something important, but not needed for a few days; maybe the receipt for an item I needed to return to a shop shortly. That would be locked by the system in advance, so that I would have to do the trip at the appointed time even if it was raining or whatever.

As you say, it is very difficult to make the system cheat proof when you know how it works. My system relied on fairly basic encryption techniques. In my system the information is only decrypted inside the pre-compiled C++ programs which contained the only copies of the key. Can you use encryption to stop you tampering with the coordinates.

I am happy to post more details if you think they might be of use.

[ruru67]

stuff

I like the idea of a contained box, or a contained app. If I had app programming skills/stuff, I'd use an app to do the tracking - possibly using public key crypto to sign the result, with the private key programmed into the app (generated at compile time and discarded after compilation). That app would then sign its waypoint submissions (or even completion like in your mode) with that key, and the lock box would then use the public key (which would be kept, obviously) to verify that the submissions came from the app. Then, the only way to spoof it would be to dig the compiled binary app out of the device and extract the private key - and while it has to be possible for the app to reconstruct the private key for use, it could be stored inside the app a way that would be very difficult to piece together.

Also, using a completely self-contained app with a local lock box means you don't have to deal with all the Internet suckage I outlined above. As long as you can communicate between your lock box and app over your local WiFi, the app can send the (authenticated) unlock command to the box when it's back in range and happy that you have been where you needed to go.

The trouble with the JavaScript app is that all the code is readable - one could spoof the request from the mobile device for the waypoint, and simply modify the code that comes back to replace the bit where it asks the geolocation stuff coordinates for its location with code that just assigns the target coordinates. Here's some code (actually lifted from the app):

Code: Select all

function updatepos(pos) {
        // Get position
        //
        var clat = pos.coords.latitude;
        var clng = pos.coords.longitude;
        var acc  = Math.round(pos.coords.accuracy);
        ...

pos comes from the geolocation stuff (the updatepos() function is called by the geolocation stuff when it senses a change in position) - all my spoofer would need to do is substitute the three instances of pos.coords.thing for appropriate hard-coded values. If I run that updated code in a browser, the resulting code will operate as if it really reached that waypoint; any subsequent "crypto" or obfuscation I might build into the communications just encrypts the spoofed values. Even if I made the "pos" variable name different each time, I only need to substitute, e.g. any occurrence of "any-valid-variable-name.coords.latitude" with the actual latitude of the waypoint. In short, there's no way to prove that the coordinates came from an actual geolocation fix.

One thing I have added, when the first request is received from a mobile device (i.e. the HTTP user agent field contains "iPhone" or "Android"), it saves the session cookie value, and verifies that all subsequent requests are from that session (locking out any other session, e.g. if I used my desktop computer to set up the route). Unfortunately, my proxy arrangement means I could get the cookie value just by watching the unencrypted network traffic between the proxy and the lock box. That problem would go away if I upgraded the lock box to be able to do SSL end to end (or otherwise secured the proxy and comms between it and the lock box).

I added a moving map display to the app last night. Still thinking about the actual path stuff...

[Keyless]

Yes, I thought I could probably extract the encryption key quite easily from the Java distributable code. (I'm not sure you can do that now that the JRE seems to have been replaced by a method that generates a distributable specific to the target machine.) I wanted to program in Java as I could generate a user interface quite easily. To prevent recovery of the key, I wanted to program the relevant bits in C++. I discovered that there is a Java Native Interface (JNI) that allows you to call a piece of C++ as if it were a function. I did find it rather difficult to use. Apparently there is a similar system which allows you to use C++ with a Java program under Android.

Determining whether I had reached a waypoint was more than an Ardunio could cope with, so I just logged an encrypted version the relevant NMEA sentences produced by the GPS. You could probably load a file into the phone containing the waypoints and make that check in the phone, Then, when the waypoints had been visited, you could generate a release code based on a master key contained in the compiled C++ together with the waypoint file. In your lock box you could have a small machine such as an Arduino, also with the master key compiled into its code and a copy of the waypoint file loaded. When you get home, you send the release key from the phone to the machine in the lock box. The machine in the lock box could then generate a copy of the release key. If they match the box gets unlocked. I think that should be reasonably cheat proof providing the waypoint file is unique, so an old code from a previous trip over the same route won't work. Also there must be no way you can persuade your phone to deliver to the program in your phone the coordinates of the waypoints without it actually being at the waypoint.

Sorry to ramble on. I don't know much about programming apps, so I might have got this completely wrong. I am basing it on a very quick internet search. This is one of the sites. https://groovetechnology.com/blog/can-c ... velopment/

[ruru67]

The NEMA sentences approach isn't a bad idea. Encrypt the sentences with a key shared between the lock box and the Arduino, and you have a pretty secure way to ensure you've been where you said you would - the only way to break that would be to find a way to pry the keys out of one or other of the boxes, which would be unlikely to be worth the effort. (And you do have an emergency release or some other Plan B, right?)

I'd want to be sure I had good GPS fixes though, as GPS works really well when it can see lots of sky, but no so much if there are buildings and trees limiting the view upward. That's kinda why I did mine the way I did - I wanted it to give me confirmation that the waypoints had been reached.

Like I said, an honest-to-goodness compiled app could hide its keys quite well, and ensure the encrypted locations actually came from the geolocation stuff. JavaScript running in a web browser really can't - it's just too easy to hack the code to slip the locations into it before encryption. Hence the other countermeasures. But I'm an Internet guy, not an apps guy, so I do what I know...

I added the GraphHopper stuff. I built an intermediate app that both the hosted and client parts of the app can talk to - I give the intermediate a full path of every waypoint, and it goes out to GraphHopper for each part of the path, and caches it, so it never has to ask about the same path twice. That makes it way faster (and is a lot nicer to GraphHopper).

When each route to a waypoint is added, I send up the path received from GraphHopper for display on the moving map; I also use it to give me a more realistic ETA (which also gets used to restrict when the waypoint can be confirmed). I walk quite fast, so I'll need to do some tests to see if its timings will leave me loitering at waypoints.

There's been a bit of getting my head around JavaScript web programming. The trick is that JavaScript never waits for anything - if you want to request an object from a remote server, you kick off the request, and an event fires when that request is completed to handle it. With the path stuff and its cache, if I add a new path and then delete it immediately, the app requests the new path, which may need to go to GraphHopper to compute, which can take a few seconds - long enough to display the updated route (sans map and distance info). I can delete it, and it'll go to the path app again for an updated path, which will be the same as the previous one, and the path cache will respond fast as it's working from saved data. Then the first query completes and displays the path as it was with the new path as it was before being deleted. I had to flag it so that if a query was already in progress, it would set a flag that the completion stuff would see - if set, it would discard the (out of date) results and perform the fetch again - repeat until we've caught up ...

I'm tempted to add a delay before a fetch to allow multiple changes do be done before sending the fetch request.

[ruru67]

Of course I can't stop playing with this thing. I even added a compass feature (I mean I know pretty much where I' going around here, but, y'know, why not?). Also a moving map feature that moves the map according to your movements - not by centering the map on my location -- I was doing that but it's annoying if you try to slide over to see something and it snaps back -- but just sliding it by as much as the movement since the last update. That way the position marker stays in the same place on the map pane - wherever you left it -- and the map slides under it. Necessary? Nope. Difficult? Nope. Cute? You betcha. A few other neat improvements on the setup page - can now add new waypoints entirely in the app (rather than pasting URLs from other maps - which you can still do), double clicking waypoints to add them (instead of clicking the waypoint then clicking the pop-up that appears).

Anyway, I gave it another run tonight.

My get-up for this trip was like last time's, but this time I pushed things a bit further. I had a gag in. This gag is a Chinese knock-off (or licensed, hard to tell - I suspect they came from the same factory) of the Silencilicone gag. I have, of course, modified mine with a rigid metal bar around the inside of the strap, and a thin bolt inside - as standard, the gag is quite soft and flexible, and even after rigidising the strap, it could be tipped out bu flexing the gag. My mods change this - lock the strap, not even particularly tight, and that thing is not coming out. I hid the gag under a face mask

I didn't put that key in the lock box. Instead, I put it in the cigarette timer box I described a little while ago, with the timer set to about half an hour. That way, if I had to bail early, it would be waiting for me when I got back.

The second change was to add a strap between my knees; this is two cuffs that go around the narrow bit between my knees and the tops of my calves, and a strap that wraps around both - the strap restricts one's stride and the cuff stop it slipping down.. Going around instead of tethering two cuffs together means the cuffs don't rotate around the legs, which is a bit easier to deal with. I put this on over my over-knee boots - again a wedge heel, about 10cm, with about 2cm sole - so about an 8cm rise.

Obviously, with knees tethered I wasn't going to be able to get on pants. So, I put on a mid calf thick skirt to cover the tether. A longish, curly wig made the skirt believable, and also covered the sides of the face mask and the gag strap appearing from under it.

Same corset, same cuffs, same hoodie. Just a tallish random lass staggering home from a bit of an evening....

So I got out of the house, and realised that the hobble was just a little too hobbling. This wasn't going to be a fast trip. Downhill was ... OK. The first leg was a steep zig-zag path. In between messing around a bit before leaving and the slow going, the loitering feature tripped on the first waypoint before I even got to it. No problem, onto the next one. This part of the path was a bit uphill, and progress was slightly but noticeably slower. Uphill in heels just makes your stride shorter, especially when hobbled. I got to the vicinity of the second waypoint. It too triggered early, not because of the loitering feature, but the location stuff just getting confused and putting me closer to the waypoint that I really was. No problem.

Uh, not no problem. The app submitted the waypoint, reloaded the page, and ...

No map. No sign of the location stuff ticking off the distance. Clearly, the app had loaded and the HMTL was good, but the JavaScipt code that did all the work was broken. Oh dear. I tried a few things, but iPhones are annoying black boxes that tell you precisely squat about what has gone wrong. Not that I could fix it anyway - the lock box locks the running code to prevent tampering.

Sigh.

I was about halfway out on an out-and back trip. and to be honest, the only thing keeping me going was the prospect of release by completing the route. With that gone, I turned for home. I was tired, this was going slower than I had anticipated.

I got to the bottom of the zig-zag path and started heading up. Going up, my stride was restricted to literally one foot in font of the other. I found that I could actually make faster progress walking backwards, although doing that on a zigzag path, covered in leaves obscuring the edges in places, with only the phone's light was a little fraught. On the zigs, the downhill side was on my right (my left if facing up the path), and I could twist to see where I was going - on the uphill side the edge of the concrete path tended to merge with the hill and I really did not need to take a tumble at this point! On the zags, the light was on the wrong side. Sure, I could have swapped sides, but since i had my left hand in my pocket to allow my right as much reach as possible, that was actually more difficult to do that one might imagine. The way the path ran up the hill meant the zigs were much longer than the zags, so I settled into a pattern of walking backwards up the zigs and forwards up the zags.

Home, I closed the door and took the gag out, thankful that its key hadn't joined the others in the main lock box. I decided to call this an emergency, and cut the plastic tie between my wrist cuffs, now that I had a pocket knife to hand. That meant I could get the hoodie off and take the corset off as well. I worked the boots out from under the knee cuffs and removed them. With the boots off,I could just slide the knee cuffs down my calves - they had been slightly loose, but I hadn't managed to get them to close on the next tighter slot. I won't make that mistake again, and next time the link between my wrists is likely to be metal rather than plastic... I could have just waited it out, but I was now really hot and just wanted to get clothes off to cool down.

So as I type this, all that's left are the (metal) wrist cuffs, still padlocked on, their keys still waiting 'til 3am - actually less than an hour away now.

I logged into the proxy server and packet-captured the app page that was being sent to the phone. I should be able to re-run that in a browser on a real computer, with debugging tools and see what I screwed up.

Tomorrow.

[Keyless]

I agree that GPS can be inaccurate if it does not have a clear view of the sky. Logging the entire route allowed me to use an online service to show my route on a map. I used the Arduino shield without an additional antenna. In one spot with trees on one side of the road it showed me some 10s of metres in the field on the clear side of the road. That was no problem for me as my waypoints were miles apart, so I could afford to include a large margin of error. I don’t know how much better it would have been with a better antenna.

I did have another, perhaps fantasy, idea. Would it be possible to have a system that generates waypoints on the fly, so you don’t know where you are going when you set off? Alternatively, perhaps it would be possible to generate a database with a reasonably large number of waypoints together with the distance and time estimate for travel between each pair. When you plan a new trip, you define only the approximate time and distance and it works out a suitable route. You don’t know the whole route when you lock in. When you reach a waypoint you are told the the next one, until you complete the route.

I drafted the above some wile ago and posted it without noticing the latest post. That sounds like quite an adventure. I'm sorry you had problems. Unfortunately systems like this do tend to have the odd problem. I had to use my backup once. That consisted of waiting for my wife to come home. I did want to recover my trip log. That's when I discovered I could crack my encryption system, so, as well as fixing the problem I had to modify the encryption.

[ruru67]

Yep, most people talk about GPS as if it's what's giving their phone its position fix, but most of the time it's not - it will use GPS if it can, but unless you're outside in an open area, it just can't see the satellites.

GPS is usually pretty good if it can get a fix; most receivers will just throw up their hands if they can't and wait until more satellites come into view. Most of my GPS messing about was in view of using a GPS receiver for time keeping (running a Stratum 1 Network Time Protocol server); I only had windows on a corner of the building, and there were neighbouring tall buildings, so the required minimum three satellites (for time keeping only, position needs four) were visible about half the time. I'd resolved to arrange moving the antenna to the roof (and its rig nearby), but it never happened.

The random waypoint idea is a good one, and yes, that would be very do-able. The front end en-route code would be the same, apart from needing to disable the "display whole route" part; the back-end stuff would be different but would still have a lot of common code. I'd probably pre-compute the route (but not display it), that way I'd know the rough expected transit time (or could control it), and the back-end waypoint/en-route code could also be re-used with only tiny changes.

I'm thinking that how I'd do this is at each waypoint, I'd choose a small number of candidate waypoints that were close (as the crow flies, I can compute that without having to ask for GraphHopper paths), and not closer than the previous waypoint (so the route doesn't go back on itself); I'd then randomly pick a candidate, and get its full path info - if it turned out the walking distance was a too far (the terrain around here means there are lots of cases where two waypoints are close but separated by streams, trackless bush, or private property and the walking path is long) I'd pick another candidate, and so-on. Possibly, I'd just have return from the last waypoint, but I'm sure an algorithm to produce some kind of loop would make the trip more interesting.

So I this morning used "tcpflow" to extract the en-route page out of the packet data I captured last night, and the bug was glaringly obvious (clearly having a "duh!" moment when coding it), and easy to fix. So that little drama shouldn't happen again - at least, not from that bug!

[ruru67]

So I had another run at this last night.

The outfit wasn't a lot different to last time, except in details. Same over-knee 10cm (2cm sole) wedge boots. Instead of the previous set of knee cuffs, I used some leather ankle/knee cuffs (these are long with lots of slots to put the staple through), joined with a steel cable. I had these threaded in such a way that the locks wouldn't jingle.

But I added some stimulation, in the form of a nasty little nipple clips attached to a TENS unit. These clips are alligator clips, modified with screws to allow them to close to a point an no more. I actually find I tune out the pain from the clips pretty quickly. The TENS signal ... less so. I had this set-up running at a fairly low frequency, in the "modulated" mode (the pulses get faster then slower, by I'd say about a factor of two), and at an intensity that made it, uh, hard to ignore.

I put the TENS unit in a garment I had modified. This was sold as a breast binder; it's a singlet with a tight panel (elasticised on the sides) across the chest inside it. To the inside of that I had sewn a padded panel; this serves two purposes: to cover nipple clips et c to prevent manipulation, and to act as a pocket in which to store electro-stim devices (with strategically placed holes for the nipple leads). The pocket's opening is placed so when worn, it's very hard to get into and manipulate (or unplug) devices stored in it. My overbust corset went over all that, making access pretty much impossible.

Then it was on with a floor length skirt, belted tightly around the waist of the corset so it wouldn't slide down (even with the heels, it wouldn't have to slip very far to be a tripping hazard). The hoodie with the steel waist cable extending into the centre pocket, as before. Wig, gag, face-mask, like last time, and again, the gag key was locked in the cigarette box, while the rest went in the main lockbox controlled by the app. Finally it was time to lock my wrists; again inside the hoodie sleeves (via holes just above the cuffs) and engaging the waist cable, but this time the short cable joining the cuffs was steel, not plastic - if I wanted to cut my way out of this, it was going to need actual tools, not just a little pocket knife.

The lock box was set to release on return (with waypoints passed) or at 6am. The app's estimate of the round trip, between three waypoints (plus the home waypoint), was about just over an hour. With the knee tether, it was going to be longer than that. And as I started out, I was again wondering if I'd bitten off more than I could chew. The first part of the trip was down the long zig-zag path; at the bottom of that a fairly flat path through the first waypoint, the shortest leg of the route. This part of the route more or less followed a creek, which meant it was a steady downhill, and I realised that although the grade wasn't steep for that part, it went a long way ... and the second waypoint was at the top of a hill. Great.

Planning rules in this area demand a five metre set-back from the front boundary of the property to any building. Yet somehow, people still set up their front door sensor lights to go off when you walk along the sidewalk in front. I hadn't really noticed this before as the routes I'd used were mainly on off-street walking paths, but about half of this route was along sidewalks rather than paths. The worst bit was a short lane that connected the creek-side walking track to a street - this was a shared driveway more than a walkway, and not being an actual street, front doors were closer to where I was walking. I'd swear every second house in that lane illuminated me with bright lights as I walked past.

Still, after midnight on a Monday night (or Tuesday morning), I again saw nobody. No pedestrians, no moving cars, not even movement in windows. I had a plan, if anyone looked like they wanted to talk to me, of gesturing at the mask and shooing them away, as if to say, "I'm sick, please stay away!" (this has only been a viable strategy since COVID!) ... but so far I've not even seen another pedestrian, let alone felt at risk of having to interact with them.

About halfway along the second leg, the route headed up the side of the valley towards the hilltop lookout. This bit was steep for streets, and as I'd found before, walking uphill with knee tethers greatly reduces one's stride. So it was long a slow slog to the top of the hill. Fortunately there were tables and seats at the lookout for a good rest and a chance to catch my breath.

One thing I hadn't taken into account was that the wind had got up and was blowing the wig around. I pulled it down at the front, but now the bangs were getting in my eyes a bit. Couldn't be helped.- I really didn't need to lose it! I'm thinking about attaching it to the face-mask to be a bit surer in future. I hadn't worn my glasses - I'm short sighted, not terribly so, but it would have been nice to have had a less blurry view from the top of the hill. It was a full moon with a fairly thin overcast, so the combination of moonlight, reflected city lights and fairly good night vision meant I didn't need to use the light on my phone much; really only for the zig-zag path at the start, that runs through a thick canopy of trees.

By this time the TENS unit was ... well, there, but not really bothering me. When moving, it was kind of the least of my worries; being hot and tired was one, and joints punishing me for their decades of abuse. (When younger, I walked everywhere, despite living on a high hill, and given the choice between a gentle climb up a winding pathway or long street, and clawing my way straight up the side of a steep hill, would often choose the latter ...) I tended to notice it much more when I stopped walking. At this point it was just ... nice.

On to the third leg of the trip. This one was a lookout on a different but nearby hill. Fortunately I didn't need to go nearly as far down as the creek before heading back uphill towards the top. I'd been fairly careful not to be tempted into taking short-cuts off the formed pathways, lest I slip and fall. But this lookout was at one end of a large fairly level area, and the paths to it and the one I was on intersected near the entrance at the other end, so I just struck out across the grass until the waypoint was met, then joined the path back out.

Finally, a walk back down the street towards home. I put the phone away in my pocket, only taking it out when I needed it for light to get down the steps to the back door that I'd left open. And ...

I'd passed the waypoint for the street frontage, and the phone hadn't been active when I did. The geolocation stuff was placing me in the back yard, outside the waypoint radius, and nothing I could do, including going back to the street, even crossing it, waving the phone around, turning off WiFi and/or cell service, could disabuse it of that notion. I suppose I could have walked back up the street a bit, but I was tired.

The potential for that kind of stupid is one of the reasons I coded the loiter feature. I was being placed within 100m of the waypoint, so the loiter timer was ticking down, and I just needed to wait it out for the 15 minute that would take. I headed inside, took the gag key from the cigarette timer and removed the mask, gag and wig. The rest just had to stay on (with the TENS unit still doing its thing) until the loiter timer ended and the box unlocked. It was about 1:30am when I got home (leaving just around midnight); the loiter time extended that to about 1:45.

Suffice to say, that home waypoint now encompasses the whole property... and next time I'll have the phone active as I approach the house as I had with all the other waypoints.

[Kinbaku]

... and next time I'll have the phone active as I approach the house as I had with all the other waypoints.

I have the app "Stay Alive!" on my smartphone to ensure that my smartphone does not turn off. Also remember to fully charge your smartphone battery. In Japan, taking many photos drained my cell phone battery and the portable battery didn't work, meaning I had to walk around for a few hours trying to find my way back to the station.

It's a good thing that no one saw you - after all, the tension remains while you walk through that illuminated street and don't know what will happen next.