To improve efficiency and stability there were 2 things I needed to do.
- Send data in larger packets to conserve bandwidth
- Implement a header periodically to allow the two signals to be periodically synced
To implement part one first we would need to implement a system to create a data stream of … A0A1A2A3B0B1B2B3 and so on. Furthermore, to implement the second part regarding the header we would need to create a data stream of H0H1H2H3A0A1A2A3B0B1B2B3.
However to do this we need to consider the fact that the data stream incoming will be less than the amount of data to be output. This requires rate transitions and registers to store the data. Thus the following methodology will be this.
- Read data
- Convert A, B channel data into [4:1] vectors
- Push both to a separate registers at the same time
- Pop A, B registers (such that 4 bits of each are released at a time to create A0A1A2A3B0B1B2B3)
- Attach the header (H0H1H2H3A0A1A2A3B0B1B2B3)
- Output data to receiver
Steps 1 and 2 are the same as before. However steps 3 and 4 were a bit of a pain to implement.
The push is done continuously by a clock and is essentially the “sampling” rate of the signal. However the pop logic is more interesting.
To properly control when to pop several things are required. 1. A way to select a channel, 2. A way to decide when to pop. A counter will be used to select a channel and then the logic that is used to pop is shown.
Finally after the data is properly popped a header is attached.
Here is the implementation. Again it is done in MATLAB 2015RB.
Originally, the idea was to implement a pilot signal and have the receiver decode the message and use a header to determine where the beginning of the signal lay. This was a relatively good idea given that the boards themselves only had to be synced up ever minute or so.
However as I learned after discussing with a professor is that while that should work in theory generating an accurate clock (through clock recovery) just based on a trigger would be nearly impossible to do.
Thus the idea evolved and changed such that training data will be sent first to the receiver to train the clock and then begin transmitting data with a periodic header to help recalculate the deviation in the clock. This would be implemented with the help of a phase locked loop.
The PLL block in Simulink outputs the frequency of the current input waveform and the deviation in the frequency over time. Thus one can use these two values to adjust and tune the frequency to their liking. Given this, I created a variable frequency oscillator (square wave) which would respond to the changes in frequency. This was taken from a Matlab FAQ post and adapted such that it would automatically ceil/floor given a certain threshold.
However this was ineffective and approximating with thresholds was not good thus given a constant frequency of 1khz with deviations from the random number generator of only 0.2Hz….the following result was produced.
In addition to this, the Simulink implementation of the PLL is utterly horrendous… Running the PLL with any sort of input especially with higher frequencies even at a frequency of 1kHz did not run at real time.
This led me to abandon clock recovery try and try to explore various transmission schemes such as synchronous and asynchronous which will be discussed in the next post.