Idea for trackable dog ball - part 1

A friend of mine has a dog that keeps losing its ball. You throw it, it catches it, it wanders around with the ball in its mouth for a while, then puts it down whilst your attention is also wandering for a moment, and bingo! It's lost. She sometimes finds it, but often not.

How about a ball that enables tracking by some means?? At least, on a theoretical basis, leading to a prototype of some sort. Yes, it's technological overkill, but an interesting challenge.

Problem statement:
  • tennis ball sized ball, sufficiently mechanically robust to handle being thrown, held in a dog's mouth, waterproof etc.
  • easily powered or charged, low battery consumption or chargeable (wireless??)
  • just has to give dog owner/operator a clue as to its whereabouts, in a large field, say 200x100m, getting close enough for a visual search is fine
Bluetooth LE seems like a start. Range of 10m/30ft, which should work reasonably because it's usually in a field!

I'm thinking about using a micro:bit as a prototype because it does BLE. It doesn't have any GPS, and frankly, GPS isn't going to be sufficiently accurate to help much.

How does the ball tell you where it is? It can
  • Send its location, or indicate the proximity of some BLE app or other
  • Flash, make a noise on instruction from user (rather than permanent light/noise, yuck)
App on a phone would be easiest for communication.

I guess the first thing is to see how far away it can be contacted using BLE. Time for some bubblewrap and a battery-powered uBit in the middle of a field!

Update - Range Feasible?
I've tried using the Bitty Software Bitty Data Logger on iPhone SE with a bubble wrapped uBit in my garden - if you hold your hand up it easily stays connected across the diagonal, which is 10m+. I need to to try a field! Meanwhile, the trusty Martin Wooley has done some testing, which indicates 200m is a possibility. Blimey.

Update - Power Consumption
Obviously it would be good to minimise the power consumption, perhaps even keeping only the BLE function on and monitored until other functions are required. This page has the results of testing power consumption for different input voltages, and it appears that running at 1.8-2V can reduce the consumption by up to 2x compared with 4V, when idling and not using the LEDs.

Update - Location Detection
This additional MW range article has a comment about being able to get the RSSI on the 'phone connected to the uBit. This could easily be used to provide some sort of range detection, or at least a "Cold/Warm/Hot" indication, based on being able to connect in the first place.

Using the nRFConnect app on my phone indicates a signal level of -54dB when beside uBit to about -90dB when about 25m or more away (across the garden!). Useful, and doesn't require a connection! All you'd have to do is have a register of the BLE GUID of the device and scan for it! Marvellous.

Of course, the hardest part is using an iPhone - it's horribly unfriendly from a development perspective. Maybe I can do something Android-y to start with.

Update - Location Detection
It turns out that people have had this great idea - Eddystone! It's a BLE protocol that allows a BLE device to advertise either UIDs or URLs which can be detected by Android directly (used to be Google Chrome also but they turned that off :-( ) or by iOS using the Physical Web app. And this latter works on my phone and my uBit, including a distance metric based on the signal strength! I'm using the max signal strength on the uBit - there's a pair of Eddystone blocks that have been added to the PXT code Bluetooth section. Wonderful!

Warning: Google has dropped native support for Eddystone and Physical Web in Android as of Dec 2018. Not sure why, apparently they couldn't control "experience quality", but there were some security issues. But you can still use Physical Web in iOS, and presumably in Android.

So I've written some ridiculously simple code for the uBit, and installed the Physical Web app on my iPhone.



Update - Signal Strength
The signal strength doesn't appear to be a very good guide to distance. Oh well. It's driven at the Physical Webb app by a header in the protocol header, which says how loudly the beacon is broadcasting, and the app then works out how far away it is. Ostensibly!

Update - URL Length
I also found out that the Eddystone URL protocol header doesn't allow very long URLs! You have to use goog.le or tinyurl to generate a short one - I know because I was showing my grandson beacons and we tried to make an exhibition in the house, with a beacon in each room, but the Wordpress URL was too long! It worked when I encoded it.

Comments

Popular posts from this blog

Replacing Coffee Machine Pump (Dualit Espressivo)

Multiple SHT30 sensors on a single I2C bus with Sonoff-Tasmota

NodeMCU + Tasmota code + SHT30