Team BB: Sky-Fi

Bhuvan’s status report (Mar 2, 2019)

This week I worked on porting a pre-existing Verilog implementation of Pong. The existing application was meant to run on the Altera DE2-115 board while we are using the DE0-CV boards. This process involved looking through the DE0-CV documentation and ensuring that the interfaces matched.

After much trial and error, I was finally able to get the project to compile and program a board. Here is a first look at the game in action:

Here is a link to my Github repo which has the changes I forked from the original implementation. My next steps involve writing wrapper modules so are able to send and receive the ball and paddle position over the network.

Dhruva’s Status Report (Mar 2, 2019)

This week, I worked on testing the circuit we built last week. The circuit we built last week was that of an IR LED feeding a square wave into a transimpedance amplifier circuit connected to a photodiode. I had three key goals this week. Firstly, to ensure that the physical component of our data-transfer is foundationally sound i.e the data can be transferred from one FPGA to the other through the LEDs and that the data was discernable when being fed from the output of our circuit to the FPGA. Secondly, I planned to redesign the circuit as so that it is condensed and we can solder the receiver and transmitter components to attach them to our FPGAs in a convienent and portable manner. Lastly, I was responsible for looking at our new circuit design and selecting parts for the final circuit so that we can order it next week and have them in time when we get back from spring break which is when the first iteration of our circuit is to be built and integrated with the FPGAs.

This week, I spent a significant time in the lab and ensured that circuit was able to send the data accurately through the LEDs and that the receiver FPGA when attached to the receiver circuit would read a 0 bit as a 0 and a 1 bit as a 1. In other words, I was trying to ensure that the output from our circuit was high enough to be registered by the FPGA as a 1 when necessary. This involved tweaking parameters for logic levels within the FPGA as well as resistor values and op-amp rail values in the circuit. In order to determine this, a 1kHz square wave was generated using the transmitting FPGA and connected to the IR LED circuit. Connected to that we had our circuit from last week which had the photodiode and amplifier. Next, the receiving FPGA was connected to the output of the receiving side of the circuit and saw the waveform digitally as well as through an oscilloscope. The idea was to replicate the input 1kHz square wave we were sending as accurately as possible. Attached below are some oscilloscope screenshots which show successful transmission and the accuracy.

The yellow wave represents the input wave to the IR LED and the green represents the wave seen at the receiving FPGA. As the graphs suggest, we were quite accurate in the transmission. The difference between the high and low voltages was enough to make them discernable to the FPGA.

On zooming in, we measured the skew of the transmission (measured to the 90% high mark). We have a skew of about 30us which is very small and expected. This does not affect our design because we had planned for the skew to be slightly larger. Additionally, since we have multiple FPGAs, we know that there is going to be a difference in their clocks which is orders of magnitude higher than this skew. Our design works such that the modulation algorithm and access protocols on the FPGA take care of this skew.

With regard to the second goal of redesigning the circuit, I tweaked some component values so that we get the same output without the inverting amplifier which we had included in last weeks circuit design. This was a significant reduction in circuit components making our circuit more compact than before. This update will be reflected in our design document which is due this Monday.

Finally, we need to order parts for the circuit next week. I have finalized the LEDs for the circuit however, I still have to select the correct op-amp. The key aspect is that the op-amp has to have a high gain-bandwidth product and a high slew rate so that at the frequencies we plan to operate on, the transimpedance amplifier works properly and the skew in amplification does not affect our access protocols. The op-amp still needs to be selected before the parts are ordered sometime next week.

Raziq’s Status Report (Mar 2, 2019)

This past week was the Design Presentation, which I was responsible for. The presentation forced us to condense our thoughts and ideas into concrete specifications and plans, and the feedback received has helped refine our designs in time for the Design Report.

The modulation/demodulation techniques have continued to be a challenge, mostly because there is a wealth of theoretical papers on the subject but a dearth of reliable and affordable implementation details. For our Design Presentation, we had to present the scheme which we had the most concrete information on – Overlapping Pulse Position Modulation, from the DarkLight paper. In short, OPPM is a modified PPM technique where data in encoded in the rise time of pulses within symbol frames.

The number of time slots per symbol frame directly correlates to the number of bits per symbol. The DarkLight authors were limited to a minimum of 800ns as the pulse width, and through experimentation they arrived at a 3.2us slot width and 11 bits per symbol, which leads to a ~6.55ms symbol frame width and 1.6Kbps data rate. We are not beholden to a 0.007% duty cycle limitation, so I’ve still kept options such as OOK in the back of my mind.

In terms of EDC, I have found Verilog implementations of encoder/decoders for codes such as Reed Solomon. I haven’t yet tested with them due to the immediate focus on modulation/demodulation, but I don’t anticipate this taking very long.

Upcoming work

Select the correct Op-Amps.

Order photodiodes, LEDs and OpAmps

Test rise time, gain, bandwidth, etc. for purchased components

Figure out how to use FPGA power for the Op-Amp rails.

Test out modulation/demodulation techniques

Implement clock/data recovery and error detection/correction modules

Implement wrapper modules for Pong to be networked

Team Status Report

As a team we are working on completing the Design Report. We have been incorporating feedback and suggestions from the Design Presentation. We are also identifying parts to purchase for our MVP. We aim to order them before spring break, so that we have sufficient building and debugging time.

Bhuvan’s status report (Feb 23, 2019)

This week I spent time in the lab with Dhruva, trying to connect the photodiode transmitter-receiver circuit to the GPIO pins of the FPGA. We observed that the FPGA was able to receive and replicate a signal a the function generator but for some reason would receive and send only 0 when  sent data from our transmitter receiver circuit.

I also spent time designing the top level protocols for communication between the different nodes to send data about the players of the game and the game state.

The below picture shows a rough schematic for how players set up who they want to play against.

The below picture shows a rough schematic for how the nodes will send data to each other after the previous step.

I am in the process of drawing out a more detailed block diagram using draw.io  and a more detailed UML diagram for the protocols using https://www.websequencediagrams.com,  for use in the design presentation and report by Monday.

Dhruva’s Status Report (Feb 23, 2019)

This week, I worked on the circuit design and ran some preliminary experiments using the circuit we had built last week. This involved hooking up the circuit to the GPIO pins of the FPGA. The set up was as follows: a square wave input was connected in series to an IR LED and a resistor. The square wave from the function generator simulated the source of data which we expect in our final product to be coming from the source FPGA. On the receiver circuit, we had a trans-impedance amplifier circuit attached to an inverting op amp circuit whose output was connected to input pin 12 of the FPGA. The FPGA was programmed such that the input pin 12 was wired to pin 15 as well so we could observe the input to the FPGA through the oscilloscope as well the waveform viewer in SignalTap.

For a gain equation of a trans-impedance amplifier circuit, goes by

V_out = – I_in . R_f

where  I_in is the current generated when the photodiode receives the pulses from the IR LED. From here the circuit is attached to a simple inverting op amp so the resulting output voltage of our receiver circuit is

Attached is the diagram of the circuit we constructed.

The FPGAs GPIO pin 12 was the input V_out input and pin 15 was debug output.

Now the task was to tweak values of R_f, R₁ and R₂ so that the FPGA is able to recognize the difference between a high and a low in the square wave. The goal was to try and ensure that the output at the GPIO pin 15 (the debug pin) would replicate the input square wave being sent from the function generator.

An ideal value of R_f was found to be in the order of 100kohms. Further exploration is yet to be done to determine whether the amplifier circuit is sending the data correctly to the FPGA, because on observing SignalTap, we were not able to receive any data in the FPGA.

I also researched protocols to handle the case when the transmitter and receiver are disconnected for a brief period of time (representing a network drop). For this project a network drop would mean a physical obstruction for a short time between the transmitter and receiver. Ideally we would like to have our network be able to recover the lost data in some way so I researched methods that do this.

In terms of the schedule, the design review is next week’s Monday so we put this part on pause and in the second half of the week as a group we focused on the high level design aspect of our entire project.

Raziq’s Status Report (Feb 23, 2019)

This week, I have narrowed down on the modulation and encoding schemes that we will use, given the hardware we have available and the targets we want to achieve. On-off keying (OOK) is a simple but effective modulation scheme that uses two different intensity levels to represent 1 and 0. Other modulation schemes like variable pulse position modulation (VPPM) and overlapping pulse position modulation (OPPM) could be used, but we do not have high energy efficiency requirements for our use case. Upstream modules address the concern about flicker mitigation (where “flicker” is defined as fluctuations in perceived brightness).

As suggested by the upcoming IEEE 802.15.7 standard, I plan to use Reed Solomon encoding (for example, RS(160,128)) as a means of forward error correction (FEC) because of its quoted suitability for indoor high-data-rate communications. 8B10B run length limited (RLL) coding is used to bound the length of runs of 1s or 0s to make clock and data recovery (CDR) easier and to reduce flicker. The 802.15.7 standard does not state that RLL can be used to achieve data rates up to 100 Mbps, but with recent improvements in VLC techniques (documented in many newer research papers) I expect being able to push the clock rate to support these encoding schemes.

Below are diagrams of OOK modulation and of the datalink layer perspective of transmission/receipt from “Rapid prototyping of standard-compliant visible light communications system” (Gavrincea et al, 2014).

I personally did not make as much progress as I hoped due to some urgent deadlines. I had hoped I would have more rigorously defined our communications protocols and testing procedures. However, next week I expect to catch up on lost time due to fewer action items outside of capstone. After presenting during design review, I expect to finalize these design decisions in time for the report so that my teammates and I can advance to the implementation phase.

Upcoming work:

Fully design and document the finer details of the project over the course of the weekend

Perform research on games that can be portable/playable on an FPGA and begin work on tweaking it to work with our design

Finalize the circuit such that the data is being transmitted in an accurately.

Research the Verilog circuit FSM for error correction, correctness checks and off-by-one errors so that data is not dropped during transmission.

Research protocols to handle the case when the transmitter and receiver are disconnected for a brief period of time.

Build the receiver so that a square waveform from the function generator is seen in the FPGA.

Team Status Report

As a team, we are working on getting the slides ready for the design presentation. We are drawing detailed schematics, block diagrams and UML diagrams to describe the protocols and working of our project.

We met with Professor Tamal on Wednesday and received feedback on what to include in our presentation and are working towards that. We are currently on track with our proposed timeline. It appears next week is going to be especially busy due to the design review and a large volume of research and implementation work.