I decided to use prototyping board as the next version of SoleSense, to reduce the clutter of the jumper cables and make a reasonably compact unit at each subsystem. For the insoles, this was relatively simple and consisted of a board with female pin headers to accommodate the Arduino nano and the NRF24L01 module. Then a thin four wire cable with a JST 1mm connector in the middle was twisted and then soldered between the board and the MPR121 module, carrying power and I2C signals.

The audio unit was significantly harder to do on prototyping board because as well as the NRF24L01, it needed the digital potentiometer that controls volume, the trim potentiometer that adjusts left-right ear volume balance and the headphone jack.

Once I had soldered everything, I also wrote code for the insoles that not only calculated the weight distribution from front to back but also took an average reading to indicate the proportion of the patient's weight which was being transferred through that foot. Using bit shifting, I combined both the tone and the volume for each insole into a single 16 bit integer variable for the NRF24L01 to transmit.

Unfortunately, the resulting audio was patchy, not to mention sounding bloopy, like an early video game. I had a feeling that the audio Arduino was struggling to handle all its tasks so I had to go into fault-finding mode. Firstly, I tried generating the audio tone with a separate Arduino and feeding it into the DS1801 digital potentiometer to see if the burden of generating two individual audio tones from a timer interrupt was a bridge too far for the Arduino, on top of listening to the NRF24L01 and commanding the DS1801 on the SPI bus. Sadly, this didn't improve the quality of the audio.

Then I wondered if the problem was to do with the NRF24L01 and the DS1801 sharing the same SPI bus. Although the DS1801 has a non-standard logic, I thought that this would only affect the Chip Select line behaviour and therefore it shouldn't affect the NRF24L01 on a different CS pin. Nevertheless, once I took the DS1801 out of the circuit (and bridged between the wipers and ends of the resistors) the tone was produced continuously, although still low resolution. I remembered that the NRF24L01 can use a softSPI library, where you select the replacement MOSI, MISO, SCK, CS etc pins in a config file, after installing the Digital.io Arduino library and including it in the sketch. I hastliy soldered some female headers along the spare digital pins of the Arduino and used some jumper wires to break out the NRF24L01. With the softSPI both volume and tone were responding as they should - Hooray! - and then I rerouted the protoboard wires to accommodate this setup, remove the jumper wires and allow the use of the original 2x4 NRF24L01 header socket. But audio was still bloopy...

PS, by this time I was getting fed up maintaining a left insole and right insole version of the insole code, so for the first time I used the #if defined C preprocessor (according to Google) to define the different pin mapping between the left and right MPR121 modules, along with a #define leftFoot line that was included or commented out to compile for each side. Definitely a massive time and sanity saver and I recommend it if you haven't tried it before.

I was a bit concerned about this apparently low refresh/update rate on the tone (I couldn't tell if it was there on the volume). My radios were being told to transmit new readings every 20ms, to match the 50Hz I had experimentally found was acceptable in a previous log. Finally, I remembered that I was using code where the NRF24L01 was being used in a transmit and receive configuration, so after it sent something it would go into a period of listening on receive and only after a set period would it exit the routine with a timeout. It turned out that I had upped the timeout from 2ms to 200ms in an earlier stage of development *for the audio module, not the insole module* but had copied the code across to the insoles at some point. After I reduced the insoles timeout to 10ms, the audio update rate should have been sorted. But it wasn't. 

I uploaded the new code to the insoles and the audio unit stopped receiving their messages. I spent an absolute age (and rage) trying to work out what I had got wrong but the short answer is that because I had left the softSPI enabled in the library and configuration file, my insoles were trying to talk to their radios on completely the wrong pins! Once I had this, the audio was updating smoothly and the volume and tone variation with foot position/loading was really noticeable. Excitingly, its now time to show the system to Caz, the physiotherapist whose idea this was!