Posted on

Thomas’ Status Report for 4/6/24

Thomas Lee

  • I started this week by working on system integration and verifying that our whole project was operating smoothly end to end. This was in preparation for the interim demo that we had this past week. This involved some code refactoring and submodule implementation, as well as manual testing in the lab to make sure we could have a polished demo. I also went and acquired a lighting kit from the IDeATe lab, getting two new DMX-capable lights, more necessarily cables, and the ENTTEC DMX to USB converter, which a previous group had told us was required to transmit signals from our laptops/Raspberry Pi’s. I set up the new lights and compared their functionality to the previous lighting fixture we had by testing a few different DMX signal generation libraries. I also wrote a few different configurations of Java test scripts to see if they would better and more organically than the older lighting fixture. Below is a video of setting different colors at regular time intervals on the new lights, which are simpler but may have a lower barrier of entry:
    https://drive.google.com/file/d/1ZJ4hMDnmAVAk5n2S4THXyMkTPESUGbx9/view?usp=sharing
    Unfortunately, we still do not have that great of an understanding of how the different channels and intensities work for the DMX controlled lighting fixtures, especially since these new lights did not come with a user manual. This will definitely require some more systematic testing to reverse engineer the behavioral specifications of the lights next week.
  • Verification: I will use timestamped requests to determine the user input to internal system round-trip time. This will help us determine the effective latency of our web app, backend, and main RPi core system for our use-case requirement of a responsive & tactile system for users. We will also create a test script that simulates multiple users to check that the system can maintain websockets for and accept requests from 50-150 concurrently connected users. This will verify our system’s effective capacity and robustness. In terms of testing we have already done we have only ran basic functionality and behavioral correctness tests for the queue, recommendation  & Spotify API request systems, and the web app.
  • My progress on the web app and queue manipulation core modules is on schedule, but the lighting system is behind schedule. There is no way to catch up on progress in regards to the lighting system besides focusing on it and spending more time on the lighting modules, which I intend to do next week.
  • Next week I will be putting much more focus on the lighting system, as there are still some issues with controlling the lights finely. I will attempt to learn how to use them better and have some skeleton lighting schemes ready for integration with the other subsystems functioning on a basic level.
Posted on

Matt’s Status Report for 4/6/24

  • This week I started off by adding the functionality to send the updated queue after a song recommendation is sent from the recommender pi.  It first sends the updated queue with just a request added to the queue then when the queue is updated, the backend sends that to all clients. I added the keep-alive functionality for users to be active at least once for 15 minutes. If the timer runs out or if the user closes the page then all of their votes will not be counted towards the likes/dislikes of the songs. The user’s likes and dislikes are still saved so when they do make another action on the page then their votes will be restored to the songs still available. I was also playing around with what should log users out. The old version had it so if they refreshed then it would log them out. Now I have the app save the data so refreshing will not make a new user. I also made some UI fixes. There is now a designated dj color and all the songs recommended by the dj say it was queued by the dj. Also when song recommendations are pending there is no option to like or dislike. 
  • Testing:  I have only run very basic tests with Luke and Thomas so far where we all queue a bunch of songs and verify if it is what we want. To test the app/Pis further I want to make a script to simulate 100-150 users making requests at random times and monitor the app for correctness and to see how it handles the load. Also for the latency we can either input timing code for the simulated users, or I can just run a user of my own while the app is under a heavy load and see if there is a noticeable difference. 
  • I’m on schedule. I did all of the things I said I wanted to do last week. 
  • Next week I plan to make tests like the ones described above and also help out in other areas of the project. The most important thing is having the backend know what song is playing when so that is probably where I’ll go first.