Posted on

Team Status Report 2/14

We believe the most significant risk to the project is still the level of environmental noise and interference that will occur with the IR communication. Since our parts have only just arrived at the end of this week, we have so far been mitigating the risk with plenty of research and design into error detection + correction to strengthen the end-to-end accuracy of our solution. In the coming weeks we plan on integrating the LED/Receivers early on with our signal processing code to determine the actual risk and if different parts / more design will be needed to mitigate.

 

The only minor change to our design is we will likely be using 940nm wavelength IR light instead of our proposed ~1400nm due to higher availability. This will likely be an improvement for the project in general, the 940nm parts are cheaper, have better directivity, and are more suited to IR serial communication due to their commercial use in remotes. This choice will likely incur a small additional cost of us needing to purchase clear IR filters to place on the glass lenses as a safety backup, since the smaller wavelength is technically less safe (although still low enough power to be completely harmless) it would not hurt to include the filters.

No changes have occurred to the schedule, we are well on track and likely a bit ahead of schedule for now.

Posted on

Todd’s Status Report for 2/7

This week consisted mostly of work with the rest of the team relating to the proposal presentation as well as the parts list so we could begin ordering parts that we needed as soon as possible.  For the parts list, I worked alongside DJ and David to select light sources and receivers. I also did research to find an appropriate microphone for us to use initially and in our final product. I settled on initially using a small I2S MEMS breakout board we can get from Adafruit that seems to be a good base for initial testing. We also found a similar form factor bone conduction microphone that could serve our purposes but does not come with nearly as much documentation or additional components as the breakout board does. Initially, the Adafruit breakout board should serve well and then we could transition to the bone conduction solution if we are confident on other aspects of the project. Since I am more focused on the hardware for this project, I am not able to make as much tangible progress on the project until parts arrive, but I have been doing research and thinking about how we want to integrate all of the parts of the project. As of now, I am also acting support for other parts of the project such as the design review slides and documentation.

Our progress is on schedule, but I am hopeful that the parts that we need to get started come in soon so that I can start with testing and assembly of circuitry. Since we were proactive with part selection and ordering, this should not be a problem.

Next week I will primarily be focused on helping the rest of the team with the design review slides and report. For deliverables, I want to develop a testing plan and framework so that we can hit the ground running once our parts arrive.

Posted on

Team Status Report for Feb 7

  • What are the most significant risks that could jeopardize the success of the project? How are these risks being managed? What contingency plans are ready? As of now, we think our main risks will be related to noise sensitivity and light interference. While we do not fully know these risks until our parts arrive, they are being managed currently by having a wide array of options to test in our system. For example, we have multiple different light sources either ordered or in a backup list to order if needed. Overall, our IR protocol will function somewhat like a TV remote. Because of this, we have some documentation available for potential risks and these will help us to mitigate issues as they arise. For the IR components, our contingency plan is to try to switch to a more well documented transmission protocol, like RF. For something like our microphone, our contingency plan is to switch to a more reliable high sensitivity bone microphone and mitigation plan is to perform basic pre-signal processing if we have too much noise. 
  • Were any changes made to the existing design of the system (requirements, block diagram, system spec, etc)? Why was this change necessary, what costs does the change incur, and how will these costs be mitigated going forward? The only change we made so far is ordering 950nm LEDs instead of 1450nm. We plan on using the 950s for testing and then switching to 1450nm. Originally we had planned on 1450nm the whole time but they are expensive and we didn’t want to throw budget away for testing parts. After more research on LED safety, we know that 950nm LEDs are also safe. But because of some potential added risk, we are now definitely adding IR filters as a fail safe. No other main changes were made to the overall design system. However, we were able to get 8GB RPis (which is something we were debating), giving us more leeway to put on larger software processes. Because this was loaned to us, there is no cost to our budget or design.
  • Provide an updated schedule if changes have occurred.NO SCHEDULING CHANGES THIS WEEK

 

    • This is also the place to put some photos of your progress or to brag about a component you got working.-Proof of concept VOSK, we are also close to live test translation software. 
Posted on

David’s Status Report for Feb 7

I began the week off spending time fine tuning both our proposal slides and the actual presentation. Because I was the one presenting, I added some notes for myself and practiced for a few hours prior to actually presenting. After this, I spent the middle of the week researching and coming up with a parts list, specifically focusing on the voice to text components of our project. I began with research on specific lighting components and searched through digiKey for their respective parts lists. Along with DJ, we determined that 950nm was sufficient for testing and had good directivity and ability to modulate frequency. After, I did research on open source models such as Open AI Whisper and Vosk, before ultimately choosing Vosk as the most promising V2T software to begin with. I then made the first proof of concept Vosk model that translated chunked up audio files into English test. This was a good enough proof of concept that we felt comfortable selecting Vosk as our primary focus for open source V2T. Following this, I did research on how to make V2T compatible on raspberry pi with some of DJs modulation specs. I have now been researching and playing around with the pigpio library for RPi and its ability to potentially be our way to accurately modulate eyeR.

My progress is on or ahead of schedule. Most of my scheduling for this week was regarding determining the parts we would use for our project. Not only did I complete this, but we put in order forms and have begun making Proof of Concepts for some of our system components. Mainly, the V2T software seems easier to use than we initially thought so we (DJ/I) are in a good position on that. We are still waiting for confirmation of our ordered parts but hoping that those are also as expected.

Next week, I hope to begin integrating the V2T software and the Rpi. If our microphone is here by then, I would like to get the RPi to take in microphone waves and convert to text. Otherwise, I would like to deliver a similar system but with the microphone replaced by computer audio files. I would like to have the software on the RPi for live translation as well. From here, I can then (not necessarily next week) coordinate with DJ and start to mesh together software components.

 

Posted on

DJ’s Status Report for 2/7

At the beginning of this week I did some initial research into serial communication protocols as well as open source speech to text to determine a rough estimate of the specs needed for our parts. I assisted in making a rough budget sheet and determining vendors for all of our parts. Then I completed the order forms for all of the components needed for our MVP.

Later in the week I experimented with Vosk speech to text, which we’ve decided to use for our project because it provides accurate, low-latency, live transcription. It also offers a variety of models of different sizes.

I also continued my research into serial communication protocols, and IR communication protocols specifically. I’ve determined some rough design ideas, specifically using a 38kHz carrier frequency combined with the ideas underlying the NEC infrared protocol (PWM) and Hamming error correction (likely 10,5) to achieve our goal of low latency, low error transmission that can support 200-250 WPM.

We are on schedule, and having been able to put in the order for all of our needed parts, as well as having the Raspberry Pis arrive already at the end of this week, puts us in a good place to continue well on track next week.

Next week a lot of my attention will be focused on the Design Review slides as well as planning for the Design Report. In terms of deliverables I plan to implement the groundwork for our encoding/signal generation and get the code running & testable on the Raspberry Pi.