The dreaded bleeps 

So, I have had a constant battle to try and make the sound (tone/frequency progression) "smooth". There just seems to be a low refresh rate "bleepiness" to it. I thought this was coming from delays in one or several of the following:

1. Reading the MPR121(s)
2. Calculating the frequency and volume to send in the radio packet
3. Sending the radio packet with retries and acks etc
4. Decoding the received packet in the audio unit and parsing into the frequency and volume components
5. Updating the "tone counter" in the audio unit interrupt service routine (I know, unlikely but I was getting desperate)

I took one insole and started littering the audio unit and insole sketches with timestamp variables, to spit out over the serial port every two seconds (ie like a blink without delay - up-to-date, but without holding up the main loop). 

I managed to identify that the radios were able to pass data ridiculously fast - so they probably weren't the issue. But that took time and I now know much more about the RF24 library (thank you so much for that library TMRh20). 

The MPR121 read took less than a millisecond, so that wasn't the issue. But neither was the calculation or parsing of the radio packets. And the tone counter just couldn't be the issue. I was starting to lose confidence when I thought rather than counting how many radio packets I was transferring, I'd count the number of changes to the frequency I was receiving. Around 30 every two seconds. 15Hz? No wonder it sounded bleepy.

So I checked the insoles - yes, the readings were spitting out in less than a millisecond but the values didn't change more than 17 times a second. This couldn't be the MPR121 I2C bus could it? I searched around for the maximum read/report rate of the MPR121 and, in the datasheet, there is this:

See the red? That's what the code I copied had set it to:

// ESI=100 
mpr121Write(0x5D, 0x24); // CDT=001 

So I tried setting it to the blue:

mpr121Write(0x5D, 0x21); // CDT=001 & ESI = 001 (2ms period)

And I now have buttery smooth audio tone progression! It's just a shame that the MPR121 isn't necessarily a good choice for scaling this up, should we get that far with the trials.

Silence is golden less distracting

The patient who will hopefully benefit from this device needs the audio to completely disappear if they aren't putting weight on the insole, so we need to adjust the volume to account for the fact that even the proximity of the patient's foot will cause a change in the readings, whether they are standing on it or not. I intend to make this calibration routine available to the therapist by command from the audio unit at some point soon, but for now the calibration routine runs when we start the Arduino:

void calibrate() {
  readSensors();
  maxRead = (value1 + value2 + value3 + value4 + value5) / 5 ; // set the initial reading of maxRead to "seed" the loop below with a realistic value
  for (int i = 0; i < 10; i++) { //this for loop takes a number (10) readings of the sensors and averages them to arrive at the "no pressure" reading
    readSensors();
    maxRead = (maxRead + (value1 + value2 + value3 + value4 + value5) / 5) / 2;
    delay(100);
  }
  maxRead = maxRead - 3;
}

 The last line just ensures there's no "wobble" and that the mute setting is selected on the digital pot.

We're also learning lots about IPR and open source licensing in order to satisfy the requirements of the trial authorities. Perhaps a log on that will be due soon.