After putting together the EMG circuit that I have designed for this project, a 24-bit ADC to digitize the analog measurements of the circuit and a NodeMCU (ESP8266-based board) to get the digitized signals and to send them wirelessly to my computer, the first prototype of a Mumai node was ready for testing.

One of the most critical aspects of the system nodes is their data transmission rate. The EMG signal has a bandwidth of 20 to 500 Hz, which implies that, in order to digitize it with no aliasing, it has to be sampled at least at 1 KHz. If each reading is sent to the receiving device once sampled, that means that the nodes have to read from the external ADC and send the measured data point every millisecond. With WiFi, this shouldn't be a problem since this technology allows high transmission data rates.

I wrote a very simple Arduino program for my ESP module, using the fantastic ESP8266 core for Arduino, to see how long it took the module to send individual measurements to my computer. The results I obtained weren't very encouraging: using the client.println command to send a floating point number took a mean time of about 26 ms, way too high for the system requirements. From my own experience, I know that sending data from an Arduino to a computer through the serial port with the Serial.println command consumes more computing time than doing it in byte format with the Serial.write command. So I thought that maybe this is also the case with the wireless communication commands, and I tried sending the data in byte format with the client.write command. After converting each measured floating point number to a four byte array (to do this, the union data type is extremely useful), and sending them to the PC, the mean computing time was reduced to about 5 ms. The improvement was remarkable, but it was still above the required time. And that's when I started thinking that maybe WiFi was not the best option as I thought.

Of course, sending each data point individually is, like we say in Spanish, "killing flies with cannon fire" (I have searched the English equivalent and it is "use a sledgehammer to crack a nut"). So I modified the basic testing code to send a data buffer with 100 data points in byte format. And it turned out that sending a 400 element array with the client.write command took the same time than sending just four bytes: 5 ms. A hundred data points means a 100 ms data segment of the EMG signal, so a 5 ms interval to send these data chunks seems more than acceptable. Problem solved.

But the seed of doubt was already planted. When doing all these tests, the sending time varied, sometimes a lot, between readings. That makes sense since the WiFi transmission rate depends on a number of factors: usage of the network, hardware (the router, the computer WiFi card), WiFi coverage... This made me think that, if I need a stable data transmission rate, perhaps WiFi is not the best option to implement the wireless network. Besides that, there is the problem of energy consumption. The EMG nodes need to transmit data continuously; this is not a IoT project where a sensor needs to send information once in a while. And WiFi is a more power hungry technology than other options. I still have to measure power consumption but, if this system is to be used for maybe hours, autonomy will be an important factor to consider.

I will explore other wireless alternatives to see what are my options. One of these alternatives is ZigBee with XBee modules but, although ZigBee is great for implementing mesh networks, XBee modules are quite expensive. My other preferred candidate is the NRF24L01+ module. This little device has a baud rate of 2 Mbps (when I did some tests back in the day, it took about 800 us to send individual data points), a power consumption of 11.3 mA during transmission and 13.5 mA during reception (according to the datasheet), a great Arduino library to program it, and they can be found at a very low price. The downside of using either XBee or NRF24 modules is that the interface will need an additional node connected to a computer or a smartphone, so that these devices can communicate with the EMG nodes. Another disadvantage of these modules when compared with the ESP8266 is that they need an additional microcontroller to run the EMG node firmware. I will continue conducting experiments and hopefully find which wireless tech is right for me. Any suggestions?