Lock In Day 2 (21/05/25)

 

Lock In Day 2

 

Short meeting

We started the day with a short meeting to quickly remind ourselves where we were in the project and the next steps that needed to be taken.

 

Working on areas

 My next task was to try to reconfigure the serialRead code that runs on the pi so that it will receive the ecg values and convert them to audio so that they can be sent using WebRTC.

 

Showcase

The showcase consisted of each group demonstrating what they managed to achieve.

We started by showing the WebRTC group (Daniel & Andrew) who managed to send a sine wave in real time and output a sound from that signal on speakers.

Dean, Jay & Alex showed the AWS ec2 instances that they created which would host the website where we could see the heart rate.

Next, the Unity group (Brendan & Mark) showed their unity app which displays a heart that would beat to the tune of a song (stayin alive by the Bee Gees was used for the demo)

Arthur demonstrated the buffer created so that values could be logged in an Excel sheet

Lastly, Andrew & I demonstrated the original pipeline that uses MQTT to show what our goal was for getting data from an ecg sensor to a webpage that would display the data in real time.

 

What didn’t work + why

We did not get to implement the full pipeline with WebRTC because there was a lot of struggles with getting real time data to send. Had we got that work as intended, it could have been implemented into the serial read code that runs on the pi so that it would send the data to the ec2 instance running on AWS. We could then connect the Unity app to the instance to retrieve the heart rate data and display a beating heart on the app.

The biggest problem was that there was a huge lag for retrieving the data. I benchmarked the time it took to retrieve the data by sending ‘0’ and when I pressed a button on the microbit it would send the value ‘1’ and I could then observe how long it would take to display ‘1’ in the terminal on the raspberry pi.

When I tried this, there was a 12 second delay between pushing the button and seeing the data in the terminal.

This may have been due to several factors such as the rate at which data is being sent, the time it takes to convert the integer value from the heart rate sensor to another value and even the raspberry pi being overloaded with work could potentially cause this delay as in some cases I noticed the raspberry pi CPU load spiked up to 95%.

 

Recommendations for next steps

I would like to investigate the use of MQTT, while it is not designed for real time data streaming, the original pipeline proved that we could get a successful stream of data at an extremely high rate (33 messages a second) which was sufficient to create a smooth Guage that would oscillate at the speed of the heart.

I would like to investigate the use of cloud flare or port forwarding to make the raspberry pi publicly available which would allow for an ec2 instance to become a subscriber of the pi’s locally run MQTT broker and receive the heart rate data.

The other thing I would like to do is investigate the feasibility of sending heart rate data from multiple Microbits to the raspberry pi. This would be achievable by sending a unique Identifier that is generated by the microbit as soon as it is powered on.

Another solution would be to send the heart rate along with the Mac Address of the Microbit, this would be a much more effective solution as in the event that the Microbit loses power and reconnects shortly after, the mac address will be the same so there will be consistency along the pipeline for that device where as a generated unique identifier will change when power is regained by the microbit.

 

 

Closing (conclusions)

In conclusion, This was an exciting project. It was exciting to work in a large group of people who were working on different areas of the pipeline as it required a lot of communication between the group to ensure that everyone was able to complete their tasks on time.

 

I enjoyed investigating WebRTC and it was interesting to compare the differences between other protocols that I am familiar with. I also enjoyed seeing the work that the others were doing who did different course streams that me such as the game development students who worked on the Unity app.