Conclusion and Recommendations » History » Version 10
Version 9 (PASCHOS, Alexandros, 12/15/2015 03:53 AM) → Version 10/14 (Gimenez Silva, Adriana, 12/15/2015 10:42 AM)
{{toc}}
h1. *7. Conclusion and Recommendations*
h2. *7.1 Conclusions*
LabVIEW LabView Communications is indeed a good tool designed for studying RF communications, better equipped with special this type of work, it has features specific for this purpose. Nonetheless, communication chains. Nevertheless, considering that this it is still new new, in comparison with other versions of NI software, the best support to have while working on LabVIEW Communications would be is from the NI forum (opened less than a year ago). It is still recommended to have LabVIEW System Design Software, as a lot of LabView, since some examples found on the internet with this software could also can be applied to LabVIEW on LabView Communications Design Suite.
USRPs Suite, but are a built on LabView.
USRPs, they're good tool for protoyping RF communication systems, with and easy to use, programmable elements that can improve signal transmission or reception. Using (features), but beware of synchronization issues, and depending on the USRP with the software mentinoed above creates a good environment for research, simulating a given communication chain with different stages such as modulation, filtering, coding, interleaving, etc. However, when communicating with USRPs synchronization is of high importance, but version they can be difficult easily or harder to achieve as war our case.
Adding coding to a transmission can greatly synchronize.
Coding does effectively improve the performance, communications, as was seen when applying BCH coding. This will allow on the system graphs coding is not hard to require less energy per symbol, but be able to achieve the same desired BER than when no implement, however LDPC coding is used, impacting cost in a positive way as well as power requirements. It also depends on the type of comparison with Reed-Solomon, BCH or convolutional coding applied, BCH is a block code, but the parameters little harder to implement will depend on the length of bit stream. In satellite communications, there is a large amount of data being dealt with, so the parameters are very high, in the order of thousands (depending on the size of the frame). Even though LDPC did not work as anticipated when applied grasp, having to our existing transmission system, it was proven on a previous example that concatenated codes of BCH and LDPC gives a better performance, since LDPC offers powerful coding and decoding, and given current computational power, it calculate likelihoods for decoding which can be widely used compared add complexity to years ago, when it was first designed.
There was a learning curve for training on functionalities of USRPs and LabVIEW Communications. It was of high interest to understand the different aspects of
each requirement and observe how varying different parameters could add complexity, or affect the signal quality, constellation, coding and decoding. simulation.
h2. *7.2 Futher Improvements*
h3. *7.2.1 Synchronization*
In the context of evaluating a satellite communication chain over USRP this project has to provide synchronization between the Transmitter and the Receiver. For a very promising designing software tool like LabVIEW Communications we managed to implement the Transmission providing modulation, filtering, coding and the implementation of an AWGN channel and accordingly for the Receiver, demodulation, matched filtering and decoding. Although synchronization is not an easy task we would have liked to accomplish that. However this project will be shared among the LabVIEW Community and uploaded in the official NI LabVIEW Communications System Design Suite Support http://www.ni.com/examples/ for further academic research, improvements and hopefully a synchronized version over the USRPs.
h3. *7.2.2 DVB-S2 compliant*
The DVB-S2 standard includes many features which were not implemented in the context of this simulation. For example in Forward Error Correction the standard uses an Interleaver to scatter burst errors. The use of interleavers would be a complement to our work done, and one feature that given improvements in the time, would be interesting $BER$ due to implement and observe how it further improves the communication chain, by reducing even more the Eb/No required for a specific BER.
Interleaver could complement our work.
h1. *7. Conclusion and Recommendations*
h2. *7.1 Conclusions*
LabVIEW LabView Communications is indeed a good tool designed for studying RF communications, better equipped with special this type of work, it has features specific for this purpose. Nonetheless, communication chains. Nevertheless, considering that this it is still new new, in comparison with other versions of NI software, the best support to have while working on LabVIEW Communications would be is from the NI forum (opened less than a year ago). It is still recommended to have LabVIEW System Design Software, as a lot of LabView, since some examples found on the internet with this software could also can be applied to LabVIEW on LabView Communications Design Suite.
USRPs Suite, but are a built on LabView.
USRPs, they're good tool for protoyping RF communication systems, with and easy to use, programmable elements that can improve signal transmission or reception. Using (features), but beware of synchronization issues, and depending on the USRP with the software mentinoed above creates a good environment for research, simulating a given communication chain with different stages such as modulation, filtering, coding, interleaving, etc. However, when communicating with USRPs synchronization is of high importance, but version they can be difficult easily or harder to achieve as war our case.
Adding coding to a transmission can greatly synchronize.
Coding does effectively improve the performance, communications, as was seen when applying BCH coding. This will allow on the system graphs coding is not hard to require less energy per symbol, but be able to achieve the same desired BER than when no implement, however LDPC coding is used, impacting cost in a positive way as well as power requirements. It also depends on the type of comparison with Reed-Solomon, BCH or convolutional coding applied, BCH is a block code, but the parameters little harder to implement will depend on the length of bit stream. In satellite communications, there is a large amount of data being dealt with, so the parameters are very high, in the order of thousands (depending on the size of the frame). Even though LDPC did not work as anticipated when applied grasp, having to our existing transmission system, it was proven on a previous example that concatenated codes of BCH and LDPC gives a better performance, since LDPC offers powerful coding and decoding, and given current computational power, it calculate likelihoods for decoding which can be widely used compared add complexity to years ago, when it was first designed.
There was a learning curve for training on functionalities of USRPs and LabVIEW Communications. It was of high interest to understand the different aspects of
each requirement and observe how varying different parameters could add complexity, or affect the signal quality, constellation, coding and decoding. simulation.
h2. *7.2 Futher Improvements*
h3. *7.2.1 Synchronization*
In the context of evaluating a satellite communication chain over USRP this project has to provide synchronization between the Transmitter and the Receiver. For a very promising designing software tool like LabVIEW Communications we managed to implement the Transmission providing modulation, filtering, coding and the implementation of an AWGN channel and accordingly for the Receiver, demodulation, matched filtering and decoding. Although synchronization is not an easy task we would have liked to accomplish that. However this project will be shared among the LabVIEW Community and uploaded in the official NI LabVIEW Communications System Design Suite Support http://www.ni.com/examples/ for further academic research, improvements and hopefully a synchronized version over the USRPs.
h3. *7.2.2 DVB-S2 compliant*
The DVB-S2 standard includes many features which were not implemented in the context of this simulation. For example in Forward Error Correction the standard uses an Interleaver to scatter burst errors. The use of interleavers would be a complement to our work done, and one feature that given improvements in the time, would be interesting $BER$ due to implement and observe how it further improves the communication chain, by reducing even more the Eb/No required for a specific BER.
Interleaver could complement our work.