Group Actions
Engagement
  • Author Author: quisss
  • Date Created: Date Created
  • Views 773 views
  • Likes 3 likes
  • Comments 4 comments
Related
Recommended

The (Actual) Final Entry

quisss

I know I said my last post was the final one, but I decided to write one more summarizing some of the decisions I made, and what makes the Real Time Coach Athlete Monitoring System so great.

 

The first critical decision that I made was to make this work with a large number of athletes rather than just one. This was largely due to the fact that while some sports are individual, many of them consist of a team with a number of athletes that each need to be monitored. This was something that I kept in mind throughout the competition and it inspired my next decision.

 

The second critical decision I made was not to use bluetooth as the direct communication to the device. Bluetooth is limited in it's range which means that the entire system is only functional if you are close enough. I knew that I would have to use bluetooth to some extent as I wanted the front end to run on an android phone, but since bluetooth connects in a one-to-one manner (one device can be connected to one other device. This meant that I would have to have some sort of router that the phone communicates to with bluetooth, and then that device can communicate with all of the individual RTC units. I did this using a serial bluetooth monitor hooked up to an arduino board with a wireless shield, which brings me to my next decision.

 

Xbees were the logical choice in wireless communication. They have very good range, are not very expensive, and require minimal skill to implement. This means that in order to put this together, there is not much skill required meaning that it could potentially be reproduced very easily. Also, there are many different models of xbees, some of which have an effective range of greater than 10 miles, effectively allowing you to use this device in activities with very large ranges such as marathons.

 

I was going to make my own heart rate monitor, but after acquiring all of the materials, I realized that there was not enough time to finish, test, and perfect it before the competition was done. This lead to a major spike in price, but could be reduced to $30 or less per HRM with more time.

 

All in all, my goal with this was to make something that is affordable, easy to manufacture, and easy to use. I feel that I accomplished each of these fairly well.

 

 

In total, the costs come out as follows:

 

Item nameCost (USD)
Wearable Unit
Chest and Shoulder Strap~10.00
Arduino Board24.72

Wireless Shield

17.12
Xbee25.47
Assorted Wires and Connectors~5.00
Heart Rate Monitor50.32
9v Battery~2.00
Bracket and bolts~2.00
Foil (Electrodes)~.50
Accelerometer32.63
3D Print~4.00
Total169.76
Communicator Unit
Arduino Board24.72
Wireless Shield17.12
Serial Bluetooth Module11.99
9v Battery~2.00
3D Print~3.00
Total58.84
  • in reply to shabaz

    This is a concept known as edge detection or state change detection. It is much like switching a switch from off to on. We can do this because during heartbeats there is a significant change in the input which makes the input recognized as high. I actually did not know you could to this, but it worked, and it worked well, so that was pretty cool. There was actually no trimming that needed to be done on my part, the AD8232 unit put out a very clear signal, as can be seen in the lone video I produced.

     

    Again, I would love to make a video demonstration, but the module is all packed up and ready to go, and the deadline is up. These criticisms are good, I wish I would have thought of them earlier.

  • in reply to quisss

    The reason it would be good to see a demo video, is because according to the code, a digital input is used for the heartbeat. But as I understand, the heart-beat detection board outputs an analog signal. It seems hard to see how effective this was (I'm presuming it was effective since you say it was, but would be good to see this). Did you have to trim the analog level until the heartbeat was detected reliably? Did the trimming have to change if a different user attached it, or if the electrodes were moved?

     

    void loop() {
    time = millis();
    heart_input = digitalRead(heart_signal);
...
    if ((heart_input != lastinput)&&(heart_input == HIGH)) {
        // If the pin state has just changed from low to high (edge detector)
        period[3] = period[2];
        period[2] = period[1];
        period[1] = period[0];
        period[0] = (int)(time - starttime); // Compute the time between the previous beat and the one that has just been detected

  • in reply to shabaz

    Wow, you caught a lot of stuff that I missed. Technically the deadline has passed, so while it is unfortunate that I cannot add all of this in another entry, I would love to show as much of this information here as I can. No, you did not miss it, I just didn't think to add all of it.

     

    The heartbeat was received in a very reliable manner. With arduino you can effectively detect spikes in digital input as can be seen in the code here: https://github.com/TheAustinSeven/RealTimeCoachArduinoCode/blob/master/senderCode/senderCode.ino in line 69. This worked with virtually no errors. The only two issues are that every once in a while the arduino picks up two readings per beat meaning that it will get one at about 800 milliseconds, and the next at about 50 milliseconds, and also it would take sometimes up to 10 seconds to filter the heart beat signal to read it accurately. During this time you get really weird readings for heart rate such as a heart rate of a few thousand beats per minute. The devices functions were not hindered by physical activity as it was held in place fairly well.

     

    I used the AD8232 HRM for heart beat detection. This had output go directly to the 7th pin of the arduino module. The accelerometer used the analog pins A0-A2. The battery was hooked up directly to the Vin pins of the arduino.

     

    As for showing data, this is where I really wish I had thought of this earlier. The device is all packed away and ready to be shipped, and I collected all of the data using the Logcat tool in android studio, so I could see what data the phone was actually receiving. This data is not automatically saved, and I wish that I had decided to hold onto it, but I did not, and it is no longer available. This was a fairly bad mistake on my part. With more time I could take a video of the logcat display which essentially shows the data array that is received and the heart rate for each communication.

     

    I am really tired, so I'm going to end this response here, but if you have any more questions, feel free to ask them.

  • Hi!

     

    I've looked at entries with the tag real_time_coach, but still struggling to find all the information.

    Any chance of a schematic or assembly diagram showing what analog board you used, and how it was connected to the battery and the Arduino?

    Also, I can't see anywhere how well the heartbeat was detected - I see the post which shows a waveform on an oscilloscope, but how did it behave in practice when you (say)

    run on the spot, wear it for an hour, etc., and what data was logged during the time? How did the analog board connect to the body for gathering the heartbeat data?

    Was it reliable? Any false alarms? Maybe I've missed all this, but I can't find it.

    Also maybe just a quick video showing you connecting it to yourself or someone, and running or doing some exercise while seeing the reported data or something - a picture says a

    thousand words : ) and for a demo a quick video says a lot more.