Location tracking

Well, amusingly, my prints are actually throttled, I just didn't want to overcomplicate the code

function throttle(func, wait, options) {
  var context, args, result;
  var timeout = null;
  var previous = 0;
  if (!options) options = {};
  var later = function() {
    previous = options.leading === false ? 0 : Date.now();
    timeout = null;
    result = func.apply(context, args);
    if (!timeout) context = args = null;
  };
  return function() {
    var now = Date.now();
    if (!previous && options.leading === false) previous = now;
    var remaining = wait - (now - previous);
    context = this;
    args = arguments;
    if (remaining <= 0 || remaining > wait) {
      if (timeout) {
        clearTimeout(timeout);
        timeout = null;
      }
      previous = now;
      result = func.apply(context, args);
      if (!timeout) context = args = null;
    } else if (!timeout && options.trailing !== false) {
      timeout = setTimeout(later, remaining);
    }
    return result;
  };
}


function printDeviceData(device) {
  try {
    Bluetooth.println(JSON.stringify(device)­);
  } catch (err) {}
}

function getDevices() {
  const throttledPrint = throttle(printDeviceData, 1000);
  
  NRF.setScan(function(device) {
    if (device.name && device.name.indexOf('Puck.js') >= 0) {
      const data = device.data.toString().substr(-1);

      if (!devices[device.name]) {
        devices[device.name] = {
          name: device.name,
          rssi: device.rssi,
          data: data,
        };
      }
      
      const oldDevice = devices[device.name];
      
      if (device.rssi !== oldDevice.rssi) {
        devices[device.name].rssi = device.rssi;
        
        throttledPrint(devices[device.name]);
      }
    }
  });
}

Please can you check process.memory().usage for a bit? And does it seem to be writing to the console pretty much all the time?

I've been trying to debug some issues with this, and all the issues I hit seem to be:

• Running out of memory inside the interrupt handling the scan
  
• Filling the output buffer inside the IRQ
  
  

If you look in here in a few minutes: http://www.espruino.com/binaries/travis/­bc5039794d1063b2035efbfc0bb674b1c33cd802­/

... you should find a substantially more stable build that'll survive even doing something like this where it keeps running out of memory and output buffer space:

NRF.setScan(function(device) {
  Bluetooth.println(JSON.stringify(device)­);
});

Hi, was any progress made on this? I'm trying to do something along the lines of @Gordon's first example - Pi Zero W boards detecting Pucks.

In theory this is totally doable, but I seem to have so many issues with RSSI readings that I'm not sure it can be used with any confidence. Readings seem to depend on Puck orientation, contain frequent spurious results and if the Puck is on someone's person, and in different places, the RSSI readings are different again. There seem to be many factors which can impact the RSSI which gets read.

Would love to know if you got somewhere with your project and to hear from anyone else who has had some success with proximity/location tracking?

Sadly yes, the strength of signal will depend on orientation of the Puck and the person holding it (and probably the Pi W too). The body partially absorbs the signal which really confuses matters.

How many Pi Zero W boards do you have? With enough and a bit of filtering it should be ok - but for instance with 2 it'd be pretty much impossible.

Hi Gordon. I have five boards, but at moment I'm only using one - nothing fancy just attempting to get some correlation between distance and RSSI signal emitted by the puck. I saw this as the first step, without some form of calibration, reliable triangulation would be hard to achieve?

I've also read of indoor location tracking being done using magnetic fields. Could the puck's magnetometers be up to this when used in an array - maybe if the person carried a magnet?

I'd have thought 5 boards would work ok. Obviously it depends how accurate you want to get - it's not going to be centimeter-accurate, but even though the signal goes up and down, if you have enough receivers you can filter that out.

Another thing you can do is use NRF.findDevices on the Puck to find the signal strength the Puck itself sees from the Pis acting as beacons (or you could just have a bunch of cheap Bluetooth beacons) - it doubles your data points which would help you avoid some noise.

I don't think the magnetometer would help that much though. If you fed the reading into some deep learning tool along with everything else as you walked around the room and trained it then it would definitely help (since the angle of the Puck affects the RSSI other things read) but realistically it'd just be too painful to do.

I'll look into reading the RSSI both ways - that's a great idea - thanks