Posted on

Team Status Report 2/21

We believe that the biggest risk at the moment is making sure that we are able to cleanly interface with the IR LEDs and the receivers. We had some trouble getting the LED to work with the RPi 5, so we are pivoting to using PICO boards that should be easier to interface. So right now on that end of the project, we are waiting for those to come in to continue to test the communication and IR signal generation.

However, the RPi 5 is working very well with the voice to text software and we were able to get it working with the I2S MEMS microphone that we have, which is a big step.

The only change to the design right now, as I mentioned before, was switching to RPi PICO boards for the IR LED component of the design. This was necessary due to the GPIO difficulty on the RPi 5 that we have. The costs to do this aren’t too high due to the affordability of the PICO boards.

Our schedule remains the same since we are already ahead of schedule and we were still able to get other parts of the device working well.

Here is a short video example of the V2T on the RPi using our MEMS mic:https://youtube.com/shorts/DJ7xVhHPy48

Posted on

DJ Status Report for 2/21

At the beginning of this week I spent a bit of time doing some final preparation for my design presentation. Also towards the start of the week I did some work with David with signal generation on the Pi. Because of the change in how the GPIO pins work on the Pi 5, none of the libraries seemed to have the functionality that we needed (hardware timed and able to create a wave of multiple pulses at once) to achieve the accuracy we want, so we were testing a method using a Linux kernel driver for IR that had mixed reviews on the Pi forums. This didn’t work so we are migrating our design to use a Pico to handle the IR hardware interfacing.
At the end of the week I pivoted and got the Vosk speech to text working on the Pi with our breakout mic.

I am still on schedule if not slightly ahead again. The Vosk took less time to integrate with the Pi than I had anticipated, and I’ll be able to get back to signal generation when the Picos arrive next week so the schedule is looking good.

Next week i’ll be spending some time on the design report document. I’ll also be working (along with David) on the signal generation and decoding code on the Pico as well as the code to accurately query Vosk.

Posted on

David’s Status Report for 2/21

What did you personally accomplish this week on the project?

I spent a decent amount of time in the early week with DJ on beginning the software for our project. We setup our RPis, but our V2T onto the Pis and began attempting GPIO modulation code. Unfortunately, the Pi 5 has a much more difficult time with hardware level GPIO than past Pis. As a result, I also spent time reformulating some design to use a pico for led control. This should be a far far easier way to actually get code to modulate the light. Aside from that, I did some work on getting the LCD screen interface coded. I have also spent about 5 hours beginning design report.

Is your progress on schedule or behind? If you are behind, what actions will be taken to catch up to the project schedule?

We are still ahead of schedule. Along with DJ we have packet encoding and decoding programs made. With our switch to pico, our scheduling may definitely be shifting a little bit in the next week or 2 depending on how difficult that is to work with.

What deliverables do you hope to complete in the next week?

Next week my main focus is working on pico integration. I (we) would like to get the modularized light working so that we can begin integrating with the V2T and our encoding / decoding software. Based on research this week, we think the pico should be easy to work with for this as it is designed more as a hardware-level microcontroller. Aside from this, I am also working on design report which we will complete by Friday.

Posted on

Todd’s Status Report for 2/14

Personal Accomplishments this Week

Along with David, I was out of town for this week so thew work that I as well a the team got done was mostly related to the design review slides. I worked alongside the team to finish the slides, working on the diagrams and slides related to hardware. Other than that I did some further parts research on the parts that we ordered that we can begin work as soon as we can with the components.

On Schedule?

I am personally on schedule for what we wanted to accomplish this week and will be ready to begin the parts testing that we are planning on doing next week.

Next Week Deliverables

When we are doing testing next week with the RPI and LEDS, I want to keep running notes and documentation so that we have all of the information that we need so we can look back at how things performed and don’t need to do any redundant testing later.

Posted on

DJ Status Report 2/14

This week, most of my time was spent working on the design presentation and preparing to present, as I am presenting this presentation. Other than that, I finalized my design research into our IR communication protocol (pictured below) and worked out the encoding of letters and the timing of the protocol to ensure that we meet our use case requirements for speed and latency (200-250WPM and 500ms latency), while making sure that we’ll have enough leeway to handle errors. At the end of the week, I also worked on the code for our Hamming encoding, testing to make sure that it would fix single bit errors and detect 2 bit errors for our custom letter encoding.

I am well on schedule with my portion of the project, slightly ahead as I hadn’t planned on beginning coding until next week.

Next week I believe that a good chunk of my time will be spent working on. the design report. I’d like to also decide on a Raspberry Pi library to use for signal generation and detection through the GPIO. Changes with how the GPIO work from the Pi 4 to 5 have apparently rendered a lot of GPIO libraries incompatible with the Pi 5, so this will require some research to determine a good fit for our project. Hopefully I’ll be able to test some simple signal generation with Todd and the waveform generator at the end of next week.

 

Posted on

David’s Status Report for Feb 14th

What did you personally accomplish this week on the project?

I was out of town for much of the week so most of my accomplishments were remote accomplishments (plus we were waiting on parts anyways). I spent a decent portion of time creating and then going through batches of edits for the slides so that DJ is ready to present next week. I was largely ahead of my gantt schedule but I went ahead and continued research into signal Rpi protocol libraries. I have researched the gpiozero / libgpio library and went through example codes that proves that it should be able to hit our design requirements of light modularization.

Is your progress on schedule or behind? If you are behind, what actions will be taken to catch up to the project schedule?

I am ahead of schedule, we got through V2T relatively fast and can now start transitioning to hardware components as all of our parts should now be here to pick up!

What deliverables do you hope to complete in the next week?

Next week my main focus is working on packet protocol. I would like to use the GPIO library(s) to actually write the code for the led modularization and be able to code our encoding scheme into the RPi. Along with todd, we would also start some hardware implementations such as putting the V2T onto the Rpi and beginning to test light modularizations.

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.