https://nicolas-barbot.ovh/wiki/api.php?action=feedcontributions&user=Nico&feedformat=atomNicolas Barbot website - User contributions [en]2022-01-17T19:51:29ZUser contributionsMediaWiki 1.36.0https://nicolas-barbot.ovh/wiki/index.php?title=List_of_Publications&diff=483List of Publications2021-11-06T08:32:40Z<p>Nico: </p>
<hr />
<div>__FORCETOC__<br />
<br />
==Journal Articles==<br />
*F. Requena et al., "Thermal Modeling of Resonant Scatterers and Reflectometry Approach for Remote Temperature Sensing," in IEEE Transactions on Microwave Theory and Techniques, vol. 69, no. 11, pp. 4720-4734, Nov. 2021, doi: 10.1109/TMTT.2021.3096986.<br />
<br />
*R. Unnikrishnan, O. Rance, N. Barbot, and E. Perret, “Chipless RFID Label with Identification and Touch-Sensing Capabilities,” Sensors, vol. 21, no. 14, p. 4862, Jul. 2021.<br />
<br />
*Z. Ali, E. Perret, N. Barbot and R. Siragusa, "Extraction of Aspect-Independent Parameters Using Spectrogram Method for Chipless Frequency-Coded RFID," in IEEE Sensors Journal, vol. 21, no. 5, pp. 6530-6542, 1 March, 2021, doi: 10.1109/JSEN.2020.3041574.<br />
<br />
*N. Barbot and E. Perret, “Linear time-variant chipless RFID sensor,” ''IEEE Transactions on Antennas and Propagation'', submitted.<br />
<br />
*F. Requena, N. Barbot, D. Kaddour, and E. Perret, "Thermal Modeling of Resonant Scatterers and Reflectometry approach for Remote Temperature Sensing" IEEE Transactions on Microwave Theory and Techniques'', accepted.<br />
<br />
*N. Barbot, O. Rance, and E. Perret, “Classical RFID vs. chipless RFID read range: Is linearity a friend or a foe?” ''IEEE Transactions on Microwave Theory and Techniques'', accepted.<br />
<br />
*N. Barbot, O. Rance, and E. Perret, “Differential RCS of modulated tag,” ''IEEE Transactions on Antennas and Propagation'', pp. 1–1, 2021, early access. doi: 10.1109/TAP.2021.3060943.<br />
<br />
*R. De Amorim, R. Siragusa, N. Barbot, G. Fontgalland, and E. Perret, “Millimeter wave chipless RFID authentication based on spatial diversity and 2D-classification approach,” ''IEEE Transactions on Antennas and Propagation'', pp. 1–1, 2021, early access. doi: 10.1109/TAP.2021.3060126.<br />
<br />
*Z. Ali, E. Perret, N. Barbot, and R. Siragusa, “Extraction of Aspect-Independent Parameters Using Spectrogram Method for Chipless Frequency-Coded RFID,” ''IEEE Sensors Journal'', pp. 1–1, 2021. doi: 10.1109/JSEN.2020.3041574. [Online]. Available: https://hal.univ-grenoble-alpes.fr/hal-03120442.<br />
<br />
*F. Requena, N. Barbot, D. Kaddour, and E. Perret, “Contactless characterization of metals’ thermal expansion coefficient by a free-space RF measurement,” ''IEEE Transactions on Antennas and Propagation'', vol. 69, no. 2, pp. 1230–1234, 2021. doi: 10.1109/TAP.2020.3010982.<br />
<br />
*N. Barbot, O. Rance, and E. Perret, “Chipless RFID reading method insensitive to tag orientation,” ''IEEE Transactions on Antennas and Propagation'', vol 69, no. 5, pp. 2896–2902, May 2021, doi: 10.1109/TAP.2020.3028187.<br />
<br />
*O. Rance, N. Barbot, and E. Perret, “Design of planar resonant scatterer with roll-invariant cross polarization,” ''IEEE Transactions on Microwave Theory and Techniques'', vol. 68, no. 10, pp. 4305–4313, 2020. doi: 10.1109/TMTT.2020.3014376.<br />
<br />
*R. Tavares de Alencar, Z. Ali, N. Barbot, M. Garbati, and E. Perret, “Practical performance comparison of 1-D and 2-D decoding methods for a chipless RFID system in a real environment,” ''IEEE Journal of Radio Frequency Identification'', vol. 4, no. 4, pp. 532–544, 2020. doi: 10.1109/JRFID.2020.2997988.<br />
<br />
*D. Nastasiu, R. Scripcaru, A. Digulescu, C. Ioana, R. De Amorim, N. Barbot, R. Siragusa, E. Perret, and F. Popescu, “A New Method of Secure Authentication Based on Electromagnetic Signatures of Chipless RFID Tags and Machine Learning Approaches,” ''Sensors'', vol. 20, no. 21, p. 6385, Nov. 2020. doi: 10.3390/s20216385. [Online]. Available: https://hal.archives-ouvertes.fr/hal-03035887.<br />
<br />
*M. M. Ahmed, E. Perret, D. Hely, R. Siragusa, and N. Barbot, “Guided electromagnetic wave technique for IC authentication,” ''Sensors'', vol. 20, no. 7, 2020, issn: 1424-8220. doi: 10.3390/s20072041. [Online]. Available: https://www.mdpi.com/1424-8220/20/7/2041.<br />
<br />
*N. Barbot, O. Rance, and E. Perret, “Angle Sensor Based on Chipless RFID Tag,” ''IEEE Antennas and Wireless Propagation Letters'', 2019. [Online]. Available: https://hal.archives-ouvertes.fr/hal-02377065.<br />
<br />
*Z. Ali, E. Perret, N. Barbot, R. Siragusa, D. Hely, M. Bernier, and F. Garet, “Authentication Using Metallic Inkjet-Printed Chipless RFID Tags,” ''IEEE Transactions on Antennas and Propagation'', pp. 1–1, Oct. 2019. doi: 10.1109/TAP.2019.2948740. [Online]. Available: https://hal.archives-ouvertes.fr/hal-02337466.<br />
<br />
*M. M. Ahmed, D. Hely, E. Perret, N. Barbot, R. Siragusa, M. Bernier, and F. Garet, “Robust and Noninvasive IC Authentication Using Radiated Electromagnetic Emissions,” Journal of Hardware and Systems Security, vol. 3, no. 3, pp. 273–288, Sep. 2019. doi: 10.1007/s41635-019-00072-y. [Online]. Available: https://hal.archives-ouvertes.fr/hal-02296583.<br />
<br />
*Z. Ali, E. Perret, N. Barbot, R. Siragusa, D. Hely, M. Bernier, and F. Garet, “Detection of Natural Randomness by Chipless RFID Approach and Its Application to Authentication,” ''IEEE Transactions on Microwave Theory and Techniques'', pp. 1–15, May 2019. doi: 10.1109/TMTT.2019.2914102. [Online]. Available: https://hal.archives-ouvertes.fr/hal-02132612.<br />
<br />
*M. M. Ahmed, D. Hely, E. Perret, N. Barbot, R. Siragusa, M. Bernier, and F. Garet, “Robust and noninvasive IC authentication using radiated electromagnetic emissions,” ''Journal of Hardware and Systems Security'', vol. 3, no. 3, pp. 273–288, Sep. 2019. <br />
<br />
*N. Barbot and E. Perret, “Accurate Positioning System Based on Chipless Technology,” ''Sensors'', Mar. 2019. doi: 10.3390/s19061341. [Online]. Available: https://hal.archives-ouvertes.fr/hal-02064576.<br />
<br />
*N. Barbot and E. Perret, “A Chipless RFID Method of 2D Localization Based on Phase Acquisition,” ''Journal of Sensors'', vol. 2018, pp. 1–6, Jul. 2018. [Online]. Available: https://hal.univ-grenoble-alpes.fr/hal-01944679.<br />
<br />
*Z. Ali, N. Barbot, R. Siragusa, E. Perret, D. Hély, M. Bernier, and F. Garet, “Detection of Minimum Geometrical Variation by Free-Space-Based Chipless Approach and its Application to Authentication,” ''IEEE Microwave and Wireless Components Letters'', vol. 28, no. 4, pp. 323–325, Jan. 2018. doi: 10.1109/LMWC.2018.2805858. [Online]. Available: https://hal.archives-ouvertes.fr/hal-01800580.<br />
<br />
*M. M. Ahmed, D. Hely, N. Barbot, R. Siragusa, E. Perret, M. Bernier, and F. Garet, “Radiated Electromagnetic Emission for Integrated Circuit Authentication,” ''IEEE Microwave and Wireless Components Letters'', vol. 27, no. 11, pp. 1028–1030, Nov. 2017. doi: 10.1109/LMWC.2017.2750078. [Online]. Available: https://hal.archives-ouvertes.fr/hal-01724143.<br />
<br />
*N. Barbot, S. Sahuguede, A. Julien-Vergonjanne, and J.-P. Cances, “Low-density Parity-check and Fountain Code Performance over Mobile Wireless Optical Channels,” ''Transactions on emerging telecommunications technologies'', vol. 25, no. 6, pp. 638–647, Jun. 2014. doi: 10.1002/ett.2812. [Online]. Available: https://hal.archives-ouvertes.fr/hal-01257508.<br />
<br />
*S. S. Torkestani, N. Barbot, S. Sahuguede, A. Julien-Vergonjanne, and J.-P. Cances, “Transmission Power Analysis of Optical Wireless Based Mobile Healthcare Systems,” ''Int J Wireless Inf Networks'', vol. 19, no. 3, pp. 201–208, Jun. 2012, Springer Science+Business Media, doi: 10.1007/s10776-012-0177-1. [Online]. Available: https://hal.archives-ouvertes.fr/hal-00790442.<br />
<br />
*N. Barbot, S. S. Torkestani, S. Sahuguede, A. Julien-Vergonjanne, and J.-P. Cances, “Maximal rate of mobile wireless optical link in indoor environment,” ''International Journal on Advanced in Telecommunications'', vol. 5, no. 3-4, pp. 274–283, 2012. [Online]. Available: https://hal-unilim.archives-ouvertes.fr/hal-00919839.<br />
<br />
==International Conferences==<br />
<br />
*N. Barbot and Etienne Perret, "Impact of the Polarization over the Read Range in Chipless RFID", in 2021 IEEE International Conference on RFID Technology and Applications<br />
(RFID-TA) (IEEE RFID-TA 2021)", accepted, Oct. 2021,<br />
<br />
*A. Azarfar, N. Barbot, and E. Perret, “Towards chipless RFID technology based on micro-doppler effect for long range applications,” ''in IEEE/MTT-S International Microwave Symposium - IMS 2021'', accepted, Jun. 2021.<br />
<br />
*F. Requena, N. Barbot, D. Kaddour, and E. Perret, “Chipless RFID temperature and humidity sensing,” ''in IEEE/MTT-S International Microwave Symposium - IMS 2021'', accepted, Jun. 2021.<br />
<br />
*N. Barbot, O. Rance, and E. Perret, “Notes on differential RCS of modulated tag,” ''in 2021 IEEE RFID conference'', Atlanta, GA, Apr. 2021 '''Best Poster Award'''<br />
<br />
*R. de Amorim, N. Barbot, R. Siragusa, and E. Perret, “Millimeter-wave chipless RFID tag for authentication applications,” ''in 2020 50th European Microwave Conference (EuMC)'', 2021, pp. 800–803. doi: 10.23919/EuMC48046.2021.9338082.<br />
<br />
*N. Barbot, O. Rance, and E. Perret, “Cross-Polarization Chipless Tag for Orientation Sensing,” ''in European Microwave Conference (EuMC)'', Utrecht, Netherlands, Jan. 2021. [Online]. Available: https://hal.archives-ouvertes.fr/hal-03120671.<br />
<br />
*O. Rance, N. Barbot, and E. Perret, “Monte carlo simulation for chipless RFID orientation sensor,” ''in 2020 IEEE International Symposium on Antennas and Propagation and North American Radio Science Meeting'', 2020, pp. 1199–1200. doi: 10.1109/IEEECONF35879.2020.9329985.<br />
<br />
*N. Barbot, O. Rance, and E. Perret, “Orientation Determination of a Scatterer Based on Polarimetric Radar Measurements,” ''in URSI GASS 2020'', Rome, Italy, Aug. 2020. [Online]. Available: https://hal.archives-ouvertes.fr/hal-02948679.<br />
<br />
*M. M. Ahmed, E. Perret, R. Siragusa, D. Hély, F. Garet, N. Barbot, and M. Bernier, “Implementation of RF communication subsets on common low frequency clocked FPGA,” ''in 2019 49th European Microwave Conference (EuMC)'', Paris, France: IEEE, Oct. 2019, pp. 742–745. doi: 10.23919/EuMC.2019.8910837. [Online]. Available: https://hal.archives-ouvertes.fr/hal-02429327.<br />
<br />
*R. T. d. Alencar, N. Barbot, M. Garbati, and E. Perret, “Practical Comparison of Decoding Methods for Chipless RFID System in Real Environment,” ''in 2019 IEEE International Conference on RFID Technology and Applications (RFID-TA)'', Pisa, Italy: IEEE, Sep. 2019, pp. 207–211. doi: 10.1109/RFID-TA.2019.8892020. [Online]. Available: https://hal.archives-ouvertes.fr/hal-02429346.<br />
<br />
*R. T. de Alencar, N. Barbot, M. Garbati, and E. Perret, “Characterization of chipless RFID tag in a 3-dimensional reading zone,” ''in 2019 IEEE International Symposium on Antennas and Propagation and USNC-URSI Radio Science Meeting'', 2019, pp. 639–640. doi: 10.1109/APUSNCURSINRSM.2019.8888559.<br />
<br />
*S. Salhi, F. Bonnefoy, S. Girard, M. Bernier, N. Barbot, R. Siragusa, E. Perret, and F. Garet, “Enhanced THz tags authentication using multivariate statistical analysis,” ''in IRMMW-THz 2019 - 44th International Conference on Infrared, Millimeter, and Terahertz Waves'', Paris, France, Sep. 2019, pp. 1–2. [Online]. Available: https://hal.archives-ouvertes.fr/hal-02282841.<br />
<br />
*F. Bonnefoy, C. Ioana, M. Bernier, N. Barbot, R. Siragusa, E. Perret, P. Martinez, and F. Garet, “Identification Of Random Internal Structuring THz Tags Using Images Correlation And SIWPD Analysis,” ''in 44th International Conference on Infrared, Millimeter, and Terahertz Waves'', Paris, France: IEEE, Sep. 2019, pp. 1–1. doi: 10.1109/IRMMW-THz.2019.8873800. [Online]. Available: https://hal.univ-grenoble-alpes.fr/hal-02297202.<br />
<br />
*F. Bonnefoy, M. Bernier, F. Garet, N. Barbot, D. Hely, R. Siragusa, and E. Perret, “Diffraction grating tags structures dedicated to authentication in the THz,” ''in French-German THz Conference 2019'', Kaiserslautern, Germany, Apr. 2019. [Online]. Available: https://hal.archives-ouvertes.fr/hal-02436662.<br />
<br />
*M. Hamdi, F. Bonnefoy, M. Bernier, F. Garet, E. Perret, N. Barbot, R. Siragusa, and D. Hely, “Identification in the Terahertz Domain using Low Cost Tags with a Fast Spectrometer,” ''in ASID 2018: 12th IEEE International Conference on Anti-counterfeiting, Security, and Identification'', Xiamen, China, Nov. 2018. doi: 10.1109/ICASID.2018.8693209. [Online]. Available: https://hal.univ-grenoble-alpes.fr/hal-02015383.<br />
<br />
*M. M. Ahmed, D. Hely, E. Perret, N. Barbot, R. Siragusa, M. Bernier, and F. Garet, “Authentication of Microcontroller Board Using Non-Invasive EM Emission Technique,” ''in 2018 IEEE 3rd International Verification and Security Workshop (IVSW)'', Platja d’Aro, Spain: IEEE, Jul. 2018, pp. 25–30. doi: 10.1109/IVSW.2018.8494883. [Online]. Available: https://hal.archives-ouvertes.fr/hal-02014214.<br />
<br />
*Z. Ali, N. Barbot, R. Siragusa, D. Hely, M. Bernier, F. Garet, and E. Perret, “Chipless RFID Tag Discrimination and the Performance of Resemblance Metrics to be used for it,” ''in IEEE/MTT-S International Microwave Symposium - IMS 2018'', Philadelphia, United States: IEEE, Jun. 2018. doi: 10.1109/MWSYM.2018.8439855. [Online]. Available: https://hal.archives-ouvertes.fr/hal-01888533.<br />
<br />
*N. Barbot and E. Perret, “2D Localization using Phase Measurement of Chipless RFID Tags,” ''in 2nd URSI AT-RASC'', Gran Canaria, Spain, May 2018. [Online]. Available: https://hal.univ-grenoble-alpes.fr/hal-02066779.<br />
<br />
*S. Chollet, L. Pion, and N. Barbot, “Secure IoT for a Pervasive Platform,” ''in 2018 IEEE International Conference on Pervasive Computing and Communications Workshops, PerCom Workshops 2018'', Athènes, Greece, Mar. 2018. [Online]. Available: https://hal.archives- ouvertes.fr/hal-01898651.<br />
<br />
*M. M. Ahmed, D. Hely, N. Barbot, R. Siragusa, E. Perret, M. Bernier, and F. Garet, “Towards a robust and efficient EM based authentication of FPGA against counterfeiting and recycling,” ''in 19th International Symposium on Computer Architecture and Digital Systems (CADS)'', Kish Island, Iran: IEEE, Dec. 2017, pp. 1–6. doi: 10.1109/CADS.2017.8310673. [Online]. Available: https://hal.univ-grenoble-alpes.fr/hal-02014230.<br />
<br />
*N. Barbot and E. Perret, “Gesture recognition with the chipless RIFD technology,” ''in 2017 XXXIInd General Assembly and Scientific Symposium of the International Union of Radio Science (URSI GASS)'', Montreal, Canada, Aug. 2017, pp. 19–26. doi: 10.23919/URSIGASS.2017.8104990. [Online]. Available: https://hal.univ-grenoble-alpes.fr/hal-01944690.<br />
<br />
*F. Bonnefoy, M. Hamdi, M. Bernier, N. Barbot, R. Siragusa, D. Hely, E. Perret, and F. Garet, “Authentication in the THz domain: a new tool to fight couterfeiting,” ''in 9th THz days'', Dunkerque, France, Jun. 2017. [Online]. Available: https://hal.univ-grenoble-alpes.fr/hal-02014053.<br />
<br />
*Z. Ali, F. Bonnefoy, R. Siragusa, N. Barbot, D. Hély, E. Perret, M. Bernier, and F. Garet, “Potential of chipless authentication based on randomness inherent in fabrication process for RF and THz,” ''in 11th European Conference on Antennas and Propagation (EUCAP)'', Paris, France, 2017. doi: 10.23919/EuCAP.2017.7928647. [Online]. Available: https://hal.archives-ouvertes.fr/hal-01800579.<br />
<br />
*M. M. Ahmed, D. Hely, R. Siragusa, N. Barbot, E. Perret, M. Bernier, and F. Garet, “Authentication of IC based on Electromagnetic Signature,” ''in 6th Conference on Trustworthy Manufacturing and Utilization of Secure Devices (TRUDEVICE 2016)'', Barcelone, Spain, Nov. 2016. [Online]. Available: https://hal.univ-grenoble-alpes.fr/hal-02014251.<br />
<br />
*N. Barbot, S. Sahuguede, A. Julien-Vergonjanne, and J.-P. Cances, “Outage capacity of mobile wireless optical link in indoor environment,” ''in Application of Information and Communication Technologies (AICT)'', Stuttgart, Germany, Oct. 2012, 5 pages. [Online]. Available: https://hal.archives-ouvertes.fr/hal-00790458.<br />
<br />
*N. Barbot, S. Sahuguede, and A. Julien-Vergonjanne, “Multiple Access Interference Impact on Outage Probability of Wireless Optical CDMA Systems,” ''in Photonics in Switching 2012'', Ajaccio - Corse, France, Sep. 2012, Session 1.5 OFDM, CDMA. [Online]. Available: https://hal-unilim.archives-ouvertes.fr/hal-00793162.<br />
<br />
*N. Barbot, S. Sahuguede, and A. Julien-Vergonjanne, “Performance of a Mobile Wireless Optical CDMA Monitoring System,” ''in The Ninth International Symposium on Wireless Communication Systems (ISWCS)'', ISSN : 2154-0217 E-ISBN : 978-1-4673-0760-4 Print ISBN: 978-1-4673-0761-1, Paris, France, Aug. 2012, pp.666–670. doi: 10.1109/ISWCS.2012.6328451. [Online]. Available: https://hal-unilim.archives-ouvertes.fr/hal-00793183.<br />
<br />
*N. Barbot, S. S. Torkestani, S. Sahuguede, A. Julien-Vergonjanne, and J.-P. Cances, “LT codes performance over indoor mobile wireless optical channel,” ''in Communication Systems, Networks & Digital Signal Processing (CSNDSP)'', 2012 8th International Symposium on, Print ISBN: 978-1-4577-1472-6, Poznan, Germany, Jul. 2012, pp. 1–4. doi: 10.1109/CSNDSP.2012.6292657. [Online]. Available: https://hal.archives-ouvertes.fr/hal-00790453.<br />
<br />
*S. S. Torkestani, N. Barbot, S. Sahuguede, A. Julien-Vergonjanne, and J.-P. Cances, “Performance and Transmission Power Bound Analysis for Optical Wireless based Mobile Healthcare Applications,” ''in 2011 IEEE 22nd International Symposium on'', Toronto, Canada, Sep. 2011, Inconnu. [Online]. Available: https://hal-unilim.archives-ouvertes.fr/hal-00650252.<br />
<br />
*N. Barbot, S. Sahuguede, A. Julien-Vergonjanne, and J.-P. Cances, “Performance Bound for LDPC Codes Over Mobile LOS Wireless Optical Channel,” ''in 2011 IEEE 73rd Vehicular Technology Conference: VTC2011-Spring'', Budapest, Hungary, May 2011, pp. 1–5. doi: 10.1109/VETECS.2011.5956176. [Online]. Available: https://hal-unilim.archives-ouvertes.fr/hal-00649807.<br />
<br />
==National Conferences==<br />
<br />
*M. M. Ahmed, E. Perret, R. Siragusa, N. Barbot, D. Hely, M. Bernier, and F. Garet, "Développement d’une plateforme RF flexible et reconfigurable basée sur un FPGA," ''21èmes Journées Nationales Microondes (JNM)'', Caen, France, May 2019. [Online]. Available: https://hal.archives-ouvertes.fr/hal-02051698.<br />
<br />
*Z. Ali, R. Siragusa, E. Perret, N. Barbot, D. Hely, M. Bernier, and F. Garet, "Méthode d’authentification basée sur des tags RFID sans puce imprimés par jet d’encre conductrice," ''21èmes Journées Nationales Microondes (JNM)'', Caen, France, May 2019. [Online]. Available: https://hal.archives-ouvertes.fr/hal-02017120.<br />
<br />
*N. Barbot and E. Perret, Localisation 2D par Mesures de Phase basée sur la Technologie Chipless, ''21èmes Journées Nationales Microondes (JNM)'', Caen, France, May 2019. [Online]. Available: https://hal.archives-ouvertes.fr/hal-02019490.<br />
<br />
*N. Barbot, S. Sahuguede, and A. Julien-Vergonjanne, Performances du contrôle d’erreur d’une transmission optique sans fil dédiée à une application de télé-surveillance mobile, Brest, France, Sep. 2013. [Online]. Available: https://hal-unilim.archives-ouvertes.fr/hal-00919862.<br />
<br />
*S. S. Torkestani, N. Barbot, S. Sahuguede, and A. Julien-Vergonjanne, Performances d’un système de transmission optique sans fil pour la télésurveillance médicale en milieu sensible confiné, Dijon, France, Sep. 2011. [Online]. Available: https://hal-unilim.archives-ouvertes.fr/hal-00650305.</div>Nicohttps://nicolas-barbot.ovh/wiki/index.php?title=Research_Activities&diff=482Research Activities2021-10-18T17:50:10Z<p>Nico: </p>
<hr />
<div>My research interests include passive (or semi-passive) transponders which can not be modeled as linear time-invariant systems. These transponders have enhanced performance in term of coding capacity and read range compared to classical linear time-invariant systems. These results and can only be achieved by breaking the linearity or the time invariance associated to the transponder.<br />
<br />
<br />
== Introduction ==<br />
<br />
[[File:Color.gif|thumb|right|Fig. 1: Environment under white light]]<br />
<br />
[[File:Color_red.gif|thumb|right|Fig. 2: Environment under red light]]<br />
<br />
Almost all the objects that we can see or characterize are Linear Time Invariant (LTI) systems. It implies that if they are impinged by an electromagnetic wave at a frequency <math>f_0</math> (in input), they also reflect or backscatter an electromagnetic wave at the same frequency <math>f_0</math> (in output).<br />
<br />
These LTI systems can be fully characterized by their impulse response <math>h(t)</math> in the time domain or their transfer function <math>H(f)</math> in the frequency domain. The output signal <math>y(t)</math> can be obtained in the time domain if the input signal <math>x(t)</math> is known as:<br />
<br />
<math><br />
y(t) = x(t) * h(t)<br />
</math><br />
<br />
Expression can equivalently be derived in the frequency domain:<br />
<br />
<math><br />
Y(f) = X(f) \times H(f)<br />
</math><br />
<br />
Classical examples include dynamical systems (electrical circuits, mechanical systems...). <br />
If we consider that the incident waveform is a continuous wave of frequency <math>f_0</math> then its real signal can be expressed as <math>x(t) = \cos 2 \pi f_0 t</math>. The received signal takes in that case, the simple form:<br />
<br />
<math><br />
y(t) = |H(f_0)| \cos (2 \pi f_0 t + Arg(H(f_0)))<br />
</math><br />
<br />
where we can easily see that the backscattered signal of a LTI system can only affect the amplitude <math>|H(f_0)|</math> and/or the phase <math>Arg(H(f_0))</math> of the incident waveform. Note that all the received power is also located at <math>f_0</math> since a LTI system can not generate a frequency which is not in the input signal.<br />
<br />
Let's consider a simple example, where an environment composed of different pens on a white support is illuminated by white light as in Fig. 1. Under these conditions, note that each object is characterized by a different color since they all accept the incident power and they each reflect a tiny part of the input spectrum. However, if we replace the white light by a red light (or any monochromatic color), each object will reflect the CW with an attenuation <math>|H(f_0)|</math> and a phase shift of <math>Arg(H(f_0))</math> but the frequency of the reflected wave will remain at <math>f_0</math> and the color of all object lies in between red (when attenuation is low) and black (when attenuation is high). Results are presented in Fig. 2. Almost all the objects that we see around us (like these pens and this support) are LTI systems.<br />
<br />
This simple observation implies important constraints if we want to identify any LTI object according the their backscattered or reflected signal:<br />
# The coding capacity only depends on the number of the color which can be distinguished. This capacity is only a function of the frequency resolution compared to the total bandwidth used by the reader. The total bandwidth used by the reader depends on the input signal. That is why we can differentiate pen under white light and not under red light.<br />
# The associated read range is only limited by the ratio in between the power backscattered by the object compared to the power reflected by the environment at the same frequency. This condition is harder to see with the picture since, pens can be separated spatially due to the camera lens but remember that an antenna cannot detect the direction of arrival of the received power.<br />
These limitation only appear since both pens and support (white table) are LTI systems and impose strict constraint in term of coding capacity and read range for any system based on LTI transponders.<br />
<br />
== Research Interest ==<br />
<br />
My research interests include all systems which cannot be modeled by a linear time-invariant system. As a direct consequence, these systems cannot be described by an impulse response or a transfer function<br />
and are able to accept the incident power at a given frequency and reflect or backscatter (a part of) this power at an other frequency or in another bandwidth. For example, in Fig. 2, these systems could appear under the red illumination as blue of green objects...<br />
This result can be obtained by only 2 ways, breaking the linearity (i.e., non linear systems) or breaking the time invariance (i.e. linear time variant systems). A third method consist of breaking the invariance on the reader side.<br />
<br />
Note also that breaking the time-invariance with a scatterer has been investigated since 1948 by H. Stockman, <ref>"Communication by Means of Reflected Power," in Proceedings of the IRE, vol. 36, no. 10, pp. 1196-1204, Oct. 1948, doi: 10.1109/JRPROC.1948.226245</ref> and can be obtained, citing the author, by "variable-damping modulation, interference or phase modulation, directional modulation, position modulation, doppler modulation, and polarization modulation". The first case is actually, the operation principle of a UHF RFID tag. Doppler and polarization modulation are described hereafter.<br />
<br />
=== Linear time variant systems ===<br />
<br />
[[File:line_coding.png|300px|thumb|right|Fig. 4: PSD of the signal backscattered by a modulating tag.]]<br />
<br />
These class of transponders include many examples. The more famous ones are classical RFID tags. UHF RFID tags can, when a sufficient power is received by the chip, switch the internal load connected to the antenna in between 2 values, its RCS is also modified and becomes a function of the time. Finally the variations of the backscattered signal generate a modulation which can be detected by the reader. As a direct consequence, the backscattered power spectral density includes components which are not at <math>f_0</math>. If the transmission data rate is much lower than the carrier frequency, narrow band signal approximation holds and PSD is located around <math>f_0</math>. The exact characteristics of the PSD depends on the data encoding used by the tag during the communication. The UHF RFID standard defines two different modulations for the tag which are FM0 and Miller (with different subcarrier sequences). Analytical formula of the PSD for FM0 is known and is equal to the Manchester encoding. For Miller modulation, analytical formula is also known, but without considering the subcarrier sequences. Fig. 5 presents the PSD of the baseband signals corresponding to the different modulations used by the tag. For all modulation we can see that the PSD is spread around <math>f_0</math> and that the system can not be considered as a LTI system.<br />
<br />
<br />
Another example appears when objects are moved or rotated into space. This interesting phenomenon is better illustrated by considering the simple case where a target is impinged by a continuous wave at a frequency <math>f_0</math>, if the radial speed of the target compared to the antenna is not zero, Doppler effect actually modifies the backscattered wave frequency received by the antenna which can be expressed as:<br />
<br />
<math> <br />
f=\left(\frac {c}{c\pm v_s}\right)f_0<br />
</math><br />
<br />
[[File:stem.png|thumb|right|Fig. 5: Spectrum of a rotating dipole impinged by a CW.]]<br />
<br />
Periodical movements of frequency <math>f_r</math>, such as vibrations and rotations, lead to simple analytical expressions where the backscattered spectrum is composed of discrete peaks located at <math>f_0 \pm n f_r</math> <ref> A. Azarfar, N. Barbot, and E. Perret. "Towards chipless RFID technology based on micro-Doppler effect for long range applications." In 2021 IEEE MTT-SInternational Microwave Symposium (IMS), Jun. 2021 Atlanta, GA</ref>. Let's consider a vertical dipole oriented along <math>z</math> located at <math>x=5</math> cm and <math>y=0</math> cm and impinged by a plane wave at 915 MHz propagating along <math>y</math>. If we rotate this dipole along the <math>z</math> axis with a frequency <math>f_r</math>, the phase backscattered electric field in farfield is modulated by a sinus function while the magnitude remains constant (micro-Doppler). This situation can surprisingly easily be simulated in time domain using a frequency solver such as <syntaxhighlight lang="text" inline>nec2</syntaxhighlight>.<br />
<br />
<syntaxhighlight lang="text" line='line' highlight="3"><br />
CE MICRO-DOPPLER<br />
GW 0 50 -0.0165 0.05 0. 0.0165 0.05 0. 0.0005<br />
GM 0 0 0. 0. 0. 0. 0. 0.<br />
GE<br />
EX 1 1 1 0 0 0 0 0 0 0<br />
FR 0 1 0 0 915e6 0<br />
RP 0 1 1 1000 0 0 0 0 1<br />
EN<br />
</syntaxhighlight><br />
<br />
Since at any given time, the system can be assumed as a linear time invariant system, the excitation of the structure by a CW can be fully described by simply determining the received amplitude and phase.<br />
Thus, the received response during the rotation can be estimated by determining the variation of amplitude and phase scattered by the structure, for each angle <math>\theta</math> of the scatterer. The variation of the amplitude and phase also correspond to the variations of the received signal the time domain signal. Thus by changing the <syntaxhighlight lang="text" inline>GM</syntaxhighlight> card, the backscattered signal can be determined for all <math>\theta</math> values. Fourier series of this signal can be computed and lead to a discrete spectrum at <math>k f_r</math> presented in Fig. 4. Analytical form is identical to a frequency modulated signal with an index modulation of <math>\beta = 1.92</math> and can be expressed as a function of the Bessel function of first kind.<br />
<br />
Another example, can be based on the polarization modulation by changing the orientation of the scatterer as a function of time <ref>N. Barbot and E. Perret, [https://nicolas-barbot.ovh/wiki/pool/nl.pdf "Linear time-variant chipless RFID sensor,"] IEEE Journal of Radio Frequency Identification, early access.</ref>. Note that this modulation can only create power at <math>f_0</math> and <math>f_0 \pm f_r</math> which is very different compared to the Doppler modulation. Results can be accurately predicted using the variation polarization scattering matrix as the function of time.<br />
<br />
Finally, note that for every modification of the response of the transponder during the interrogation done by the reader implies a modulation of the backscattered signal in time which generates a non-zero power in the PSD around <math>f_0</math>. However these modifications require an energy source which can be brought by the reader itself (as in UHF RFID) or by an external action (as the displacement or rotation of the tag). In these latter case, transponders can be considered as semi-passive.<br />
<br />
=== Imaging systems ===<br />
<br />
[[File:Myean13.png|thumb|right|Fig. 6: Barcode and modulated reflected signal]]<br />
<br />
Imaging systems are a special kind of linear time variant system where the variations are not produced by the tag but by the reader itself. In this case, the tag remains a LTI systems, but the reading method done by the reader allows to extract the tag response as a function of variation in time which break the invariance propertie. These tags (and the associated reading method) are not limited by the bounds on coding capacity and read range. The simplest example is the barcode and is presented in Fig. 5. Classical barcodes are composed of black stripes and can encode 43 bits of information. Barcodes are read by sweeping the beam produced by a laser diode along the tag and by measuring the variations of the reflected signal in time. Scientists often usually consider that chipless technology is more related to barcodes than UHF technology, however, note that the reflected signal of a barcode is a modulated signal which is, by principle, identical to the backscattered signals of UHF RFID and moving or rotating tags. As such, barcodes and their reading method cannot be considered as LTI systems and are characterized by a non-zero delta RCS and a (possible) much larger read range.<br />
<br />
This spatial diversity allows to use the same color multiple time to encode information (stripes do not have to use a different color and 2 colors are enought) which significantly increases the coding capacity. <br />
2D images and their associated reading method can also be considered as linear time variant systems (which include QR code, or any image obtained with a lens and camera sensor). All these systems operate in the optical domain since spatial resolution is only limited by the small beam divergence of laser diodes (less than 1 mrad) or the sensor matrix size of camera sensors. However, note that when frequency is decreased, antenna directivity is also reduced which significantly limits the performance of this approach in the RF domain. For example in UWB band half power angle is usually higher than 10° which imposes large separation in between stripes (or resonators).<br />
<br />
=== Non linear systems ===<br />
<br />
Transponders based on a non-linear element (such as a Schottky diode) can accept a power at <math>f_0</math> and generate a power at <math>n f_0</math>. Let's consider the simple circuit composed of a generator connected to a load but where a diode in inserted in serial in the circuit. The diode is a simple device which conducts the current mainly in a single direction. The relation which describe the current <math>I</math> flowing through the diode as a function of the voltage across the junction <math>V_D</math> can be expressed as:<br />
<br />
<math><br />
I=I_S\left(e^{\frac {V_D}{nV_T}}-1\right)<br />
</math><br />
<br />
with <math>V_T = kT/q</math>. If we consider a small variation of the junction voltage <math>v</math> around a bias voltage operating point <math>V_b</math>, the current <math>i</math> can be expressed as Taylor series:<br />
<br />
<math><br />
i(v) = i(V_b) + \frac{i^{(1)}}{1!} (v-V_b) + \frac{i^{(2)}(V_b)}{2!} (v-V_D)^2 + \frac{i^{(3)}(V_b)}{3!} (v-V_b)^3+\cdots<br />
</math><br />
<br />
where <math>i^{(n)}</math> is the <math>n^{\text{th}}</math>-derivative of <math>i(v)</math> according to <math>v</math>.<br />
<br />
If an harmonic tension such as <math>v(t)=A\cos \omega_0 t</math> is applied to this diode, its current <math>i(t)</math><br />
can be expressed as:<br />
<br />
<math><br />
\begin{align}<br />
i(V_D,t) &= i(V_D) + [\frac{A^2}{4} i^{(2)}(V_b) + \frac{A^4}{64}i^{(4)}(V_b)+\cdots]\\<br />
&+ [A i^{(1)}(V_D) + \frac{A^3}{8} i^{(3)}(V_b) + \cdots] \cos \omega_0 t\\<br />
&+ [\frac{A^2}{4} i^{(2)}(V_b) + \frac{A^4}{48}i^{(4)}(V_b)+\cdots] \cos 2\omega_0 t\\<br />
&+ [\frac{A^3}{24} i^{(3)}(V_b) + \frac{A^5}{384}i^{(4)}(V_b)+\cdots] \cos 3\omega_0 t\\<br />
&+ \cdots<br />
\end{align}<br />
</math><br />
<br />
where we can see that an infinite sum of harmonics has been created due the non-linear behavior of the diode.<br />
<!-- Note also, that each term can be viewed as coefficient of Fourier series of the decomposition <math>i(V_d, t)</math>. --><br />
<br />
<!-- [[File:Vtime.png|300px|thumb|right|Voltage across R in the time domain]] --><br />
<br />
[[File:Vfrequency.png|300px|thumb|right|Fig. 3: Voltage across R in the frequency domain]]<br />
<br />
This circuit can easily be simulated using <syntaxhighlight lang="text" inline>ngspice</syntaxhighlight> using the transient analysis to clearly see the effect of the non-linearity of a HSMS285x diode.<br />
Amplitude has been set to 1V, frequency at 915 MHz. Simulation has been computed over a duration of 10 periods with 100 samples per period. Fourier series have been computed over the voltage across the load.<br />
<br />
<syntaxhighlight lang="text" line="line"><br />
.title diode<br />
.param A = 1<br />
.param f0 = 915e6<br />
.model hsms285x D (IS=3e-6 RS=25 N=1.06 CJO=0.18pF VJ=0.35 M=0.5 EG=0.69 XTI=2 BV=3.8 IBV=3e-4)<br />
V1 1 0 dc 0 SIN(0 A f0 0NS 0)<br />
Ra 2 1 50<br />
D1 2 3 hsms285x<br />
Rl 3 0 50<br />
.end<br />
<br />
.csparam csf0 = {f0}<br />
.csparam duration = {10.0/f0}<br />
.csparam fsample = {1/(100*f0)}<br />
.control<br />
tran $&fsample $&duration<br />
plot v(3)<br />
fourier $&csf0 v(3)<br />
.endc<br />
</syntaxhighlight><br />
<br />
The simulation clearly shows that the power dissipated into the load contains power at <math>f_0</math> but also at <math>n f_0</math> due to the non-linear behavior of the diode.<br />
Harvesters use the power located at <math>n=0</math> where as harmonic transponders are based on the power located at <math>n > 1</math>.<br />
<br />
For passive harmonic transponders, an antenna accepting the power at <math>f_0</math> have to be added. The backscattered power at <math>n f_0</math> should also be re-radiated by another antenna.<br />
The main difficulty appears from the incident power which is very low (few micro Watt) which need to generate a voltage higher than the threshold of the diode (around 0.3 V). Usually the conversion loss associated to these devices is lower than -20 dB (i.e. only 1% of the incident power is converted to an harmonic frequency). However, read range of these transponders can easily achieve more than 5 m while satisfying regulation standards.<br />
<br />
----<br />
<br />
Finally, all presented systems (time-varing and non-linear transponders) can also be characterized by a non-zero differential RCS (or delta RCS) <math>\sigma_d</math> since they are able to modulate their backscattered power. This delta RCS is the direct generalization of the quantity classically defined for UHF tags. More information can be found [[Differential RCS|here]].<br />
<br />
== Conclusion ==<br />
<br />
I hope you have liked this page. If you have any comment, remarks or questions about these ideas, feel free to send me an email:<br />
<br />
[mailto:nicolas.barbot@lcis.grenoble-inp.fr <syntaxhighlight lang="text" inline>nicolas.barbot@lcis.grenoble-inp.fr</syntaxhighlight>]<br />
<br />
Collaborations often start by simple emails...<br />
<br />
==References==<br />
<br />
<references /></div>Nicohttps://nicolas-barbot.ovh/wiki/index.php?title=Research_Activities&diff=481Research Activities2021-10-18T09:51:31Z<p>Nico: </p>
<hr />
<div>My research interests include passive (or semi-passive) transponders which can not be modeled as linear time-invariant systems. These transponders have enhanced performance in term of coding capacity and read range compared to classical linear time-invariant systems. These results and can only be achieved by breaking the linearity or the time invariance associated to the transponder.<br />
<br />
<br />
== Introduction ==<br />
<br />
[[File:Color.gif|thumb|right|Fig. 1: Environment under white light]]<br />
<br />
[[File:Color_red.gif|thumb|right|Fig. 2: Environment under red light]]<br />
<br />
Almost all the objects that we can see or characterize are Linear Time Invariant (LTI) systems. It implies that if they are impinged by an electromagnetic wave at a frequency <math>f_0</math> (in input), they also reflect or backscatter an electromagnetic wave at the same frequency <math>f_0</math> (in output).<br />
<br />
These LTI systems can be fully characterized by their impulse response <math>h(t)</math> in the time domain or their transfer function <math>H(f)</math> in the frequency domain. The output signal <math>y(t)</math> can be obtained in the time domain if the input signal <math>x(t)</math> is known as:<br />
<br />
<math><br />
y(t) = x(t) * h(t)<br />
</math><br />
<br />
Expression can equivalently be derived in the frequency domain:<br />
<br />
<math><br />
Y(f) = X(f) \times H(f)<br />
</math><br />
<br />
Classical examples include dynamical systems (electrical circuits, mechanical systems...). <br />
If we consider that the incident waveform is a continuous wave of frequency <math>f_0</math> then its real signal can be expressed as <math>x(t) = \cos 2 \pi f_0 t</math>. The received signal takes in that case, the simple form:<br />
<br />
<math><br />
y(t) = |H(f_0)| \cos (2 \pi f_0 t + Arg(H(f_0)))<br />
</math><br />
<br />
where we can easily see that the backscattered signal of a LTI system can only affect the amplitude <math>|H(f_0)|</math> and/or the phase <math>Arg(H(f_0))</math> of the incident waveform. Note that all the received power is also located at <math>f_0</math> since a LTI system can not generate a frequency which is not in the input signal.<br />
<br />
Let's consider a simple example, where an environment composed of different pens on a white support is illuminated by white light as in Fig. 1. Under these conditions, note that each object is characterized by a different color since they all accept the incident power and they each reflect a tiny part of the input spectrum. However, if we replace the white light by a red light (or any monochromatic color), each object will reflect the CW with an attenuation <math>|H(f_0)|</math> and a phase shift of <math>Arg(H(f_0))</math> but the frequency of the reflected wave will remain at <math>f_0</math> and the color of all object lies in between red (when attenuation is low) and black (when attenuation is high). Results are presented in Fig. 2. Almost all the objects that we see around us (like these pens and this support) are LTI systems.<br />
<br />
This simple observation implies important constraints if we want to identify any LTI object according the their backscattered or reflected signal:<br />
# The coding capacity only depends on the number of the color which can be distinguished. This capacity is only a function of the frequency resolution compared to the total bandwidth used by the reader. The total bandwidth used by the reader depends on the input signal. That is why we can differentiate pen under white light and not under red light.<br />
# The associated read range is only limited by the ratio in between the power backscattered by the object compared to the power reflected by the environment at the same frequency. This condition is harder to see with the picture since, pens can be separated spatially due to the camera lens but remember that an antenna cannot detect the direction of arrival of the received power.<br />
These limitation only appear since both pens and support (white table) are LTI systems and impose strict constraint in term of coding capacity and read range for any system based on LTI transponders.<br />
<br />
== Research Interest ==<br />
<br />
My research interests include all systems which cannot be modeled by a linear time-invariant system. As a direct consequence, these systems cannot be described by an impulse response or a transfer function<br />
and are able to accept the incident power at a given frequency and reflect or backscatter (a part of) this power at an other frequency or in another bandwidth. For example, in Fig. 2, these systems could appear under the red illumination as blue of green objects...<br />
This result can be obtained by only 2 ways, breaking the linearity (i.e., non linear systems) or breaking the time invariance (i.e. linear time variant systems). A third method consist of breaking the invariance on the reader side.<br />
<br />
Note also that breaking the time-invariance with a scatterer has been investigated since 1948 by H. Stockman, <ref>"Communication by Means of Reflected Power," in Proceedings of the IRE, vol. 36, no. 10, pp. 1196-1204, Oct. 1948, doi: 10.1109/JRPROC.1948.226245</ref> for "variable-damping modulation, interference or phase modulation, directional modulation, position modulation, doppler modulation, and polarization modulation".<br />
<br />
=== Linear time variant systems ===<br />
<br />
[[File:line_coding.png|300px|thumb|right|Fig. 4: PSD of the signal backscattered by a modulating tag.]]<br />
<br />
These class of transponders include many examples. The more famous ones are classical RFID tags. UHF RFID tags can, when a sufficient power is received by the chip, switch the internal load connected to the antenna in between 2 values, its RCS is also modified and becomes a function of the time. Finally the variations of the backscattered signal generate a modulation which can be detected by the reader. As a direct consequence, the backscattered power spectral density includes components which are not at <math>f_0</math>. If the transmission data rate is much lower than the carrier frequency, narrow band signal approximation holds and PSD is located around <math>f_0</math>. The exact characteristics of the PSD depends on the data encoding used by the tag during the communication. The UHF RFID standard defines two different modulations for the tag which are FM0 and Miller (with different subcarrier sequences). Analytical formula of the PSD for FM0 is known and is equal to the Manchester encoding. For Miller modulation, analytical formula is also known, but without considering the subcarrier sequences. Fig. 5 presents the PSD of the baseband signals corresponding to the different modulations used by the tag. For all modulation we can see that the PSD is spread around <math>f_0</math> and that the system can not be considered as a LTI system.<br />
<br />
<br />
Another example appears when objects are moved or rotated into space. This interesting phenomenon is better illustrated by considering the simple case where a target is impinged by a continuous wave at a frequency <math>f_0</math>, if the radial speed of the target compared to the antenna is not zero, Doppler effect actually modifies the backscattered wave frequency received by the antenna which can be expressed as:<br />
<br />
<math> <br />
f=\left(\frac {c}{c\pm v_s}\right)f_0<br />
</math><br />
<br />
[[File:stem.png|thumb|right|Fig. 5: Spectrum of a rotating dipole impinged by a CW.]]<br />
<br />
Periodical movements of frequency <math>f_r</math>, such as vibrations and rotations, lead to simple analytical expressions where the backscattered spectrum is composed of discrete peaks located at <math>f_0 \pm n f_r</math> <ref> A. Azarfar, N. Barbot, and E. Perret. "Towards chipless RFID technology based on micro-Doppler effect for long range applications." In 2021 IEEE MTT-SInternational Microwave Symposium (IMS), Jun. 2021 Atlanta, GA</ref>. Let's consider a vertical dipole oriented along <math>z</math> located at <math>x=5</math> cm and <math>y=0</math> cm and impinged by a plane wave at 915 MHz propagating along <math>y</math>. If we rotate this dipole along the <math>z</math> axis with a frequency <math>f_r</math>, the phase backscattered electric field in farfield is modulated by a sinus function while the magnitude remains constant (micro-Doppler). This situation can surprisingly easily by simulated in time domain using a frequency solver such as <syntaxhighlight lang="text" inline>nec2</syntaxhighlight>.<br />
<br />
<syntaxhighlight lang="text" line='line' highlight="3"><br />
CE MICRO-DOPPLER<br />
GW 0 50 -0.0165 0.05 0. 0.0165 0.05 0. 0.0005<br />
GM 0 0 0. 0. 0. 0. 0. 0.<br />
GE<br />
EX 1 1 1 0 0 0 0 0 0 0<br />
FR 0 1 0 0 915e6 0<br />
RP 0 1 1 1000 0 0 0 0 1<br />
EN<br />
</syntaxhighlight><br />
<br />
Since at any given time, the system can be assumed as a linear time invariant system, the excitation of the structure by a CW can be fully described by simply determining the received amplitude and phase.<br />
Thus, the received response during the rotation can be estimated by determining the variation of amplitude and phase scattered by the structure, for each angle <math>\theta</math> of the scatterer. The variation of the amplitude and phase also correspond to the variations of the received signal the time domain signal. Thus by changing the <syntaxhighlight lang="text" inline>GM</syntaxhighlight> card, the backscattered signal can be determined for all <math>\theta</math> values. Fourier series of this signal can be computed and lead to a discrete spectrum at <math>k f_r</math> presented in Fig. 4. Analytical form is identical to a frequency modulated signal with an index modulation of <math>\beta = 1.92</math> and can be expressed as a function of the Bessel function of first kind.<br />
<br />
Another example, can be based on the polarization modulation by changing the orientation of the scatterer as a function of time <ref>N. Barbot and E. Perret, [https://nicolas-barbot.ovh/wiki/pool/nl.pdf "Linear time-variant chipless RFID sensor,"] IEEE Journal of Radio Frequency Identification, accepted.</ref>. Note that this modulation can only create power at <math>f_0</math> and <math>f_0 \pm f_r</math> which is very different compared to the Doppler modulation. Results can be accurately predicted using the variation polarization scattering matrix as the function of time.<br />
<br />
Finally, note that for every modification of the response of the transponder during the interrogation done by the reader implies a modulation of the backscattered signal in time which generate a non-zero power in the PSD around <math>f_0</math>. However these modifications require an energy source which can be brought by the reader itself (as in UHF RFID) or by an external action (as the displacement or rotation of the tag). In these latter case, transponders can be considered as semi-passive.<br />
<br />
=== Imaging systems ===<br />
<br />
[[File:Myean13.png|thumb|right|Fig. 6: Barcode and modulated reflected signal]]<br />
<br />
Imaging systems are a special kind of linear time variant system where the variations are not produced by the tag but by the reader itself. In this case, the tag remains a LTI systems, but the reading method done by the reader allows to extract the tag response as a function of variation in time which break the invariance propertie. These tags (and the associated reading method) are not limited by the bounds on coding capacity and read range. The simplest example is the barcode and is presented in Fig. 5. Classical barcodes are composed of black stripes and can encode 43 bits of information. Barcodes are read by sweeping the beam produced by a laser diode along the tag and by measuring the variations of the reflected signal in time. Scientists often usually consider that chipless technology is more related to barcodes than UHF technology, however, note that the reflected signal of a barcode is a modulated signal which is, by principle, identical to the backscattered signals of UHF RFID and moving or rotating tags. As such, barcodes and their reading method cannot be considered as LTI systems and are characterized by a non-zero delta RCS and a (possible) much larger read range.<br />
<br />
This spatial diversity allows to use the same color multiple time to encode information (stripes do not have to use a different color and 2 colors are enought) which significantly increases the coding capacity. <br />
2D images and their associated reading method can also be considered as linear time variant systems (which include QR code, or any image obtained with a lens and camera sensor). All these systems operate in the optical domain since spatial resolution is only limited by the small beam divergence of laser diodes (less than 1 mrad) or the sensor matrix size of camera sensors. However, note that when frequency is decreased, antenna directivity is also reduced which significantly limits the performance of this approach in the RF domain. For example in UWB band half power angle is usually higher than 10° which imposes large separation in between stripes (or resonators).<br />
<br />
=== Non linear systems ===<br />
<br />
Transponders based on a non-linear element (such as a Schottky diode) can accept a power at <math>f_0</math> and generate a power at <math>n f_0</math>. Let's consider the simple circuit composed of a generator connected to a load but where a diode in inserted in serial in the circuit. The diode is a simple device which conducts the current mainly in a single direction. The relation which describe the current <math>I</math> flowing through the diode as a function of the voltage across the junction <math>V_D</math> can be expressed as:<br />
<br />
<math><br />
I=I_S\left(e^{\frac {V_D}{nV_T}}-1\right)<br />
</math><br />
<br />
with <math>V_T = kT/q</math>. If we consider a small variation of the junction voltage <math>v</math> around a bias voltage operating point <math>V_b</math>, the current <math>i</math> can be expressed as Taylor series:<br />
<br />
<math><br />
i(v) = i(V_b) + \frac{i^{(1)}}{1!} (v-V_b) + \frac{i^{(2)}(V_b)}{2!} (v-V_D)^2 + \frac{i^{(3)}(V_b)}{3!} (v-V_b)^3+\cdots<br />
</math><br />
<br />
where <math>i^{(n)}</math> is the <math>n^{\text{th}}</math>-derivative of <math>i(v)</math> according to <math>v</math>.<br />
<br />
If an harmonic tension such as <math>v(t)=A\cos \omega_0 t</math> is applied to this diode, its current <math>i(t)</math><br />
can be expressed as:<br />
<br />
<math><br />
\begin{align}<br />
i(V_D,t) &= i(V_D) + [\frac{A^2}{4} i^{(2)}(V_b) + \frac{A^4}{64}i^{(4)}(V_b)+\cdots]\\<br />
&+ [A i^{(1)}(V_D) + \frac{A^3}{8} i^{(3)}(V_b) + \cdots] \cos \omega_0 t\\<br />
&+ [\frac{A^2}{4} i^{(2)}(V_b) + \frac{A^4}{48}i^{(4)}(V_b)+\cdots] \cos 2\omega_0 t\\<br />
&+ [\frac{A^3}{24} i^{(3)}(V_b) + \frac{A^5}{384}i^{(4)}(V_b)+\cdots] \cos 3\omega_0 t\\<br />
&+ \cdots<br />
\end{align}<br />
</math><br />
<br />
where we can see that an infinite sum of harmonics has been created due the non-linear behavior of the diode.<br />
<!-- Note also, that each term can be viewed as coefficient of Fourier series of the decomposition <math>i(V_d, t)</math>. --><br />
<br />
<!-- [[File:Vtime.png|300px|thumb|right|Voltage across R in the time domain]] --><br />
<br />
[[File:Vfrequency.png|300px|thumb|right|Fig. 3: Voltage across R in the frequency domain]]<br />
<br />
This circuit can easily be simulated using <syntaxhighlight lang="text" inline>ngspice</syntaxhighlight> using the transient analysis to clearly see the effect of the non-linearity of a HSMS285x diode.<br />
Amplitude has been set to 1V, frequency at 915 MHz. Simulation has been computed over a duration of 10 periods with 100 samples per period. Fourier series have been computed over the voltage across the load.<br />
<br />
<syntaxhighlight lang="text" line="line"><br />
.title diode<br />
.param A = 1<br />
.param f0 = 915e6<br />
.model hsms285x D (IS=3e-6 RS=25 N=1.06 CJO=0.18pF VJ=0.35 M=0.5 EG=0.69 XTI=2 BV=3.8 IBV=3e-4)<br />
V1 1 0 dc 0 SIN(0 A f0 0NS 0)<br />
Ra 2 1 50<br />
D1 2 3 hsms285x<br />
Rl 3 0 50<br />
.end<br />
<br />
.csparam csf0 = {f0}<br />
.csparam duration = {10.0/f0}<br />
.csparam fsample = {1/(100*f0)}<br />
.control<br />
tran $&fsample $&duration<br />
plot v(3)<br />
fourier $&csf0 v(3)<br />
.endc<br />
</syntaxhighlight><br />
<br />
The simulation clearly shows that the power dissipated into the load contains power at <math>f_0</math> but also at <math>n f_0</math> due to the non-linear behavior of the diode.<br />
Harvesters use the power located at <math>n=0</math> where as harmonic transponders are based on the power located at <math>n > 1</math>.<br />
<br />
For passive harmonic transponders, an antenna accepting the power at <math>f_0</math> have to be added. The backscattered power at <math>n f_0</math> should also be re-radiated by another antenna.<br />
The main difficulty appears from the incident power which is very low (few micro Watt) which need to generate a voltage higher than the threshold of the diode (around 0.3 V). Usually the conversion loss associated to these devices is lower than -20 dB (i.e. only 1% of the incident power is converted to an harmonic frequency). However, read range of these transponders can easily achieve more than 5 m while satisfying regulation standards.<br />
<br />
----<br />
<br />
Finally, all presented systems (time-varing and non-linear transponders) can also be characterized by a non-zero differential RCS (or delta RCS) <math>\sigma_d</math> since they are able to modulate their backscattered power. This delta RCS is the direct generalization of the quantity classically defined for UHF tags. More information can be found [[Differential RCS|here]].<br />
<br />
== Conclusion ==<br />
<br />
I hope you have liked this page. If you have any comment, remarks or questions about these ideas, feel free to send me an email:<br />
<br />
[mailto:nicolas.barbot@lcis.grenoble-inp.fr <syntaxhighlight lang="text" inline>nicolas.barbot@lcis.grenoble-inp.fr</syntaxhighlight>]<br />
<br />
Collaborations often start by simple emails...<br />
<br />
==References==<br />
<br />
<references /></div>Nicohttps://nicolas-barbot.ovh/wiki/index.php?title=Research_Activities&diff=480Research Activities2021-10-18T09:45:50Z<p>Nico: </p>
<hr />
<div>My research interests include passive (or semi-passive) transponders which can not be modeled as linear time-invariant systems. These transponders have enhanced performance in term of coding capacity and read range compared to classical linear time-invariant systems. These results and can only be achieved by breaking the linearity or the time invariance associated to the transponder.<br />
<br />
<br />
== Introduction ==<br />
<br />
[[File:Color.gif|thumb|right|Fig. 1: Environment under white light]]<br />
<br />
[[File:Color_red.gif|thumb|right|Fig. 2: Environment under red light]]<br />
<br />
Almost all the objects that we can see or characterize are Linear Time Invariant (LTI) systems. It implies that if they are impinged by an electromagnetic wave at a frequency <math>f_0</math> (in input), they also reflect or backscatter an electromagnetic wave at the same frequency <math>f_0</math> (in output).<br />
<br />
These LTI systems can be fully characterized by their impulse response <math>h(t)</math> in the time domain or their transfer function <math>H(f)</math> in the frequency domain. The output signal <math>y(t)</math> can be obtained in the time domain if the input signal <math>x(t)</math> is known as:<br />
<br />
<math><br />
y(t) = x(t) * h(t)<br />
</math><br />
<br />
Expression can equivalently be derived in the frequency domain:<br />
<br />
<math><br />
Y(f) = X(f) \times H(f)<br />
</math><br />
<br />
Classical examples include dynamical systems (electrical circuits, mechanical systems...). <br />
If we consider that the incident waveform is a continuous wave of frequency <math>f_0</math> then its real signal can be expressed as <math>x(t) = \cos 2 \pi f_0 t</math>. The received signal takes in that case, the simple form:<br />
<br />
<math><br />
y(t) = |H(f_0)| \cos (2 \pi f_0 t + Arg(H(f_0)))<br />
</math><br />
<br />
where we can easily see that the backscattered signal of a LTI system can only affect the amplitude <math>|H(f_0)|</math> and/or the phase <math>Arg(H(f_0))</math> of the incident waveform. Note that all the received power is also located at <math>f_0</math> since a LTI system can not generate a frequency which is not in the input signal.<br />
<br />
Let's consider a simple example, where an environment composed of different pens on a white support is illuminated by white light as in Fig. 1. Under these conditions, note that each object is characterized by a different color since they all accept the incident power and they each reflect a tiny part of the input spectrum. However, if we replace the white light by a red light (or any monochromatic color), each object will reflect the CW with an attenuation <math>|H(f_0)|</math> and a phase shift of <math>Arg(H(f_0))</math> but the frequency of the reflected wave will remain at <math>f_0</math> and the color of all object lies in between red (when attenuation is low) and black (when attenuation is high). Results are presented in Fig. 2. Almost all the objects that we see around us (like these pens and this support) are LTI systems.<br />
<br />
This simple observation implies important constraints if we want to identify any LTI object according the their backscattered or reflected signal:<br />
# The coding capacity only depends on the number of the color which can be distinguished. This capacity is only a function of the frequency resolution compared to the total bandwidth used by the reader. The total bandwidth used by the reader depends on the input signal. That is why we can differentiate pen under white light and not under red light.<br />
# The associated read range is only limited by the ratio in between the power backscattered by the object compared to the power reflected by the environment at the same frequency. This condition is harder to see with the picture since, pens can be separated spatially due to the camera lens but remember that an antenna cannot detect the direction of arrival of the received power.<br />
These limitation only appear since both pens and support (white table) are LTI systems and impose strict constraint in term of coding capacity and read range for any system based on LTI transponders.<br />
<br />
== Research Interest ==<br />
<br />
My research interests include all systems which cannot be modeled by a linear time-invariant system. As a direct consequence, these systems cannot be described by an impulse response or a transfer function<br />
and are able to accept the incident power at a given frequency and reflect or backscatter (a part of) this power at an other frequency or in another bandwidth. For example, in Fig. 2, these systems could appear under the red illumination as blue of green objects...<br />
This result can be obtained by only 2 ways, breaking the linearity (i.e., non linear systems) or breaking the time invariance (i.e. linear time variant systems). A third method consist of breaking the invariance on the reader side.<br />
<br />
Note also that breaking the time-invariance with a scatterer has been investigated since 1948 by H. Stockman, <ref>"Communication by Means of Reflected Power," in Proceedings of the IRE, vol. 36, no. 10, pp. 1196-1204, Oct. 1948, doi: 10.1109/JRPROC.1948.226245</ref> for "variable-damping modulation, interference or phase modulation, directional modulation, position modulation, doppler modulation, and polarization modulation".<br />
<br />
=== Linear time variant systems ===<br />
<br />
[[File:line_coding.png|300px|thumb|right|Fig. 4: PSD of the signal backscattered by a modulating tag.]]<br />
<br />
These class of transponders include many examples. The more famous ones are classical RFID tags. UHF RFID tags can, when a sufficient power is received by the chip, switch the internal load connected to the antenna in between 2 values, its RCS is also modified and becomes a function of the time. Finally the variations of the backscattered signal generate a modulation which can be detected by the reader. As a direct consequence, the backscattered power spectral density includes components which are not at <math>f_0</math>. If the transmission data rate is much lower than the carrier frequency, narrow band signal approximation holds and PSD is located around <math>f_0</math>. The exact characteristics of the PSD depends on the data encoding used by the tag during the communication. The UHF RFID standard defines two different modulations for the tag which are FM0 and Miller (with different subcarrier sequences). Analytical formula of the PSD for FM0 is known and is equal to the Manchester encoding. For Miller modulation, analytical formula is also known, but without considering the subcarrier sequences. Fig. 5 presents the PSD of the baseband signals corresponding to the different modulations used by the tag. For all modulation we can see that the PSD is spread around <math>f_0</math> and that the system can not be considered as a LTI system.<br />
<br />
<br />
Another example appears when objects are moved or rotated into space. This interesting phenomenon is better illustrated by considering the simple case where a target is impinged by a continuous wave at a frequency <math>f_0</math>, if the radial speed of the target compared to the antenna is not zero, Doppler effect actually modifies the backscattered wave frequency received by the antenna which can be expressed as:<br />
<br />
<math> <br />
f=\left(\frac {c}{c\pm v_s}\right)f_0<br />
</math><br />
<br />
[[File:stem.png|thumb|right|Fig. 5: Spectrum of a rotating dipole impinged by a CW.]]<br />
<br />
Periodical movements of frequency <math>f_r</math>, such as vibrations and rotations, lead to simple analytical expressions where the backscattered spectrum is composed of discrete peaks located at <math>f_0 \pm n f_r</math> <ref> A. Azarfar, N. Barbot, and E. Perret. "Towards chipless RFID technology based on micro-Doppler effect for long range applications." In 2021 IEEE MTT-SInternational Microwave Symposium (IMS), Jun. 2021 Atlanta, GA</ref>. Let's consider a vertical dipole oriented along <math>z</math> located at <math>x=5</math> cm and <math>y=0</math> cm and impinged by a plane wave at 915 MHz propagating along <math>y</math>. If we rotate this dipole along the <math>z</math> axis with a frequency <math>f_r</math>, the phase backscattered electric field in farfield is modulated by a sinus function while the magnitude remains constant (micro-Doppler). This situation can surprisingly easily by simulated in time domain using a frequency solver such as <syntaxhighlight lang="text" inline>nec2</syntaxhighlight>.<br />
<br />
<syntaxhighlight lang="text" line='line' highlight="3"><br />
CE MICRO-DOPPLER<br />
GW 0 50 -0.0165 0.05 0. 0.0165 0.05 0. 0.0005<br />
GM 0 0 0. 0. 0. 0. 0. 0.<br />
GE<br />
EX 1 1 1 0 0 0 0 0 0 0<br />
FR 0 1 0 0 915e6 0<br />
RP 0 1 1 1000 0 0 0 0 1<br />
EN<br />
</syntaxhighlight><br />
<br />
Since at any given time, the system can be assumed as a linear time invariant system, the excitation of the structure by a CW can be fully described by simply determining the received amplitude and phase.<br />
Thus, the received response during the rotation can be estimated by determining the variation of amplitude and phase scattered by the structure, for each angle <math>\theta</math> of the scatterer. The variation of the amplitude and phase also correspond to the variations of the received signal the time domain signal. Thus by changing the <syntaxhighlight lang="text" inline>GM</syntaxhighlight> card, the backscattered signal can be determined for all <math>\theta</math> values. Fourier series of this signal can be computed and lead to a discrete spectrum at <math>k f_r</math> presented in Fig. 4. Analytical form is identical to a frequency modulated signal with an index modulation of <math>\beta = 1.92</math> and can be expressed as a function of the Bessel function of first kind.<br />
<br />
Another example, can be based on the polarization modulation by changing the orientation of the scatterer as a function of time <ref>N. Barbot and E. Perret, [https://nicolas-barbot.ovh/wiki/pool/nl.pdf "Linear time-variant chipless RFID sensor,"] IEEE Journal of Radio Frequency Identification, accepted.</ref>. Note that this modulation can only create power at <math>f_0</math> and <f_0 \pm f_r> which is very different compared to the Doppler modulation.<br />
<br />
Finally, note that for every modification of the response of the transponder during the interrogation done by the reader implies a modulation of the backscattered signal in time which generate a non-zero power in the PSD around <math>f_0</math>. However these modifications require an energy source which can be brought by the reader itself (as in UHF RFID) or by an external action (as the displacement or rotation of the tag). In these latter case, transponders can be considered as semi-passive.<br />
<br />
=== Imaging systems ===<br />
<br />
[[File:Myean13.png|thumb|right|Fig. 6: Barcode and modulated reflected signal]]<br />
<br />
Imaging systems are a special kind of linear time variant system where the variations are not produced by the tag but by the reader itself. In this case, the tag remains a LTI systems, but the reading method done by the reader allows to extract the tag response as a function of variation in time which break the invariance propertie. These tags (and the associated reading method) are not limited by the bounds on coding capacity and read range. The simplest example is the barcode and is presented in Fig. 5. Classical barcodes are composed of black stripes and can encode 43 bits of information. Barcodes are read by sweeping the beam produced by a laser diode along the tag and by measuring the variations of the reflected signal in time. Scientists often usually consider that chipless technology is more related to barcodes than UHF technology, however, note that the reflected signal of a barcode is a modulated signal which is, by principle, identical to the backscattered signals of UHF RFID and moving or rotating tags. As such, barcodes and their reading method cannot be considered as LTI systems and are characterized by a non-zero delta RCS and a (possible) much larger read range.<br />
<br />
This spatial diversity allows to use the same color multiple time to encode information (stripes do not have to use a different color and 2 colors are enought) which significantly increases the coding capacity. <br />
2D images and their associated reading method can also be considered as linear time variant systems (which include QR code, or any image obtained with a lens and camera sensor). All these systems operate in the optical domain since spatial resolution is only limited by the small beam divergence of laser diodes (less than 1 mrad) or the sensor matrix size of camera sensors. However, note that when frequency is decreased, antenna directivity is also reduced which significantly limits the performance of this approach in the RF domain. For example in UWB band half power angle is usually higher than 10° which imposes large separation in between stripes (or resonators).<br />
<br />
=== Non linear systems ===<br />
<br />
Transponders based on a non-linear element (such as a Schottky diode) can accept a power at <math>f_0</math> and generate a power at <math>n f_0</math>. Let's consider the simple circuit composed of a generator connected to a load but where a diode in inserted in serial in the circuit. The diode is a simple device which conducts the current mainly in a single direction. The relation which describe the current <math>I</math> flowing through the diode as a function of the voltage across the junction <math>V_D</math> can be expressed as:<br />
<br />
<math><br />
I=I_S\left(e^{\frac {V_D}{nV_T}}-1\right)<br />
</math><br />
<br />
with <math>V_T = kT/q</math>. If we consider a small variation of the junction voltage <math>v</math> around a bias voltage operating point <math>V_b</math>, the current <math>i</math> can be expressed as Taylor series:<br />
<br />
<math><br />
i(v) = i(V_b) + \frac{i^{(1)}}{1!} (v-V_b) + \frac{i^{(2)}(V_b)}{2!} (v-V_D)^2 + \frac{i^{(3)}(V_b)}{3!} (v-V_b)^3+\cdots<br />
</math><br />
<br />
where <math>i^{(n)}</math> is the <math>n^{\text{th}}</math>-derivative of <math>i(v)</math> according to <math>v</math>.<br />
<br />
If an harmonic tension such as <math>v(t)=A\cos \omega_0 t</math> is applied to this diode, its current <math>i(t)</math><br />
can be expressed as:<br />
<br />
<math><br />
\begin{align}<br />
i(V_D,t) &= i(V_D) + [\frac{A^2}{4} i^{(2)}(V_b) + \frac{A^4}{64}i^{(4)}(V_b)+\cdots]\\<br />
&+ [A i^{(1)}(V_D) + \frac{A^3}{8} i^{(3)}(V_b) + \cdots] \cos \omega_0 t\\<br />
&+ [\frac{A^2}{4} i^{(2)}(V_b) + \frac{A^4}{48}i^{(4)}(V_b)+\cdots] \cos 2\omega_0 t\\<br />
&+ [\frac{A^3}{24} i^{(3)}(V_b) + \frac{A^5}{384}i^{(4)}(V_b)+\cdots] \cos 3\omega_0 t\\<br />
&+ \cdots<br />
\end{align}<br />
</math><br />
<br />
where we can see that an infinite sum of harmonics has been created due the non-linear behavior of the diode.<br />
<!-- Note also, that each term can be viewed as coefficient of Fourier series of the decomposition <math>i(V_d, t)</math>. --><br />
<br />
<!-- [[File:Vtime.png|300px|thumb|right|Voltage across R in the time domain]] --><br />
<br />
[[File:Vfrequency.png|300px|thumb|right|Fig. 3: Voltage across R in the frequency domain]]<br />
<br />
This circuit can easily be simulated using <syntaxhighlight lang="text" inline>ngspice</syntaxhighlight> using the transient analysis to clearly see the effect of the non-linearity of a HSMS285x diode.<br />
Amplitude has been set to 1V, frequency at 915 MHz. Simulation has been computed over a duration of 10 periods with 100 samples per period. Fourier series have been computed over the voltage across the load.<br />
<br />
<syntaxhighlight lang="text" line="line"><br />
.title diode<br />
.param A = 1<br />
.param f0 = 915e6<br />
.model hsms285x D (IS=3e-6 RS=25 N=1.06 CJO=0.18pF VJ=0.35 M=0.5 EG=0.69 XTI=2 BV=3.8 IBV=3e-4)<br />
V1 1 0 dc 0 SIN(0 A f0 0NS 0)<br />
Ra 2 1 50<br />
D1 2 3 hsms285x<br />
Rl 3 0 50<br />
.end<br />
<br />
.csparam csf0 = {f0}<br />
.csparam duration = {10.0/f0}<br />
.csparam fsample = {1/(100*f0)}<br />
.control<br />
tran $&fsample $&duration<br />
plot v(3)<br />
fourier $&csf0 v(3)<br />
.endc<br />
</syntaxhighlight><br />
<br />
The simulation clearly shows that the power dissipated into the load contains power at <math>f_0</math> but also at <math>n f_0</math> due to the non-linear behavior of the diode.<br />
Harvesters use the power located at <math>n=0</math> where as harmonic transponders are based on the power located at <math>n > 1</math>.<br />
<br />
For passive harmonic transponders, an antenna accepting the power at <math>f_0</math> have to be added. The backscattered power at <math>n f_0</math> should also be re-radiated by another antenna.<br />
The main difficulty appears from the incident power which is very low (few micro Watt) which need to generate a voltage higher than the threshold of the diode (around 0.3 V). Usually the conversion loss associated to these devices is lower than -20 dB (i.e. only 1% of the incident power is converted to an harmonic frequency). However, read range of these transponders can easily achieve more than 5 m while satisfying regulation standards.<br />
<br />
----<br />
<br />
Finally, all presented systems (time-varing and non-linear transponders) can also be characterized by a non-zero differential RCS (or delta RCS) <math>\sigma_d</math> since they are able to modulate their backscattered power. This delta RCS is the direct generalization of the quantity classically defined for UHF tags. More information can be found [[Differential RCS|here]].<br />
<br />
== Conclusion ==<br />
<br />
I hope you have liked this page. If you have any comment, remarks or questions about these ideas, feel free to send me an email:<br />
<br />
[mailto:nicolas.barbot@lcis.grenoble-inp.fr <syntaxhighlight lang="text" inline>nicolas.barbot@lcis.grenoble-inp.fr</syntaxhighlight>]<br />
<br />
Collaborations often start by simple emails...<br />
<br />
==References==<br />
<br />
<references /></div>Nicohttps://nicolas-barbot.ovh/wiki/index.php?title=Research_Activities&diff=479Research Activities2021-10-18T09:42:43Z<p>Nico: </p>
<hr />
<div>My research interests include passive (or semi-passive) transponders which can not be modeled as linear time-invariant systems. These transponders have enhanced performance in term of coding capacity and read range compared to classical linear time-invariant systems. These results and can only be achieved by breaking the linearity or the time invariance associated to the transponder.<br />
<br />
<br />
== Introduction ==<br />
<br />
[[File:Color.gif|thumb|right|Fig. 1: Environment under white light]]<br />
<br />
[[File:Color_red.gif|thumb|right|Fig. 2: Environment under red light]]<br />
<br />
Almost all the objects that we can see or characterize are Linear Time Invariant (LTI) systems. It implies that if they are impinged by an electromagnetic wave at a frequency <math>f_0</math> (in input), they also reflect or backscatter an electromagnetic wave at the same frequency <math>f_0</math> (in output).<br />
<br />
These LTI systems can be fully characterized by their impulse response <math>h(t)</math> in the time domain or their transfer function <math>H(f)</math> in the frequency domain. The output signal <math>y(t)</math> can be obtained in the time domain if the input signal <math>x(t)</math> is known as:<br />
<br />
<math><br />
y(t) = x(t) * h(t)<br />
</math><br />
<br />
Expression can equivalently be derived in the frequency domain:<br />
<br />
<math><br />
Y(f) = X(f) \times H(f)<br />
</math><br />
<br />
Classical examples include dynamical systems (electrical circuits, mechanical systems...). <br />
If we consider that the incident waveform is a continuous wave of frequency <math>f_0</math> then its real signal can be expressed as <math>x(t) = \cos 2 \pi f_0 t</math>. The received signal takes in that case, the simple form:<br />
<br />
<math><br />
y(t) = |H(f_0)| \cos (2 \pi f_0 t + Arg(H(f_0)))<br />
</math><br />
<br />
where we can easily see that the backscattered signal of a LTI system can only affect the amplitude <math>|H(f_0)|</math> and/or the phase <math>Arg(H(f_0))</math> of the incident waveform. Note that all the received power is also located at <math>f_0</math> since a LTI system can not generate a frequency which is not in the input signal.<br />
<br />
Let's consider a simple example, where an environment composed of different pens on a white support is illuminated by white light as in Fig. 1. Under these conditions, note that each object is characterized by a different color since they all accept the incident power and they each reflect a tiny part of the input spectrum. However, if we replace the white light by a red light (or any monochromatic color), each object will reflect the CW with an attenuation <math>|H(f_0)|</math> and a phase shift of <math>Arg(H(f_0))</math> but the frequency of the reflected wave will remain at <math>f_0</math> and the color of all object lies in between red (when attenuation is low) and black (when attenuation is high). Results are presented in Fig. 2. Almost all the objects that we see around us (like these pens and this support) are LTI systems.<br />
<br />
This simple observation implies important constraints if we want to identify any LTI object according the their backscattered or reflected signal:<br />
# The coding capacity only depends on the number of the color which can be distinguished. This capacity is only a function of the frequency resolution compared to the total bandwidth used by the reader. The total bandwidth used by the reader depends on the input signal. That is why we can differentiate pen under white light and not under red light.<br />
# The associated read range is only limited by the ratio in between the power backscattered by the object compared to the power reflected by the environment at the same frequency. This condition is harder to see with the picture since, pens can be separated spatially due to the camera lens but remember that an antenna cannot detect the direction of arrival of the received power.<br />
These limitation only appear since both pens and support (white table) are LTI systems and impose strict constraint in term of coding capacity and read range for any system based on LTI transponders.<br />
<br />
== Research Interest ==<br />
<br />
My research interests include all systems which cannot be modeled by a linear time-invariant system. As a direct consequence, these systems cannot be described by an impulse response or a transfer function<br />
and are able to accept the incident power at a given frequency and reflect or backscatter (a part of) this power at an other frequency or in another bandwidth. For example, in Fig. 2, these systems could appear under the red illumination as blue of green objects...<br />
This result can be obtained by only 2 ways, breaking the linearity (i.e., non linear systems) or breaking the time invariance (i.e. linear time variant systems). A third method consist of breaking the invariance on the reader side.<br />
<br />
Note also that breaking the time-invariance with a scatterer has been investigated since 1948 by H. Stockman, <ref>"Communication by Means of Reflected Power," in Proceedings of the IRE, vol. 36, no. 10, pp. 1196-1204, Oct. 1948, doi: 10.1109/JRPROC.1948.226245</ref> for "variable-damping modulation, interference or phase modulation, directional modulation, position modulation, doppler modulation, and polarization modulation".<br />
<br />
=== Linear time variant systems ===<br />
<br />
[[File:line_coding.png|300px|thumb|right|Fig. 4: PSD of the signal backscattered by a modulating tag.]]<br />
<br />
These class of transponders include many examples. The more famous ones are classical RFID tags. UHF RFID tags can, when a sufficient power is received by the chip, switch the internal load connected to the antenna in between 2 values, its RCS is also modified and becomes a function of the time. Finally the variations of the backscattered signal generate a modulation which can be detected by the reader. As a direct consequence, the backscattered power spectral density includes components which are not at <math>f_0</math>. If the transmission data rate is much lower than the carrier frequency, narrow band signal approximation holds and PSD is located around <math>f_0</math>. The exact characteristics of the PSD depends on the data encoding used by the tag during the communication. The UHF RFID standard defines two different modulations for the tag which are FM0 and Miller (with different subcarrier sequences). Analytical formula of the PSD for FM0 is known and is equal to the Manchester encoding. For Miller modulation, analytical formula is also known, but without considering the subcarrier sequences. Fig. 5 presents the PSD of the baseband signals corresponding to the different modulations used by the tag. For all modulation we can see that the PSD is spread around <math>f_0</math> and that the system can not be considered as a LTI system.<br />
<br />
<br />
Another example appears when objects are moved or rotated into space. This interesting phenomenon is better illustrated by considering the simple case where a target is impinged by a continuous wave at a frequency <math>f_0</math>, if the radial speed of the target compared to the antenna is not zero, Doppler effect actually modifies the backscattered wave frequency received by the antenna which can be expressed as:<br />
<br />
<math> <br />
f=\left(\frac {c}{c\pm v_s}\right)f_0<br />
</math><br />
<br />
[[File:stem.png|thumb|right|Fig. 5: Spectrum of a rotating dipole impinged by a CW.]]<br />
<br />
Periodical movements of frequency <math>f_r</math>, such as vibrations and rotations, lead to simple analytical expressions where the backscattered spectrum is composed of discrete peaks located at <math>f_0 \pm n f_r</math> <ref> A. Azarfar, N. Barbot, and E. Perret. "Towards chipless RFID technology based on micro-Doppler effect for long range applications." In 2021 IEEE MTT-SInternational Microwave Symposium (IMS), Jun. 2021 Atlanta, GA</ref>. Let's consider a vertical dipole oriented along <math>z</math> located at <math>x=5</math> cm and <math>y=0</math> cm and impinged by a plane wave at 915 MHz propagating along <math>y</math>. If we rotate this dipole along the <math>z</math> axis with a frequency <math>f_r</math>, the phase backscattered electric field in farfield is modulated by a sinus function while the magnitude remains constant (micro-Doppler). This situation can surprisingly easily by simulated in time domain using a frequency solver such as <syntaxhighlight lang="text" inline>nec2</syntaxhighlight>.<br />
<br />
<syntaxhighlight lang="text" line='line' highlight="3"><br />
CE MICRO-DOPPLER<br />
GW 0 50 -0.0165 0.05 0. 0.0165 0.05 0. 0.0005<br />
GM 0 0 0. 0. 0. 0. 0. 0.<br />
GE<br />
EX 1 1 1 0 0 0 0 0 0 0<br />
FR 0 1 0 0 915e6 0<br />
RP 0 1 1 1000 0 0 0 0 1<br />
EN<br />
</syntaxhighlight><br />
<br />
Since at any given time, the system can be assumed as a linear time invariant system, the excitation of the structure by a CW can be fully described by simply determining the received amplitude and phase.<br />
Thus, the received response during the rotation can be estimated by determining the variation of amplitude and phase scattered by the structure, for each angle <math>\theta</math> of the scatterer. The variation of the amplitude and phase also correspond to the variations of the received signal the time domain signal. Thus by changing the <syntaxhighlight lang="text" inline>GM</syntaxhighlight> card, the backscattered signal can be determined for all <math>\theta</math> values. Fourier series of this signal can be computed and lead to a discrete spectrum at <math>k f_r</math> presented in Fig. 4. Analytical form is identical to a frequency modulated signal with an index modulation of <math>\beta = 1.92</math> and can be expressed as a function of the Bessel function of first kind.<br />
<br />
Another example, can be based on the polarization modulation by changing the orientation of the scatterer as a function of time <ref> </ref>.<br />
<br />
Finally, note that for every modification of the response of the transponder during the interrogation done by the reader implies a modulation of the backscattered signal in time which generate a non-zero power in the PSD around <math>f_0</math>. However these modifications require an energy source which can be brought by the reader itself (as in UHF RFID) or by an external action (as the displacement or rotation of the tag). In these latter case, transponders can be considered as semi-passive.<br />
<br />
=== Imaging systems ===<br />
<br />
[[File:Myean13.png|thumb|right|Fig. 6: Barcode and modulated reflected signal]]<br />
<br />
Imaging systems are a special kind of linear time variant system where the variations are not produced by the tag but by the reader itself. In this case, the tag remains a LTI systems, but the reading method done by the reader allows to extract the tag response as a function of variation in time which break the invariance propertie. These tags (and the associated reading method) are not limited by the bounds on coding capacity and read range. The simplest example is the barcode and is presented in Fig. 5. Classical barcodes are composed of black stripes and can encode 43 bits of information. Barcodes are read by sweeping the beam produced by a laser diode along the tag and by measuring the variations of the reflected signal in time. Scientists often usually consider that chipless technology is more related to barcodes than UHF technology, however, note that the reflected signal of a barcode is a modulated signal which is, by principle, identical to the backscattered signals of UHF RFID and moving or rotating tags. As such, barcodes and their reading method cannot be considered as LTI systems and are characterized by a non-zero delta RCS and a (possible) much larger read range.<br />
<br />
This spatial diversity allows to use the same color multiple time to encode information (stripes do not have to use a different color and 2 colors are enought) which significantly increases the coding capacity. <br />
2D images and their associated reading method can also be considered as linear time variant systems (which include QR code, or any image obtained with a lens and camera sensor). All these systems operate in the optical domain since spatial resolution is only limited by the small beam divergence of laser diodes (less than 1 mrad) or the sensor matrix size of camera sensors. However, note that when frequency is decreased, antenna directivity is also reduced which significantly limits the performance of this approach in the RF domain. For example in UWB band half power angle is usually higher than 10° which imposes large separation in between stripes (or resonators).<br />
<br />
=== Non linear systems ===<br />
<br />
Transponders based on a non-linear element (such as a Schottky diode) can accept a power at <math>f_0</math> and generate a power at <math>n f_0</math>. Let's consider the simple circuit composed of a generator connected to a load but where a diode in inserted in serial in the circuit. The diode is a simple device which conducts the current mainly in a single direction. The relation which describe the current <math>I</math> flowing through the diode as a function of the voltage across the junction <math>V_D</math> can be expressed as:<br />
<br />
<math><br />
I=I_S\left(e^{\frac {V_D}{nV_T}}-1\right)<br />
</math><br />
<br />
with <math>V_T = kT/q</math>. If we consider a small variation of the junction voltage <math>v</math> around a bias voltage operating point <math>V_b</math>, the current <math>i</math> can be expressed as Taylor series:<br />
<br />
<math><br />
i(v) = i(V_b) + \frac{i^{(1)}}{1!} (v-V_b) + \frac{i^{(2)}(V_b)}{2!} (v-V_D)^2 + \frac{i^{(3)}(V_b)}{3!} (v-V_b)^3+\cdots<br />
</math><br />
<br />
where <math>i^{(n)}</math> is the <math>n^{\text{th}}</math>-derivative of <math>i(v)</math> according to <math>v</math>.<br />
<br />
If an harmonic tension such as <math>v(t)=A\cos \omega_0 t</math> is applied to this diode, its current <math>i(t)</math><br />
can be expressed as:<br />
<br />
<math><br />
\begin{align}<br />
i(V_D,t) &= i(V_D) + [\frac{A^2}{4} i^{(2)}(V_b) + \frac{A^4}{64}i^{(4)}(V_b)+\cdots]\\<br />
&+ [A i^{(1)}(V_D) + \frac{A^3}{8} i^{(3)}(V_b) + \cdots] \cos \omega_0 t\\<br />
&+ [\frac{A^2}{4} i^{(2)}(V_b) + \frac{A^4}{48}i^{(4)}(V_b)+\cdots] \cos 2\omega_0 t\\<br />
&+ [\frac{A^3}{24} i^{(3)}(V_b) + \frac{A^5}{384}i^{(4)}(V_b)+\cdots] \cos 3\omega_0 t\\<br />
&+ \cdots<br />
\end{align}<br />
</math><br />
<br />
where we can see that an infinite sum of harmonics has been created due the non-linear behavior of the diode.<br />
<!-- Note also, that each term can be viewed as coefficient of Fourier series of the decomposition <math>i(V_d, t)</math>. --><br />
<br />
<!-- [[File:Vtime.png|300px|thumb|right|Voltage across R in the time domain]] --><br />
<br />
[[File:Vfrequency.png|300px|thumb|right|Fig. 3: Voltage across R in the frequency domain]]<br />
<br />
This circuit can easily be simulated using <syntaxhighlight lang="text" inline>ngspice</syntaxhighlight> using the transient analysis to clearly see the effect of the non-linearity of a HSMS285x diode.<br />
Amplitude has been set to 1V, frequency at 915 MHz. Simulation has been computed over a duration of 10 periods with 100 samples per period. Fourier series have been computed over the voltage across the load.<br />
<br />
<syntaxhighlight lang="text" line="line"><br />
.title diode<br />
.param A = 1<br />
.param f0 = 915e6<br />
.model hsms285x D (IS=3e-6 RS=25 N=1.06 CJO=0.18pF VJ=0.35 M=0.5 EG=0.69 XTI=2 BV=3.8 IBV=3e-4)<br />
V1 1 0 dc 0 SIN(0 A f0 0NS 0)<br />
Ra 2 1 50<br />
D1 2 3 hsms285x<br />
Rl 3 0 50<br />
.end<br />
<br />
.csparam csf0 = {f0}<br />
.csparam duration = {10.0/f0}<br />
.csparam fsample = {1/(100*f0)}<br />
.control<br />
tran $&fsample $&duration<br />
plot v(3)<br />
fourier $&csf0 v(3)<br />
.endc<br />
</syntaxhighlight><br />
<br />
The simulation clearly shows that the power dissipated into the load contains power at <math>f_0</math> but also at <math>n f_0</math> due to the non-linear behavior of the diode.<br />
Harvesters use the power located at <math>n=0</math> where as harmonic transponders are based on the power located at <math>n > 1</math>.<br />
<br />
For passive harmonic transponders, an antenna accepting the power at <math>f_0</math> have to be added. The backscattered power at <math>n f_0</math> should also be re-radiated by another antenna.<br />
The main difficulty appears from the incident power which is very low (few micro Watt) which need to generate a voltage higher than the threshold of the diode (around 0.3 V). Usually the conversion loss associated to these devices is lower than -20 dB (i.e. only 1% of the incident power is converted to an harmonic frequency). However, read range of these transponders can easily achieve more than 5 m while satisfying regulation standards.<br />
<br />
----<br />
<br />
Finally, all presented systems (time-varing and non-linear transponders) can also be characterized by a non-zero differential RCS (or delta RCS) <math>\sigma_d</math> since they are able to modulate their backscattered power. This delta RCS is the direct generalization of the quantity classically defined for UHF tags. More information can be found [[Differential RCS|here]].<br />
<br />
== Conclusion ==<br />
<br />
I hope you have liked this page. If you have any comment, remarks or questions about these ideas, feel free to send me an email:<br />
<br />
[mailto:nicolas.barbot@lcis.grenoble-inp.fr <syntaxhighlight lang="text" inline>nicolas.barbot@lcis.grenoble-inp.fr</syntaxhighlight>]<br />
<br />
Collaborations often start by simple emails...<br />
<br />
==References==<br />
<br />
<references /></div>Nicohttps://nicolas-barbot.ovh/wiki/index.php?title=Research_Activities&diff=478Research Activities2021-10-18T09:23:58Z<p>Nico: </p>
<hr />
<div>My research interests include passive (or semi-passive) transponders which can not be modeled as linear time-invariant systems. These transponders have enhanced performance in term of coding capacity and read range compared to classical linear time-invariant systems. These results and can only be achieved by breaking the linearity or the time invariance associated to the transponder.<br />
<br />
<br />
== Introduction ==<br />
<br />
[[File:Color.gif|thumb|right|Fig. 1: Environment under white light]]<br />
<br />
[[File:Color_red.gif|thumb|right|Fig. 2: Environment under red light]]<br />
<br />
Almost all the objects that we can see or characterize are Linear Time Invariant (LTI) systems. It implies that if they are impinged by an electromagnetic wave at a frequency <math>f_0</math> (in input), they also reflect or backscatter an electromagnetic wave at the same frequency <math>f_0</math> (in output).<br />
<br />
These LTI systems can be fully characterized by their impulse response <math>h(t)</math> in the time domain or their transfer function <math>H(f)</math> in the frequency domain. The output signal <math>y(t)</math> can be obtained in the time domain if the input signal <math>x(t)</math> is known as:<br />
<br />
<math><br />
y(t) = x(t) * h(t)<br />
</math><br />
<br />
Expression can equivalently be derived in the frequency domain:<br />
<br />
<math><br />
Y(f) = X(f) \times H(f)<br />
</math><br />
<br />
Classical examples include dynamical systems (electrical circuits, mechanical systems...). <br />
If we consider that the incident waveform is a continuous wave of frequency <math>f_0</math> then its real signal can be expressed as <math>x(t) = \cos 2 \pi f_0 t</math>. The received signal takes in that case, the simple form:<br />
<br />
<math><br />
y(t) = |H(f_0)| \cos (2 \pi f_0 t + Arg(H(f_0)))<br />
</math><br />
<br />
where we can easily see that the backscattered signal of a LTI system can only affect the amplitude <math>|H(f_0)|</math> and/or the phase <math>Arg(H(f_0))</math> of the incident waveform. Note that all the received power is also located at <math>f_0</math> since a LTI system can not generate a frequency which is not in the input signal.<br />
<br />
Let's consider a simple example, where an environment composed of different pens on a white support is illuminated by white light as in Fig. 1. Under these conditions, note that each object is characterized by a different color since they all accept the incident power and they each reflect a tiny part of the input spectrum. However, if we replace the white light by a red light (or any monochromatic color), each object will reflect the CW with an attenuation <math>|H(f_0)|</math> and a phase shift of <math>Arg(H(f_0))</math> but the frequency of the reflected wave will remain at <math>f_0</math> and the color of all object lies in between red (when attenuation is low) and black (when attenuation is high). Results are presented in Fig. 2. Almost all the objects that we see around us (like these pens and this support) are LTI systems.<br />
<br />
This simple observation implies important constraints if we want to identify any LTI object according the their backscattered or reflected signal:<br />
# The coding capacity only depends on the number of the color which can be distinguished. This capacity is only a function of the frequency resolution compared to the total bandwidth used by the reader. The total bandwidth used by the reader depends on the input signal. That is why we can differentiate pen under white light and not under red light.<br />
# The associated read range is only limited by the ratio in between the power backscattered by the object compared to the power reflected by the environment at the same frequency. This condition is harder to see with the picture since, pens can be separated spatially due to the camera lens but remember that an antenna cannot detect the direction of arrival of the received power.<br />
These limitation only appear since both pens and support (white table) are LTI systems and impose strict constraint in term of coding capacity and read range for any system based on LTI transponders.<br />
<br />
== Research Interest ==<br />
<br />
My research interests include all systems which cannot be modeled by a linear time-invariant system. As a direct consequence, these systems cannot be described by an impulse response or a transfer function<br />
and are able to accept the incident power at a given frequency and reflect or backscatter (a part of) this power at an other frequency or in another bandwidth. For example, in Fig. 2, these systems could appear under the red illumination as blue of green objects...<br />
This result can be obtained by only 2 ways, breaking the linearity (i.e., non linear systems) or breaking the time invariance (i.e. linear time variant systems). A third method consist of breaking the invariance on the reader side.<br />
<br />
Note also that breaking the time-invariance with a scatterer has been investigated since 1948 by H. Stockman, <ref>"Communication by Means of Reflected Power," in Proceedings of the IRE, vol. 36, no. 10, pp. 1196-1204, Oct. 1948, doi: 10.1109/JRPROC.1948.226245</ref> for both loaded scatterers (which is the basic principle used in UHF RFID) and rotating scatterers.<br />
<br />
=== Linear time variant systems ===<br />
<br />
[[File:line_coding.png|300px|thumb|right|Fig. 4: PSD of the signal backscattered by a modulating tag.]]<br />
<br />
These class of transponders include many examples. The more famous ones are classical RFID tags. UHF RFID tags can, when a sufficient power is received by the chip, switch the internal load connected to the antenna in between 2 values, its RCS is also modified and becomes a function of the time. Finally the variations of the backscattered signal generate a modulation which can be detected by the reader. As a direct consequence, the backscattered power spectral density includes components which are not at <math>f_0</math>. If the transmission data rate is much lower than the carrier frequency, narrow band signal approximation holds and PSD is located around <math>f_0</math>. The exact characteristics of the PSD depends on the data encoding used by the tag during the communication. The UHF RFID standard defines two different modulations for the tag which are FM0 and Miller (with different subcarrier sequences). Analytical formula of the PSD for FM0 is known and is equal to the Manchester encoding. For Miller modulation, analytical formula is also known, but without considering the subcarrier sequences. Fig. 5 presents the PSD of the baseband signals corresponding to the different modulations used by the tag. For all modulation we can see that the PSD is spread around <math>f_0</math> and that the system can not be considered as a LTI system.<br />
<br />
<br />
Another example appears when objects are moved or rotated into space. This interesting phenomenon is better illustrated by considering the simple case where a target is impinged by a continuous wave at a frequency <math>f_0</math>, if the radial speed of the target compared to the antenna is not zero, Doppler effect actually modifies the backscattered wave frequency received by the antenna which can be expressed as:<br />
<br />
<math> <br />
f=\left(\frac {c}{c\pm v_s}\right)f_0<br />
</math><br />
<br />
[[File:stem.png|thumb|right|Fig. 5: Spectrum of a rotating dipole impinged by a CW.]]<br />
<br />
Periodical movements of frequency <math>f_r</math>, such as vibrations and rotations, lead to simple analytical expressions where the backscattered spectrum is composed of discrete peaks located at <math>f_0 \pm n f_r</math>. Let's consider a vertical dipole oriented along <math>z</math> located at <math>x=5</math> cm and <math>y=0</math> cm and impinged by a plane wave at 915 MHz propagating along <math>y</math>. If we rotate this dipole along the <math>z</math> axis with a frequency <math>f_r</math>, the phase backscattered electric field in farfield is modulated by a sinus function while the magnitude remains constant (micro-Doppler). This situation can surprisingly easily by simulated in time domain using a frequency solver such as <syntaxhighlight lang="text" inline>nec2</syntaxhighlight>.<br />
<br />
<syntaxhighlight lang="text" line='line' highlight="3"><br />
CE MICRO-DOPPLER<br />
GW 0 50 -0.0165 0.05 0. 0.0165 0.05 0. 0.0005<br />
GM 0 0 0. 0. 0. 0. 0. 0.<br />
GE<br />
EX 1 1 1 0 0 0 0 0 0 0<br />
FR 0 1 0 0 915e6 0<br />
RP 0 1 1 1000 0 0 0 0 1<br />
EN<br />
</syntaxhighlight><br />
<br />
Since at any given time, the system can be assumed as a linear time invariant system, the excitation of the structure by a CW can be fully described by simply determining the received amplitude and phase.<br />
Thus, the received response during the rotation can be estimated by determining the variation of amplitude and phase scattered by the structure, for each angle <math>\theta</math> of the scatterer. The variation of the amplitude and phase also correspond to the variations of the received signal the time domain signal. Thus by changing the <syntaxhighlight lang="text" inline>GM</syntaxhighlight> card, the backscattered signal can be determined for all <math>\theta</math> values. Fourier series of this signal can be computed and lead to a discrete spectrum at <math>k f_r</math> presented in Fig. 4. Analytical form is identical to a frequency modulated signal with an index modulation of <math>\beta = 1.92</math> and can be expressed as a function of the Bessel function of first kind.<br />
<br />
Finally, note that for every modification of the response of the transponder during the interrogation done by the reader implies a modulation of the backscattered signal in time which generate a non-zero power in the PSD around <math>f_0</math>. However these modifications require an energy source which can be brought by the reader itself (as in UHF RFID) or by an external action (as the displacement or rotation of the tag). In these latter case, transponders can be considered as semi-passive.<br />
<br />
=== Imaging systems ===<br />
<br />
[[File:Myean13.png|thumb|right|Fig. 6: Barcode and modulated reflected signal]]<br />
<br />
Imaging systems are a special kind of linear time variant system where the variations are not produced by the tag but by the reader itself. In this case, the tag remains a LTI systems, but the reading method done by the reader allows to extract the tag response as a function of variation in time which break the invariance propertie. These tags (and the associated reading method) are not limited by the bounds on coding capacity and read range. The simplest example is the barcode and is presented in Fig. 5. Classical barcodes are composed of black stripes and can encode 43 bits of information. Barcodes are read by sweeping the beam produced by a laser diode along the tag and by measuring the variations of the reflected signal in time. Scientists often usually consider that chipless technology is more related to barcodes than UHF technology, however, note that the reflected signal of a barcode is a modulated signal which is, by principle, identical to the backscattered signals of UHF RFID and moving or rotating tags. As such, barcodes and their reading method cannot be considered as LTI systems and are characterized by a non-zero delta RCS and a (possible) much larger read range.<br />
<br />
This spatial diversity allows to use the same color multiple time to encode information (stripes do not have to use a different color and 2 colors are enought) which significantly increases the coding capacity. <br />
2D images and their associated reading method can also be considered as linear time variant systems (which include QR code, or any image obtained with a lens and camera sensor). All these systems operate in the optical domain since spatial resolution is only limited by the small beam divergence of laser diodes (less than 1 mrad) or the sensor matrix size of camera sensors. However, note that when frequency is decreased, antenna directivity is also reduced which significantly limits the performance of this approach in the RF domain. For example in UWB band half power angle is usually higher than 10° which imposes large separation in between stripes (or resonators).<br />
<br />
=== Non linear systems ===<br />
<br />
Transponders based on a non-linear element (such as a Schottky diode) can accept a power at <math>f_0</math> and generate a power at <math>n f_0</math>. Let's consider the simple circuit composed of a generator connected to a load but where a diode in inserted in serial in the circuit. The diode is a simple device which conducts the current mainly in a single direction. The relation which describe the current <math>I</math> flowing through the diode as a function of the voltage across the junction <math>V_D</math> can be expressed as:<br />
<br />
<math><br />
I=I_S\left(e^{\frac {V_D}{nV_T}}-1\right)<br />
</math><br />
<br />
with <math>V_T = kT/q</math>. If we consider a small variation of the junction voltage <math>v</math> around a bias voltage operating point <math>V_b</math>, the current <math>i</math> can be expressed as Taylor series:<br />
<br />
<math><br />
i(v) = i(V_b) + \frac{i^{(1)}}{1!} (v-V_b) + \frac{i^{(2)}(V_b)}{2!} (v-V_D)^2 + \frac{i^{(3)}(V_b)}{3!} (v-V_b)^3+\cdots<br />
</math><br />
<br />
where <math>i^{(n)}</math> is the <math>n^{\text{th}}</math>-derivative of <math>i(v)</math> according to <math>v</math>.<br />
<br />
If an harmonic tension such as <math>v(t)=A\cos \omega_0 t</math> is applied to this diode, its current <math>i(t)</math><br />
can be expressed as:<br />
<br />
<math><br />
\begin{align}<br />
i(V_D,t) &= i(V_D) + [\frac{A^2}{4} i^{(2)}(V_b) + \frac{A^4}{64}i^{(4)}(V_b)+\cdots]\\<br />
&+ [A i^{(1)}(V_D) + \frac{A^3}{8} i^{(3)}(V_b) + \cdots] \cos \omega_0 t\\<br />
&+ [\frac{A^2}{4} i^{(2)}(V_b) + \frac{A^4}{48}i^{(4)}(V_b)+\cdots] \cos 2\omega_0 t\\<br />
&+ [\frac{A^3}{24} i^{(3)}(V_b) + \frac{A^5}{384}i^{(4)}(V_b)+\cdots] \cos 3\omega_0 t\\<br />
&+ \cdots<br />
\end{align}<br />
</math><br />
<br />
where we can see that an infinite sum of harmonics has been created due the non-linear behavior of the diode.<br />
<!-- Note also, that each term can be viewed as coefficient of Fourier series of the decomposition <math>i(V_d, t)</math>. --><br />
<br />
<!-- [[File:Vtime.png|300px|thumb|right|Voltage across R in the time domain]] --><br />
<br />
[[File:Vfrequency.png|300px|thumb|right|Fig. 3: Voltage across R in the frequency domain]]<br />
<br />
This circuit can easily be simulated using <syntaxhighlight lang="text" inline>ngspice</syntaxhighlight> using the transient analysis to clearly see the effect of the non-linearity of a HSMS285x diode.<br />
Amplitude has been set to 1V, frequency at 915 MHz. Simulation has been computed over a duration of 10 periods with 100 samples per period. Fourier series have been computed over the voltage across the load.<br />
<br />
<syntaxhighlight lang="text" line="line"><br />
.title diode<br />
.param A = 1<br />
.param f0 = 915e6<br />
.model hsms285x D (IS=3e-6 RS=25 N=1.06 CJO=0.18pF VJ=0.35 M=0.5 EG=0.69 XTI=2 BV=3.8 IBV=3e-4)<br />
V1 1 0 dc 0 SIN(0 A f0 0NS 0)<br />
Ra 2 1 50<br />
D1 2 3 hsms285x<br />
Rl 3 0 50<br />
.end<br />
<br />
.csparam csf0 = {f0}<br />
.csparam duration = {10.0/f0}<br />
.csparam fsample = {1/(100*f0)}<br />
.control<br />
tran $&fsample $&duration<br />
plot v(3)<br />
fourier $&csf0 v(3)<br />
.endc<br />
</syntaxhighlight><br />
<br />
The simulation clearly shows that the power dissipated into the load contains power at <math>f_0</math> but also at <math>n f_0</math> due to the non-linear behavior of the diode.<br />
Harvesters use the power located at <math>n=0</math> where as harmonic transponders are based on the power located at <math>n > 1</math>.<br />
<br />
For passive harmonic transponders, an antenna accepting the power at <math>f_0</math> have to be added. The backscattered power at <math>n f_0</math> should also be re-radiated by another antenna.<br />
The main difficulty appears from the incident power which is very low (few micro Watt) which need to generate a voltage higher than the threshold of the diode (around 0.3 V). Usually the conversion loss associated to these devices is lower than -20 dB (i.e. only 1% of the incident power is converted to an harmonic frequency). However, read range of these transponders can easily achieve more than 5 m while satisfying regulation standards.<br />
<br />
----<br />
<br />
Finally, all presented systems (time-varing and non-linear transponders) can also be characterized by a non-zero differential RCS (or delta RCS) <math>\sigma_d</math> since they are able to modulate their backscattered power. This delta RCS is the direct generalization of the quantity classically defined for UHF tags. More information can be found [[Differential RCS|here]].<br />
<br />
== Conclusion ==<br />
<br />
I hope you have liked this page. If you have any comment, remarks or questions about these ideas, feel free to send me an email:<br />
<br />
[mailto:nicolas.barbot@lcis.grenoble-inp.fr <syntaxhighlight lang="text" inline>nicolas.barbot@lcis.grenoble-inp.fr</syntaxhighlight>]<br />
<br />
Collaborations often start by simple emails...<br />
<br />
==References==<br />
<br />
<references /></div>Nicohttps://nicolas-barbot.ovh/wiki/index.php?title=Research_Activities&diff=477Research Activities2021-10-18T09:20:47Z<p>Nico: </p>
<hr />
<div>My research interests include passive (or semi-passive) transponders which can not be modeled as linear time-invariant systems. These transponders have enhanced performance in term of coding capacity and read range compared to classical linear time-invariant systems. These results and can only be achieved by breaking the linearity or the time invariance associated to the transponder.<br />
<br />
<br />
== Introduction ==<br />
<br />
[[File:Color.gif|thumb|right|Fig. 1: Environment under white light]]<br />
<br />
[[File:Color_red.gif|thumb|right|Fig. 2: Environment under red light]]<br />
<br />
Almost all the objects that we can see or characterize are Linear Time Invariant (LTI) systems. It implies that if they are impinged by an electromagnetic wave at a frequency <math>f_0</math> (in input), they also reflect or backscatter an electromagnetic wave at the same frequency <math>f_0</math> (in output).<br />
<br />
These LTI systems can be fully characterized by their impulse response <math>h(t)</math> in the time domain or their transfer function <math>H(f)</math> in the frequency domain. The output signal <math>y(t)</math> can be obtained in the time domain if the input signal <math>x(t)</math> is known as:<br />
<br />
<math><br />
y(t) = x(t) * h(t)<br />
</math><br />
<br />
Expression can equivalently be derived in the frequency domain:<br />
<br />
<math><br />
Y(f) = X(f) \times H(f)<br />
</math><br />
<br />
Classical examples include dynamical systems (electrical circuits, mechanical systems...). <br />
If we consider that the incident waveform is a continuous wave of frequency <math>f_0</math> then its real signal can be expressed as <math>x(t) = \cos 2 \pi f_0 t</math>. The received signal takes in that case, the simple form:<br />
<br />
<math><br />
y(t) = |H(f_0)| \cos (2 \pi f_0 t + Arg(H(f_0)))<br />
</math><br />
<br />
where we can easily see that the backscattered signal of a LTI system can only affect the amplitude <math>|H(f_0)|</math> and/or the phase <math>Arg(H(f_0))</math> of the incident waveform. Note that all the received power is also located at <math>f_0</math> since a LTI system can not generate a frequency which is not in the input signal.<br />
<br />
Let's consider a simple example, where an environment composed of different pens on a white support is illuminated by white light as in Fig. 1. Under these conditions, note that each object is characterized by a different color since they all accept the incident power and they each reflect a tiny part of the input spectrum. However, if we replace the white light by a red light (or any monochromatic color), each object will reflect the CW with an attenuation <math>|H(f_0)|</math> and a phase shift of <math>Arg(H(f_0))</math> but the frequency of the reflected wave will remain at <math>f_0</math> and the color of all object lies in between red (when attenuation is low) and black (when attenuation is high). Results are presented in Fig. 2. Almost all the objects that we see around us (like these pens and this support) are LTI systems.<br />
<br />
This simple observation implies important constraints if we want to identify any LTI object according the their backscattered or reflected signal:<br />
# The coding capacity only depends on the number of the color which can be distinguished. This capacity is only a function of the frequency resolution compared to the total bandwidth used by the reader. The total bandwidth used by the reader depends on the input signal. That is why we can differentiate pen under white light and not under red light.<br />
# The associated read range is only limited by the ratio in between the power backscattered by the object compared to the power reflected by the environment at the same frequency. This condition is harder to see with the picture since, pens can be separated spatially due to the camera lens but remember that an antenna cannot detect the direction of arrival of the received power.<br />
These limitation only appear since both pens and support (white table) are LTI systems and impose strict constraint in term of coding capacity and read range for any system based on LTI transponders.<br />
<br />
== Research Interest ==<br />
<br />
My research interests include all systems which cannot be modeled by a linear time-invariant system. As a direct consequence, these systems cannot be described by an impulse response or a transfer function<br />
and are able to accept the incident power at a given frequency and reflect or backscatter (a part of) this power at an other frequency or in another bandwidth. For example, in Fig. 2, these systems could appear under the red illumination as blue of green objects...<br />
This result can be obtained by only 2 ways, breaking the linearity (i.e., non linear systems) or breaking the time invariance (i.e. linear time variant systems). A third method consist of breaking the invariance on the reader side.<br />
<br />
Note also that breaking the time-invariance with a scatterer has been investigated since 1948 by H. Stockman, <ref>"Communication by Means of Reflected Power," in Proceedings of the IRE, vol. 36, no. 10, pp. 1196-1204, Oct. 1948, doi: 10.1109/JRPROC.1948.226245</ref> for both loaded scatterers (which is the basic principle used in UHF RFID) and rotating scatterers.<br />
<br />
=== Linear time variant systems ===<br />
<br />
[[File:line_coding.png|300px|thumb|right|Fig. 4: PSD of the signal backscattered by a modulating tag.]]<br />
<br />
These class of transponders include many examples. The more famous ones are classical RFID tags. UHF RFID tags can, when a sufficient power is received by the chip, switch the internal load connected to the antenna in between 2 values, its RCS is also modified and becomes a function of the time. Finally the variations of the backscattered signal generate a modulation which can be detected by the reader. As a direct consequence, the backscattered power spectral density includes components which are not at <math>f_0</math>. If the transmission data rate is much lower than the carrier frequency, narrow band signal approximation holds and PSD is located around <math>f_0</math>. The exact characteristics of the PSD depends on the data encoding used by the tag during the communication. The UHF RFID standard defines two different modulations for the tag which are FM0 and Miller (with different subcarrier sequences). Analytical formula of the PSD for FM0 is known and is equal to the Manchester encoding. For Miller modulation, analytical formula is also known, but without considering the subcarrier sequences. Fig. 5 presents the PSD of the baseband signals corresponding to the different modulations used by the tag. For all modulation we can see that the PSD is spread around <math>f_0</math> and that the system can not be considered as a LTI system.<br />
<br />
<br />
Another example appears when objects are moved or rotated into space. This interesting phenomenon is better illustrated by considering the simple case where a target is impinged by a continuous wave at a frequency <math>f_0</math>, if the radial speed of the target compared to the antenna is not zero, Doppler effect actually modifies the backscattered wave frequency received by the antenna which can be expressed as:<br />
<br />
<math> <br />
f=\left(\frac {c}{c\pm v_s}\right)f_0<br />
</math><br />
<br />
[[File:stem.png|thumb|right|Fig. 5: Spectrum of a rotating dipole impinged by a CW.]]<br />
<br />
Periodical movements of frequency <math>f_r</math>, such as vibrations and rotations, lead to simple analytical expressions where the backscattered spectrum is composed of discrete peaks located at <math>f_0 \pm n f_r</math>. Let's consider a vertical dipole oriented along <math>z</math> located at <math>x=5</math> cm and <math>y=0</math> cm and impinged by a plane wave at 915 MHz propagating along <math>y</math>. If we rotate this dipole along the <math>z</math> axis with a frequency <math>f_r</math>, the phase backscattered electric field in farfield is modulated by a sinus function while the magnitude remains constant (micro-Doppler). This situation can surprisingly easily by simulated in time domain using a frequency solver such as <syntaxhighlight lang="text" inline>nec2</syntaxhighlight>.<br />
<br />
<syntaxhighlight lang="text" line='line' highlight="3"><br />
CE MICRO-DOPPLER<br />
GW 0 50 -0.0165 0.05 0. 0.0165 0.05 0. 0.0005<br />
GM 0 0 0. 0. 0. 0. 0. 0.<br />
GE<br />
EX 1 1 1 0 0 0 0 0 0 0<br />
FR 0 1 0 0 915e6 0<br />
RP 0 1 1 1000 0 0 0 0 1<br />
EN<br />
</syntaxhighlight><br />
<br />
Since at any given time, the system can be assumed as a linear time invariant system, the excitation of the structure by a CW can be fully described by simply determining the received amplitude and phase.<br />
Thus, the received response during the rotation can be estimated by determining the variation of amplitude and phase scattered by the structure, for each angle <math>\theta</math> of the scatterer. The variation of the amplitude and phase also correspond to the variations of the received signal the time domain signal. Thus by changing the <syntaxhighlight lang="text" inline>GM</syntaxhighlight> card, the backscattered signal can be determined for all <math>\theta</math> values. Fourier series of this signal can be computed and lead to a discrete spectrum at <math>k f_r</math> presented in Fig. 4. Analytical form is identical to a frequency modulated signal with an index modulation of <math>\beta = 1.92</math> and can be expressed as a function of the Bessel function of first kind.<br />
<br />
Finally, note that for every modification of the response of the transponder during the interrogation done by the reader implies a modulation of the backscattered signal in time which generate a non-zero power in the PSD around <math>f_0</math>. However these modifications require an energy source which can be brought by the reader itself (as in UHF RFID) or by an external action (as the displacement or rotation of the tag). In these latter case, transponders can be considered as semi-passive.<br />
<br />
=== Imaging systems ===<br />
<br />
[[File:Myean13.png|thumb|right|Fig. 6: Barcode and modulated reflected signal]]<br />
<br />
Imaging systems are a special kind of linear time variant system where the variations are not produced by the tag but by the reader itself. In this case, the tag remains a LTI systems, but the reading method done by the reader allows to extract the tag response as a function of variation in time which break the invariance propertie. These tags (and the associated reading method) are not limited by the bounds on coding capacity and read range. The simplest example is the barcode and is presented in Fig. 5. Classical barcodes are composed of black stripes and can encode 43 bits of information. Barcodes are read by sweeping the beam produced by a laser diode along the tag and by measuring the variations of the reflected signal in time. Scientists often usually consider that chipless technology is more related to barcodes than UHF technology, however, note that the reflected signal of a barcode is a modulated signal which is, by principle, identical to the backscattered signals of UHF RFID and moving or rotating tags. As such, barcodes and their reading method cannot be considered as LTI systems and are characterized by a non-zero delta RCS and a (possible) much larger read range.<br />
<br />
This spatial diversity allows to use the same color multiple time to encode information (stripes do not have to use a different color and 2 colors are enought) which significantly increases the coding capacity. <br />
2D images and their associated reading method can also be considered as linear time variant systems (which include QR code, or any image obtained with a lens and camera sensor). All these systems operate in the optical domain since spatial resolution is only limited by the small beam divergence of laser diodes (less than 1 mrad) or the sensor matrix size of camera sensors. However, note that when frequency is decreased, antenna directivity is also reduced which significantly limits the performance of this approach in the RF domain. For example in UWB band half power angle is usually higher than 10° which imposes large separation in between stripes (or resonators).<br />
<br />
=== Non linear systems ===<br />
<br />
Transponders based on a non-linear element (such as a Schottky diode) can accept a power at <math>f_0</math> and generate a power at <math>n f_0</math>. Let's consider the simple circuit composed of a generator connected to a load but where a diode in inserted in serial in the circuit. The diode is a simple device which conducts the current mainly in a single direction. The relation which describe the current <math>I</math> flowing through the diode as a function of the voltage across the junction <math>V_D</math> can be expressed as:<br />
<br />
<math><br />
I=I_S\left(e^{\frac {V_D}{nV_T}}-1\right)<br />
</math><br />
<br />
with <math>V_T = kT/q</math>. If we consider a small variation of the junction voltage <math>v</math> around a bias voltage operating point <math>V_b</math>, the current <math>i</math> can be expressed as Taylor series:<br />
<br />
<math><br />
i(v) = i(V_b) + \frac{i^{(1)}}{1!} (v-V_b) + \frac{i^{(2)}(V_b)}{2!} (v-V_D)^2 + \frac{i^{(3)}(V_b)}{3!} (v-V_b)^3+\cdots<br />
</math><br />
<br />
where <math>i^{(n)}</math> is the <math>n^{\text{th}}</math>-derivative of <math>i(v)</math> according to <math>v</math>.<br />
<br />
If an harmonic tension such as <math>v(t)=A\cos \omega_0 t</math> is applied to this diode, its current <math>i(t)</math><br />
can be expressed as:<br />
<br />
<math><br />
\begin{align}<br />
i(V_D,t) &= i(V_D) + [\frac{A^2}{4} i^{(2)}(V_b) + \frac{A^4}{64}i^{(4)}(V_b)+\cdots]\\<br />
&+ [A i^{(1)}(V_D) + \frac{A^3}{8} i^{(3)}(V_b) + \cdots] \cos \omega_0 t\\<br />
&+ [\frac{A^2}{4} i^{(2)}(V_b) + \frac{A^4}{48}i^{(4)}(V_b)+\cdots] \cos 2\omega_0 t\\<br />
&+ [\frac{A^3}{24} i^{(3)}(V_b) + \frac{A^5}{384}i^{(4)}(V_b)+\cdots] \cos 3\omega_0 t\\<br />
&+ \cdots<br />
\end{align}<br />
</math><br />
<br />
where we can see that an infinite sum of harmonics has been created due the non-linear behavior of the diode.<br />
<!-- Note also, that each term can be viewed as coefficient of Fourier series of the decomposition <math>i(V_d, t)</math>. --><br />
<br />
<!-- [[File:Vtime.png|300px|thumb|right|Voltage across R in the time domain]] --><br />
<br />
[[File:Vfrequency.png|300px|thumb|right|Fig. 3: Voltage across R in the frequency domain]]<br />
<br />
This circuit can easily be simulated using <syntaxhighlight lang="text" inline>ngspice</syntaxhighlight> using the transient analysis to clearly see the effect of the non-linearity of a HSMS285x diode.<br />
Amplitude has been set to 1V, frequency at 915 MHz. Simulation has been computed over a duration of 10 periods with 100 samples per period. Fourier series have been computed over the voltage across the load.<br />
<br />
<syntaxhighlight lang="text" line="line"><br />
.title diode<br />
.param A = 1<br />
.param f0 = 915e6<br />
.model hsms285x D (IS=3e-6 RS=25 N=1.06 CJO=0.18pF VJ=0.35 M=0.5 EG=0.69 XTI=2 BV=3.8 IBV=3e-4)<br />
V1 1 0 dc 0 SIN(0 A f0 0NS 0)<br />
Ra 2 1 50<br />
D1 2 3 hsms285x<br />
Rl 3 0 50<br />
.end<br />
<br />
.csparam csf0 = {f0}<br />
.csparam duration = {10.0/f0}<br />
.csparam fsample = {1/(100*f0)}<br />
.control<br />
tran $&fsample $&duration<br />
plot v(3)<br />
fourier $&csf0 v(3)<br />
.endc<br />
</syntaxhighlight><br />
<br />
The simulation clearly shows that the power dissipated into the load contains power at <math>f_0</math> but also at <math>n f_0</math> due to the non-linear behavior of the diode.<br />
Harvesters use the power located at <math>n=0</math> where as harmonic transponders are based on the power located at <math>n > 1</math>.<br />
<br />
For passive harmonic transponders, an antenna accepting the power at <math>f_0</math> have to be added. The backscattered power at <math>n f_0</math> should also be re-radiated by another antenna.<br />
The main difficulty appears from the incident power which is very low (few micro Watt) which need to generate a voltage higher than the threshold of the diode (around 0.3 V). Usually the conversion loss associated to these devices is lower than -20 dB (i.e. only 1% of the incident power is converted to an harmonic frequency). However, read range of these transponders can easily achieve more than 5 m while satisfying regulation standards.<br />
<br />
Finally, all presented systems (time-varing and non-linear transponders) can also be characterized by a non-zero differential RCS (or delta RCS) <math>\sigma_d</math> since they are able to modulate their backscattered power. This delta RCS is the direct generalization of the quantity classically defined for UHF tags. More information can be found [[Differential RCS|here]].<br />
<br />
== Conclusion ==<br />
<br />
I hope you have liked this page. If you have any comment, remarks or questions about these ideas, feel free to send me an email:<br />
<br />
[mailto:nicolas.barbot@lcis.grenoble-inp.fr <syntaxhighlight lang="text" inline>nicolas.barbot@lcis.grenoble-inp.fr</syntaxhighlight>]<br />
<br />
Collaborations often start by simple emails...<br />
<br />
==References==<br />
<br />
<references /></div>Nicohttps://nicolas-barbot.ovh/wiki/index.php?title=Research_Activities&diff=476Research Activities2021-10-18T09:11:07Z<p>Nico: </p>
<hr />
<div>My research interests include passive (or semi-passive) transponders which can not be modeled as linear time-invariant systems. These transponders have enhanced performance in term of coding capacity and read range compared to classical linear time-invariant systems. These results and can only be achieved by breaking the linearity or the time invariance associated to the transponder.<br />
<br />
<br />
== Introduction ==<br />
<br />
[[File:Color.gif|thumb|right|Fig. 1: Environment under white light]]<br />
<br />
[[File:Color_red.gif|thumb|right|Fig. 2: Environment under red light]]<br />
<br />
Almost all the objects that we can see or characterize are Linear Time Invariant (LTI) systems. It implies that if they are impinged by an electromagnetic wave at a frequency <math>f_0</math> (in input), they also reflect or backscatter an electromagnetic wave at the same frequency <math>f_0</math> (in output).<br />
<br />
These LTI systems can be fully characterized by their impulse response <math>h(t)</math> in the time domain or their transfer function <math>H(f)</math> in the frequency domain. The output signal <math>y(t)</math> can be obtained in the time domain if the input signal <math>x(t)</math> is known as:<br />
<br />
<math><br />
y(t) = x(t) * h(t)<br />
</math><br />
<br />
Expression can equivalently be derived in the frequency domain:<br />
<br />
<math><br />
Y(f) = X(f) \times H(f)<br />
</math><br />
<br />
Classical examples include dynamical systems (electrical circuits, mechanical systems...). <br />
If we consider that the incident waveform is a continuous wave of frequency <math>f_0</math> then its real signal can be expressed as <math>x(t) = \cos 2 \pi f_0 t</math>. The received signal takes in that case, the simple form:<br />
<br />
<math><br />
y(t) = |H(f_0)| \cos (2 \pi f_0 t + Arg(H(f_0)))<br />
</math><br />
<br />
where we can easily see that the backscattered signal of a LTI system can only affect the amplitude <math>|H(f_0)|</math> and/or the phase <math>Arg(H(f_0))</math> of the incident waveform. Note that all the received power is also located at <math>f_0</math> since a LTI system can not generate a frequency which is not in the input signal.<br />
<br />
Let's consider a simple example, where an environment composed of different pens on a white support is illuminated by white light as in Fig. 1. Under these conditions, note that each object is characterized by a different color since they all accept the incident power and they each reflect a tiny part of the input spectrum. However, if we replace the white light by a red light (or any monochromatic color), each object will reflect the CW with an attenuation <math>|H(f_0)|</math> and a phase shift of <math>Arg(H(f_0))</math> but the frequency of the reflected wave will remain at <math>f_0</math> and the color of all object lies in between red (when attenuation is low) and black (when attenuation is high). Results are presented in Fig. 2. Almost all the objects that we see around us (like these pens and this support) are LTI systems.<br />
<br />
This simple observation implies important constraints if we want to identify any LTI object according the their backscattered or reflected signal:<br />
# The coding capacity only depends on the number of the color which can be distinguished. This capacity is only a function of the frequency resolution compared to the total bandwidth used by the reader. The total bandwidth used by the reader depends on the input signal. That is why we can differentiate pen under white light and not under red light.<br />
# The associated read range is only limited by the ratio in between the power backscattered by the object compared to the power reflected by the environment at the same frequency. This condition is harder to see with the picture since, pens can be separated spatially due to the camera lens but remember that an antenna cannot detect the direction of arrival of the received power.<br />
These limitation only appear since both pens and support (white table) are LTI systems and impose strict constraint in term of coding capacity and read range for any system based on LTI transponders.<br />
<br />
== Research Interest ==<br />
<br />
My research interests include all systems which cannot be modeled by a linear time-invariant system. As a direct consequence, these systems cannot be described by an impulse response or a transfer function<br />
and are able to accept the incident power at a given frequency and reflect or backscatter (a part of) this power at an other frequency or in another bandwidth. For example, in Fig. 2, these systems could appear under the red illumination as blue of green objects...<br />
This result can be obtained by only 2 ways, breaking the linearity (i.e., non linear systems) or breaking the time invariance (i.e. linear time variant systems). A third method consist of breaking the invariance on the reader side.<br />
<br />
Note also that breaking the time-invariance with a scatterer has been investigated since 1948 by H. Stockman, <ref>"Communication by Means of Reflected Power," in Proceedings of the IRE, vol. 36, no. 10, pp. 1196-1204, Oct. 1948, doi: 10.1109/JRPROC.1948.226245</ref> for both loaded scatterers (which is the basic principle used in UHF RFID) and rotating scatterers.<br />
<br />
=== Linear time variant systems ===<br />
<br />
[[File:line_coding.png|300px|thumb|right|Fig. 4: PSD of the signal backscattered by a modulating tag.]]<br />
<br />
These class of transponders include many examples. The more famous ones are classical RFID tags. UHF RFID tags can, when a sufficient power is received by the chip, switch the internal load connected to the antenna in between 2 values, its RCS is also modified and becomes a function of the time. Finally the variations of the backscattered signal generate a modulation which can be detected by the reader. As a direct consequence, the backscattered power spectral density includes components which are not at <math>f_0</math>. If the transmission data rate is much lower than the carrier frequency, narrow band signal approximation holds and PSD is located around <math>f_0</math>. The exact characteristics of the PSD depends on the data encoding used by the tag during the communication. The UHF RFID standard defines two different modulations for the tag which are FM0 and Miller (with different subcarrier sequences). Analytical formula of the PSD for FM0 is known and is equal to the Manchester encoding. For Miller modulation, analytical formula is also known, but without considering the subcarrier sequences. Fig. 5 presents the PSD of the baseband signals corresponding to the different modulations used by the tag. For all modulation we can see that the PSD is spread around <math>f_0</math> and that the system can not be considered as a LTI system.<br />
<br />
<br />
Another example appears when objects are moved or rotated into space. This interesting phenomenon is better illustrated by considering the simple case where a target is impinged by a continuous wave at a frequency <math>f_0</math>, if the radial speed of the target compared to the antenna is not zero, Doppler effect actually modifies the backscattered wave frequency received by the antenna which can be expressed as:<br />
<br />
<math> <br />
f=\left(\frac {c}{c\pm v_s}\right)f_0<br />
</math><br />
<br />
[[File:stem.png|thumb|right|Fig. 5: Spectrum of a rotating dipole impinged by a CW.]]<br />
<br />
Periodical movements of frequency <math>f_r</math>, such as vibrations and rotations, lead to simple analytical expressions where the backscattered spectrum is composed of discrete peaks located at <math>f_0 \pm n f_r</math>. Let's consider a vertical dipole oriented along <math>z</math> located at <math>x=5</math> cm and <math>y=0</math> cm and impinged by a plane wave at 915 MHz propagating along <math>y</math>. If we rotate this dipole along the <math>z</math> axis with a frequency <math>f_r</math>, the phase backscattered electric field in farfield is modulated by a sinus function while the magnitude remains constant (micro-Doppler). This situation can surprisingly easily by simulated in time domain using a frequency solver such as <syntaxhighlight lang="text" inline>nec2</syntaxhighlight>.<br />
<br />
<syntaxhighlight lang="text" line='line' highlight="3"><br />
CE MICRO-DOPPLER<br />
GW 0 50 -0.0165 0.05 0. 0.0165 0.05 0. 0.0005<br />
GM 0 0 0. 0. 0. 0. 0. 0.<br />
GE<br />
EX 1 1 1 0 0 0 0 0 0 0<br />
FR 0 1 0 0 915e6 0<br />
RP 0 1 1 1000 0 0 0 0 1<br />
EN<br />
</syntaxhighlight><br />
<br />
Since at any given time, the system can be assumed as a linear time invariant system, the excitation of the structure by a CW can be fully described by simply determining the received amplitude and phase.<br />
Thus, the received response during the rotation can be estimated by determining the variation of amplitude and phase scattered by the structure, for each angle <math>\theta</math> of the scatterer. The variation of the amplitude and phase also correspond to the variations of the received signal the time domain signal. Thus by changing the <syntaxhighlight lang="text" inline>GM</syntaxhighlight> card, the backscattered signal can be determined for all <math>\theta</math> values. Fourier series of this signal can be computed and lead to a discrete spectrum at <math>k f_r</math> presented in Fig. 4. Analytical form is identical to a frequency modulated signal with an index modulation of <math>\beta = 1.92</math> and can be expressed as a function of the Bessel function of first kind.<br />
<br />
Finally, note that for every modification of the response of the transponder during the interrogation done by the reader implies a modulation of the backscattered signal in time which generate a non-zero power in the PSD around <math>f_0</math>. However these modifications require an energy source which can be brought by the reader itself (as in UHF RFID) or by an external action (as the displacement or rotation of the tag). In these latter case, transponders can be considered as semi-passive.<br />
<br />
=== Imaging systems ===<br />
<br />
[[File:Myean13.png|thumb|right|Fig. 6: Barcode and modulated reflected signal]]<br />
<br />
Imaging systems are a special kind of linear time variant system where the variations are not produced by the tag but by the reader itself. In this case, the tag remains a LTI systems, but the reading method done by the reader allows to extract the tag response as a function of variation in time which break the invariance propertie. These tags (and the associated reading method) are not limited by the bounds on coding capacity and read range. The simplest example is the barcode and is presented in Fig. 5. Classical barcodes are composed of black stripes and can encode 43 bits of information. Barcodes are read by sweeping the beam produced by a laser diode along the tag and by measuring the variations of the reflected signal in time. Scientists often usually consider that chipless technology is more related to barcodes than UHF technology, however, note that the reflected signal of a barcode is a modulated signal which is, by principle, identical to the backscattered signals of UHF RFID and moving or rotating tags. As such, barcodes and their reading method cannot be considered as LTI systems and are characterized by a non-zero delta RCS and a (possible) much larger read range.<br />
<br />
This spatial diversity allows to use the same color multiple time to encode information (stripes do not have to use a different color and 2 colors are enought) which significantly increases the coding capacity. <br />
2D images and their associated reading method can also be considered as linear time variant systems (which include QR code, or any image obtained with a lens and camera sensor). All these systems operate in the optical domain since spatial resolution is only limited by the small beam divergence of laser diodes (less than 1 mrad) or the sensor matrix size of camera sensors. However, note that when frequency is decreased, antenna directivity is also reduced which significantly limits the performance of this approach in the RF domain. For example in UWB band half power angle is usually higher than 10° which imposes large separation in between stripes (or resonators).<br />
<br />
=== Non linear systems ===<br />
<br />
Transponders based on a non-linear element (such as a Schottky diode) can accept a power at <math>f_0</math> and generate a power at <math>n f_0</math>. Let's consider the simple circuit composed of a generator connected to a load but where a diode in inserted in serial in the circuit. The diode is a simple device which conducts the current mainly in a single direction. The relation which describe the current <math>I</math> flowing through the diode as a function of the voltage across the junction <math>V_D</math> can be expressed as:<br />
<br />
<math><br />
I=I_S\left(e^{\frac {V_D}{nV_T}}-1\right)<br />
</math><br />
<br />
with <math>V_T = kT/q</math>. If we consider a small variation of the junction voltage <math>v</math> around a bias voltage operating point <math>V_b</math>, the current <math>i</math> can be expressed as Taylor series:<br />
<br />
<math><br />
i(v) = i(V_b) + \frac{i^{(1)}}{1!} (v-V_b) + \frac{i^{(2)}(V_b)}{2!} (v-V_D)^2 + \frac{i^{(3)}(V_b)}{3!} (v-V_b)^3+\cdots<br />
</math><br />
<br />
where <math>i^{(n)}</math> is the <math>n^{\text{th}}</math>-derivative of <math>i(v)</math> according to <math>v</math>.<br />
<br />
If an harmonic tension such as <math>v(t)=A\cos \omega_0 t</math> is applied to this diode, its current <math>i(t)</math><br />
can be expressed as:<br />
<br />
<math><br />
\begin{align}<br />
i(V_D,t) &= i(V_D) + [\frac{A^2}{4} i^{(2)}(V_b) + \frac{A^4}{64}i^{(4)}(V_b)+\cdots]\\<br />
&+ [A i^{(1)}(V_D) + \frac{A^3}{8} i^{(3)}(V_b) + \cdots] \cos \omega_0 t\\<br />
&+ [\frac{A^2}{4} i^{(2)}(V_b) + \frac{A^4}{48}i^{(4)}(V_b)+\cdots] \cos 2\omega_0 t\\<br />
&+ [\frac{A^3}{24} i^{(3)}(V_b) + \frac{A^5}{384}i^{(4)}(V_b)+\cdots] \cos 3\omega_0 t\\<br />
&+ \cdots<br />
\end{align}<br />
</math><br />
<br />
where we can see that an infinite sum of harmonics has been created due the non-linear behavior of the diode.<br />
<!-- Note also, that each term can be viewed as coefficient of Fourier series of the decomposition <math>i(V_d, t)</math>. --><br />
<br />
<!-- [[File:Vtime.png|300px|thumb|right|Voltage across R in the time domain]] --><br />
<br />
[[File:Vfrequency.png|300px|thumb|right|Fig. 3: Voltage across R in the frequency domain]]<br />
<br />
This circuit can easily be simulated using <syntaxhighlight lang="text" inline>ngspice</syntaxhighlight> using the transient analysis to clearly see the effect of the non-linearity of a HSMS285x diode.<br />
Amplitude has been set to 1V, frequency at 915 MHz. Simulation has been computed over a duration of 10 periods with 100 samples per period. Fourier series have been computed over the voltage across the load.<br />
<br />
<syntaxhighlight lang="text" line="line"><br />
.title diode<br />
.param A = 1<br />
.param f0 = 915e6<br />
.model hsms285x D (IS=3e-6 RS=25 N=1.06 CJO=0.18pF VJ=0.35 M=0.5 EG=0.69 XTI=2 BV=3.8 IBV=3e-4)<br />
V1 1 0 dc 0 SIN(0 A f0 0NS 0)<br />
Ra 2 1 50<br />
D1 2 3 hsms285x<br />
Rl 3 0 50<br />
.end<br />
<br />
.csparam csf0 = {f0}<br />
.csparam duration = {10.0/f0}<br />
.csparam fsample = {1/(100*f0)}<br />
.control<br />
tran $&fsample $&duration<br />
plot v(3)<br />
fourier $&csf0 v(3)<br />
.endc<br />
</syntaxhighlight><br />
<br />
The simulation clearly shows that the power dissipated into the load contains power at <math>f_0</math> but also at <math>n f_0</math> due to the non-linear behavior of the diode.<br />
Harvesters use the power located at <math>n=0</math> where as harmonic transponders are based on the power located at <math>n > 1</math>.<br />
<br />
For passive harmonic transponders, an antenna accepting the power at <math>f_0</math> have to be added. The backscattered power at <math>n f_0</math> should also be re-radiated by another antenna.<br />
The main difficulty appears from the incident power which is very low (few micro Watt) which need to generate a voltage higher than the threshold of the diode (around 0.3 V). Usually the conversion loss associated to these devices is lower than -20 dB (i.e. only 1% of the incident power is converted to an harmonic frequency). However, read range of these transponders can easily achieve more than 5 m while satisfying regulation standards.<br />
<br />
Finally, all presented systems (non linear and time-varing transponders) can also be characterized by a non-zero differential RCS (or delta RCS) <math>\sigma_d</math>. This delta RCS is the direct generalization of the quantity classically defined for UHF tags. More information can be found [[Differential RCS|here]].<br />
<br />
== Conclusion ==<br />
<br />
I hope you have liked this page. If you have any comment, remarks or questions about these ideas, feel free to send me an email:<br />
<br />
[mailto:nicolas.barbot@lcis.grenoble-inp.fr <syntaxhighlight lang="text" inline>nicolas.barbot@lcis.grenoble-inp.fr</syntaxhighlight>]<br />
<br />
Collaborations often start by simple emails...<br />
<br />
==References==<br />
<br />
<references /></div>Nicohttps://nicolas-barbot.ovh/wiki/index.php?title=Research_Activities&diff=475Research Activities2021-10-18T07:20:15Z<p>Nico: </p>
<hr />
<div>My research interests include passive (or semi-passive) transponders which can not be modeled as linear time-invariant systems. These transponders have enhanced performance in term of coding capacity and read range compared to classical linear time-invariant systems. These results and can only be achieved by breaking the linearity or the time invariance associated to the transponder.<br />
<br />
<br />
== Introduction ==<br />
<br />
[[File:Color.gif|thumb|right|Fig. 1: Environment under white light]]<br />
<br />
[[File:Color_red.gif|thumb|right|Fig. 2: Environment under red light]]<br />
<br />
Almost all the objects that we can see or characterize are Linear Time Invariant (LTI) systems. It implies that if they are impinged by an electromagnetic wave at a frequency <math>f_0</math> (in input), they also reflect or backscatter an electromagnetic wave at the same frequency <math>f_0</math> (in output).<br />
<br />
These LTI systems can be fully characterized by their impulse response <math>h(t)</math> in the time domain or their transfer function <math>H(f)</math> in the frequency domain. The output signal <math>y(t)</math> can be obtained in the time domain if the input signal <math>x(t)</math> is known as:<br />
<br />
<math><br />
y(t) = x(t) * h(t)<br />
</math><br />
<br />
Expression can equivalently be derived in the frequency domain:<br />
<br />
<math><br />
Y(f) = X(f) \times H(f)<br />
</math><br />
<br />
Classical examples include dynamical systems (electrical circuits, mechanical systems...). <br />
If we consider that the incident waveform is a continuous wave of frequency <math>f_0</math> then its real signal can be expressed as <math>x(t) = \cos 2 \pi f_0 t</math>. The received signal takes in that case, the simple form:<br />
<br />
<math><br />
y(t) = |H(f_0)| \cos (2 \pi f_0 t + Arg(H(f_0)))<br />
</math><br />
<br />
where we can easily see that the backscattered signal of a LTI system can only affect the amplitude <math>|H(f_0)|</math> and/or the phase <math>Arg(H(f_0))</math> of the incident waveform. Note that all the received power is also located at <math>f_0</math> since a LTI system can not generate a frequency which is not in the input signal.<br />
<br />
Let's consider a simple example, where an environment composed of different pens on a white support is illuminated by white light as in Fig. 1. Under these conditions, note that each object is characterized by a different color since they all accept the incident power and they each reflect a tiny part of the input spectrum. However, if we replace the white light by a red light (or any monochromatic color), each object will reflect the CW with an attenuation <math>|H(f_0)|</math> and a phase shift of <math>Arg(H(f_0))</math> but the frequency of the reflected wave will remain at <math>f_0</math> and the color of all object lies in between red (when attenuation is low) and black (when attenuation is high). Results are presented in Fig. 2. Almost all the objects that we see around us (like these pens and this support) are LTI systems.<br />
<br />
This simple observation implies important constraints if we want to identify any LTI object according the their backscattered or reflected signal:<br />
# The coding capacity only depends on the number of the color which can be distinguished. This capacity is only a function of the frequency resolution compared to the total bandwidth used by the reader. The total bandwidth used by the reader depends on the input signal. That is why we can differentiate pen under white light and not under red light.<br />
# The associated read range is only limited by the ratio in between the power backscattered by the object compared to the power reflected by the environment at the same frequency. This condition is harder to see with the picture since, pens can be separated spatially due to the camera lens but remember that an antenna cannot detect the direction of arrival of the received power.<br />
These limitation only appear since both pens and support (white table) are LTI systems and impose strict constraint in term of coding capacity and read range for any system based on LTI transponders.<br />
<br />
== Research Interest ==<br />
<br />
My research interests include all systems which cannot be modeled by a linear time-invariant system. As a direct consequence, these systems cannot be described by an impulse response or a transfer function<br />
and are able to accept the incident power at a given frequency and reflect or backscatter (a part of) this power at an other frequency or in another bandwidth. For example, in Fig. 2, these systems could appear under the red illumination as blue of green objects...<br />
This result can be obtained by only 2 ways, breaking the linearity (i.e., non linear systems) or breaking the time invariance (i.e. linear time variant systems). A third method consist of breaking the invariance on the reader side.<br />
<br />
Note also that breaking the linearity by a scatterer has been investigated since 1948 by H. Stockman, <ref>"Communication by Means of Reflected Power," in Proceedings of the IRE, vol. 36, no. 10, pp. 1196-1204, Oct. 1948, doi: 10.1109/JRPROC.1948.226245</ref>.<br />
<br />
=== Non linear systems ===<br />
<br />
Transponders based on a non-linear element (such as a Schottky diode) can accept a power at <math>f_0</math> and generate a power at <math>n f_0</math>. Let's consider the simple circuit composed of a generator connected to a load but where a diode in inserted in serial in the circuit. The diode is a simple device which conducts the current mainly in a single direction. The relation which describe the current <math>I</math> flowing through the diode as a function of the voltage across the junction <math>V_D</math> can be expressed as:<br />
<br />
<math><br />
I=I_S\left(e^{\frac {V_D}{nV_T}}-1\right)<br />
</math><br />
<br />
with <math>V_T = kT/q</math>. If we consider a small variation of the junction voltage <math>v</math> around a bias voltage operating point <math>V_b</math>, the current <math>i</math> can be expressed as Taylor series:<br />
<br />
<math><br />
i(v) = i(V_b) + \frac{i^{(1)}}{1!} (v-V_b) + \frac{i^{(2)}(V_b)}{2!} (v-V_D)^2 + \frac{i^{(3)}(V_b)}{3!} (v-V_b)^3+\cdots<br />
</math><br />
<br />
where <math>i^{(n)}</math> is the <math>n^{\text{th}}</math>-derivative of <math>i(v)</math> according to <math>v</math>.<br />
<br />
If an harmonic tension such as <math>v(t)=A\cos \omega_0 t</math> is applied to this diode, its current <math>i(t)</math><br />
can be expressed as:<br />
<br />
<math><br />
\begin{align}<br />
i(V_D,t) &= i(V_D) + [\frac{A^2}{4} i^{(2)}(V_b) + \frac{A^4}{64}i^{(4)}(V_b)+\cdots]\\<br />
&+ [A i^{(1)}(V_D) + \frac{A^3}{8} i^{(3)}(V_b) + \cdots] \cos \omega_0 t\\<br />
&+ [\frac{A^2}{4} i^{(2)}(V_b) + \frac{A^4}{48}i^{(4)}(V_b)+\cdots] \cos 2\omega_0 t\\<br />
&+ [\frac{A^3}{24} i^{(3)}(V_b) + \frac{A^5}{384}i^{(4)}(V_b)+\cdots] \cos 3\omega_0 t\\<br />
&+ \cdots<br />
\end{align}<br />
</math><br />
<br />
where we can see that an infinite sum of harmonics has been created due the non-linear behavior of the diode.<br />
<!-- Note also, that each term can be viewed as coefficient of Fourier series of the decomposition <math>i(V_d, t)</math>. --><br />
<br />
<!-- [[File:Vtime.png|300px|thumb|right|Voltage across R in the time domain]] --><br />
<br />
[[File:Vfrequency.png|300px|thumb|right|Fig. 3: Voltage across R in the frequency domain]]<br />
<br />
This circuit can easily be simulated using <syntaxhighlight lang="text" inline>ngspice</syntaxhighlight> using the transient analysis to clearly see the effect of the non-linearity of a HSMS285x diode.<br />
Amplitude has been set to 1V, frequency at 915 MHz. Simulation has been computed over a duration of 10 periods with 100 samples per period. Fourier series have been computed over the voltage across the load.<br />
<br />
<syntaxhighlight lang="text" line="line"><br />
.title diode<br />
.param A = 1<br />
.param f0 = 915e6<br />
.model hsms285x D (IS=3e-6 RS=25 N=1.06 CJO=0.18pF VJ=0.35 M=0.5 EG=0.69 XTI=2 BV=3.8 IBV=3e-4)<br />
V1 1 0 dc 0 SIN(0 A f0 0NS 0)<br />
Ra 2 1 50<br />
D1 2 3 hsms285x<br />
Rl 3 0 50<br />
.end<br />
<br />
.csparam csf0 = {f0}<br />
.csparam duration = {10.0/f0}<br />
.csparam fsample = {1/(100*f0)}<br />
.control<br />
tran $&fsample $&duration<br />
plot v(3)<br />
fourier $&csf0 v(3)<br />
.endc<br />
</syntaxhighlight><br />
<br />
The simulation clearly shows that the power dissipated into the load contains power at <math>f_0</math> but also at <math>n f_0</math> due to the non-linear behavior of the diode.<br />
Harvesters use the power located at <math>n=0</math> where as harmonic transponders are based on the power located at <math>n > 1</math>.<br />
<br />
For passive harmonic transponders, an antenna accepting the power at <math>f_0</math> have to be added. The backscattered power at <math>n f_0</math> should also be re-radiated by another antenna.<br />
The main difficulty appears from the incident power which is very low (few micro Watt) which need to generate a voltage higher than the threshold of the diode (around 0.3 V). Usually the conversion loss associated to these devices is lower than -20 dB (i.e. only 1% of the incident power is converted to an harmonic frequency). However, read range of these transponders can easily achieve more than 5 m while satisfying regulation standards.<br />
<br />
=== Linear time variant systems ===<br />
<br />
[[File:line_coding.png|300px|thumb|right|Fig. 4: PSD of the signal backscattered by a modulating tag.]]<br />
<br />
These class of transponders include many examples. The more famous ones are classical RFID tags. UHF RFID tags can, when a sufficient power is received by the chip, switch the internal load connected to the antenna in between 2 values, its RCS is also modified and becomes a function of the time. Finally the variations of the backscattered signal generate a modulation which can be detected by the reader. As a direct consequence, the backscattered power spectral density includes components which are not at <math>f_0</math>. If the transmission data rate is much lower than the carrier frequency, narrow band signal approximation holds and PSD is located around <math>f_0</math>. The exact characteristics of the PSD depends on the data encoding used by the tag during the communication. The UHF RFID standard defines two different modulations for the tag which are FM0 and Miller (with different subcarrier sequences). Analytical formula of the PSD for FM0 is known and is equal to the Manchester encoding. For Miller modulation, analytical formula is also known, but without considering the subcarrier sequences. Fig. 5 presents the PSD of the baseband signals corresponding to the different modulations used by the tag. For all modulation we can see that the PSD is spread around <math>f_0</math> and that the system can not be considered as a LTI system.<br />
<br />
<br />
Another example appears when objects are moved or rotated into space. This interesting phenomenon is better illustrated by considering the simple case where a target is impinged by a continuous wave at a frequency <math>f_0</math>, if the radial speed of the target compared to the antenna is not zero, Doppler effect actually modifies the backscattered wave frequency received by the antenna which can be expressed as:<br />
<br />
<math> <br />
f=\left(\frac {c}{c\pm v_s}\right)f_0<br />
</math><br />
<br />
[[File:stem.png|thumb|right|Fig. 5: Spectrum of a rotating dipole impinged by a CW.]]<br />
<br />
Periodical movements of frequency <math>f_r</math>, such as vibrations and rotations, lead to simple analytical expressions where the backscattered spectrum is composed of discrete peaks located at <math>f_0 \pm n f_r</math>. Let's consider a vertical dipole oriented along <math>z</math> located at <math>x=5</math> cm and <math>y=0</math> cm and impinged by a plane wave at 915 MHz propagating along <math>y</math>. If we rotate this dipole along the <math>z</math> axis with a frequency <math>f_r</math>, the phase backscattered electric field in farfield is modulated by a sinus function while the magnitude remains constant (micro-Doppler). This situation can surprisingly easily by simulated in time domain using a frequency solver such as <syntaxhighlight lang="text" inline>nec2</syntaxhighlight>.<br />
<br />
<syntaxhighlight lang="text" line='line' highlight="3"><br />
CE MICRO-DOPPLER<br />
GW 0 50 -0.0165 0.05 0. 0.0165 0.05 0. 0.0005<br />
GM 0 0 0. 0. 0. 0. 0. 0.<br />
GE<br />
EX 1 1 1 0 0 0 0 0 0 0<br />
FR 0 1 0 0 915e6 0<br />
RP 0 1 1 1000 0 0 0 0 1<br />
EN<br />
</syntaxhighlight><br />
<br />
Since at any given time, the system can be assumed as a linear time invariant system, the excitation of the structure by a CW can be fully described by simply determining the received amplitude and phase.<br />
Thus, the received response during the rotation can be estimated by determining the variation of amplitude and phase scattered by the structure, for each angle <math>\theta</math> of the scatterer. The variation of the amplitude and phase also correspond to the variations of the received signal the time domain signal. Thus by changing the <syntaxhighlight lang="text" inline>GM</syntaxhighlight> card, the backscattered signal can be determined for all <math>\theta</math> values. Fourier series of this signal can be computed and lead to a discrete spectrum at <math>k f_r</math> presented in Fig. 4. Analytical form is identical to a frequency modulated signal with an index modulation of <math>\beta = 1.92</math> and can be expressed as a function of the Bessel function of first kind.<br />
<br />
Finally, note that for every modification of the response of the transponder during the interrogation done by the reader implies a modulation of the backscattered signal in time which generate a non-zero power in the PSD around <math>f_0</math>. However these modifications require an energy source which can be brought by the reader itself (as in UHF RFID) or by an external action (as the displacement or rotation of the tag). In these latter case, transponders can be considered as semi-passive.<br />
<br />
=== Imaging systems ===<br />
<br />
[[File:Myean13.png|thumb|right|Fig. 6: Barcode and modulated reflected signal]]<br />
<br />
Imaging systems are a special kind of linear time variant system where the variations are not produced by the tag but by the reader itself. In this case, the tag remains a LTI systems, but the reading method done by the reader allows to extract the tag response as a function of variation in time which break the invariance propertie. These tags (and the associated reading method) are not limited by the bounds on coding capacity and read range. The simplest example is the barcode and is presented in Fig. 5. Classical barcodes are composed of black stripes and can encode 43 bits of information. Barcodes are read by sweeping the beam produced by a laser diode along the tag and by measuring the variations of the reflected signal in time. Scientists often usually consider that chipless technology is more related to barcodes than UHF technology, however, note that the reflected signal of a barcode is a modulated signal which is, by principle, identical to the backscattered signals of UHF RFID and moving or rotating tags. As such, barcodes and their reading method cannot be considered as LTI systems and are characterized by a non-zero delta RCS and a (possible) much larger read range.<br />
<br />
This spatial diversity allows to use the same color multiple time to encode information (stripes do not have to use a different color and 2 colors are enought) which significantly increases the coding capacity. <br />
2D images and their associated reading method can also be considered as linear time variant systems (which include QR code, or any image obtained with a lens and camera sensor). All these systems operate in the optical domain since spatial resolution is only limited by the small beam divergence of laser diodes (less than 1 mrad) or the sensor matrix size of camera sensors. However, note that when frequency is decreased, antenna directivity is also reduced which significantly limits the performance of this approach in the RF domain. For example in UWB band half power angle is usually higher than 10° which imposes large separation in between stripes (or resonators).<br />
<br />
Finally, all presented systems (non linear and time-varing transponders) can also be characterized by a non-zero differential RCS (or delta RCS) <math>\sigma_d</math>. This delta RCS is the direct generalization of the quantity classically defined for UHF tags. More information can be found [[Differential RCS|here]].<br />
<br />
== Conclusion ==<br />
<br />
I hope you have liked this page. If you have any comment, remarks or questions about these ideas, feel free to send me an email:<br />
<br />
[mailto:nicolas.barbot@lcis.grenoble-inp.fr <syntaxhighlight lang="text" inline>nicolas.barbot@lcis.grenoble-inp.fr</syntaxhighlight>]<br />
<br />
Collaborations often start by simple emails...<br />
<br />
==References==<br />
<br />
<references /></div>Nicohttps://nicolas-barbot.ovh/wiki/index.php?title=SC311_Wireless_Communications&diff=474SC311 Wireless Communications2021-10-15T13:25:10Z<p>Nico: </p>
<hr />
<div>The objective of this course is to understand how we can transmit a message in-between a transmitter and a receiver spatially separated. Especially, how we can use signal processing operations to adapt (i.e. modulate and demodulate) the message to realize the transmission over wired or wireless channels. This course describes the processes realized at a signal level and can be related to [[MA331 Information Theory and Channel Coding]] (which presents the general problem at a higher level).<br />
<br />
Slides of the course can be downloaded here. Exercises can be downloaded here. The following of this page corresponds to the labs.<br />
<br />
__TOC__<br />
<br />
In this labs, we will realize different modulations and demodulations used to transmit and receive analog and digital messages.<br />
Spectrum (or power spectral density) will also be determined.<br />
Finally, performance, in term of Sinal to Noise Ratio (SNR) or Bit Error Rate (BER) will be estimated in each case.<br />
<br />
These labs are based on [https://www.gnuradio.org/ GNU Radio] which is a free software that provides a large number of software blocks to perform most signal processing operations. The blocks are mostly written in C ++. It is possible to use these blocks directly from Python to simulate or create telecommunication systems.<br />
In addition, to make it easier to get started, GNU Radio also provides a utility called <syntaxhighlight lang="text" inline>gnuradio-companion</syntaxhighlight> to assemble blocks graphically and to generate the corresponding python script. This subject have been written for GNU Radio, but it can be equivalently realized using [https://www.gnu.org/software/octave/index Octave], or [http://itpp.sourceforge.net/4.3.1/ IT++] library.<br />
<br />
== Getting Started ==<br />
<br />
* Open a terminal.<br />
<br />
* Create a working directory in which you will place your scripts.<br />
<br />
* Run <syntaxhighlight lang="text" inline>gnuradio-companion</syntaxhighlight>.<br />
<br />
This software allows you to use blocks (available in the right column) and to connect them to realize any complex signal processing operations. Resulting program is called a flowgraph in GNU Radio language.<br />
<br />
For any flowgraph, there is basically 3 types of blocks: sources (which produce samples and have at least 1 output), sinks (which consume samples and have at least 1 input) and processing block (which have at least 1 input and 1 output). Blocks are simply connected by creating a link in-between an output of a block and an input of another block.<br />
<br />
* Create the flowgraph presented in Fig. 1.<br />
<br />
[[File:Im1.png|frame|center|Fig. 1: Simple generation and data plotting]]<br />
<br />
The <syntaxhighlight lang="text" inline>Signal Source</syntaxhighlight> block generates an infinity of sinusoidal samples (or other) from the different parameters. These samples are displayed according to the time using the <syntaxhighlight lang="text" inline>Scope Sink</syntaxhighlight> block. <syntaxhighlight lang="text" inline>Throttle</syntaxhighlight> block does not modify the samples but allows to perform a flow control on all the data circulating between the source and the sink. Last, be careful to the color of the input and output of each block since they represent the type of data flowing on the link. The following table presents main data type and associated used by GNU Radio. Also, since Python is strongly typed, colors located at both ends of a wire have to be the same.<br />
<br />
{| class="wikitable" style="text-align: left;"<br />
|-<br />
!Color<br />
!Type<br />
!Size<br />
|-<br />
|style="background: #3399ff;"|<br />
|Complex<br />
|2 x 64 bits<br />
|-<br />
|style="background: #f57c00;"|<br />
|Float<br />
|64 bits<br />
|-<br />
|style="background: #009688;"|<br />
|Int<br />
|64/32 bits<br />
|-<br />
|style="background: #ffeb3b;"|<br />
|Short<br />
|16 bits<br />
|-<br />
|style="background: #d500f9;"|<br />
|Char<br />
|8 bits<br />
|}<br />
<br />
* Save the flowgraph under your directory. This file is saved with a <syntaxhighlight lang="text" inline>.grc</syntaxhighlight> extension.<br />
<br />
* Generate the associated Python script associated to your flowgraph using the "blue to red" button. If errors are present, the script is not generated and full listing is present under the no entry sign. When successful, observe the python script named <syntaxhighlight lang="text" inline>top_block.py</syntaxhighlight> in your directory.<br />
<br />
* Execute the script by pressing the run button. Equivalently, you can also invoke <syntaxhighlight lang="text" inline>python top_block.py</syntaxhighlight>.<br />
<br />
The execution should display an oscilloscope-like widow with the corresponding signal (a cosine function). You can stop the execution by closing the window or by pressing the stop button.<br />
<br />
* Check the amplitude and the period of the generated signal.<br />
<br />
* Finally, add a <syntaxhighlight lang="text" inline>Slider</syntaxhighlight> block to modify the frequency of the signal in real time (without recompiling the flowgraph) and check the operation on the scope. Save the flowgraph.<br />
<br />
Note that the source simply generates samples which are plotted by the sink, however, this source and this sink can produce and consume as much data that your CPU can handle (data are just generated and plotted iteratively as fast as possible). To overcome this issue, the <syntaxhighlight lang="text" inline>Throttle</syntaxhighlight> block is used to process a given number of sample per second, thus lowering the CPU load to few percents. Most of the blocks in GNU Radio do not fixed the rate at which samples are processed: when sufficient number of samples are present at the input, the considered function is called and produces samples at the output which are then available for the other blocks. Usually, this rate is fixed when we work with real devices (for example an audio card can acquire samples at a given frequency e.g. 48 kHz) which fixed the rate for the whole flowgraph. In our example, we do not use any real device so the rate has to be fixed using the <syntaxhighlight lang="text" inline>Throttle</syntaxhighlight> block. Also, for each flowgraph, a single rate has to be used thus if we work with a real device, the <syntaxhighlight lang="text" inline>Throttle</syntaxhighlight> block is not needed anymore and has to be removed.<br />
<br />
<br />
* Create the flowgraph presented in Fig. 2.<br />
<br />
[[File:Im2.png|frame|center|Fig. 2: Simple operations on signals]]<br />
<br />
* Add a <syntaxhighlight lang="text" inline>FFT Sink</syntaxhighlight> to observe the signal spectrum. On the graph, the two peaks are very close and seem to be confused. Reduce the frequency sampling to increase the frequency resolution. Explain the phenomenum.<br />
<br />
* What is the minimum value of the sampling frequency? Observe the signal (in time and in frequency) for frequencies below this limit.<br />
<br />
* Replace the <syntaxhighlight lang="text" inline>Add</syntaxhighlight> block with a multiplier block <syntaxhighlight lang="text" inline>Mult</syntaxhighlight>. Predict the position of the peaks in the output signal. Check your results.<br />
<br />
* Add a filter (block <syntaxhighlight lang="text" inline>Low Pass Filter</syntaxhighlight>) to recover the low frequency part of the signal. Check your results in the time and frequency domain. Repeat the manipulation to keep the high frequency part.<br />
<br />
The <syntaxhighlight lang="text" inline>Low Pass Filter</syntaxhighlight> (and <syntaxhighlight lang="text" inline>High Pass Filter</syntaxhighlight>) blocks are high-level blocks which realize the design (i.e. determining the coefficients of the filter) as well as the filtering (i.e. the convolution). The filter design can also be done with <syntaxhighlight lang="text" inline>gr_filter_design</syntaxhighlight> to obtain the coefficients. These coefficients can then be used directly by the blocks <syntaxhighlight lang="text" inline>FIR Filter</syntaxhighlight> and <syntaxhighlight lang="text" inline>IIR Filter</syntaxhighlight>.<br />
<br />
== Amplitude Modulation ==<br />
<br />
=== Double side band without carrier ===<br />
<br />
* Realize the modulation of a signal <math>m(t)=\cos 2\pi f_m t</math> using a double side band without carrier. Note that transmitted signal can be expressed as<br />
<br />
<math><br />
s(t) = A m(t) \cos 2 \pi f_0 t<br />
</math><br />
<br />
* Observe the signal in both time and frequency domain.<br />
<br />
* Give the architecture of a coherent detector used to recover the message <math>m(t)</math> from <math>x(t)</math>.<br />
<br />
* Implement this detector to demodulate the signal and verify the good operation. You can use 2 different flowgraphs (1 for the transmission and 1 for the reception) using a <syntaxhighlight lang="text" inline>File Sink</syntaxhighlight> and <syntaxhighlight lang="text" inline>File Source</syntaxhighlight> respectively.<br />
<br />
=== Double side band with carrier ===<br />
<br />
* Realize the modulation of a signal <math>m(t)=\cos 2\pi f_m t</math> using a double side band with carrier. Note that transmitted signal can be expressed as<br />
<br />
[[File:Env.png|thumb|right|Fig. 3: Envelope detector used for AM signals.]]<br />
<br />
<math><br />
s(t) = A (1 + k_a m(t)) \cos 2 \pi f_0 t<br />
</math><br />
<br />
* Observe the signal in both time and frequency domain.<br />
<br />
* Modify the modulation index <math>k_a</math> using a slider and observe the modification of the signal.<br />
<br />
* AM signals are usually demodulted using a simple envelope detector. The architecture of this decoder is presented in Fig. 3.<br />
<br />
* Implement this detector to demodulate the signal and verify the good operation.<br />
<br />
* Check also if the AM signal can be decoded using the coherent detector.<br />
<br />
* Finally, download the file [https://nicolas-barbot.ovh/wiki/pool/am_usrp710.dat <syntaxhighlight lang="text" inline>am_usrp710.dat</syntaxhighlight>]. This file contains the complex envelope (I and Q channels) received by a USRP around the frequency 710 kHz with a sampling frequency of 256 kHz. Visualize the data with a block <syntaxhighlight lang="text" inline>FFT Sink</syntaxhighlight> (insert a block <syntaxhighlight lang="text" inline>Throttle</syntaxhighlight> to avoid overloading the processor). On the graph, we can see two stations transmit at 710 kHz (center) and 790 kHz (to the right). Knowing that the bandwidth of an AM signal is 10 kHz, insert a low pass filter allowing to select the station located around 710 kHz. Check that the filter is working properly on the graph. Insert the envelope detector at the output of the filter and a block <syntaxhighlight lang="text" inline>Rational Resampler</syntaxhighlight> to adapt the bit rate to the sound card (48 kHz) using an <syntaxhighlight lang="text" inline>Audio Sink</syntaxhighlight>.<br />
<br />
* Check the correct operation on the PC speakers (add if needed a <syntaxhighlight lang="text" inline>Multiply Const.</syntaxhighlight> block to set the volume of the station).<br />
<br />
* Bonus: Demodulate the station at 790 kHz.<br />
<br />
== Frequency Modulation ==<br />
<br />
Expression of a frequency modulated signal is given by:<br />
<br />
<math><br />
s(t) = A \cos(2\pi f_0 t + 2\pi k_f \int_0^t m(u) du)<br />
</math><br />
<br />
Spectrum for general signal is usually unknown unless for very simple cases.<br />
<br />
* Create the following flowgraph to generate a frequency (or phase) modulated signal.<br />
<br />
[[File:Fm1.png|frame|center|Fig. 4: Frequency modulation generation.]]<br />
<br />
* Observe the transmitted spectrum.<br />
<br />
* Find the values of the modulation index <math>\beta</math> to cancel the power at <math>f_0</math>, <math>f_0\pm f_m</math>, <math>f_0\pm 2f_m</math>...<br />
<br />
* Create a decoder for the transmitted signal. Check the correct operation for different messages <math>m(t)</math></div>Nicohttps://nicolas-barbot.ovh/wiki/index.php?title=Differential_RCS&diff=473Differential RCS2021-10-14T19:37:19Z<p>Nico: </p>
<hr />
<div>Differential RCS (or delta RCS) characterizes the aptitude of a tag to modulate the backscattered power. This parameter is has been introduced by P. Nikitin for UHF tags <ref>P. V. Nikitin, K. V. S. Rao, and R. D. Martinez, “Differential RCS of RFID tag,” Electronics Letters, vol. 43, no. 8, pp. 431–432, Apr. 2007.</ref> and is classically estimated based on the variation of the IQ channels of the two states of the chip in the time domain. This quantity can however be generalized for any modulating tag in the frequency domain. The frequency definition remains compatible to the time definition. Finally, this new definition allows to estimate the delta RCS of any tag accurately using a simple spectrum analyzer.<br />
<br />
__TOC__<br />
<br />
==Definition==<br />
<br />
[[File:Delta.png|thumb|right|Fig. 1: Power spectral density of the signal backscattered by a modulating tag in the frequency domain.]]<br />
<br />
Details have been presented in <ref>N. Barbot, O. Rance, and E. Perret, [https://nicolas-barbot.ovh/wiki/pool/rcs.pdf "Differential RCS of modulated tag,"] IEEE Transactions on Antennas and Propagation, pp. 1–1, 2021, early access. doi: 10.1109/TAP.2021.3060943.</ref> and can be seen as a complementary definition compared to the time definition. The basic idea relies on the decomposition of the RCS <math>\sigma</math> into a static RCS <math>\sigma_s</math> and a dynamic RCS <math>\sigma_d</math> and to pass into the frequency domain. Fig. 1 presents the main result where the (total) backscattered signal by the modulating UHF tag can be decomposed into 2 parts. Component located at <math>f_0</math> can be linked to <math>\sigma_s</math> whereas component located around <math>f_0</math> can be linked to <math>\sigma_d</math>.<br />
<br />
Also, this frequency definition (as the original definition) is not limited to RFID tags and can be applied to any linear time-varying system such as rotating tags, moving tag and (surprisingly) barcodes.<br />
Another consequence is that linear time-invariant systems, are characterized by a delta RCS of 0.<br />
<br />
==Known Delta RCS==<br />
<br />
* For a UHF tag, assuming that the chip can switch with a equal probability in-between 2 states characterized with <math>\Gamma_1</math> and <math>\Gamma_2</math>, and is connected to a half-wavelength antenna, the delta RCS <math>\sigma_d</math> can be expressed as:<br />
<br />
<math><br />
\sigma_d = \frac{\lambda^2 G^2}{4 \pi} \frac{|\Gamma_1 - \Gamma_2|^2}{4}<br />
</math><br />
<br />
At 915 MHz, this equation predicts a maximal delta RCS for passive (i.e., <math>\{\Gamma_1 = 0; \Gamma_2=-1\})</math> and semi-passive (i.e., <math>\{\Gamma_1 = +1; \Gamma_2=-1\})</math> UHF tags<br />
of -22 dBsm (63 cm<math>^2</math>) and -16 dBsm (230 cm<math>^2</math>) respectively.<br />
<br />
* For a vertical dipole oriented along <math>z</math> rotating at a frequency <math>f_r</math> located at a distance <math>r</math> of its axis and impinged by a vertical plane, the delta RCS of this rotating dipole can simply be expressed as:<br />
<br />
<math><br />
\sigma_d = [1 - J_0(\beta)] \sigma<br />
</math><br />
<br />
where <math>J_n</math> are the first kind Bessel function of order <math>n</math>, <math>\beta = \frac{2 \pi r}{\lambda}</math> and <math>\sigma</math> is the RCS of the dipole. Note that in this case<br />
variation of the backscattered power is continuous.<br />
<br />
For a short-circuited half-wavelength dipole at 915 MHz, rotating at a distance of <math>r=12.5</math> cm, delta RCS is equal to -10 dBsm (920 cm<math>^2</math>) which outperforms any UHF tag.<br />
<br />
==Measurement==<br />
<br />
Measurement method is based on the measurement of the modulated PSD of the backscattered signal <math>S_R(f-f_0)</math> which can be directly estimated by any spectrum analyzer. Delta RCS can finally be expressed as:<br />
<br />
<math><br />
\sigma_d = \frac{(4\pi)^3 d_1^2 d_2^2}{P_t G_t G_r \lambda^2} \times \left[\int_{f_0-b}^{f_0-\epsilon} S_R(f-f_0)\,\mathrm{d}f + \int_{f_0+\epsilon}^{f_0+b} S_R(f-f_0)\,\mathrm{d}f\right]<br />
</math><br />
<br />
where <math>2b</math> is the span of the instrument and <math>\epsilon</math> a constant allowing to remove the static contribution generated by the tag (and the environment).<br />
<br />
<br />
<references /></div>Nicohttps://nicolas-barbot.ovh/wiki/index.php?title=Nicolas_Barbot&diff=472Nicolas Barbot2021-10-14T19:33:23Z<p>Nico: </p>
<hr />
<div>{{Infobox person<br />
| name = Nicolas Barbot<br />
| image = File:NBarbot.jpg<br />
| image_size = 220px<br />
| nationality = French<br />
| birth_date = {{Birth date and age|1986|08|11}}<br />
| birth_place = Limoges, France<br />
}}<br />
<br />
'''Nicolas Barbot''' received the M.Sc. degree and Ph.D. degree from the University de Limoges, France. His Ph.D. work in [https://www.xlim.fr/ Xlim] Laboratory was focused on error-correcting codes for the optical wireless channel. He also realized a post-doctoral work in joint source-channel decoding at [https://l2s.centralesupelec.fr/ L2S] Laboratory, in Gif-sur-Yvette, France. Since September 2014, he has been an Assistant Professor at the Université Grenoble Alpes - Grenoble Institute of Technology, in Valence, France. His scientific background at [https://lcis.grenoble-inp.fr/ LCIS] Laboratory covers wireless communications systems based on backscattering principle which include classical RFID and chipless RFID.<br />
<br />
His research interest include transponders which can not be described by linear time-invariant systems. This gathers harmonic transponders which are based on the use of a non-linear component (Schottky diode) or linear time-variant transponders which are based on the modification of their response in the time domain.<br />
He also places special interests on antenna design and instrumentation based on these phenomenons.<br />
<br />
==Education==<br />
<br />
{| class="wikitable" style="text-align: left;width: 80%;"<br />
|-<br />
!Period<br />
!Postion/Diploma<br />
|-<br />
|2014–2021<br />
|align=left|Assistant Professor at Grenoble INP - Esisar, LCIS, Valence, France<br />
|-<br />
|2013–2014<br />
|align=left|Post-Doc at Laboratoire des Signaux et Systèmes (L2S), ''Cross-Layer Design of Wireless Tranceivers'', Gif-sur-Yvette, France<br />
|-<br />
|2010–2013<br />
|align=left|PhD Thesis, Xlim CNRS UMR 7252, ''Channel Coding for Optical Wireless Communications'', Limoges, France<br />
|-<br />
|2009–2010<br />
|align=left|Master Degree, Faculté des Sciences, ''Technologies Hyperfréquences, Électronique et Optique'', Limoges, France<br />
|-<br />
|2007–2010<br />
|align=left|Diplome d'ingénieur, École Nationale Supérieure d’Ingénieurs de Limoges, Électronique et Télécommunications, Limoges, France<br />
|-<br />
|2005–2007<br />
|align=left|DUT Mesures Physiques, IUT du Limousin, Limoges, France<br />
|}<br />
<br />
==Teaching ==<br />
<br />
{| class="wikitable" style="text-align: left;width: 80%;"<br />
|-<br />
!Courses<br />
!Full name<br />
!Grade<br />
!ECTS<br />
|-<br />
|[[CE515 Advanced Processor Architecture and SoC Design|CE515]]<br />
|align=left|Advanced Processor Architecture and SoC Design<br />
|5A<br />
|4<br />
|-<br />
|[[PX505 Innovation Project|PX505]]<br />
|align=left|Innovation Project<br />
|5A<br />
|4<br />
|-<br />
|[[AC469 Introduction to statistical signal processing|AC469]]<br />
|align=left|Introduction to statistical signal processing<br />
|4App<br />
|1.5<br />
|-<br />
|[[SC311 Wireless Communications|SC311]]<br />
|align=left|Wireless Communications<br />
|3A<br />
|2.5<br />
|-<br />
|[[MA331 Information Theory and Channel Coding|MA331]]<br />
|align=left|Information Theory and Channel Coding<br />
|3A<br />
|3<br />
|-<br />
|[[PX302 Introduction to STM32 micro-controllers|PX302]]<br />
|align=left|Introduction to STM32 micro-controllers<br />
|3A<br />
|3<br />
|-<br />
|[[PX212 Mini-Project|PX212]]<br />
|align=left|Mini-Project<br />
|2A<br />
|6<br />
|}<br />
<br />
==Research Activities==<br />
<br />
In the first part of my career, my research activities have been focused on chipless RFID.<br />
This technology allows to reduce the cost of the tags since information can be embedded and transmitted to the reader<br />
without using a silicon chip. However, since these tags are Linear Time-Invariant (LTI) systems<br />
<ref>N. Barbot, O. Rance, and E. Perret, [https://nicolas-barbot.ovh/wiki/pool/range.pdf "Classical RFID vs. chipless RFID read range: Is linearity a friend or a foe?,"]<br />
IEEE Transactions on Microwave Theory and Techniques, pp. 1–1, 2021, early access. doi: 10.1109/TMTT.2021.3077019.</ref>, their backscattered power<br />
are also located in the same bandwidth as the one used by the reader making the reading difficult in non-free space environments.<br />
Consequently, significant limitations appears in term of read range, coding capacity and media access control for any chipless tag.<br />
In order to break these limitations, my research investigations now cover:<br />
* non-linear (or harmonic) transponders which can backscatter a power at <math>n f_0</math>. These transponders are base on a non-linear component (typically a Schottky diode).<br />
* linear time-variant transponders which can backscatter a power around <math>f_0</math> <ref>N. Barbot and E. Perret, [https://nicolas-barbot.ovh/wiki/pool/nl.pdf "Linear time-variant chipless RFID sensor,"] IEEE Journal of Radio Frequency Identification, accepted.</ref>. These transponders can modulate the backscattered signal (classical UHF tags, micro-Doppler or more generally any moving scatterers).<br />
<br />
In these two cases, the tags cannot be described by LTI systems and are not bounded by the previous limitations. They<br />
are also characterized by a non zero delta RCS <math>\sigma_d</math><ref>N. Barbot, O. Rance, and E. Perret, [https://nicolas-barbot.ovh/wiki/pool/rcs.pdf "Differential RCS of modulated tag,"] IEEE Transactions on Antennas and Propagation, pp. 1–1, 2021, early access. doi: 10.1109/TAP.2021.3060943.</ref>.<br />
<br />
Additional details can be found [[Research Activities|here]].<br />
<br />
PhD students:<br />
* '''Ashkan Azarfar''', "Détection de tags sans puce basée sur l'effet Doppler pour les applications de reconnaissance de gestes," Directeur: Etienne Perret, Co-directeur: Nicolas Barbot.<br />
<br />
* '''Florian Requena''', "Conception de tags RIFD sans puce, robustes, pour applications capteur," Directeur: Etienne Perret, Co-directeur: Darine Kaddour, Nicolas Barbot.<br />
<br />
* '''Raymundo de Amorim Junior''', "Tags sans puce millimétriques pour applications sécurisées," Directeur: Etienne Perret, Co-directeur: Romain Siragusa, Nicolas Barbot.<br />
<br />
* '''Rahul Unnikrishnan''', "Reconnaissance de gestes avec des tags chipless," Directeur: Etienne Perret, Co-directeur: Nicolas Barbot.<br />
<br />
* '''Raphael Tavares de Alencar''', "Contribution à la conception et la réalisation de tags RFID sans puce compatibles avec des procédés industriels de fabrication," Directeur: Etienne Perret, Co-directeur: Marco Garbati, Nicolas Barbot.<br />
<br />
* '''Florent Bonnefoy''', "Authentification dans le domaine THz," Directeur: Frédéric Garet, Co-directeur: Maxime Bernier, Nicolas Barbot.<br />
<br />
See the complete [[List of Publications]].<br />
<br />
==CV==<br />
<br />
[https://nicolas-barbot.ovh/wiki/pool/cv_en.pdf English Version]<br />
<br />
[https://nicolas-barbot.ovh/wiki/pool/cv.pdf French Version]<br />
<br />
==References==<br />
<br />
<references/><br />
<br />
==External links==<br />
[https://scholar.google.com/citations?user=mMhPOZYAAAAJ&hl=en&oi=ao Google Scholar]<br />
<br />
[https://orcid.org/0000-0001-6355-9109 ORCID ID]</div>Nicohttps://nicolas-barbot.ovh/wiki/index.php?title=Nicolas_Barbot&diff=471Nicolas Barbot2021-10-14T19:27:15Z<p>Nico: </p>
<hr />
<div>{{Infobox person<br />
| name = Nicolas Barbot<br />
| image = File:NBarbot.jpg<br />
| image_size = 220px<br />
| nationality = French<br />
| birth_date = {{Birth date and age|1986|08|11}}<br />
| birth_place = Limoges, France<br />
}}<br />
<br />
'''Nicolas Barbot''' received the M.Sc. degree and Ph.D. degree from the University de Limoges, France. His Ph.D. work in [https://www.xlim.fr/ Xlim] Laboratory was focused on error-correcting codes for the optical wireless channel. He also realized a post-doctoral work in joint source-channel decoding at [https://l2s.centralesupelec.fr/ L2S] Laboratory, in Gif-sur-Yvette, France. Since September 2014, he has been an Assistant Professor at the Université Grenoble Alpes - Grenoble Institute of Technology, in Valence, France. His scientific background at [https://lcis.grenoble-inp.fr/ LCIS] Laboratory covers wireless communications systems based on backscattering principle which include classical RFID and chipless RFID.<br />
<br />
His research interest include transponders which can not be described by linear time-invariant systems. This gathers harmonic transponders which are based on the use of a non-linear component (Schottky diode) or linear time-variant transponders which are based on the modification of their response in the time domain.<br />
He also places special interests on antenna design and instrumentation based on these phenomenons.<br />
<br />
==Education==<br />
<br />
{| class="wikitable" style="text-align: left;width: 80%;"<br />
|-<br />
!Period<br />
!Postion/Diploma<br />
|-<br />
|2014–2021<br />
|align=left|Assistant Professor at Grenoble INP - Esisar, LCIS, Valence, France<br />
|-<br />
|2013–2014<br />
|align=left|Post-Doc at Laboratoire des Signaux et Systèmes (L2S), ''Cross-Layer Design of Wireless Tranceivers'', Gif-sur-Yvette, France<br />
|-<br />
|2010–2013<br />
|align=left|PhD Thesis, Xlim CNRS UMR 7252, ''Channel Coding for Optical Wireless Communications'', Limoges, France<br />
|-<br />
|2009–2010<br />
|align=left|Master Degree, Faculté des Sciences, ''Technologies Hyperfréquences, Électronique et Optique'', Limoges, France<br />
|-<br />
|2007–2010<br />
|align=left|Diplome d'ingénieur, École Nationale Supérieure d’Ingénieurs de Limoges, Électronique et Télécommunications, Limoges, France<br />
|-<br />
|2005–2007<br />
|align=left|DUT Mesures Physiques, IUT du Limousin, Limoges, France<br />
|}<br />
<br />
==Teaching ==<br />
<br />
{| class="wikitable" style="text-align: left;width: 80%;"<br />
|-<br />
!Courses<br />
!Full name<br />
!Grade<br />
!ECTS<br />
|-<br />
|[[CE515 Advanced Processor Architecture and SoC Design|CE515]]<br />
|align=left|Advanced Processor Architecture and SoC Design<br />
|5A<br />
|4<br />
|-<br />
|[[PX505 Innovation Project|PX505]]<br />
|align=left|Innovation Project<br />
|5A<br />
|4<br />
|-<br />
|[[AC469 Introduction to statistical signal processing|AC469]]<br />
|align=left|Introduction to statistical signal processing<br />
|4App<br />
|1.5<br />
|-<br />
|[[SC311 Wireless Communications|SC311]]<br />
|align=left|Wireless Communications<br />
|3A<br />
|2.5<br />
|-<br />
|[[MA331 Information Theory and Channel Coding|MA331]]<br />
|align=left|Information Theory and Channel Coding<br />
|3A<br />
|3<br />
|-<br />
|[[PX302 Introduction to STM32 micro-controllers|PX302]]<br />
|align=left|Introduction to STM32 micro-controllers<br />
|3A<br />
|3<br />
|-<br />
|[[PX212 Mini-Project|PX212]]<br />
|align=left|Mini-Project<br />
|2A<br />
|6<br />
|}<br />
<br />
==Research Activities==<br />
<br />
In the first part of my career, my research activities have been focused on chipless RFID.<br />
This technology allows to reduce the cost of the tags since information can be embedded and transmitted to the reader<br />
without using a silicon chip. However, since these tags are Linear Time-Invariant (LTI) systems<br />
<ref>N. Barbot, O. Rance, and E. Perret, [https://nicolas-barbot.ovh/wiki/pool/range.pdf "Classical RFID vs. chipless RFID read range: Is linearity a friend or a foe?,"]<br />
IEEE Transactions on Microwave Theory and Techniques, pp. 1–1, 2021, early access. doi: 10.1109/TMTT.2021.3077019.</ref>, their backscattered power<br />
are also located in the same bandwidth as the one used by the reader making the reading difficult in non-free space environments.<br />
Consequently, significant limitations appears in term of read range, coding capacity and media access control for any chipless tag.<br />
In order to break these limitations, my research investigations now cover:<br />
* non-linear (or harmonic) transponders which can backscatter a power at <math>n f_0</math>. These transponders are base on a non-linear component (typically a Schottky diode).<br />
* linear time-variant transponders which can backscatter a power around <math>f_0</math> <ref>N. Barbot and E. Perret, [https://nicolas-barbot.ovh/wiki/pool/nl.pdf "Linear time-variant chipless RFID sensor,"] IEEE Journal of Radio Frequency Identification, accepted.</ref>. These transponders can modulate the backscattered signal (classical UHF tags, micro-Doppler or more generally any moving scatterers).<br />
<br />
In these two cases, the tags cannot be described by LTI systems and are not bounded by the previous limitations. They<br />
are also characterized by a non zero delta RCS <math>\sigma_d</math><ref>N. Barbot, O. Rance, and E. Perret, [https://nicolas-barbot.ovh/wiki/pool/delta.pdf "Differential RCS of modulated tag,"] IEEE Transactions on Antennas and Propagation, pp. 1–1, 2021, early access. doi: 10.1109/TAP.2021.3060943.</ref>.<br />
<br />
Additional details can be found [[Research Activities|here]].<br />
<br />
PhD students:<br />
* '''Ashkan Azarfar''', "Détection de tags sans puce basée sur l'effet Doppler pour les applications de reconnaissance de gestes," Directeur: Etienne Perret, Co-directeur: Nicolas Barbot.<br />
<br />
* '''Florian Requena''', "Conception de tags RIFD sans puce, robustes, pour applications capteur," Directeur: Etienne Perret, Co-directeur: Darine Kaddour, Nicolas Barbot.<br />
<br />
* '''Raymundo de Amorim Junior''', "Tags sans puce millimétriques pour applications sécurisées," Directeur: Etienne Perret, Co-directeur: Romain Siragusa, Nicolas Barbot.<br />
<br />
* '''Rahul Unnikrishnan''', "Reconnaissance de gestes avec des tags chipless," Directeur: Etienne Perret, Co-directeur: Nicolas Barbot.<br />
<br />
* '''Raphael Tavares de Alencar''', "Contribution à la conception et la réalisation de tags RFID sans puce compatibles avec des procédés industriels de fabrication," Directeur: Etienne Perret, Co-directeur: Marco Garbati, Nicolas Barbot.<br />
<br />
* '''Florent Bonnefoy''', "Authentification dans le domaine THz," Directeur: Frédéric Garet, Co-directeur: Maxime Bernier, Nicolas Barbot.<br />
<br />
See the complete [[List of Publications]].<br />
<br />
==CV==<br />
<br />
[https://nicolas-barbot.ovh/wiki/pool/cv_en.pdf English Version]<br />
<br />
[https://nicolas-barbot.ovh/wiki/pool/cv.pdf French Version]<br />
<br />
==References==<br />
<br />
<references/><br />
<br />
==External links==<br />
[https://scholar.google.com/citations?user=mMhPOZYAAAAJ&hl=en&oi=ao Google Scholar]<br />
<br />
[https://orcid.org/0000-0001-6355-9109 ORCID ID]</div>Nicohttps://nicolas-barbot.ovh/wiki/index.php?title=CE515_Advanced_Processor_Architecture_and_SoC_Design&diff=470CE515 Advanced Processor Architecture and SoC Design2021-10-06T16:59:06Z<p>Nico: </p>
<hr />
<div>This course is separated into 2 parts. The first one deals will SoC design and programming and is supervised by David Hély. The second one is focused on the SIMD extension present inside ARM architecture. The goal of this lab is implement and develop algorithms (functions) optimized for the NEON extension included in the architecture ARMv7-A et ARMv7-R. Slides of the course can be found [https://nicolas-barbot.ovh/wiki/pool/neon_en.pdf here]. This course requires the basic knowledge of a micro-controller architecture and classical C programming. Processing will run over a [https://www.xilinx.com/ Xilinx] [https://www.xilinx.com/products/silicon-devices/soc/zynq-7000.html Zynq 7000] SoC which contain an ARM Cortex A9 MP Core. Performance of the NEON engine will be compared to the performance of classical implementation (C function executed on the ARM core).<br />
<br />
== Introduction ==<br />
<br />
[[File:Zynq.png|thumb|right|Zynq 7000 architecture]]<br />
<br />
A lot of peripherals generate (or accept) data whose the size is smaller than the processor register size (e.g., 16 bits ADC and 32 bits processor.) When the CPU process these data, a single data is used at a time and processor register is not used fully which imply that the efficiency of the system is decreased. SIMD technology uses a single instruction to realize the same operation on multiple data (in the same time) which increase the execution speed.<br />
<br />
NEON extension has been introduced in the ARMv7 architecture. This extension adds a set of registers (64 and 128 bits) and a SIMD instruction set <ref> NEON Programmer's Guide Version 1.0 ([https://nicolas-barbot.ovh/wiki/pool/DEN0018A_neon_programmers_guide.pdf ARM DEN0018A])</ref>. NEON instructions and ARM instructions are processed in the same time. Exact execution time depends on the Cortex used by the SoC <ref> Cortex-A9 NEON Media Processing Engine, Technical Reference Manual ([https://nicolas-barbot.ovh/wiki/pool/DDI0409G_cortex_a9_neon_mpe_r3p0_trm.pdf ARM DDI 0409])</ref> but all NEON instructions can be processed by the NEON engine. Classical instructions (ARM, Thumb, Thumb2) are described in the reference manual <ref> ARM Architecture Reference Manual, ARMv7-A and ARMv7-R edition ([https://nicolas-barbot.ovh/wiki/pool/DDI0406C_C_arm_architecture_reference_manual.pdf ARM DDI 0406])</ref>.<br />
<br />
During this lab, we will use the development board Zybo. This board include a Zynq 7000 System on Chip. This Soc is composed of FPGA and a Cortex A9 MP Core. Each core include one NEON engine. Figure 1 presents the system architecture. The four first exercises evaluate the performance of simple processing algorithms without any operating system (baremetal or standalone). The final exercise use the NEON extension in a Linux environment.<br />
<br />
== Standalone Application ==<br />
<br />
In this first exercise, we will develop, build, and run a simple application on the Zybo board.<br />
<br />
* Download the [https://nicolas-barbot.ovh/wiki/pool/void.zip <syntaxhighlight lang="text" inline>void</syntaxhighlight>] project.<br />
* Extract the project into a new directory on your computer.<br />
* Observe the structure of the project and open the <syntaxhighlight lang="text" inline>main.c</syntaxhighlight> source file in an editor.<br />
<br />
<syntaxhighlight lang="C" line><br />
#include <stdio.h><br />
#include "platform.h"<br />
#include "xil_printf.h"<br />
<br />
<br />
int main()<br />
{<br />
init_platform();<br />
<br />
print("Hello World\n\r");<br />
<br />
cleanup_platform();<br />
return 0;<br />
}<br />
</syntaxhighlight><br />
<br />
<syntaxhighlight lang="C" inline>init_platform()</syntaxhighlight> function is defined in <syntaxhighlight lang="text" inline>platform.c</syntaxhighlight> file and permit to activate cache memory on the Cortex A9 MP Core. This function call is not mandatory. <syntaxhighlight lang="C" inline>printf()</syntaxhighlight> allows to send the argument on the UART of the Zynq 7000. This function also supports the classical formatting of numbers.<br />
<br />
* Open a terminal (<syntaxhighlight inline lang="text">cmd.exe</syntaxhighlight>) and go to your project location (using <syntaxhighlight lang="text" inline>cd</syntaxhighlight>).<br />
<br />
* Execute the following script: <syntaxhighlight lang="text" inline>C:\Xilinx\Vitis\2019.2\settings64.bat</syntaxhighlight>. This script modifies the PATH evironment variable and allows to call the Xilinx tools directly form the command line.<br />
<br />
* Build process is fully automatized using [https://en.wikipedia.org/wiki/Make_(software) <syntaxhighlight lang="text" inline>make</syntaxhighlight>]. Open the <syntaxhighlight lang="text" inline>Makefile</syntaxhighlight> in your editor:<br />
<br />
<syntaxhighlight lang="Makefile" line='line'><br />
CC=arm-none-eabi-gcc<br />
CFLAGS=-mcpu=cortex-a9 -mfpu=neon -mfloat-abi=hard -c -Wall -I./include<br />
LDFLAGS=-mcpu=cortex-a9 -mfpu=neon -mfloat-abi=hard -Wl,-build-id=none -specs=Xilinx.spec -Wl,-T -Wl,lscript.ld -Llib<br />
LIBS=-Wl,--start-group,-lxil,-lgcc,-lc,--end-group<br />
<br />
all: main.elf<br />
<br />
main.o: main.c<br />
$(CC) $(CFLAGS) -o main.o main.c<br />
<br />
platform.o: platform.c<br />
$(CC) $(CFLAGS) -o platform.o platform.c<br />
<br />
main.elf: main.o platform.o<br />
$(CC) $(LDFLAGS) -o main.elf main.o platform.o $(LIBS)<br />
<br />
clean:<br />
rm *.o main.elf<br />
</syntaxhighlight><br />
<br />
The four first lines are simple variables. The rest of the file is composed of 4 rules. The first line of each rule defines the name of the target and its associated dependencies. For each rule, <syntaxhighlight lang="text" inline>make</syntaxhighlight> checks the modification date of the dependencies compared to the one of the target. If one of the dependencies has been modified after the target, <syntaxhighlight lang="text" inline>make</syntaxhighlight> run the command(s) located after the first line (and which have to begin by tab).<br />
<br />
* To build the project invoke <syntaxhighlight lang="text" inline>make</syntaxhighlight> at the prompt. You should observe the following output:<br />
<br />
<syntaxhighlight lang="text"><br />
$ make<br />
arm-none-eabi-gcc -c -Wall -I./include -o main.o main.c<br />
arm-none-eabi-gcc -c -Wall -I./include -o platform.o platform.c<br />
arm-none-eabi-gcc -mcpu=cortex-a9 -mfpu=neon -mfloat-abi=hard -Wl,-build-id=none -specs=Xilinx.spec -Wl,-T -Wl,lscript.ld -Llib -o main.elf main.o platform.o -Wl,--start-group,-lxil,-lgcc,-lc,--end-group<br />
$<br />
</syntaxhighlight><br />
<br />
If the building process is successful, the executable file <syntaxhighlight lang="text" inline>main.elf</syntaxhighlight> is generated. If the process fails, errors located in the source files (or Makefile) have to be corrected.<br />
<br />
* Check that the file <syntaxhighlight lang="text" inline>main.elf</syntaxhighlight> has been generated in your project directory. Note that this file has been built for the ARM architecture and cannot be executed on your computer.<br />
<br />
Until now, we have successfully built our first application. The following steps allow to transfer the executable file into the memory of the Zynq 7000 and to run the program:<br />
<br />
* Before transferring the executable file on the board, check that jumper JP5 is placed on the JTAG position and connect the PROG UART connector to the PC.<br />
Finally, switch on the SW4 switch (LD11 diode should be on).<br />
<br />
* Start the <syntaxhighlight lang="text" inline>xsct</syntaxhighlight> software in a terminal:<br />
<br />
<syntaxhighlight lang="text"><br />
$ xsct<br />
</syntaxhighlight><br />
<br />
* Type the following commands in <syntaxhighlight lang="text" inline>xsct</syntaxhighlight> (one at a time):<br />
<br />
<syntaxhighlight lang="text"><br />
connect -host 127.0.0.1 -port 3121<br />
targets<br />
targets 2<br />
source ps7_init.tcl<br />
ps7_init<br />
dow main.elf<br />
</syntaxhighlight><br />
<br />
The function <syntaxhighlight lang="text" inline>ps7_init()</syntaxhighlight> permits to activate the clock, the memory controller, and the peripherals (UART). This function have to be called before writing to the memory.<br />
<br />
* In another terminal, observe the [https://en.wikipedia.org/wiki/Serial_port serial port] with a terminal (e.g. <syntaxhighlight lang="text" inline>putty</syntaxhighlight> in Windows).<br />
For the link settings Baud rate: 115200, 8 bits data, 1 bit stop, without parity check.<br />
<br />
* In <syntaxhighlight lang="text" inline>xsct</syntaxhighlight>, now type the following commands:<br />
<br />
<syntaxhighlight lang="text"><br />
con<br />
stop<br />
</syntaxhighlight><br />
<br />
and observe the results on the serial port.<br />
<br />
* Validate the correct execution of the program.<br />
<br />
Before continuing with the next exercises, open 3 different terminals: the first one will be used to build the executable file (with make); the second one will be used to transfer the program on the board (with <syntaxhighlight lang="text" inline>xsct</syntaxhighlight>); the last one will be used to observe the results. Note that for the second terminal, a single <syntaxhighlight lang="text" inline>xsct</syntaxhighlight> session can be used to transfer multiple programs and that the start command will automatically detect if a new version of the program is available and transfer it on the board.<br />
<br />
== Timming ==<br />
<br />
Programming using NEON is not straight forward and many implementations can be evaluated. In order to compare the performance in between different possible implementations, timming has to be used to accurately estimate the execution time of a given section of code. The Zynq 7000 provides a real-time timer which can be controlled using the Xilinx library. This timer is incremented at a rate which is 2 time lower that the Cortex A9 clock frequency.<br />
<br />
* Add the header file <syntaxhighlight lang="text" inline>xtime_l.h</syntaxhighlight> to <syntaxhighlight lang="text" inline>main.c</syntaxhighlight> by adding the line:<br />
<br />
<syntaxhighlight lang="C" line='line'><br />
#include "xtime_l.h"<br />
</syntaxhighlight><br />
<br />
* In the function main.c, declare a variable of type <syntaxhighlight lang="text" inline>XTime</syntaxhighlight><br />
<br />
* Use the functions <syntaxhighlight lang="text" inline>XTime_SetTime(XTime Xtime)</syntaxhighlight> and <syntaxhighlight lang="text" inline>XTime_GetTime(XTime *Xtime)</syntaxhighlight>, to set or get the value inside the timer. <br />
<br />
* Add a dummy loop in main.c and determine the execution time of the associated processing. Note that the micro-controller frequency can be obtained in the macro <syntaxhighlight lang="text" inline>XPAR_CPU_CORTEXA9_CORE_CLOCK_FREQ_HZ</syntaxhighlight> defined in the file <syntaxhighlight lang="text" inline>xparameters.h</syntaxhighlight>.<br />
<br />
We are now ready to develop our first programs using the NEON engine. In each exercises, we will implement a simple algorithm in C and evaluate the performance in term of execution time. Then, we will implement the same algorithm using NEON instruction and compare the execution time. <br />
<br />
== Sum of an array ==<br />
<br />
* Create a new project by copying the <syntaxhighlight lang="text" inline>void</syntaxhighlight> directory under a different name.<br />
<br />
* Include the file <syntaxhighlight lang="text" inline>stdint.h</syntaxhighlight> which give access to sets of integer types having specified widths.<br />
<br />
* Declare an array of size 2048 where each element is a 16 bits signed integer and initialize the array to a default value.<br />
<br />
* Add a function <syntaxhighlight lang="text" inline>sum_c()</syntaxhighlight> which compute the sum of this array.<br />
<br />
* Determine the execution time of this function (this result will be used as a reference later).<br />
<br />
* Add a new file <syntaxhighlight lang="text" inline>neon.c</syntaxhighlight> to your project and write the function <syntaxhighlight lang="text" inline>sum_ni()</syntaxhighlight> which can compute the sum of the same array using NEON intrinsics.<br />
<br />
* Modify <syntaxhighlight lang="text" inline>Makefile</syntaxhighlight> to add a new rule for the file <syntaxhighlight lang="text" inline>neon.c</syntaxhighlight> (don't forget the options <syntaxhighlight lang="text" inline>-mcpu</syntaxhighlight>, <syntaxhighlight lang="text" inline>-mfloat-abi</syntaxhighlight> and <syntaxhighlight lang="text" inline>-mfpu</syntaxhighlight>). Generate the new executable file and check the correctness of your new function. <br />
<br />
* Determine its execution time and compare to the one obtained using the classical implementation in C. Rebuild your application using different optimization option (<syntaxhighlight lang="text" inline>O1</syntaxhighlight>, <syntaxhighlight lang="text" inline>O2</syntaxhighlight> and <syntaxhighlight lang="text" inline>O3</syntaxhighlight>). <br />
<br />
* Observe the assembly routine generated by the compiler with the command:<br />
<syntaxhighlight lang="text"><br />
$arm-none-eabi-gcc -S neon.c -o neon.s<br />
</syntaxhighlight><br />
Locate the NEON instructions and compare them to the ones in <syntaxhighlight lang="text" inline>neon.c</syntaxhighlight>.<br />
<br />
== Matrix Multiplication ==<br />
<br />
We consider the multiplication of 2 matrices <math>A</math> and <math>B</math> of dimension 4x4 into a third matrix <math>C</math>.<br />
<br />
* Create a new project<br />
<br />
* Write on a piece of paper the expression of each element of <math>c_{i,j}</math><br />
<br />
* Modify the <syntaxhighlight lang="text" inline>main()</syntaxhighlight> function to declare 2 matrix <syntaxhighlight lang="text" inline>A</syntaxhighlight> and <syntaxhighlight lang="text" inline>B</syntaxhighlight> initialized and a matrix <syntaxhighlight lang="text" inline>C</syntaxhighlight> (which is not initialized) of size 4x4 where each element is a float (32 bits).<br />
<br />
* Add a function <syntaxhighlight lang="text" inline>mat_product_c()</syntaxhighlight> to compute the matrix product of <syntaxhighlight lang="text" inline>A</syntaxhighlight> and <syntaxhighlight lang="text" inline>B</syntaxhighlight> and store the result in the <syntaxhighlight lang="text" inline>C</syntaxhighlight> matrix.<br />
<br />
* Validate the result by executing your function and measure the execution time of the C function.<br />
<br />
* Add a file <syntaxhighlight lang="text" inline>neon.c</syntaxhighlight> and write a function <syntaxhighlight lang="text" inline>mat_product_ni()</syntaxhighlight> to realize the matrix multiplication using NEON intrinsics. Check the correctness of your program.<br />
<br />
* Determine the execution time and the gain that we can obtain by using the NEON extension.<br />
<br />
== Edge Detection ==<br />
<br />
[[File:Nsew.png|thumb|right|Element position]]<br />
<br />
The goal of this exercise is to detect a large variation of the value of 2 neighboring elements in a 2D array. We which to store the result in a new 2D array composed of only 2 values 0 or 1 (0 if the neighboring elements are closed in value, 1 otherwise).<br />
<br />
For each element <math>C</math>, we can compute the quantity <math>|G|</math>:<br />
<br />
<math><br />
|G| = |E-W|+|N-S|<br />
</math><br />
<br />
where <math>|G|</math> can be viewed as an approximation of the magnitude of the gradient.<br />
<br />
If <math>|G|</math> is higher than a threshold value, then an edge is detected (and we store a 1 in the output array).<br />
If <math>|G|</math> is lower than the threshold value, a 0 has to be placed inside the output array.<br />
<br />
* Create a new project.<br />
<br />
* Modify the <syntaxhighlight lang="text" inline>main()</syntaxhighlight> function to declare 2 2D array <syntaxhighlight lang="text" inline>x</syntaxhighlight> and <syntaxhighlight lang="text" inline>y</syntaxhighlight> of size 10x10 where each element is an 8 bits unsigned integer. Initialize the input array <syntaxhighlight lang="text" inline>x</syntaxhighlight> to 0 for the upper triangular part and 100 for the lower triangular part.<br />
<br />
* Add a function <syntaxhighlight lang="text" inline>edge_c()</syntaxhighlight> to compute the values in the output array <syntaxhighlight lang="text" inline>y</syntaxhighlight> (edge detection).<br />
<br />
* Check the result by executing your program and determine the execution time of the C function<br />
<br />
* Add the file <syntaxhighlight lang="text" inline>neon.c</syntaxhighlight> and write the function <syntaxhighlight lang="text" inline>edge_ni()</syntaxhighlight> to realize the edge detection and store the result in the output array.<br />
<br />
* Determine the execution time and the gain obtained using the NEON extension.<br />
<br />
== Linux Application ==<br />
<br />
[[File:Output_c.png|thumb|right|Edge Detection]]<br />
<br />
The objective of this part is to start a Linux distribution on the Zybo development board and to evaluate the performance of our edge detection application on a bitmap image. Several distribution are available to run over Zynq 7000 SoC. Some of them provide a file system only in the RAM. Some others can use the file system from an external flash memory (SD card).<br />
Linaro distribution is a Ubuntu based distribution and provide the same tools than a desktop distribution (graphical user interface). Before doing the following operations, check that the Zybo board is switch off. Also, this exercise can be realize with a [https://en.wikipedia.org/wiki/Raspberry_Pi Raspberry] Pi 2 or 3 ([https://nicolas-barbot.ovh/wiki/pool/rpi.zip <syntaxhighlight lang="text" inline>rpi.zip</syntaxhighlight>]).<br />
<br />
* Insert the SD card in the slot located under the board.<br />
<br />
* Place jumper JP5 on SD position. The board will now start from the SD card.<br />
<br />
* Connect a USB cable between UART and the PC. Connect the USB hub on the OTG connector. <br />
<br />
* Connect the HDMI output to a screen by using an adaptor.<br />
<br />
* Switch on the board. You should see on the UART output, the startup messages of the kernel and finally the root invite.<br />
<br />
* Go inside the \verb+/home/linaro+ directory and modify the existing project to add your edge detection function (add the C version and the NEON version).<br />
<br />
* Build the project with the Makefile.<br />
<br />
* Start the program with the name of a bitmap image as a second argument. The program should generate the image <syntaxhighlight lang="text" inline>output.bmp</syntaxhighlight>.<br />
<br />
* Check the correctness of your program (adapt the threshold value).<br />
<br />
* We wish to analyze the performance of our program with <syntaxhighlight lang="text" inline>gprof</syntaxhighlight>. This tool is able to periodically interrupt the program under test to evaluate the load of each function on the processor. In order to increase the accuracy of the measurement, add a loop to repeat all the process 100 times. Rebuild your program using the <syntaxhighlight lang="text" inline>-pg</syntaxhighlight> option.<br />
<br />
* Execute your newly generated program (with the <syntaxhighlight lang="text" inline>edge_c()</syntaxhighlight> function). Notice that the compilation process generate now a <syntaxhighlight lang="text" inline>gmon.out</syntaxhighlight> file. This file contains the profiling information. Finally execute the following command:<br />
<syntaxhighlight lang="text"><br />
$ gprof test gmon.out > res<br />
</syntaxhighlight><br />
<br />
* Open the <syntaxhighlight lang="text" inline>res</syntaxhighlight> file in an editor to see the results.<br />
<br />
* Replace the <syntaxhighlight lang="text" inline>edge_c()</syntaxhighlight> function with the <syntaxhighlight lang="text" inline>edge_ni()</syntaxhighlight> function and profile the program again.<br />
<br />
* If you have enough time, replace the functions <syntaxhighlight lang="text" inline>color2gray_c()</syntaxhighlight> and <syntaxhighlight lang="text" inline>gray2color_c()</syntaxhighlight> by new functions using the NEON engine.<br />
<br />
== Conclusion ==<br />
<br />
At the end of these labs, you should now be able to develop, build, and optimize an application using the NEON engine present in Cortex-A processors.<br />
<br />
==References==<br />
<br />
<references /></div>Nicohttps://nicolas-barbot.ovh/wiki/index.php?title=CE515_Advanced_Processor_Architecture_and_SoC_Design&diff=469CE515 Advanced Processor Architecture and SoC Design2021-10-06T08:38:40Z<p>Nico: </p>
<hr />
<div>This course is separated into 2 parts. The first one deals will SoC design and programming and is supervised by David Hély. The second one is focused on the SIMD extension present inside ARM architecture. The goal of this lab is implement and develop algorithms (functions) optimized for the NEON extension included in the architecture ARMv7-A et ARMv7-R. Slides of the course can be found [https://nicolas-barbot.ovh/wiki/pool/neon_en.pdf here]. This course requires the basic knowledge of a micro-controller architecture and classical C programming. Processing will run over a [https://www.xilinx.com/ Xilinx] [https://www.xilinx.com/products/silicon-devices/soc/zynq-7000.html Zynq 7000] SoC which contain an ARM Cortex A9 MP Core. Performance of the NEON engine will be compared to the performance of classical implementation (C function executed on the ARM core).<br />
<br />
== Introduction ==<br />
<br />
[[File:Zynq.png|thumb|right|Zynq 7000 architecture]]<br />
<br />
A lot of peripherals generate (or accept) data whose the size is smaller than the processor register size (e.g., 16 bits ADC and 32 bits processor.) When the CPU process these data, a single data is used at a time and processor register is not used fully which imply that the efficiency of the system is decreased. SIMD technology uses a single instruction to realize the same operation on multiple data (in the same time) which increase the execution speed.<br />
<br />
NEON extension has been introduced in the ARMv7 architecture. This extension adds a set of registers (64 and 128 bits) and a SIMD instruction set <ref> NEON Programmer's Guide Version 1.0 ([https://nicolas-barbot.ovh/wiki/pool/DEN0018A_neon_programmers_guide.pdf ARM DEN0018A])</ref>. NEON instructions and ARM instructions are processed in the same time. Exact execution time depends on the Cortex used by the SoC <ref> Cortex-A9 NEON Media Processing Engine, Technical Reference Manual ([https://nicolas-barbot.ovh/wiki/pool/DDI0409G_cortex_a9_neon_mpe_r3p0_trm.pdf ARM DDI 0409])</ref> but all NEON instructions can be processed by the NEON engine. Classical instructions (ARM, Thumb, Thumb2) are described in the reference manual <ref> ARM Architecture Reference Manual, ARMv7-A and ARMv7-R edition ([https://nicolas-barbot.ovh/wiki/pool/DDI0406C_C_arm_architecture_reference_manual.pdf ARM DDI 0406])</ref>.<br />
<br />
During this lab, we will use the development board Zybo. This board include a Zynq 7000 System on Chip. This Soc is composed of FPGA and a Cortex A9 MP Core. Each core include one NEON engine. Figure 1 presents the system architecture. The four first exercises evaluate the performance of simple processing algorithms without any operating system (baremetal or standalone). The final exercise use the NEON extension in a Linux environment.<br />
<br />
== Standalone Application ==<br />
<br />
In this first exercise, we will develop, build, and run a simple application on the Zybo board.<br />
<br />
* Download the [https://nicolas-barbot.ovh/wiki/pool/void.zip <syntaxhighlight lang="text" inline>void</syntaxhighlight>] project.<br />
* Extract the project into a new directory on your computer.<br />
* Observe the structure of the project and open the <syntaxhighlight lang="text" inline>main.c</syntaxhighlight> source file in an editor.<br />
<br />
<syntaxhighlight lang="C" line><br />
#include <stdio.h><br />
#include "platform.h"<br />
#include "xil_printf.h"<br />
<br />
<br />
int main()<br />
{<br />
init_platform();<br />
<br />
print("Hello World\n\r");<br />
<br />
cleanup_platform();<br />
return 0;<br />
}<br />
</syntaxhighlight><br />
<br />
<syntaxhighlight lang="C" inline>init_platform()</syntaxhighlight> function is defined in <syntaxhighlight lang="text" inline>platform.c</syntaxhighlight> file and permit to activate cache memory on the Cortex A9 MP Core. This function call is not mandatory. <syntaxhighlight lang="C" inline>printf()</syntaxhighlight> allows to send the argument on the UART of the Zynq 7000. This function also supports the classical formatting of numbers.<br />
<br />
* Open a terminal (<syntaxhighlight inline lang="text">cmd.exe</syntaxhighlight>) and go to your project location (using <syntaxhighlight lang="text" inline>cd</syntaxhighlight>).<br />
<br />
* Execute the following script: <syntaxhighlight lang="text" inline>C:\Xilinx\Vitis\2019.2\settings64.bat</syntaxhighlight>. This script modifies the PATH evironment variable and allows to call the Xilinx tools directly form the command line.<br />
<br />
* Build process is fully automatized using [https://en.wikipedia.org/wiki/Make_(software) <syntaxhighlight lang="text" inline>make</syntaxhighlight>]. Open the <syntaxhighlight lang="text" inline>Makefile</syntaxhighlight> in your editor:<br />
<br />
<syntaxhighlight lang="Makefile" line='line'><br />
CC=arm-none-eabi-gcc<br />
CFLAGS=-mcpu=cortex-a9 -mfpu=vfpv3 -mfloat-abi=hard -c -Wall -I./include<br />
LDFLAGS=-mcpu=cortex-a9 -mfpu=vfpv3 -mfloat-abi=hard -Wl,-build-id=none -specs=Xilinx.spec -Wl,-T -Wl,lscript.ld -Llib<br />
LIBS=-Wl,--start-group,-lxil,-lgcc,-lc,--end-group<br />
<br />
all: main.elf<br />
<br />
main.o: main.c<br />
$(CC) $(CFLAGS) -o main.o main.c<br />
<br />
platform.o: platform.c<br />
$(CC) $(CFLAGS) -o platform.o platform.c<br />
<br />
main.elf: main.o platform.o<br />
$(CC) $(LDFLAGS) -o main.elf main.o platform.o $(LIBS)<br />
<br />
clean:<br />
rm *.o main.elf<br />
</syntaxhighlight><br />
<br />
The four first lines are simple variables. The rest of the file is composed of 4 rules. The first line of each rule defines the name of the target and its associated dependencies. For each rule, <syntaxhighlight lang="text" inline>make</syntaxhighlight> checks the modification date of the dependencies compared to the one of the target. If one of the dependencies has been modified after the target, <syntaxhighlight lang="text" inline>make</syntaxhighlight> run the command(s) located after the first line (and which have to begin by tab).<br />
<br />
* To build the project invoke <syntaxhighlight lang="text" inline>make</syntaxhighlight> at the prompt. You should observe the following output:<br />
<br />
<syntaxhighlight lang="text"><br />
$ make<br />
arm-none-eabi-gcc -c -Wall -I./include -o main.o main.c<br />
arm-none-eabi-gcc -c -Wall -I./include -o platform.o platform.c<br />
arm-none-eabi-gcc -mcpu=cortex-a9 -mfpu=vfpv3 -mfloat-abi=hard -Wl,-build-id=none -specs=Xilinx.spec -Wl,-T -Wl,lscript.ld -Llib -o main.elf main.o platform.o -Wl,--start-group,-lxil,-lgcc,-lc,--end-group<br />
$<br />
</syntaxhighlight><br />
<br />
If the building process is successful, the executable file <syntaxhighlight lang="text" inline>main.elf</syntaxhighlight> is generated. If the process fails, errors located in the source files (or Makefile) have to be corrected.<br />
<br />
* Check that the file <syntaxhighlight lang="text" inline>main.elf</syntaxhighlight> has been generated in your project directory. Note that this file has been built for the ARM architecture and cannot be executed on your computer.<br />
<br />
Until now, we have successfully built our first application. The following steps allow to transfer the executable file into the memory of the Zynq 7000 and to run the program:<br />
<br />
* Before transferring the executable file on the board, check that jumper JP5 is placed on the JTAG position and connect the PROG UART connector to the PC.<br />
Finally, switch on the SW4 switch (LD11 diode should be on).<br />
<br />
* Start the <syntaxhighlight lang="text" inline>xsct</syntaxhighlight> software in a terminal:<br />
<br />
<syntaxhighlight lang="text"><br />
$ xsct<br />
</syntaxhighlight><br />
<br />
* Type the following commands in <syntaxhighlight lang="text" inline>xsct</syntaxhighlight> (one at a time):<br />
<br />
<syntaxhighlight lang="text"><br />
connect -host 127.0.0.1 -port 3121<br />
targets<br />
targets 2<br />
source ps7_init.tcl<br />
ps7_init<br />
dow main.elf<br />
</syntaxhighlight><br />
<br />
The function <syntaxhighlight lang="text" inline>ps7_init()</syntaxhighlight> permits to activate the clock, the memory controller, and the peripherals (UART). This function have to be called before writing to the memory.<br />
<br />
* In another terminal, observe the [https://en.wikipedia.org/wiki/Serial_port serial port] with a terminal (e.g. <syntaxhighlight lang="text" inline>putty</syntaxhighlight> in Windows).<br />
For the link settings Baud rate: 115200, 8 bits data, 1 bit stop, without parity check.<br />
<br />
* In <syntaxhighlight lang="text" inline>xsct</syntaxhighlight>, now type the following commands:<br />
<br />
<syntaxhighlight lang="text"><br />
con<br />
stop<br />
</syntaxhighlight><br />
<br />
and observe the results on the serial port.<br />
<br />
* Validate the correct execution of the program.<br />
<br />
Before continuing with the next exercises, open 3 different terminals: the first one will be used to build the executable file (with make); the second one will be used to transfer the program on the board (with <syntaxhighlight lang="text" inline>xsct</syntaxhighlight>); the last one will be used to observe the results. Note that for the second terminal, a single <syntaxhighlight lang="text" inline>xsct</syntaxhighlight> session can be used to transfer multiple programs and that the start command will automatically detect if a new version of the program is available and transfer it on the board.<br />
<br />
== Timming ==<br />
<br />
Programming using NEON is not straight forward and many implementations can be evaluated. In order to compare the performance in between different possible implementations, timming has to be used to accurately estimate the execution time of a given section of code. The Zynq 7000 provides a real-time timer which can be controlled using the Xilinx library. This timer is incremented at a rate which is 2 time lower that the Cortex A9 clock frequency.<br />
<br />
* Add the header file <syntaxhighlight lang="text" inline>xtime_l.h</syntaxhighlight> to <syntaxhighlight lang="text" inline>main.c</syntaxhighlight> by adding the line:<br />
<br />
<syntaxhighlight lang="C" line='line'><br />
#include "xtime_l.h"<br />
</syntaxhighlight><br />
<br />
* In the function main.c, declare a variable of type <syntaxhighlight lang="text" inline>XTime</syntaxhighlight><br />
<br />
* Use the functions <syntaxhighlight lang="text" inline>XTime_SetTime(XTime Xtime)</syntaxhighlight> and <syntaxhighlight lang="text" inline>XTime_GetTime(XTime *Xtime)</syntaxhighlight>, to set or get the value inside the timer. <br />
<br />
* Add a dummy loop in main.c and determine the execution time of the associated processing. Note that the micro-controller frequency can be obtained in the macro <syntaxhighlight lang="text" inline>XPAR_CPU_CORTEXA9_CORE_CLOCK_FREQ_HZ</syntaxhighlight> defined in the file <syntaxhighlight lang="text" inline>xparameters.h</syntaxhighlight>.<br />
<br />
We are now ready to develop our first programs using the NEON engine. In each exercises, we will implement a simple algorithm in C and evaluate the performance in term of execution time. Then, we will implement the same algorithm using NEON instruction and compare the execution time. <br />
<br />
== Sum of an array ==<br />
<br />
* Create a new project by copying the <syntaxhighlight lang="text" inline>void</syntaxhighlight> directory under a different name.<br />
<br />
* Include the file <syntaxhighlight lang="text" inline>stdint.h</syntaxhighlight> which give access to sets of integer types having specified widths.<br />
<br />
* Declare an array of size 2048 where each element is a 16 bits signed integer and initialize the array to a default value.<br />
<br />
* Add a function <syntaxhighlight lang="text" inline>sum_c()</syntaxhighlight> which compute the sum of this array.<br />
<br />
* Determine the execution time of this function (this result will be used as a reference later).<br />
<br />
* Add a new file <syntaxhighlight lang="text" inline>neon.c</syntaxhighlight> to your project and write the function <syntaxhighlight lang="text" inline>sum_ni()</syntaxhighlight> which can compute the sum of the same array using NEON intrinsics.<br />
<br />
* Modify <syntaxhighlight lang="text" inline>Makefile</syntaxhighlight> to add a new rule for the file <syntaxhighlight lang="text" inline>neon.c</syntaxhighlight> (don't forget the options <syntaxhighlight lang="text" inline>-mcpu</syntaxhighlight>, <syntaxhighlight lang="text" inline>-mfloat-abi</syntaxhighlight> and <syntaxhighlight lang="text" inline>-mfpu</syntaxhighlight>). Generate the new executable file and check the correctness of your new function. <br />
<br />
* Determine its execution time and compare to the one obtained using the classical implementation in C. Rebuild your application using different optimization option (<syntaxhighlight lang="text" inline>O1</syntaxhighlight>, <syntaxhighlight lang="text" inline>O2</syntaxhighlight> and <syntaxhighlight lang="text" inline>O3</syntaxhighlight>). <br />
<br />
* Observe the assembly routine generated by the compiler with the command:<br />
<syntaxhighlight lang="text"><br />
$arm-none-eabi-gcc -S neon.c -o neon.s<br />
</syntaxhighlight><br />
Locate the NEON instructions and compare them to the ones in <syntaxhighlight lang="text" inline>neon.c</syntaxhighlight>.<br />
<br />
== Matrix Multiplication ==<br />
<br />
We consider the multiplication of 2 matrices <math>A</math> and <math>B</math> of dimension 4x4 into a third matrix <math>C</math>.<br />
<br />
* Create a new project<br />
<br />
* Write on a piece of paper the expression of each element of <math>c_{i,j}</math><br />
<br />
* Modify the <syntaxhighlight lang="text" inline>main()</syntaxhighlight> function to declare 2 matrix <syntaxhighlight lang="text" inline>A</syntaxhighlight> and <syntaxhighlight lang="text" inline>B</syntaxhighlight> initialized and a matrix <syntaxhighlight lang="text" inline>C</syntaxhighlight> (which is not initialized) of size 4x4 where each element is a float (32 bits).<br />
<br />
* Add a function <syntaxhighlight lang="text" inline>mat_product_c()</syntaxhighlight> to compute the matrix product of <syntaxhighlight lang="text" inline>A</syntaxhighlight> and <syntaxhighlight lang="text" inline>B</syntaxhighlight> and store the result in the <syntaxhighlight lang="text" inline>C</syntaxhighlight> matrix.<br />
<br />
* Validate the result by executing your function and measure the execution time of the C function.<br />
<br />
* Add a file <syntaxhighlight lang="text" inline>neon.c</syntaxhighlight> and write a function <syntaxhighlight lang="text" inline>mat_product_ni()</syntaxhighlight> to realize the matrix multiplication using NEON intrinsics. Check the correctness of your program.<br />
<br />
* Determine the execution time and the gain that we can obtain by using the NEON extension.<br />
<br />
== Edge Detection ==<br />
<br />
[[File:Nsew.png|thumb|right|Element position]]<br />
<br />
The goal of this exercise is to detect a large variation of the value of 2 neighboring elements in a 2D array. We which to store the result in a new 2D array composed of only 2 values 0 or 1 (0 if the neighboring elements are closed in value, 1 otherwise).<br />
<br />
For each element <math>C</math>, we can compute the quantity <math>|G|</math>:<br />
<br />
<math><br />
|G| = |E-W|+|N-S|<br />
</math><br />
<br />
where <math>|G|</math> can be viewed as an approximation of the magnitude of the gradient.<br />
<br />
If <math>|G|</math> is higher than a threshold value, then an edge is detected (and we store a 1 in the output array).<br />
If <math>|G|</math> is lower than the threshold value, a 0 has to be placed inside the output array.<br />
<br />
* Create a new project.<br />
<br />
* Modify the <syntaxhighlight lang="text" inline>main()</syntaxhighlight> function to declare 2 2D array <syntaxhighlight lang="text" inline>x</syntaxhighlight> and <syntaxhighlight lang="text" inline>y</syntaxhighlight> of size 10x10 where each element is an 8 bits unsigned integer. Initialize the input array <syntaxhighlight lang="text" inline>x</syntaxhighlight> to 0 for the upper triangular part and 100 for the lower triangular part.<br />
<br />
* Add a function <syntaxhighlight lang="text" inline>edge_c()</syntaxhighlight> to compute the values in the output array <syntaxhighlight lang="text" inline>y</syntaxhighlight> (edge detection).<br />
<br />
* Check the result by executing your program and determine the execution time of the C function<br />
<br />
* Add the file <syntaxhighlight lang="text" inline>neon.c</syntaxhighlight> and write the function <syntaxhighlight lang="text" inline>edge_ni()</syntaxhighlight> to realize the edge detection and store the result in the output array.<br />
<br />
* Determine the execution time and the gain obtained using the NEON extension.<br />
<br />
== Linux Application ==<br />
<br />
[[File:Output_c.png|thumb|right|Edge Detection]]<br />
<br />
The objective of this part is to start a Linux distribution on the Zybo development board and to evaluate the performance of our edge detection application on a bitmap image. Several distribution are available to run over Zynq 7000 SoC. Some of them provide a file system only in the RAM. Some others can use the file system from an external flash memory (SD card).<br />
Linaro distribution is a Ubuntu based distribution and provide the same tools than a desktop distribution (graphical user interface). Before doing the following operations, check that the Zybo board is switch off. Also, this exercise can be realize with a [https://en.wikipedia.org/wiki/Raspberry_Pi Raspberry] Pi 2 or 3 ([https://nicolas-barbot.ovh/wiki/pool/rpi.zip <syntaxhighlight lang="text" inline>rpi.zip</syntaxhighlight>]).<br />
<br />
* Insert the SD card in the slot located under the board.<br />
<br />
* Place jumper JP5 on SD position. The board will now start from the SD card.<br />
<br />
* Connect a USB cable between UART and the PC. Connect the USB hub on the OTG connector. <br />
<br />
* Connect the HDMI output to a screen by using an adaptor.<br />
<br />
* Switch on the board. You should see on the UART output, the startup messages of the kernel and finally the root invite.<br />
<br />
* Go inside the \verb+/home/linaro+ directory and modify the existing project to add your edge detection function (add the C version and the NEON version).<br />
<br />
* Build the project with the Makefile.<br />
<br />
* Start the program with the name of a bitmap image as a second argument. The program should generate the image <syntaxhighlight lang="text" inline>output.bmp</syntaxhighlight>.<br />
<br />
* Check the correctness of your program (adapt the threshold value).<br />
<br />
* We wish to analyze the performance of our program with <syntaxhighlight lang="text" inline>gprof</syntaxhighlight>. This tool is able to periodically interrupt the program under test to evaluate the load of each function on the processor. In order to increase the accuracy of the measurement, add a loop to repeat all the process 100 times. Rebuild your program using the <syntaxhighlight lang="text" inline>-pg</syntaxhighlight> option.<br />
<br />
* Execute your newly generated program (with the <syntaxhighlight lang="text" inline>edge_c()</syntaxhighlight> function). Notice that the compilation process generate now a <syntaxhighlight lang="text" inline>gmon.out</syntaxhighlight> file. This file contains the profiling information. Finally execute the following command:<br />
<syntaxhighlight lang="text"><br />
$ gprof test gmon.out > res<br />
</syntaxhighlight><br />
<br />
* Open the <syntaxhighlight lang="text" inline>res</syntaxhighlight> file in an editor to see the results.<br />
<br />
* Replace the <syntaxhighlight lang="text" inline>edge_c()</syntaxhighlight> function with the <syntaxhighlight lang="text" inline>edge_ni()</syntaxhighlight> function and profile the program again.<br />
<br />
* If you have enough time, replace the functions <syntaxhighlight lang="text" inline>color2gray_c()</syntaxhighlight> and <syntaxhighlight lang="text" inline>gray2color_c()</syntaxhighlight> by new functions using the NEON engine.<br />
<br />
== Conclusion ==<br />
<br />
At the end of these labs, you should now be able to develop, build, and optimize an application using the NEON engine present in Cortex-A processors.<br />
<br />
==References==<br />
<br />
<references /></div>Nicohttps://nicolas-barbot.ovh/wiki/index.php?title=CE515_Advanced_Processor_Architecture_and_SoC_Design&diff=468CE515 Advanced Processor Architecture and SoC Design2021-10-06T07:29:58Z<p>Nico: </p>
<hr />
<div>This course is separated into 2 parts. The first one deals will SoC design and programming and is supervised by David Hély. The second one is focused on the SIMD extension present inside ARM architecture. The goal of this lab is implement and develop algorithms (functions) optimized for the NEON extension included in the architecture ARMv7-A et ARMv7-R. Slides of the course can be found [https://nicolas-barbot.ovh/wiki/pool/neon_en.pdf here]. This course requires the basic knowledge of a micro-controller architecture and classical C programming. Processing will run over a [https://www.xilinx.com/ Xilinx] [https://www.xilinx.com/products/silicon-devices/soc/zynq-7000.html Zynq 7000] SoC which contain an ARM Cortex A9 MP Core. Performance of the NEON engine will be compared to the performance of classical implementation (C function executed on the ARM core).<br />
<br />
== Introduction ==<br />
<br />
[[File:Zynq.png|thumb|right|Zynq 7000 architecture]]<br />
<br />
A lot of peripherals generate (or accept) data whose the size is smaller than the processor register size (e.g., 16 bits ADC and 32 bits processor.) When the CPU process these data, a single data is used at a time and processor register is not used fully which imply that the efficiency of the system is decreased. SIMD technology uses a single instruction to realize the same operation on multiple data (in the same time) which increase the execution speed.<br />
<br />
NEON extension has been introduced in the ARMv7 architecture. This extension adds a set of registers (64 and 128 bits) and a SIMD instruction set <ref> NEON Programmer's Guide Version 1.0 ([https://nicolas-barbot.ovh/wiki/pool/DEN0018A_neon_programmers_guide.pdf ARM DEN0018A])</ref>. NEON instructions and ARM instructions are processed in the same time. Exact execution time depends on the Cortex used by the SoC <ref> Cortex-A9 NEON Media Processing Engine, Technical Reference Manual ([https://nicolas-barbot.ovh/wiki/pool/DDI0409G_cortex_a9_neon_mpe_r3p0_trm.pdf ARM DDI 0409])</ref> but all NEON instructions can be processed by the NEON engine. Classical instructions (ARM, Thumb, Thumb2) are described in the reference manual <ref> ARM Architecture Reference Manual, ARMv7-A and ARMv7-R edition ([https://nicolas-barbot.ovh/wiki/pool/DDI0406C_C_arm_architecture_reference_manual.pdf ARM DDI 0406])</ref>.<br />
<br />
During this lab, we will use the development board Zybo. This board include a Zynq 7000 System on Chip. This Soc is composed of FPGA and a Cortex A9 MP Core. Each core include one NEON engine. Figure 1 presents the system architecture. The four first exercises evaluate the performance of simple processing algorithms without any operating system (baremetal or standalone). The final exercise use the NEON extension in a Linux environment.<br />
<br />
== Standalone Application ==<br />
<br />
In this first exercise, we will develop, build, and run a simple application on the Zybo board.<br />
<br />
* Download the [https://nicolas-barbot.ovh/wiki/pool/void.zip <syntaxhighlight lang="text" inline>void</syntaxhighlight>] project.<br />
* Extract the project into a new directory on your computer.<br />
* Observe the structure of the project and open the <syntaxhighlight lang="text" inline>main.c</syntaxhighlight> source file in an editor.<br />
<br />
<syntaxhighlight lang="C" line><br />
#include <stdio.h><br />
#include "platform.h"<br />
#include "xil_printf.h"<br />
<br />
<br />
int main()<br />
{<br />
init_platform();<br />
<br />
print("Hello World\n\r");<br />
<br />
cleanup_platform();<br />
return 0;<br />
}<br />
</syntaxhighlight><br />
<br />
<syntaxhighlight lang="C" inline>init_platform()</syntaxhighlight> function is defined in <syntaxhighlight lang="text" inline>platform.c</syntaxhighlight> file and permit to activate cache memory on the Cortex A9 MP Core. This function call is not mandatory. <syntaxhighlight lang="C" inline>printf()</syntaxhighlight> allows to send the argument on the UART of the Zynq 7000. This function also supports the classical formatting of numbers.<br />
<br />
* Open a terminal (<syntaxhighlight inline lang="text">cmd.exe</syntaxhighlight>) and go to your project location (using <syntaxhighlight lang="text" inline>cd</syntaxhighlight>).<br />
<br />
* Execute the following script: <syntaxhighlight lang="text" inline>C:\Xilinx\Vitis\2019.2\settings64.bat</syntaxhighlight>. This script modifies the PATH evironment variable and allows to call the Xilinx tools directly form the command line.<br />
<br />
* Build process is fully automatized using [https://en.wikipedia.org/wiki/Make_(software) <syntaxhighlight lang="text" inline>make</syntaxhighlight>]. Open the <syntaxhighlight lang="text" inline>Makefile</syntaxhighlight> in your editor:<br />
<br />
<syntaxhighlight lang="Makefile" line='line'><br />
CC=arm-none-eabi-gcc<br />
CFLAGS=-mcpu=cortex-a9 -mfpu=vfpv3 -mfloat-abi=hard -c -Wall -I./include<br />
LDFLAGS=-mcpu=cortex-a9 -mfpu=vfpv3 -mfloat-abi=hard -Wl,-build-id=none -specs=Xilinx.spec -Wl,-T -Wl,lscript.ld -Llib<br />
LIBS=-Wl,--start-group,-lxil,-lgcc,-lc,--end-group<br />
<br />
all: main.elf<br />
<br />
main.o: main.c<br />
$(CC) $(CFLAGS) -o main.o main.c<br />
<br />
platform.o: platform.c<br />
$(CC) $(CFLAGS) -o platform.o platform.c<br />
<br />
main.elf: main.o platform.o<br />
$(CC) $(LDFLAGS) -o main.elf main.o platform.o $(LIBS)<br />
<br />
clean:<br />
rm *.o main.elf<br />
</syntaxhighlight><br />
<br />
The four first lines are simple variables. The rest of the file is composed of 4 rules. The first line of each rule defines the name of the target and its associated dependencies. For each rule, <syntaxhighlight lang="text" inline>make</syntaxhighlight> checks the modification date of the dependencies compared to the one of the target. If one of the dependencies has been modified after the target, <syntaxhighlight lang="text" inline>make</syntaxhighlight> run the command(s) located after the first line (and which have to begin by tab).<br />
<br />
* To build the project invoke <syntaxhighlight lang="text" inline>make</syntaxhighlight> at the prompt. You should observe the following output:<br />
<br />
<syntaxhighlight lang="text"><br />
$ make<br />
arm-none-eabi-gcc -c -Wall -I./include -o main.o main.c<br />
arm-none-eabi-gcc -c -Wall -I./include -o platform.o platform.c<br />
arm-none-eabi-gcc -mcpu=cortex-a9 -mfpu=vfpv3 -mfloat-abi=hard -Wl,-build-id=none -specs=Xilinx.spec -Wl,-T -Wl,lscript.ld -Llib -o main.elf main.o platform.o -Wl,--start-group,-lxil,-lgcc,-lc,--end-group<br />
$<br />
</syntaxhighlight><br />
<br />
If the building process is successful, the executable file <syntaxhighlight lang="text" inline>main.elf</syntaxhighlight> is generated. If the process fails, errors located in the source files (or Makefile) have to be corrected.<br />
<br />
* Check that the file <syntaxhighlight lang="text" inline>main.elf</syntaxhighlight> has been generated in your project directory. Note that this file has been built for the ARM architecture and cannot be executed on your computer.<br />
<br />
Until now, we have successfully built our first application. The following steps allow to transfer the executable file into the memory of the Zynq 7000 and to run the program:<br />
<br />
* Before transferring the executable file on the board, check that jumper JP5 is placed on the JTAG position and connect the PROG UART connector to the PC.<br />
Finally, switch on the SW4 switch (LD11 diode should be on).<br />
<br />
* Start the <syntaxhighlight lang="text" inline>xsct</syntaxhighlight> software in a terminal:<br />
<br />
<syntaxhighlight lang="text"><br />
$ xsct<br />
</syntaxhighlight><br />
<br />
* Type the following commands in <syntaxhighlight lang="text" inline>xsct</syntaxhighlight> (one at a time):<br />
<br />
<syntaxhighlight lang="text"><br />
connect -host localhost -port 3121<br />
targets<br />
targets 2<br />
source ps7_init.tcl<br />
ps7_init<br />
dow main.elf<br />
</syntaxhighlight><br />
<br />
The function <syntaxhighlight lang="text" inline>ps7_init()</syntaxhighlight> permits to activate the clock, the memory controller, and the peripherals (UART). This function have to be called before writing to the memory.<br />
<br />
* In another terminal, observe the [https://en.wikipedia.org/wiki/Serial_port serial port] with a terminal (e.g. <syntaxhighlight lang="text" inline>putty</syntaxhighlight> in Windows).<br />
For the link settings Baud rate: 115200, 8 bits data, 1 bit stop, without parity check.<br />
<br />
* In <syntaxhighlight lang="text" inline>xsct</syntaxhighlight>, now type the following commands:<br />
<br />
<syntaxhighlight lang="text"><br />
con<br />
stop<br />
</syntaxhighlight><br />
<br />
and observe the results on the serial port.<br />
<br />
* Validate the correct execution of the program.<br />
<br />
Before continuing with the next exercises, open 3 different terminals: the first one will be used to build the executable file (with make); the second one will be used to transfer the program on the board (with <syntaxhighlight lang="text" inline>xsct</syntaxhighlight>); the last one will be used to observe the results. Note that for the second terminal, a single <syntaxhighlight lang="text" inline>xsct</syntaxhighlight> session can be used to transfer multiple programs and that the start command will automatically detect if a new version of the program is available and transfer it on the board.<br />
<br />
== Timming ==<br />
<br />
Programming using NEON is not straight forward and many implementations can be evaluated. In order to compare the performance in between different possible implementations, timming has to be used to accurately estimate the execution time of a given section of code. The Zynq 7000 provides a real-time timer which can be controlled using the Xilinx library. This timer is incremented at a rate which is 2 time lower that the Cortex A9 clock frequency.<br />
<br />
* Add the header file <syntaxhighlight lang="text" inline>xtime_l.h</syntaxhighlight> to <syntaxhighlight lang="text" inline>main.c</syntaxhighlight> by adding the line:<br />
<br />
<syntaxhighlight lang="C" line='line'><br />
#include "xtime_l.h"<br />
</syntaxhighlight><br />
<br />
* In the function main.c, declare a variable of type <syntaxhighlight lang="text" inline>XTime</syntaxhighlight><br />
<br />
* Use the functions <syntaxhighlight lang="text" inline>XTime_SetTime(XTime Xtime)</syntaxhighlight> and <syntaxhighlight lang="text" inline>XTime_GetTime(XTime *Xtime)</syntaxhighlight>, to set or get the value inside the timer. <br />
<br />
* Add a dummy loop in main.c and determine the execution time of the associated processing. Note that the micro-controller frequency can be obtained in the macro <syntaxhighlight lang="text" inline>XPAR_CPU_CORTEXA9_CORE_CLOCK_FREQ_HZ</syntaxhighlight> defined in the file <syntaxhighlight lang="text" inline>xparameters.h</syntaxhighlight>.<br />
<br />
We are now ready to develop our first programs using the NEON engine. In each exercises, we will implement a simple algorithm in C and evaluate the performance in term of execution time. Then, we will implement the same algorithm using NEON instruction and compare the execution time. <br />
<br />
== Sum of an array ==<br />
<br />
* Create a new project by copying the <syntaxhighlight lang="text" inline>void</syntaxhighlight> directory under a different name.<br />
<br />
* Include the file <syntaxhighlight lang="text" inline>stdint.h</syntaxhighlight> which give access to sets of integer types having specified widths.<br />
<br />
* Declare an array of size 2048 where each element is a 16 bits signed integer and initialize the array to a default value.<br />
<br />
* Add a function <syntaxhighlight lang="text" inline>sum_c()</syntaxhighlight> which compute the sum of this array.<br />
<br />
* Determine the execution time of this function (this result will be used as a reference later).<br />
<br />
* Add a new file <syntaxhighlight lang="text" inline>neon.c</syntaxhighlight> to your project and write the function <syntaxhighlight lang="text" inline>sum_ni()</syntaxhighlight> which can compute the sum of the same array using NEON intrinsics.<br />
<br />
* Modify <syntaxhighlight lang="text" inline>Makefile</syntaxhighlight> to add a new rule for the file <syntaxhighlight lang="text" inline>neon.c</syntaxhighlight> (don't forget the options <syntaxhighlight lang="text" inline>-mcpu</syntaxhighlight>, <syntaxhighlight lang="text" inline>-mfloat-abi</syntaxhighlight> and <syntaxhighlight lang="text" inline>-mfpu</syntaxhighlight>). Generate the new executable file and check the correctness of your new function. <br />
<br />
* Determine its execution time and compare to the one obtained using the classical implementation in C. Rebuild your application using different optimization option (<syntaxhighlight lang="text" inline>O1</syntaxhighlight>, <syntaxhighlight lang="text" inline>O2</syntaxhighlight> and <syntaxhighlight lang="text" inline>O3</syntaxhighlight>). <br />
<br />
* Observe the assembly routine generated by the compiler with the command:<br />
<syntaxhighlight lang="text"><br />
$arm-none-eabi-gcc -S neon.c -o neon.s<br />
</syntaxhighlight><br />
Locate the NEON instructions and compare them to the ones in <syntaxhighlight lang="text" inline>neon.c</syntaxhighlight>.<br />
<br />
== Matrix Multiplication ==<br />
<br />
We consider the multiplication of 2 matrices <math>A</math> and <math>B</math> of dimension 4x4 into a third matrix <math>C</math>.<br />
<br />
* Create a new project<br />
<br />
* Write on a piece of paper the expression of each element of <math>c_{i,j}</math><br />
<br />
* Modify the <syntaxhighlight lang="text" inline>main()</syntaxhighlight> function to declare 2 matrix <syntaxhighlight lang="text" inline>A</syntaxhighlight> and <syntaxhighlight lang="text" inline>B</syntaxhighlight> initialized and a matrix <syntaxhighlight lang="text" inline>C</syntaxhighlight> (which is not initialized) of size 4x4 where each element is a float (32 bits).<br />
<br />
* Add a function <syntaxhighlight lang="text" inline>mat_product_c()</syntaxhighlight> to compute the matrix product of <syntaxhighlight lang="text" inline>A</syntaxhighlight> and <syntaxhighlight lang="text" inline>B</syntaxhighlight> and store the result in the <syntaxhighlight lang="text" inline>C</syntaxhighlight> matrix.<br />
<br />
* Validate the result by executing your function and measure the execution time of the C function.<br />
<br />
* Add a file <syntaxhighlight lang="text" inline>neon.c</syntaxhighlight> and write a function <syntaxhighlight lang="text" inline>mat_product_ni()</syntaxhighlight> to realize the matrix multiplication using NEON intrinsics. Check the correctness of your program.<br />
<br />
* Determine the execution time and the gain that we can obtain by using the NEON extension.<br />
<br />
== Edge Detection ==<br />
<br />
[[File:Nsew.png|thumb|right|Element position]]<br />
<br />
The goal of this exercise is to detect a large variation of the value of 2 neighboring elements in a 2D array. We which to store the result in a new 2D array composed of only 2 values 0 or 1 (0 if the neighboring elements are closed in value, 1 otherwise).<br />
<br />
For each element <math>C</math>, we can compute the quantity <math>|G|</math>:<br />
<br />
<math><br />
|G| = |E-W|+|N-S|<br />
</math><br />
<br />
where <math>|G|</math> can be viewed as an approximation of the magnitude of the gradient.<br />
<br />
If <math>|G|</math> is higher than a threshold value, then an edge is detected (and we store a 1 in the output array).<br />
If <math>|G|</math> is lower than the threshold value, a 0 has to be placed inside the output array.<br />
<br />
* Create a new project.<br />
<br />
* Modify the <syntaxhighlight lang="text" inline>main()</syntaxhighlight> function to declare 2 2D array <syntaxhighlight lang="text" inline>x</syntaxhighlight> and <syntaxhighlight lang="text" inline>y</syntaxhighlight> of size 10x10 where each element is an 8 bits unsigned integer. Initialize the input array <syntaxhighlight lang="text" inline>x</syntaxhighlight> to 0 for the upper triangular part and 100 for the lower triangular part.<br />
<br />
* Add a function <syntaxhighlight lang="text" inline>edge_c()</syntaxhighlight> to compute the values in the output array <syntaxhighlight lang="text" inline>y</syntaxhighlight> (edge detection).<br />
<br />
* Check the result by executing your program and determine the execution time of the C function<br />
<br />
* Add the file <syntaxhighlight lang="text" inline>neon.c</syntaxhighlight> and write the function <syntaxhighlight lang="text" inline>edge_ni()</syntaxhighlight> to realize the edge detection and store the result in the output array.<br />
<br />
* Determine the execution time and the gain obtained using the NEON extension.<br />
<br />
== Linux Application ==<br />
<br />
[[File:Output_c.png|thumb|right|Edge Detection]]<br />
<br />
The objective of this part is to start a Linux distribution on the Zybo development board and to evaluate the performance of our edge detection application on a bitmap image. Several distribution are available to run over Zynq 7000 SoC. Some of them provide a file system only in the RAM. Some others can use the file system from an external flash memory (SD card).<br />
Linaro distribution is a Ubuntu based distribution and provide the same tools than a desktop distribution (graphical user interface). Before doing the following operations, check that the Zybo board is switch off. Also, this exercise can be realize with a [https://en.wikipedia.org/wiki/Raspberry_Pi Raspberry] Pi 2 or 3 ([https://nicolas-barbot.ovh/wiki/pool/rpi.zip <syntaxhighlight lang="text" inline>rpi.zip</syntaxhighlight>]).<br />
<br />
* Insert the SD card in the slot located under the board.<br />
<br />
* Place jumper JP5 on SD position. The board will now start from the SD card.<br />
<br />
* Connect a USB cable between UART and the PC. Connect the USB hub on the OTG connector. <br />
<br />
* Connect the HDMI output to a screen by using an adaptor.<br />
<br />
* Switch on the board. You should see on the UART output, the startup messages of the kernel and finally the root invite.<br />
<br />
* Go inside the \verb+/home/linaro+ directory and modify the existing project to add your edge detection function (add the C version and the NEON version).<br />
<br />
* Build the project with the Makefile.<br />
<br />
* Start the program with the name of a bitmap image as a second argument. The program should generate the image <syntaxhighlight lang="text" inline>output.bmp</syntaxhighlight>.<br />
<br />
* Check the correctness of your program (adapt the threshold value).<br />
<br />
* We wish to analyze the performance of our program with <syntaxhighlight lang="text" inline>gprof</syntaxhighlight>. This tool is able to periodically interrupt the program under test to evaluate the load of each function on the processor. In order to increase the accuracy of the measurement, add a loop to repeat all the process 100 times. Rebuild your program using the <syntaxhighlight lang="text" inline>-pg</syntaxhighlight> option.<br />
<br />
* Execute your newly generated program (with the <syntaxhighlight lang="text" inline>edge_c()</syntaxhighlight> function). Notice that the compilation process generate now a <syntaxhighlight lang="text" inline>gmon.out</syntaxhighlight> file. This file contains the profiling information. Finally execute the following command:<br />
<syntaxhighlight lang="text"><br />
$ gprof test gmon.out > res<br />
</syntaxhighlight><br />
<br />
* Open the <syntaxhighlight lang="text" inline>res</syntaxhighlight> file in an editor to see the results.<br />
<br />
* Replace the <syntaxhighlight lang="text" inline>edge_c()</syntaxhighlight> function with the <syntaxhighlight lang="text" inline>edge_ni()</syntaxhighlight> function and profile the program again.<br />
<br />
* If you have enough time, replace the functions <syntaxhighlight lang="text" inline>color2gray_c()</syntaxhighlight> and <syntaxhighlight lang="text" inline>gray2color_c()</syntaxhighlight> by new functions using the NEON engine.<br />
<br />
== Conclusion ==<br />
<br />
At the end of these labs, you should now be able to develop, build, and optimize an application using the NEON engine present in Cortex-A processors.<br />
<br />
==References==<br />
<br />
<references /></div>Nicohttps://nicolas-barbot.ovh/wiki/index.php?title=CE515_Advanced_Processor_Architecture_and_SoC_Design&diff=467CE515 Advanced Processor Architecture and SoC Design2021-10-05T11:53:10Z<p>Nico: </p>
<hr />
<div>This course is separated into 2 parts. The first one deals will SoC design and programming and is supervised by David Hély. The second one is focused on the SIMD extension present inside ARM architecture. The goal of this lab is implement and develop algorithms (functions) optimized for the NEON extension included in the architecture ARMv7-A et ARMv7-R. Slides of the course can be found [https://nicolas-barbot.ovh/wiki/pool/neon_en.pdf here]. This course requires the basic knowledge of a micro-controller architecture and classical C programming. Processing will run over a [https://www.xilinx.com/ Xilinx] [https://www.xilinx.com/products/silicon-devices/soc/zynq-7000.html Zynq 7000] SoC which contain an ARM Cortex A9 MP Core. Performance of the NEON engine will be compared to the performance of classical implementation (C function executed on the ARM core).<br />
<br />
== Introduction ==<br />
<br />
[[File:Zynq.png|thumb|right|Zynq 7000 architecture]]<br />
<br />
A lot of peripherals generate (or accept) data whose the size is smaller than the processor register size (e.g., 16 bits ADC and 32 bits processor.) When the CPU process these data, a single data is used at a time and processor register is not used fully which imply that the efficiency of the system is decreased. SIMD technology uses a single instruction to realize the same operation on multiple data (in the same time) which increase the execution speed.<br />
<br />
NEON extension has been introduced in the ARMv7 architecture. This extension adds a set of registers (64 and 128 bits) and a SIMD instruction set <ref> NEON Programmer's Guide Version 1.0 ([https://nicolas-barbot.ovh/wiki/pool/DEN0018A_neon_programmers_guide.pdf ARM DEN0018A])</ref>. NEON instructions and ARM instructions are processed in the same time. Exact execution time depends on the Cortex used by the SoC <ref> Cortex-A9 NEON Media Processing Engine, Technical Reference Manual ([https://nicolas-barbot.ovh/wiki/pool/DDI0409G_cortex_a9_neon_mpe_r3p0_trm.pdf ARM DDI 0409])</ref> but all NEON instructions can be processed by the NEON engine. Classical instructions (ARM, Thumb, Thumb2) are described in the reference manual <ref> ARM Architecture Reference Manual, ARMv7-A and ARMv7-R edition ([https://nicolas-barbot.ovh/wiki/pool/DDI0406C_C_arm_architecture_reference_manual.pdf ARM DDI 0406])</ref>.<br />
<br />
During this lab, we will use the development board Zybo. This board include a Zynq 7000 System on Chip. This Soc is composed of FPGA and a Cortex A9 MP Core. Each core include one NEON engine. Figure 1 presents the system architecture. The four first exercises evaluate the performance of simple processing algorithms without any operating system (baremetal or standalone). The final exercise use the NEON extension in a Linux environment.<br />
<br />
== Standalone Application ==<br />
<br />
In this first exercise, we will develop, build, and run a simple application on the Zybo board.<br />
<br />
* Download the [https://nicolas-barbot.ovh/wiki/pool/void.zip <syntaxhighlight lang="text" inline>void</syntaxhighlight>] project.<br />
* Extract the project into a new directory on your computer.<br />
* Observe the structure of the project and open the <syntaxhighlight lang="text" inline>main.c</syntaxhighlight> source file in an editor.<br />
<br />
<syntaxhighlight lang="C" line><br />
#include <stdio.h><br />
#include "platform.h"<br />
#include "xil_printf.h"<br />
<br />
<br />
int main()<br />
{<br />
init_platform();<br />
<br />
print("Hello World\n\r");<br />
<br />
cleanup_platform();<br />
return 0;<br />
}<br />
</syntaxhighlight><br />
<br />
<syntaxhighlight lang="C" inline>init_platform()</syntaxhighlight> function is defined in <syntaxhighlight lang="text" inline>platform.c</syntaxhighlight> file and permit to activate cache memory on the Cortex A9 MP Core. This function call is not mandatory. <syntaxhighlight lang="C" inline>printf()</syntaxhighlight> allows to send the argument on the UART of the Zynq 7000. This function also supports the classical formatting of numbers.<br />
<br />
* Open a terminal (<syntaxhighlight inline lang="text">cmd.exe</syntaxhighlight>) and go to your project location (using <syntaxhighlight lang="text" inline>cd</syntaxhighlight>).<br />
<br />
* Execute the following script: <syntaxhighlight lang="text" inline>C:\Xilinx\Vitis\2019.2\settings64.bat</syntaxhighlight>. This script modifies the PATH evironment variable and allows to call the Xilinx tools directly form the command line.<br />
<br />
* Build process is fully automatized using [https://en.wikipedia.org/wiki/Make_(software) <syntaxhighlight lang="text" inline>make</syntaxhighlight>]. Open the <syntaxhighlight lang="text" inline>Makefile</syntaxhighlight> in your editor:<br />
<br />
<syntaxhighlight lang="Makefile" line='line'><br />
CC=arm-none-eabi-gcc<br />
CFLAGS=-mcpu=cortex-a9 -mfpu=vfpv3 -mfloat-abi=hard -c -Wall -I./include<br />
LDFLAGS=-mcpu=cortex-a9 -mfpu=vfpv3 -mfloat-abi=hard -Wl,-build-id=none -specs=Xilinx.spec -Wl,-T -Wl,lscript.ld -Llib<br />
LIBS=-Wl,--start-group,-lxil,-lgcc,-lc,--end-group<br />
<br />
all: main.elf<br />
<br />
main.o: main.c<br />
$(CC) $(CFLAGS) -o main.o main.c<br />
<br />
platform.o: platform.c<br />
$(CC) $(CFLAGS) -o platform.o platform.c<br />
<br />
main.elf: main.o platform.o<br />
$(CC) $(LDFLAGS) -o main.elf main.o platform.o $(LIBS)<br />
<br />
clean:<br />
rm *.o main.elf<br />
</syntaxhighlight><br />
<br />
The four first lines are simple variables. The rest of the file is composed of 4 rules. The first line of each rule defines the name of the target and its associated dependencies. For each rule, <syntaxhighlight lang="text" inline>make</syntaxhighlight> checks the modification date of the dependencies compared to the one of the target. If one of the dependencies has been modified after the target, <syntaxhighlight lang="text" inline>make</syntaxhighlight> run the command(s) located after the first line (and which have to begin by tab).<br />
<br />
* To build the project invoke <syntaxhighlight lang="text" inline>make</syntaxhighlight> at the prompt. You should observe the following output:<br />
<br />
<syntaxhighlight lang="text"><br />
$ make<br />
arm-none-eabi-gcc -c -Wall -I./include -o main.o main.c<br />
arm-none-eabi-gcc -c -Wall -I./include -o platform.o platform.c<br />
arm-none-eabi-gcc -mcpu=cortex-a9 -mfpu=vfpv3 -mfloat-abi=hard -Wl,-build-id=none -specs=Xilinx.spec -Wl,-T -Wl,lscript.ld -Llib -o main.elf main.o platform.o -Wl,--start-group,-lxil,-lgcc,-lc,--end-group<br />
$<br />
</syntaxhighlight><br />
<br />
If the building process is successful, the executable file <syntaxhighlight lang="text" inline>main.elf</syntaxhighlight> is generated. If the process fails, errors located in the source files (or Makefile) have to be corrected.<br />
<br />
* Check that the file <syntaxhighlight lang="text" inline>main.elf</syntaxhighlight> has been generated in your project directory. Note that this file has been built for the ARM architecture and cannot be executed on your computer.<br />
<br />
Until now, we have successfully built our first application. The following steps allow to transfer the executable file into the memory of the Zynq 7000 and to run the program:<br />
<br />
* Before transferring the executable file on the board, check that jumper JP5 is placed on the JTAG position and connect the PROG UART connector to the PC.<br />
Finally, switch on the SW4 switch (LD11 diode should be on).<br />
<br />
* Start the <syntaxhighlight lang="text" inline>xsct</syntaxhighlight> software in a terminal:<br />
<br />
<syntaxhighlight lang="text"><br />
$ xsct<br />
</syntaxhighlight><br />
<br />
* Type the following commands in <syntaxhighlight lang="text" inline>xsct</syntaxhighlight> (one at a time):<br />
<br />
<syntaxhighlight lang="text"><br />
connect -host localhost -port 3121<br />
targets<br />
targets 2<br />
source ps7_init.tcl<br />
ps7_init<br />
dow main.elf<br />
</syntaxhighlight><br />
<br />
The function <syntaxhighlight lang="text" inline>ps7_init()</syntaxhighlight> permits to activate the clock, the memory controller, and the peripherals (UART). This function have to be called before writing to the memory.<br />
<br />
* In another terminal, observe the [https://en.wikipedia.org/wiki/Serial_port serial port] with a terminal (e.g. <syntaxhighlight lang="text" inline>putty</syntaxhighlight> in Windows).<br />
For the link settings Baud rate: 115200, 8 bits data, 1 bit stop, without parity check.<br />
<br />
* In <syntaxhighlight lang="text" inline>xmd</syntaxhighlight>, now type the following commands:<br />
<br />
<syntaxhighlight lang="text"><br />
con<br />
stop<br />
</syntaxhighlight><br />
<br />
and observe the results on the serial port.<br />
<br />
* Validate the correct execution of the program.<br />
<br />
Before continuing with the next exercises, open 3 different terminals: the first one will be used to build the executable file (with cs-make); the second one will be used to transfer the program on the board (with <syntaxhighlight lang="text" inline>xmd</syntaxhighlight>); the last one will be used to observe the results. Note that for the second terminal, a single <syntaxhighlight lang="text" inline>xmd</syntaxhighlight> session can be used to transfer multiple programs and that the start command will automatically detect if a new version of the program is available and transfer it on the board.<br />
<br />
== Timming ==<br />
<br />
Programming using NEON is not straight forward and many implementations can be evaluated. In order to compare the performance in between different possible implementations, timming has to be used to accurately estimate the execution time of a given section of code. The Zynq 7000 provides a real-time timer which can be controlled using the Xilinx library. This timer is incremented at a rate which is 2 time lower that the Cortex A9 clock frequency.<br />
<br />
* Add the header file <syntaxhighlight lang="text" inline>xtime_l.h</syntaxhighlight> to <syntaxhighlight lang="text" inline>main.c</syntaxhighlight> by adding the line:<br />
<br />
<syntaxhighlight lang="C" line='line'><br />
#include "xtime_l.h"<br />
</syntaxhighlight><br />
<br />
* In the function main.c, declare a variable of type <syntaxhighlight lang="text" inline>XTime</syntaxhighlight><br />
<br />
* Use the functions <syntaxhighlight lang="text" inline>XTime_SetTime(XTime Xtime)</syntaxhighlight> and <syntaxhighlight lang="text" inline>XTime_GetTime(XTime *Xtime)</syntaxhighlight>, to set or get the value inside the timer. <br />
<br />
* Add a dummy loop in main.c and determine the execution time of the associated processing. Note that the micro-controller frequency can be obtained in the macro <syntaxhighlight lang="text" inline>XPAR_CPU_CORTEXA9_CORE_CLOCK_FREQ_HZ</syntaxhighlight> defined in the file <syntaxhighlight lang="text" inline>xparameters.h</syntaxhighlight>.<br />
<br />
We are now ready to develop our first programs using the NEON engine. In each exercises, we will implement a simple algorithm in C and evaluate the performance in term of execution time. Then, we will implement the same algorithm using NEON instruction and compare the execution time. <br />
<br />
== Sum of an array ==<br />
<br />
* Create a new project by copying the <syntaxhighlight lang="text" inline>void</syntaxhighlight> directory under a different name.<br />
<br />
* Include the file <syntaxhighlight lang="text" inline>stdint.h</syntaxhighlight> which give access to sets of integer types having specified widths.<br />
<br />
* Declare an array of size 2048 where each element is a 16 bits signed integer and initialize the array to a default value.<br />
<br />
* Add a function <syntaxhighlight lang="text" inline>sum_c()</syntaxhighlight> which compute the sum of this array.<br />
<br />
* Determine the execution time of this function (this result will be used as a reference later).<br />
<br />
* Add a new file <syntaxhighlight lang="text" inline>neon.c</syntaxhighlight> to your project and write the function <syntaxhighlight lang="text" inline>sum_ni()</syntaxhighlight> which can compute the sum of the same array using NEON intrinsics.<br />
<br />
* Modify <syntaxhighlight lang="text" inline>Makefile</syntaxhighlight> to add a new rule for the file <syntaxhighlight lang="text" inline>neon.c</syntaxhighlight> (don't forget the options <syntaxhighlight lang="text" inline>-mcpu</syntaxhighlight>, <syntaxhighlight lang="text" inline>-mfloat-abi</syntaxhighlight> and <syntaxhighlight lang="text" inline>-mfpu</syntaxhighlight>). Generate the new executable file and check the correctness of your new function. <br />
<br />
* Determine its execution time and compare to the one obtained using the classical implementation in C. Rebuild your application using different optimization option (<syntaxhighlight lang="text" inline>O1</syntaxhighlight>, <syntaxhighlight lang="text" inline>O2</syntaxhighlight> and <syntaxhighlight lang="text" inline>O3</syntaxhighlight>). <br />
<br />
* Observe the assembly routine generated by the compiler with the command:<br />
<syntaxhighlight lang="text"><br />
$arm-none-eabi-gcc -S neon.c -o neon.s<br />
</syntaxhighlight><br />
Locate the NEON instructions and compare them to the ones in <syntaxhighlight lang="text" inline>neon.c</syntaxhighlight>.<br />
<br />
== Matrix Multiplication ==<br />
<br />
We consider the multiplication of 2 matrices <math>A</math> and <math>B</math> of dimension 4x4 into a third matrix <math>C</math>.<br />
<br />
* Create a new project<br />
<br />
* Write on a piece of paper the expression of each element of <math>c_{i,j}</math><br />
<br />
* Modify the <syntaxhighlight lang="text" inline>main()</syntaxhighlight> function to declare 2 matrix <syntaxhighlight lang="text" inline>A</syntaxhighlight> and <syntaxhighlight lang="text" inline>B</syntaxhighlight> initialized and a matrix <syntaxhighlight lang="text" inline>C</syntaxhighlight> (which is not initialized) of size 4x4 where each element is a float (32 bits).<br />
<br />
* Add a function <syntaxhighlight lang="text" inline>mat_product_c()</syntaxhighlight> to compute the matrix product of <syntaxhighlight lang="text" inline>A</syntaxhighlight> and <syntaxhighlight lang="text" inline>B</syntaxhighlight> and store the result in the <syntaxhighlight lang="text" inline>C</syntaxhighlight> matrix.<br />
<br />
* Validate the result by executing your function and measure the execution time of the C function.<br />
<br />
* Add a file <syntaxhighlight lang="text" inline>neon.c</syntaxhighlight> and write a function <syntaxhighlight lang="text" inline>mat_product_ni()</syntaxhighlight> to realize the matrix multiplication using NEON intrinsics. Check the correctness of your program.<br />
<br />
* Determine the execution time and the gain that we can obtain by using the NEON extension.<br />
<br />
== Edge Detection ==<br />
<br />
[[File:Nsew.png|thumb|right|Element position]]<br />
<br />
The goal of this exercise is to detect a large variation of the value of 2 neighboring elements in a 2D array. We which to store the result in a new 2D array composed of only 2 values 0 or 1 (0 if the neighboring elements are closed in value, 1 otherwise).<br />
<br />
For each element <math>C</math>, we can compute the quantity <math>|G|</math>:<br />
<br />
<math><br />
|G| = |E-W|+|N-S|<br />
</math><br />
<br />
where <math>|G|</math> can be viewed as an approximation of the magnitude of the gradient.<br />
<br />
If <math>|G|</math> is higher than a threshold value, then an edge is detected (and we store a 1 in the output array).<br />
If <math>|G|</math> is lower than the threshold value, a 0 has to be placed inside the output array.<br />
<br />
* Create a new project.<br />
<br />
* Modify the <syntaxhighlight lang="text" inline>main()</syntaxhighlight> function to declare 2 2D array <syntaxhighlight lang="text" inline>x</syntaxhighlight> and <syntaxhighlight lang="text" inline>y</syntaxhighlight> of size 10x10 where each element is an 8 bits unsigned integer. Initialize the input array <syntaxhighlight lang="text" inline>x</syntaxhighlight> to 0 for the upper triangular part and 100 for the lower triangular part.<br />
<br />
* Add a function <syntaxhighlight lang="text" inline>edge_c()</syntaxhighlight> to compute the values in the output array <syntaxhighlight lang="text" inline>y</syntaxhighlight> (edge detection).<br />
<br />
* Check the result by executing your program and determine the execution time of the C function<br />
<br />
* Add the file <syntaxhighlight lang="text" inline>neon.c</syntaxhighlight> and write the function <syntaxhighlight lang="text" inline>edge_ni()</syntaxhighlight> to realize the edge detection and store the result in the output array.<br />
<br />
* Determine the execution time and the gain obtained using the NEON extension.<br />
<br />
== Linux Application ==<br />
<br />
[[File:Output_c.png|thumb|right|Edge Detection]]<br />
<br />
The objective of this part is to start a Linux distribution on the Zybo development board and to evaluate the performance of our edge detection application on a bitmap image. Several distribution are available to run over Zynq 7000 SoC. Some of them provide a file system only in the RAM. Some others can use the file system from an external flash memory (SD card).<br />
Linaro distribution is a Ubuntu based distribution and provide the same tools than a desktop distribution (graphical user interface). Before doing the following operations, check that the Zybo board is switch off. Also, this exercise can be realize with a [https://en.wikipedia.org/wiki/Raspberry_Pi Raspberry] Pi 2 or 3 ([https://nicolas-barbot.ovh/wiki/pool/rpi.zip <syntaxhighlight lang="text" inline>rpi.zip</syntaxhighlight>]).<br />
<br />
* Insert the SD card in the slot located under the board.<br />
<br />
* Place jumper JP5 on SD position. The board will now start from the SD card.<br />
<br />
* Connect a USB cable between UART and the PC. Connect the USB hub on the OTG connector. <br />
<br />
* Connect the HDMI output to a screen by using an adaptor.<br />
<br />
* Switch on the board. You should see on the UART output, the startup messages of the kernel and finally the root invite.<br />
<br />
* Go inside the \verb+/home/linaro+ directory and modify the existing project to add your edge detection function (add the C version and the NEON version).<br />
<br />
* Build the project with the Makefile.<br />
<br />
* Start the program with the name of a bitmap image as a second argument. The program should generate the image <syntaxhighlight lang="text" inline>output.bmp</syntaxhighlight>.<br />
<br />
* Check the correctness of your program (adapt the threshold value).<br />
<br />
* We wish to analyze the performance of our program with <syntaxhighlight lang="text" inline>gprof</syntaxhighlight>. This tool is able to periodically interrupt the program under test to evaluate the load of each function on the processor. In order to increase the accuracy of the measurement, add a loop to repeat all the process 100 times. Rebuild your program using the <syntaxhighlight lang="text" inline>-pg</syntaxhighlight> option.<br />
<br />
* Execute your newly generated program (with the <syntaxhighlight lang="text" inline>edge_c()</syntaxhighlight> function). Notice that the compilation process generate now a <syntaxhighlight lang="text" inline>gmon.out</syntaxhighlight> file. This file contains the profiling information. Finally execute the following command:<br />
<syntaxhighlight lang="text"><br />
$ gprof test gmon.out > res<br />
</syntaxhighlight><br />
<br />
* Open the <syntaxhighlight lang="text" inline>res</syntaxhighlight> file in an editor to see the results.<br />
<br />
* Replace the <syntaxhighlight lang="text" inline>edge_c()</syntaxhighlight> function with the <syntaxhighlight lang="text" inline>edge_ni()</syntaxhighlight> function and profile the program again.<br />
<br />
* If you have enough time, replace the functions <syntaxhighlight lang="text" inline>color2gray_c()</syntaxhighlight> and <syntaxhighlight lang="text" inline>gray2color_c()</syntaxhighlight> by new functions using the NEON engine.<br />
<br />
== Conclusion ==<br />
<br />
At the end of these labs, you should now be able to develop, build, and optimize an application using the NEON engine present in Cortex-A processors.<br />
<br />
==References==<br />
<br />
<references /></div>Nicohttps://nicolas-barbot.ovh/wiki/index.php?title=CE515_Advanced_Processor_Architecture_and_SoC_Design&diff=466CE515 Advanced Processor Architecture and SoC Design2021-10-04T18:39:50Z<p>Nico: </p>
<hr />
<div>This course is separated into 2 parts. The first one deals will SoC design and programming and is supervised by David Hély. The second one is focused on the SIMD extension present inside ARM architecture. The goal of this lab is implement and develop algorithms (functions) optimized for the NEON extension included in the architecture ARMv7-A et ARMv7-R. Slides of the course can be found [https://nicolas-barbot.ovh/wiki/pool/neon_en.pdf here]. This course requires the basic knowledge of a micro-controller architecture and classical C programming. Processing will run over a [https://www.xilinx.com/ Xilinx] [https://www.xilinx.com/products/silicon-devices/soc/zynq-7000.html Zynq 7000] SoC which contain an ARM Cortex A9 MP Core. Performance of the NEON engine will be compared to the performance of classical implementation (C function executed on the ARM core).<br />
<br />
== Introduction ==<br />
<br />
[[File:Zynq.png|thumb|right|Zynq 7000 architecture]]<br />
<br />
A lot of peripherals generate (or accept) data whose the size is smaller than the processor register size (e.g., 16 bits ADC and 32 bits processor.) When the CPU process these data, a single data is used at a time and processor register is not used fully which imply that the efficiency of the system is decreased. SIMD technology uses a single instruction to realize the same operation on multiple data (in the same time) which increase the execution speed.<br />
<br />
NEON extension has been introduced in the ARMv7 architecture. This extension adds a set of registers (64 and 128 bits) and a SIMD instruction set <ref> NEON Programmer's Guide Version 1.0 ([https://nicolas-barbot.ovh/wiki/pool/DEN0018A_neon_programmers_guide.pdf ARM DEN0018A])</ref>. NEON instructions and ARM instructions are processed in the same time. Exact execution time depends on the Cortex used by the SoC <ref> Cortex-A9 NEON Media Processing Engine, Technical Reference Manual ([https://nicolas-barbot.ovh/wiki/pool/DDI0409G_cortex_a9_neon_mpe_r3p0_trm.pdf ARM DDI 0409])</ref> but all NEON instructions can be processed by the NEON engine. Classical instructions (ARM, Thumb, Thumb2) are described in the reference manual <ref> ARM Architecture Reference Manual, ARMv7-A and ARMv7-R edition ([https://nicolas-barbot.ovh/wiki/pool/DDI0406C_C_arm_architecture_reference_manual.pdf ARM DDI 0406])</ref>.<br />
<br />
During this lab, we will use the development board Zybo. This board include a Zynq 7000 System on Chip. This Soc is composed of FPGA and a Cortex A9 MP Core. Each core include one NEON engine. Figure 1 presents the system architecture. The four first exercises evaluate the performance of simple processing algorithms without any operating system (baremetal or standalone). The final exercise use the NEON extension in a Linux environment.<br />
<br />
== Standalone Application ==<br />
<br />
In this first exercise, we will develop, build, and run a simple application on the Zybo board.<br />
<br />
* Download the [https://nicolas-barbot.ovh/wiki/pool/void.zip <syntaxhighlight lang="text" inline>void</syntaxhighlight>] project.<br />
* Extract the project into a new directory on your computer.<br />
* Observe the structure of the project and open the <syntaxhighlight lang="text" inline>main.c</syntaxhighlight> source file in an editor.<br />
<br />
<syntaxhighlight lang="C" line><br />
#include <stdio.h><br />
#include "platform.h"<br />
#include "xil_printf.h"<br />
<br />
<br />
int main()<br />
{<br />
init_platform();<br />
<br />
print("Hello World\n\r");<br />
<br />
cleanup_platform();<br />
return 0;<br />
}<br />
</syntaxhighlight><br />
<br />
<syntaxhighlight lang="C" inline>init_platform()</syntaxhighlight> function is defined in <syntaxhighlight lang="text" inline>platform.c</syntaxhighlight> file and permit to activate cache memory on the Cortex A9 MP Core. This function call is not mandatory. <syntaxhighlight lang="C" inline>printf()</syntaxhighlight> allows to send the argument on the UART of the Zynq 7000. This function also supports the classical formatting of numbers.<br />
<br />
* Open a terminal (<syntaxhighlight inline lang="text">cmd.exe</syntaxhighlight>) and go to your project location (using <syntaxhighlight lang="text" inline>cd</syntaxhighlight>).<br />
<br />
* Execute the following script: <syntaxhighlight lang="text" inline>C:\Xilinx\Vitis\2019.2\settings64.bat</syntaxhighlight>. This script modifies the PATH evironment variable and allows to call the Xilinx tools directly form the command line.<br />
<br />
* Build process is fully automatized using [https://en.wikipedia.org/wiki/Make_(software) <syntaxhighlight lang="text" inline>make</syntaxhighlight>]. Open the <syntaxhighlight lang="text" inline>Makefile</syntaxhighlight> in your editor:<br />
<br />
<syntaxhighlight lang="Makefile" line='line'><br />
CC=arm-none-eabi-gcc<br />
CFLAGS=-mcpu=cortex-a9 -mfpu=vfpv3 -mfloat-abi=hard -c -Wall -I./include<br />
LDFLAGS=-mcpu=cortex-a9 -mfpu=vfpv3 -mfloat-abi=hard -Wl,-build-id=none -specs=Xilinx.spec -Wl,-T -Wl,lscript.ld -Llib<br />
LIBS=-Wl,--start-group,-lxil,-lgcc,-lc,--end-group<br />
<br />
all: main.elf<br />
<br />
main.o: main.c<br />
$(CC) $(CFLAGS) -o main.o main.c<br />
<br />
platform.o: platform.c<br />
$(CC) $(CFLAGS) -o platform.o platform.c<br />
<br />
main.elf: main.o platform.o<br />
$(CC) $(LDFLAGS) -o main.elf main.o platform.o $(LIBS)<br />
<br />
clean:<br />
rm *.o main.elf<br />
</syntaxhighlight><br />
<br />
The four first lines are simple variables. The rest of the file is composed of 4 rules. The first line of each rule defines the name of the target and its associated dependencies. For each rule, <syntaxhighlight lang="text" inline>make</syntaxhighlight> checks the modification date of the dependencies compared to the one of the target. If one of the dependencies has been modified after the target, <syntaxhighlight lang="text" inline>make</syntaxhighlight> run the command(s) located after the first line (and which have to begin by tab).<br />
<br />
* To build the project invoke <syntaxhighlight lang="text" inline>make</syntaxhighlight> at the prompt. You should observe the following output:<br />
<br />
<syntaxhighlight lang="text"><br />
$ make<br />
arm-none-eabi-gcc -c -Wall -I./include -o main.o main.c<br />
arm-none-eabi-gcc -c -Wall -I./include -o platform.o platform.c<br />
arm-none-eabi-gcc -mcpu=cortex-a9 -mfpu=vfpv3 -mfloat-abi=hard -Wl,-build-id=none -specs=Xilinx.spec -Wl,-T -Wl,lscript.ld -Llib -o main.elf main.o platform.o -Wl,--start-group,-lxil,-lgcc,-lc,--end-group<br />
$<br />
</syntaxhighlight><br />
<br />
If the building process is successful, the executable file <syntaxhighlight lang="text" inline>main.elf</syntaxhighlight> is generated. If the process fails, errors located in the source files (or Makefile) have to be corrected.<br />
<br />
* Check that the file <syntaxhighlight lang="text" inline>main.elf</syntaxhighlight> has been generated in your project directory. Note that this file has been built for the ARM architecture and cannot be executed on your computer.<br />
<br />
Until now, we have successfully built our first application. The following steps allow to transfer the executable file into the memory of the Zynq 7000 and to run the program:<br />
<br />
* Before transferring the executable file on the board, check that jumper JP5 is placed on the JTAG position and connect the PROG UART connector to the PC.<br />
Finally, switch on the SW4 switch (LD11 diode should be on).<br />
<br />
* Start the <syntaxhighlight lang="text" inline>xsct</syntaxhighlight> software in a terminal:<br />
<br />
<syntaxhighlight lang="text"><br />
$ xsct<br />
</syntaxhighlight><br />
<br />
* Type the following commands in <syntaxhighlight lang="text" inline>xsct</syntaxhighlight> (one at a time):<br />
<br />
<syntaxhighlight lang="text"><br />
connect -host localhost -port 3121<br />
targets<br />
targets 2<br />
source ps7_init.tcl<br />
ps7_init<br />
dow main.elf<br />
</syntaxhighlight><br />
<br />
The function <syntaxhighlight lang="text" inline>ps7_init()</syntaxhighlight> permits to activate the clock, the memory controller, and the peripherals (UART). This function have to be called before writing to the memory.<br />
<br />
* In another terminal, observe the [https://en.wikipedia.org/wiki/Serial_port serial port] with a terminal (e.g. <syntaxhighlight lang="text" inline>putty</syntaxhighlight> in Windows).<br />
For the link settings Baud rate: 115200, 8 bits data, 1 bit stop, without parity check.<br />
<br />
* In <syntaxhighlight lang="text" inline>xmd</syntaxhighlight>, now type the following commands:<br />
<br />
<syntaxhighlight lang="text"><br />
con<br />
stop<br />
</syntaxhighlight><br />
<br />
and observe the results on the serial port.<br />
<br />
* Validate the correct execution of the program.<br />
<br />
Before continuing with the next exercises, open 3 different terminals: the first one will be used to build the executable file (with cs-make); the second one will be used to transfer the program on the board (with <syntaxhighlight lang="text" inline>xmd</syntaxhighlight>); the last one will be used to observe the results. Note that for the second terminal, a single <syntaxhighlight lang="text" inline>xmd</syntaxhighlight> session can be used to transfer multiple programs and that the start command will automatically detect if a new version of the program is available and transfer it on the board.<br />
<br />
== Timming ==<br />
<br />
Programming using NEON is not straight forward and many implementations can be evaluated. In order to compare the performance in between different possible implementations, timming has to be used to accurately estimate the execution time of a given section of code. The Zynq 7000 provides a real-time timer which can be controlled using the Xilinx library. This timer is incremented at a rate which is 2 time lower that the Cortex A9 clock frequency.<br />
<br />
* Add the header file <syntaxhighlight lang="text" inline>xtime_l.h</syntaxhighlight> to <syntaxhighlight lang="text" inline>main.c</syntaxhighlight> by adding the line:<br />
<br />
<syntaxhighlight lang="C" line='line'><br />
#include <xscutimer.h><br />
</syntaxhighlight><br />
<br />
* In the function main.c, declare a variable of type <syntaxhighlight lang="text" inline>XTime</syntaxhighlight><br />
<br />
* Use the functions <syntaxhighlight lang="text" inline>XTime_SetTime(XTime Xtime)</syntaxhighlight> and <syntaxhighlight lang="text" inline>XTime_GetTime(XTime *Xtime)</syntaxhighlight>, to set or get the value inside the timer. <br />
<br />
* Add a dummy loop in main.c and determine the execution time of the associated processing. Note that the micro-controller frequency can be obtained in the macro <syntaxhighlight lang="text" inline>XPAR_CPU_CORTEXA9_CORE_CLOCK_FREQ_HZ</syntaxhighlight> defined in the file <syntaxhighlight lang="text" inline>xparameters.h</syntaxhighlight>.<br />
<br />
We are now ready to develop our first programs using the NEON engine. In each exercises, we will implement a simple algorithm in C and evaluate the performance in term of execution time. Then, we will implement the same algorithm using NEON instruction and compare the execution time. <br />
<br />
== Sum of an array ==<br />
<br />
* Create a new project by copying the <syntaxhighlight lang="text" inline>void</syntaxhighlight> directory under a different name.<br />
<br />
* Include the file <syntaxhighlight lang="text" inline>stdint.h</syntaxhighlight> which give access to sets of integer types having specified widths.<br />
<br />
* Declare an array of size 2048 where each element is a 16 bits signed integer and initialize the array to a default value.<br />
<br />
* Add a function <syntaxhighlight lang="text" inline>sum_c()</syntaxhighlight> which compute the sum of this array.<br />
<br />
* Determine the execution time of this function (this result will be used as a reference later).<br />
<br />
* Add a new file <syntaxhighlight lang="text" inline>neon.c</syntaxhighlight> to your project and write the function <syntaxhighlight lang="text" inline>sum_ni()</syntaxhighlight> which can compute the sum of the same array using NEON intrinsics.<br />
<br />
* Modify <syntaxhighlight lang="text" inline>Makefile</syntaxhighlight> to add a new rule for the file <syntaxhighlight lang="text" inline>neon.c</syntaxhighlight> (don't forget the options <syntaxhighlight lang="text" inline>-mcpu</syntaxhighlight>, <syntaxhighlight lang="text" inline>-mfloat-abi</syntaxhighlight> and <syntaxhighlight lang="text" inline>-mfpu</syntaxhighlight>). Generate the new executable file and check the correctness of your new function. <br />
<br />
* Determine its execution time and compare to the one obtained using the classical implementation in C. Rebuild your application using different optimization option (<syntaxhighlight lang="text" inline>O1</syntaxhighlight>, <syntaxhighlight lang="text" inline>O2</syntaxhighlight> and <syntaxhighlight lang="text" inline>O3</syntaxhighlight>). <br />
<br />
* Observe the assembly routine generated by the compiler with the command:<br />
<syntaxhighlight lang="text"><br />
$arm-none-eabi-gcc -S neon.c -o neon.s<br />
</syntaxhighlight><br />
Locate the NEON instructions and compare them to the ones in <syntaxhighlight lang="text" inline>neon.c</syntaxhighlight>.<br />
<br />
== Matrix Multiplication ==<br />
<br />
We consider the multiplication of 2 matrices <math>A</math> and <math>B</math> of dimension 4x4 into a third matrix <math>C</math>.<br />
<br />
* Create a new project<br />
<br />
* Write on a piece of paper the expression of each element of <math>c_{i,j}</math><br />
<br />
* Modify the <syntaxhighlight lang="text" inline>main()</syntaxhighlight> function to declare 2 matrix <syntaxhighlight lang="text" inline>A</syntaxhighlight> and <syntaxhighlight lang="text" inline>B</syntaxhighlight> initialized and a matrix <syntaxhighlight lang="text" inline>C</syntaxhighlight> (which is not initialized) of size 4x4 where each element is a float (32 bits).<br />
<br />
* Add a function <syntaxhighlight lang="text" inline>mat_product_c()</syntaxhighlight> to compute the matrix product of <syntaxhighlight lang="text" inline>A</syntaxhighlight> and <syntaxhighlight lang="text" inline>B</syntaxhighlight> and store the result in the <syntaxhighlight lang="text" inline>C</syntaxhighlight> matrix.<br />
<br />
* Validate the result by executing your function and measure the execution time of the C function.<br />
<br />
* Add a file <syntaxhighlight lang="text" inline>neon.c</syntaxhighlight> and write a function <syntaxhighlight lang="text" inline>mat_product_ni()</syntaxhighlight> to realize the matrix multiplication using NEON intrinsics. Check the correctness of your program.<br />
<br />
* Determine the execution time and the gain that we can obtain by using the NEON extension.<br />
<br />
== Edge Detection ==<br />
<br />
[[File:Nsew.png|thumb|right|Element position]]<br />
<br />
The goal of this exercise is to detect a large variation of the value of 2 neighboring elements in a 2D array. We which to store the result in a new 2D array composed of only 2 values 0 or 1 (0 if the neighboring elements are closed in value, 1 otherwise).<br />
<br />
For each element <math>C</math>, we can compute the quantity <math>|G|</math>:<br />
<br />
<math><br />
|G| = |E-W|+|N-S|<br />
</math><br />
<br />
where <math>|G|</math> can be viewed as an approximation of the magnitude of the gradient.<br />
<br />
If <math>|G|</math> is higher than a threshold value, then an edge is detected (and we store a 1 in the output array).<br />
If <math>|G|</math> is lower than the threshold value, a 0 has to be placed inside the output array.<br />
<br />
* Create a new project.<br />
<br />
* Modify the <syntaxhighlight lang="text" inline>main()</syntaxhighlight> function to declare 2 2D array <syntaxhighlight lang="text" inline>x</syntaxhighlight> and <syntaxhighlight lang="text" inline>y</syntaxhighlight> of size 10x10 where each element is an 8 bits unsigned integer. Initialize the input array <syntaxhighlight lang="text" inline>x</syntaxhighlight> to 0 for the upper triangular part and 100 for the lower triangular part.<br />
<br />
* Add a function <syntaxhighlight lang="text" inline>edge_c()</syntaxhighlight> to compute the values in the output array <syntaxhighlight lang="text" inline>y</syntaxhighlight> (edge detection).<br />
<br />
* Check the result by executing your program and determine the execution time of the C function<br />
<br />
* Add the file <syntaxhighlight lang="text" inline>neon.c</syntaxhighlight> and write the function <syntaxhighlight lang="text" inline>edge_ni()</syntaxhighlight> to realize the edge detection and store the result in the output array.<br />
<br />
* Determine the execution time and the gain obtained using the NEON extension.<br />
<br />
== Linux Application ==<br />
<br />
[[File:Output_c.png|thumb|right|Edge Detection]]<br />
<br />
The objective of this part is to start a Linux distribution on the Zybo development board and to evaluate the performance of our edge detection application on a bitmap image. Several distribution are available to run over Zynq 7000 SoC. Some of them provide a file system only in the RAM. Some others can use the file system from an external flash memory (SD card).<br />
Linaro distribution is a Ubuntu based distribution and provide the same tools than a desktop distribution (graphical user interface). Before doing the following operations, check that the Zybo board is switch off. Also, this exercise can be realize with a [https://en.wikipedia.org/wiki/Raspberry_Pi Raspberry] Pi 2 or 3 ([https://nicolas-barbot.ovh/wiki/pool/rpi.zip <syntaxhighlight lang="text" inline>rpi.zip</syntaxhighlight>]).<br />
<br />
* Insert the SD card in the slot located under the board.<br />
<br />
* Place jumper JP5 on SD position. The board will now start from the SD card.<br />
<br />
* Connect a USB cable between UART and the PC. Connect the USB hub on the OTG connector. <br />
<br />
* Connect the HDMI output to a screen by using an adaptor.<br />
<br />
* Switch on the board. You should see on the UART output, the startup messages of the kernel and finally the root invite.<br />
<br />
* Go inside the \verb+/home/linaro+ directory and modify the existing project to add your edge detection function (add the C version and the NEON version).<br />
<br />
* Build the project with the Makefile.<br />
<br />
* Start the program with the name of a bitmap image as a second argument. The program should generate the image <syntaxhighlight lang="text" inline>output.bmp</syntaxhighlight>.<br />
<br />
* Check the correctness of your program (adapt the threshold value).<br />
<br />
* We wish to analyze the performance of our program with <syntaxhighlight lang="text" inline>gprof</syntaxhighlight>. This tool is able to periodically interrupt the program under test to evaluate the load of each function on the processor. In order to increase the accuracy of the measurement, add a loop to repeat all the process 100 times. Rebuild your program using the <syntaxhighlight lang="text" inline>-pg</syntaxhighlight> option.<br />
<br />
* Execute your newly generated program (with the <syntaxhighlight lang="text" inline>edge_c()</syntaxhighlight> function). Notice that the compilation process generate now a <syntaxhighlight lang="text" inline>gmon.out</syntaxhighlight> file. This file contains the profiling information. Finally execute the following command:<br />
<syntaxhighlight lang="text"><br />
$ gprof test gmon.out > res<br />
</syntaxhighlight><br />
<br />
* Open the <syntaxhighlight lang="text" inline>res</syntaxhighlight> file in an editor to see the results.<br />
<br />
* Replace the <syntaxhighlight lang="text" inline>edge_c()</syntaxhighlight> function with the <syntaxhighlight lang="text" inline>edge_ni()</syntaxhighlight> function and profile the program again.<br />
<br />
* If you have enough time, replace the functions <syntaxhighlight lang="text" inline>color2gray_c()</syntaxhighlight> and <syntaxhighlight lang="text" inline>gray2color_c()</syntaxhighlight> by new functions using the NEON engine.<br />
<br />
== Conclusion ==<br />
<br />
At the end of these labs, you should now be able to develop, build, and optimize an application using the NEON engine present in Cortex-A processors.<br />
<br />
==References==<br />
<br />
<references /></div>Nicohttps://nicolas-barbot.ovh/wiki/index.php?title=CE515_Advanced_Processor_Architecture_and_SoC_Design&diff=465CE515 Advanced Processor Architecture and SoC Design2021-10-04T16:54:44Z<p>Nico: </p>
<hr />
<div>This course is separated into 2 parts. The first one deals will SoC design and programming and is supervised by David Hély. The second one is focused on the SIMD extension present inside ARM architecture. The goal of this lab is implement and develop algorithms (functions) optimized for the NEON extension included in the architecture ARMv7-A et ARMv7-R. Slides of the course can be found [https://nicolas-barbot.ovh/wiki/pool/neon_en.pdf here]. This course requires the basic knowledge of a micro-controller architecture and classical C programming. Processing will run over a [https://www.xilinx.com/ Xilinx] [https://www.xilinx.com/products/silicon-devices/soc/zynq-7000.html Zynq 7000] SoC which contain an ARM Cortex A9 MP Core. Performance of the NEON engine will be compared to the performance of classical implementation (C function executed on the ARM core).<br />
<br />
== Introduction ==<br />
<br />
[[File:Zynq.png|thumb|right|Zynq 7000 architecture]]<br />
<br />
A lot of peripherals generate (or accept) data whose the size is smaller than the processor register size (e.g., 16 bits ADC and 32 bits processor.) When the CPU process these data, a single data is used at a time and processor register is not used fully which imply that the efficiency of the system is decreased. SIMD technology uses a single instruction to realize the same operation on multiple data (in the same time) which increase the execution speed.<br />
<br />
NEON extension has been introduced in the ARMv7 architecture. This extension adds a set of registers (64 and 128 bits) and a SIMD instruction set <ref> NEON Programmer's Guide Version 1.0 ([https://nicolas-barbot.ovh/wiki/pool/DEN0018A_neon_programmers_guide.pdf ARM DEN0018A])</ref>. NEON instructions and ARM instructions are processed in the same time. Exact execution time depends on the Cortex used by the SoC <ref> Cortex-A9 NEON Media Processing Engine, Technical Reference Manual ([https://nicolas-barbot.ovh/wiki/pool/DDI0409G_cortex_a9_neon_mpe_r3p0_trm.pdf ARM DDI 0409])</ref> but all NEON instructions can be processed by the NEON engine. Classical instructions (ARM, Thumb, Thumb2) are described in the reference manual <ref> ARM Architecture Reference Manual, ARMv7-A and ARMv7-R edition ([https://nicolas-barbot.ovh/wiki/pool/DDI0406C_C_arm_architecture_reference_manual.pdf ARM DDI 0406])</ref>.<br />
<br />
During this lab, we will use the development board Zybo. This board include a Zynq 7000 System on Chip. This Soc is composed of FPGA and a Cortex A9 MP Core. Each core include one NEON engine. Figure 1 presents the system architecture. The four first exercises evaluate the performance of simple processing algorithms without any operating system (baremetal or standalone). The final exercise use the NEON extension in a Linux environment.<br />
<br />
== Standalone Application ==<br />
<br />
In this first exercise, we will develop, build, and run a simple application on the Zybo board.<br />
<br />
* Download the [https://nicolas-barbot.ovh/wiki/pool/void.zip <syntaxhighlight lang="text" inline>void</syntaxhighlight>] project.<br />
* Extract the project into a new directory on your computer.<br />
* Observe the structure of the project and open the <syntaxhighlight lang="text" inline>main.c</syntaxhighlight> source file in an editor.<br />
<br />
<syntaxhighlight lang="C" line><br />
#include <stdio.h><br />
#include "platform.h"<br />
#include "xil_printf.h"<br />
<br />
<br />
int main()<br />
{<br />
init_platform();<br />
<br />
print("Hello World\n\r");<br />
<br />
cleanup_platform();<br />
return 0;<br />
}<br />
</syntaxhighlight><br />
<br />
<syntaxhighlight lang="C" inline>init_platform()</syntaxhighlight> function is defined in <syntaxhighlight lang="text" inline>platform.c</syntaxhighlight> file and permit to activate cache memory on the Cortex A9 MP Core. This function call is not mandatory. <syntaxhighlight lang="C" inline>printf()</syntaxhighlight> allows to send the argument on the UART of the Zynq 7000. This function also supports the classical formatting of numbers.<br />
<br />
* Open a terminal (<syntaxhighlight inline lang="text">cmd.exe</syntaxhighlight>) and go to your project location (using <syntaxhighlight lang="text" inline>cd</syntaxhighlight>).<br />
<br />
* Execute the following script: <syntaxhighlight lang="text" inline>C:\Xilinx\Vitis\2019.2\settings64.bat</syntaxhighlight>. This script modifies the PATH evironment variable and allows to call the Xilinx tools directly form the command line.<br />
<br />
* Build process is fully automatized using [https://en.wikipedia.org/wiki/Make_(software) <syntaxhighlight lang="text" inline>make</syntaxhighlight>]. Open the <syntaxhighlight lang="text" inline>Makefile</syntaxhighlight> in your editor:<br />
<br />
<syntaxhighlight lang="Makefile" line='line'><br />
CC=arm-none-eabi-gcc<br />
CFLAGS=-mcpu=cortex-a9 -mfpu=vfpv3 -mfloat-abi=hard -c -Wall -I./include<br />
LDFLAGS=-mcpu=cortex-a9 -mfpu=vfpv3 -mfloat-abi=hard -Wl,-build-id=none -specs=Xilinx.spec -Wl,-T -Wl,lscript.ld -Llib<br />
LIBS=-Wl,--start-group,-lxil,-lgcc,-lc,--end-group<br />
<br />
all: main.elf<br />
<br />
main.o: main.c<br />
$(CC) $(CFLAGS) -o main.o main.c<br />
<br />
platform.o: platform.c<br />
$(CC) $(CFLAGS) -o platform.o platform.c<br />
<br />
main.elf: main.o platform.o<br />
$(CC) $(LDFLAGS) -o main.elf main.o platform.o $(LIBS)<br />
<br />
clean:<br />
rm *.o main.elf<br />
</syntaxhighlight><br />
<br />
The four first lines are simple variables. The rest of the file is composed of 4 rules. The first line of each rule defines the name of the target and its associated dependencies. For each rule, <syntaxhighlight lang="text" inline>make</syntaxhighlight> checks the modification date of the dependencies compared to the one of the target. If one of the dependencies has been modified after the target, <syntaxhighlight lang="text" inline>make</syntaxhighlight> run the command(s) located after the first line (and which have to begin by tab).<br />
<br />
* To build the project invoke <syntaxhighlight lang="text" inline>make</syntaxhighlight> at the prompt. You should observe the following output:<br />
<br />
<syntaxhighlight lang="text"><br />
$ make<br />
arm-none-eabi-gcc -c -Wall -I./include -o main.o main.c<br />
arm-none-eabi-gcc -c -Wall -I./include -o platform.o platform.c<br />
arm-none-eabi-gcc -mcpu=cortex-a9 -mfpu=vfpv3 -mfloat-abi=hard -Wl,-build-id=none -specs=Xilinx.spec -Wl,-T -Wl,lscript.ld -Llib -o main.elf main.o platform.o -Wl,--start-group,-lxil,-lgcc,-lc,--end-group<br />
$<br />
</syntaxhighlight><br />
<br />
If the building process is successful, the executable file <syntaxhighlight lang="text" inline>main.elf</syntaxhighlight> is generated. If the process fails, errors located in the source files (or Makefile) have to be corrected.<br />
<br />
* Check that the file <syntaxhighlight lang="text" inline>main.elf</syntaxhighlight> has been generated in your project directory. Note that this file has been built for the ARM architecture and cannot be executed on your computer.<br />
<br />
Until now, we have successfully built our first application. The following steps allow to transfer the executable file into the memory of the Zynq 7000 and to run the program:<br />
<br />
* Before transferring the executable file on the board, check that jumper JP5 is placed on the JTAG position and connect the PROG UART connector to the PC.<br />
Finally, switch on the SW4 switch (LD11 diode should be on).<br />
<br />
* Start the <syntaxhighlight lang="text" inline>xsct</syntaxhighlight> software in a terminal:<br />
<br />
<syntaxhighlight lang="text"><br />
$ xsct<br />
</syntaxhighlight><br />
<br />
* Type the following commands in <syntaxhighlight lang="text" inline>xsct</syntaxhighlight> (one at a time):<br />
<br />
<syntaxhighlight lang="text"><br />
connect -host localhost -port 3121<br />
targets<br />
targets 2<br />
source ps7_init.tcl<br />
ps7_init<br />
dow main.elf<br />
</syntaxhighlight><br />
<br />
The function <syntaxhighlight lang="text" inline>ps7_init()</syntaxhighlight> permits to activate the clock, the memory controller, and the peripherals (UART). This function have to be called before writing to the memory.<br />
<br />
* In another terminal, observe the [https://en.wikipedia.org/wiki/Serial_port serial port] with a terminal (e.g. <syntaxhighlight lang="text" inline>putty</syntaxhighlight> in Windows).<br />
For the link settings Baud rate: 115200, 8 bits data, 1 bit stop, without parity check.<br />
<br />
* In <syntaxhighlight lang="text" inline>xmd</syntaxhighlight>, now type the following commands:<br />
<br />
<syntaxhighlight lang="text"><br />
con<br />
stop<br />
</syntaxhighlight><br />
<br />
and observe the results on the serial port.<br />
<br />
* Validate the correct execution of the program.<br />
<br />
Before continuing with the next exercises, open 3 different terminals: the first one will be used to build the executable file (with cs-make); the second one will be used to transfer the program on the board (with <syntaxhighlight lang="text" inline>xmd</syntaxhighlight>); the last one will be used to observe the results. Note that for the second terminal, a single <syntaxhighlight lang="text" inline>xmd</syntaxhighlight> session can be used to transfer multiple programs and that the start command will automatically detect if a new version of the program is available and transfer it on the board.<br />
<br />
== Timming ==<br />
<br />
Programming using NEON is not straight forward and many implementations can be evaluated. In order to compare the performance in between different possible implementations, timming has to be used to accurately estimate the execution time of a given section of code. The Zynq 7000 provides a real-time timer which can be controlled using the Xilinx library. This timer is incremented at a rate which is 2 time lower that the Cortex A9 clock frequency.<br />
<br />
* Add the header file <syntaxhighlight lang="text" inline>xtime_l.h</syntaxhighlight> to <syntaxhighlight lang="text" inline>main.c</syntaxhighlight> by adding the line:<br />
<br />
<syntaxhighlight lang="C" line='line'><br />
#include <xtime_l.h><br />
</syntaxhighlight><br />
<br />
* In the function main.c, declare a variable of type <syntaxhighlight lang="text" inline>XTime</syntaxhighlight><br />
<br />
* Use the functions <syntaxhighlight lang="text" inline>XTime_SetTime(XTime Xtime)</syntaxhighlight> and <syntaxhighlight lang="text" inline>XTime_GetTime(XTime *Xtime)</syntaxhighlight>, to set or get the value inside the timer. <br />
<br />
* Add a dummy loop in main.c and determine the execution time of the associated processing. Note that the micro-controller frequency can be obtained in the macro <syntaxhighlight lang="text" inline>XPAR_CPU_CORTEXA9_CORE_CLOCK_FREQ_HZ</syntaxhighlight> defined in the file <syntaxhighlight lang="text" inline>xparameters.h</syntaxhighlight>.<br />
<br />
We are now ready to develop our first programs using the NEON engine. In each exercises, we will implement a simple algorithm in C and evaluate the performance in term of execution time. Then, we will implement the same algorithm using NEON instruction and compare the execution time. <br />
<br />
== Sum of an array ==<br />
<br />
* Create a new project by copying the <syntaxhighlight lang="text" inline>void</syntaxhighlight> directory under a different name.<br />
<br />
* Include the file <syntaxhighlight lang="text" inline>stdint.h</syntaxhighlight> which give access to sets of integer types having specified widths.<br />
<br />
* Declare an array of size 2048 where each element is a 16 bits signed integer and initialize the array to a default value.<br />
<br />
* Add a function <syntaxhighlight lang="text" inline>sum_c()</syntaxhighlight> which compute the sum of this array.<br />
<br />
* Determine the execution time of this function (this result will be used as a reference later).<br />
<br />
* Add a new file <syntaxhighlight lang="text" inline>neon.c</syntaxhighlight> to your project and write the function <syntaxhighlight lang="text" inline>sum_ni()</syntaxhighlight> which can compute the sum of the same array using NEON intrinsics.<br />
<br />
* Modify <syntaxhighlight lang="text" inline>Makefile</syntaxhighlight> to add a new rule for the file <syntaxhighlight lang="text" inline>neon.c</syntaxhighlight> (don't forget the options <syntaxhighlight lang="text" inline>-mcpu</syntaxhighlight>, <syntaxhighlight lang="text" inline>-mfloat-abi</syntaxhighlight> and <syntaxhighlight lang="text" inline>-mfpu</syntaxhighlight>). Generate the new executable file and check the correctness of your new function. <br />
<br />
* Determine its execution time and compare to the one obtained using the classical implementation in C. Rebuild your application using different optimization option (<syntaxhighlight lang="text" inline>O1</syntaxhighlight>, <syntaxhighlight lang="text" inline>O2</syntaxhighlight> and <syntaxhighlight lang="text" inline>O3</syntaxhighlight>). <br />
<br />
* Observe the assembly routine generated by the compiler with the command:<br />
<syntaxhighlight lang="text"><br />
$arm-xilinx-eabi-gcc -S neon.c -o neon.s<br />
</syntaxhighlight><br />
Locate the NEON instructions and compare them to the ones in <syntaxhighlight lang="text" inline>neon.c</syntaxhighlight>.<br />
<br />
== Matrix Multiplication ==<br />
<br />
We consider the multiplication of 2 matrices <math>A</math> and <math>B</math> of dimension 4x4 into a third matrix <math>C</math>.<br />
<br />
* Create a new project<br />
<br />
* Write on a piece of paper the expression of each element of <math>c_{i,j}</math><br />
<br />
* Modify the <syntaxhighlight lang="text" inline>main()</syntaxhighlight> function to declare 2 matrix <syntaxhighlight lang="text" inline>A</syntaxhighlight> and <syntaxhighlight lang="text" inline>B</syntaxhighlight> initialized and a matrix <syntaxhighlight lang="text" inline>C</syntaxhighlight> (which is not initialized) of size 4x4 where each element is a float (32 bits).<br />
<br />
* Add a function <syntaxhighlight lang="text" inline>mat_product_c()</syntaxhighlight> to compute the matrix product of <syntaxhighlight lang="text" inline>A</syntaxhighlight> and <syntaxhighlight lang="text" inline>B</syntaxhighlight> and store the result in the <syntaxhighlight lang="text" inline>C</syntaxhighlight> matrix.<br />
<br />
* Validate the result by executing your function and measure the execution time of the C function.<br />
<br />
* Add a file <syntaxhighlight lang="text" inline>neon.c</syntaxhighlight> and write a function <syntaxhighlight lang="text" inline>mat_product_ni()</syntaxhighlight> to realize the matrix multiplication using NEON intrinsics. Check the correctness of your program.<br />
<br />
* Determine the execution time and the gain that we can obtain by using the NEON extension.<br />
<br />
== Edge Detection ==<br />
<br />
[[File:Nsew.png|thumb|right|Element position]]<br />
<br />
The goal of this exercise is to detect a large variation of the value of 2 neighboring elements in a 2D array. We which to store the result in a new 2D array composed of only 2 values 0 or 1 (0 if the neighboring elements are closed in value, 1 otherwise).<br />
<br />
For each element <math>C</math>, we can compute the quantity <math>|G|</math>:<br />
<br />
<math><br />
|G| = |E-W|+|N-S|<br />
</math><br />
<br />
where <math>|G|</math> can be viewed as an approximation of the magnitude of the gradient.<br />
<br />
If <math>|G|</math> is higher than a threshold value, then an edge is detected (and we store a 1 in the output array).<br />
If <math>|G|</math> is lower than the threshold value, a 0 has to be placed inside the output array.<br />
<br />
* Create a new project.<br />
<br />
* Modify the <syntaxhighlight lang="text" inline>main()</syntaxhighlight> function to declare 2 2D array <syntaxhighlight lang="text" inline>x</syntaxhighlight> and <syntaxhighlight lang="text" inline>y</syntaxhighlight> of size 10x10 where each element is an 8 bits unsigned integer. Initialize the input array <syntaxhighlight lang="text" inline>x</syntaxhighlight> to 0 for the upper triangular part and 100 for the lower triangular part.<br />
<br />
* Add a function <syntaxhighlight lang="text" inline>edge_c()</syntaxhighlight> to compute the values in the output array <syntaxhighlight lang="text" inline>y</syntaxhighlight> (edge detection).<br />
<br />
* Check the result by executing your program and determine the execution time of the C function<br />
<br />
* Add the file <syntaxhighlight lang="text" inline>neon.c</syntaxhighlight> and write the function <syntaxhighlight lang="text" inline>edge_ni()</syntaxhighlight> to realize the edge detection and store the result in the output array.<br />
<br />
* Determine the execution time and the gain obtained using the NEON extension.<br />
<br />
== Linux Application ==<br />
<br />
[[File:Output_c.png|thumb|right|Edge Detection]]<br />
<br />
The objective of this part is to start a Linux distribution on the Zybo development board and to evaluate the performance of our edge detection application on a bitmap image. Several distribution are available to run over Zynq 7000 SoC. Some of them provide a file system only in the RAM. Some others can use the file system from an external flash memory (SD card).<br />
Linaro distribution is a Ubuntu based distribution and provide the same tools than a desktop distribution (graphical user interface). Before doing the following operations, check that the Zybo board is switch off. Also, this exercise can be realize with a [https://en.wikipedia.org/wiki/Raspberry_Pi Raspberry] Pi 2 or 3 ([https://nicolas-barbot.ovh/wiki/pool/rpi.zip <syntaxhighlight lang="text" inline>rpi.zip</syntaxhighlight>]).<br />
<br />
* Insert the SD card in the slot located under the board.<br />
<br />
* Place jumper JP5 on SD position. The board will now start from the SD card.<br />
<br />
* Connect a USB cable between UART and the PC. Connect the USB hub on the OTG connector. <br />
<br />
* Connect the HDMI output to a screen by using an adaptor.<br />
<br />
* Switch on the board. You should see on the UART output, the startup messages of the kernel and finally the root invite.<br />
<br />
* Go inside the \verb+/home/linaro+ directory and modify the existing project to add your edge detection function (add the C version and the NEON version).<br />
<br />
* Build the project with the Makefile.<br />
<br />
* Start the program with the name of a bitmap image as a second argument. The program should generate the image <syntaxhighlight lang="text" inline>output.bmp</syntaxhighlight>.<br />
<br />
* Check the correctness of your program (adapt the threshold value).<br />
<br />
* We wish to analyze the performance of our program with <syntaxhighlight lang="text" inline>gprof</syntaxhighlight>. This tool is able to periodically interrupt the program under test to evaluate the load of each function on the processor. In order to increase the accuracy of the measurement, add a loop to repeat all the process 100 times. Rebuild your program using the <syntaxhighlight lang="text" inline>-pg</syntaxhighlight> option.<br />
<br />
* Execute your newly generated program (with the <syntaxhighlight lang="text" inline>edge_c()</syntaxhighlight> function). Notice that the compilation process generate now a <syntaxhighlight lang="text" inline>gmon.out</syntaxhighlight> file. This file contains the profiling information. Finally execute the following command:<br />
<syntaxhighlight lang="text"><br />
$ gprof test gmon.out > res<br />
</syntaxhighlight><br />
<br />
* Open the <syntaxhighlight lang="text" inline>res</syntaxhighlight> file in an editor to see the results.<br />
<br />
* Replace the <syntaxhighlight lang="text" inline>edge_c()</syntaxhighlight> function with the <syntaxhighlight lang="text" inline>edge_ni()</syntaxhighlight> function and profile the program again.<br />
<br />
* If you have enough time, replace the functions <syntaxhighlight lang="text" inline>color2gray_c()</syntaxhighlight> and <syntaxhighlight lang="text" inline>gray2color_c()</syntaxhighlight> by new functions using the NEON engine.<br />
<br />
== Conclusion ==<br />
<br />
At the end of these labs, you should now be able to develop, build, and optimize an application using the NEON engine present in Cortex-A processors.<br />
<br />
==References==<br />
<br />
<references /></div>Nicohttps://nicolas-barbot.ovh/wiki/index.php?title=CE515_Advanced_Processor_Architecture_and_SoC_Design&diff=464CE515 Advanced Processor Architecture and SoC Design2021-10-04T16:37:04Z<p>Nico: </p>
<hr />
<div>This course is separated into 2 parts. The first one deals will SoC design and programming and is supervised by David Hély. The second one is focused on the SIMD extension present inside ARM architecture. The goal of this lab is implement and develop algorithms (functions) optimized for the NEON extension included in the architecture ARMv7-A et ARMv7-R. Slides of the course can be found [https://nicolas-barbot.ovh/wiki/pool/neon_en.pdf here]. This course requires the basic knowledge of a micro-controller architecture and classical C programming. Processing will run over a [https://www.xilinx.com/ Xilinx] [https://www.xilinx.com/products/silicon-devices/soc/zynq-7000.html Zynq 7000] SoC which contain an ARM Cortex A9 MP Core. Performance of the NEON engine will be compared to the performance of classical implementation (C function executed on the ARM core).<br />
<br />
== Introduction ==<br />
<br />
[[File:Zynq.png|thumb|right|Zynq 7000 architecture]]<br />
<br />
A lot of peripherals generate (or accept) data whose the size is smaller than the processor register size (e.g., 16 bits ADC and 32 bits processor.) When the CPU process these data, a single data is used at a time and processor register is not used fully which imply that the efficiency of the system is decreased. SIMD technology uses a single instruction to realize the same operation on multiple data (in the same time) which increase the execution speed.<br />
<br />
NEON extension has been introduced in the ARMv7 architecture. This extension adds a set of registers (64 and 128 bits) and a SIMD instruction set <ref> NEON Programmer's Guide Version 1.0 ([https://nicolas-barbot.ovh/wiki/pool/DEN0018A_neon_programmers_guide.pdf ARM DEN0018A])</ref>. NEON instructions and ARM instructions are processed in the same time. Exact execution time depends on the Cortex used by the SoC <ref> Cortex-A9 NEON Media Processing Engine, Technical Reference Manual ([https://nicolas-barbot.ovh/wiki/pool/DDI0409G_cortex_a9_neon_mpe_r3p0_trm.pdf ARM DDI 0409])</ref> but all NEON instructions can be processed by the NEON engine. Classical instructions (ARM, Thumb, Thumb2) are described in the reference manual <ref> ARM Architecture Reference Manual, ARMv7-A and ARMv7-R edition ([https://nicolas-barbot.ovh/wiki/pool/DDI0406C_C_arm_architecture_reference_manual.pdf ARM DDI 0406])</ref>.<br />
<br />
During this lab, we will use the development board Zybo. This board include a Zynq 7000 System on Chip. This Soc is composed of FPGA and a Cortex A9 MP Core. Each core include one NEON engine. Figure 1 presents the system architecture. The four first exercises evaluate the performance of simple processing algorithms without any operating system (baremetal or standalone). The final exercise use the NEON extension in a Linux environment.<br />
<br />
== Standalone Application ==<br />
<br />
In this first exercise, we will develop, build, and run a simple application on the Zybo board.<br />
<br />
* Download the [https://nicolas-barbot.ovh/wiki/pool/void.zip <syntaxhighlight lang="text" inline>void</syntaxhighlight>] project.<br />
* Extract the project into a new directory on your computer.<br />
* Observe the structure of the project and open the <syntaxhighlight lang="text" inline>main.c</syntaxhighlight> source file in an editor.<br />
<br />
<syntaxhighlight lang="C" line><br />
#include <stdio.h><br />
#include "platform.h"<br />
#include "xil_printf.h"<br />
<br />
<br />
int main()<br />
{<br />
init_platform();<br />
<br />
print("Hello World\n\r");<br />
<br />
cleanup_platform();<br />
return 0;<br />
}<br />
</syntaxhighlight><br />
<br />
<syntaxhighlight lang="C" inline>init_platform()</syntaxhighlight> function is defined in <syntaxhighlight lang="text" inline>platform.c</syntaxhighlight> file and permit to activate cache memory on the Cortex A9 MP Core. This function call is not mandatory. <syntaxhighlight lang="C" inline>printf()</syntaxhighlight> allows to send the argument on the UART of the Zynq 7000. This function also supports the classical formatting of numbers.<br />
<br />
* Open a terminal (<syntaxhighlight inline lang="text">cmd.exe</syntaxhighlight>) and go to your project location (using <syntaxhighlight lang="text" inline>cd</syntaxhighlight>).<br />
<br />
* Execute the following script: <syntaxhighlight lang="text" inline>C:\Xilinx\Vitis\2019.2\settings64.bat</syntaxhighlight>. This script modifies the PATH evironment variable and allows to call the Xilinx tools directly form the command line.<br />
<br />
* Build process is fully automatized using [https://en.wikipedia.org/wiki/Make_(software) <syntaxhighlight lang="text" inline>make</syntaxhighlight>]. Open the <syntaxhighlight lang="text" inline>Makefile</syntaxhighlight> in your editor:<br />
<br />
<syntaxhighlight lang="Makefile" line='line'><br />
CC=arm-none-eabi-gcc<br />
CFLAGS=-mcpu=cortex-a9 -mfpu=vfpv3 -mfloat-abi=hard -c -Wall -I./include<br />
LDFLAGS=-mcpu=cortex-a9 -mfpu=vfpv3 -mfloat-abi=hard -Wl,-build-id=none -specs=Xilinx.spec -Wl,-T -Wl,lscript.ld -Llib<br />
LIBS=-Wl,--start-group,-lxil,-lgcc,-lc,--end-group<br />
<br />
all: main.elf<br />
<br />
main.o: main.c<br />
$(CC) $(CFLAGS) -o main.o main.c<br />
<br />
platform.o: platform.c<br />
$(CC) $(CFLAGS) -o platform.o platform.c<br />
<br />
main.elf: main.o platform.o<br />
$(CC) $(LDFLAGS) -o main.elf main.o platform.o $(LIBS)<br />
<br />
clean:<br />
rm *.o main.elf<br />
</syntaxhighlight><br />
<br />
The four first lines are simple variables. The rest of the file is composed of 4 rules. The first line of each rule defines the name of the target and its associated dependencies. For each rule, <syntaxhighlight lang="text" inline>make</syntaxhighlight> checks the modification date of the dependencies compared to the one of the target. If one of the dependencies has been modified after the target, <syntaxhighlight lang="text" inline>make</syntaxhighlight> run the command(s) located after the first line (and which have to begin by tab).<br />
<br />
* To build the project invoke <syntaxhighlight lang="text" inline>make</syntaxhighlight> at the prompt. You should observe the following output:<br />
<br />
<syntaxhighlight lang="text"><br />
$ make<br />
arm-xilinx-eabi-gcc -c -Wall -I./include -o main.o main.c<br />
arm-xilinx-eabi-gcc -Wl,-T -Wl,lscript.ld -L./lib -o main.elf main.o platform.o -Wl,--start-group,-lxil,-lgcc,-lc,--end-group<br />
$<br />
</syntaxhighlight><br />
<br />
If the building process is successful, the executable file <syntaxhighlight lang="text" inline>main.elf</syntaxhighlight> is generated. If the process fails, errors located in the source files (or Makefile) have to be corrected.<br />
<br />
* Check that the file <syntaxhighlight lang="text" inline>main.elf</syntaxhighlight> has been generated in your project directory. Note that this file has been built for the ARM architecture and cannot be executed on your computer.<br />
<br />
Until now, we have successfully built our first application. The following steps allow to transfer the executable file into the memory of the Zynq 7000 and to run the program:<br />
<br />
* Before transferring the executable file on the board, check that jumper JP5 is placed on the JTAG position and connect the PROG UART connector to the PC.<br />
Finally, switch on the SW4 switch (LD11 diode should be on).<br />
<br />
* Start the <syntaxhighlight lang="text" inline>xsct</syntaxhighlight> software in a terminal:<br />
<br />
<syntaxhighlight lang="text"><br />
$ xsct<br />
</syntaxhighlight><br />
<br />
* Type the following commands in xsct (one at a time):<br />
<br />
<syntaxhighlight lang="text"><br />
connect -host localhost -port 3121<br />
targets<br />
targets 2<br />
source ps7_init.tcl<br />
ps7_init<br />
dow main.elf<br />
</syntaxhighlight><br />
<br />
The function <syntaxhighlight lang="text" inline>ps7_init()</syntaxhighlight> permits to activate the clock, the memory controller, and the peripherals (UART).<br />
<br />
* In another terminal, observe the [https://en.wikipedia.org/wiki/Serial_port serial port] with a terminal (e.g. <syntaxhighlight lang="text" inline>putty</syntaxhighlight> in Windows).<br />
For the link settings Baud rate: 115200, 8 bits data, 1 bit stop, without parity check.<br />
<br />
* In <syntaxhighlight lang="text" inline>xmd</syntaxhighlight>, now type the following commands:<br />
<br />
<syntaxhighlight lang="text"><br />
con<br />
stop<br />
</syntaxhighlight><br />
<br />
and observe the results on the serial port.<br />
<br />
* Validate the correct execution of the program.<br />
<br />
Before continuing with the next exercises, open 3 different terminals: the first one will be used to build the executable file (with cs-make); the second one will be used to transfer the program on the board (with <syntaxhighlight lang="text" inline>xmd</syntaxhighlight>); the last one will be used to observe the results. Note that for the second terminal, a single <syntaxhighlight lang="text" inline>xmd</syntaxhighlight> session can be used to transfer multiple programs and that the start command will automatically detect if a new version of the program is available and transfer it on the board.<br />
<br />
== Timming ==<br />
<br />
Programming using NEON is not straight forward and many implementations can be evaluated. In order to compare the performance in between different possible implementations, timming has to be used to accurately estimate the execution time of a given section of code. The Zynq 7000 provides a real-time timer which can be controlled using the Xilinx library. This timer is incremented at a rate which is 2 time lower that the Cortex A9 clock frequency.<br />
<br />
* Add the header file <syntaxhighlight lang="text" inline>xtime_l.h</syntaxhighlight> to <syntaxhighlight lang="text" inline>main.c</syntaxhighlight> by adding the line:<br />
<br />
<syntaxhighlight lang="C" line='line'><br />
#include <xtime_l.h><br />
</syntaxhighlight><br />
<br />
* In the function main.c, declare a variable of type <syntaxhighlight lang="text" inline>XTime</syntaxhighlight><br />
<br />
* Use the functions <syntaxhighlight lang="text" inline>XTime_SetTime(XTime Xtime)</syntaxhighlight> and <syntaxhighlight lang="text" inline>XTime_GetTime(XTime *Xtime)</syntaxhighlight>, to set or get the value inside the timer. <br />
<br />
* Add a dummy loop in main.c and determine the execution time of the associated processing. Note that the micro-controller frequency can be obtained in the macro <syntaxhighlight lang="text" inline>XPAR_CPU_CORTEXA9_CORE_CLOCK_FREQ_HZ</syntaxhighlight> defined in the file <syntaxhighlight lang="text" inline>xparameters.h</syntaxhighlight>.<br />
<br />
We are now ready to develop our first programs using the NEON engine. In each exercises, we will implement a simple algorithm in C and evaluate the performance in term of execution time. Then, we will implement the same algorithm using NEON instruction and compare the execution time. <br />
<br />
== Sum of an array ==<br />
<br />
* Create a new project by copying the <syntaxhighlight lang="text" inline>void</syntaxhighlight> directory under a different name.<br />
<br />
* Include the file <syntaxhighlight lang="text" inline>stdint.h</syntaxhighlight> which give access to sets of integer types having specified widths.<br />
<br />
* Declare an array of size 2048 where each element is a 16 bits signed integer and initialize the array to a default value.<br />
<br />
* Add a function <syntaxhighlight lang="text" inline>sum_c()</syntaxhighlight> which compute the sum of this array.<br />
<br />
* Determine the execution time of this function (this result will be used as a reference later).<br />
<br />
* Add a new file <syntaxhighlight lang="text" inline>neon.c</syntaxhighlight> to your project and write the function <syntaxhighlight lang="text" inline>sum_ni()</syntaxhighlight> which can compute the sum of the same array using NEON intrinsics.<br />
<br />
* Modify <syntaxhighlight lang="text" inline>Makefile</syntaxhighlight> to add a new rule for the file <syntaxhighlight lang="text" inline>neon.c</syntaxhighlight> (don't forget the options <syntaxhighlight lang="text" inline>-mcpu</syntaxhighlight>, <syntaxhighlight lang="text" inline>-mfloat-abi</syntaxhighlight> and <syntaxhighlight lang="text" inline>-mfpu</syntaxhighlight>). Generate the new executable file and check the correctness of your new function. <br />
<br />
* Determine its execution time and compare to the one obtained using the classical implementation in C. Rebuild your application using different optimization option (<syntaxhighlight lang="text" inline>O1</syntaxhighlight>, <syntaxhighlight lang="text" inline>O2</syntaxhighlight> and <syntaxhighlight lang="text" inline>O3</syntaxhighlight>). <br />
<br />
* Observe the assembly routine generated by the compiler with the command:<br />
<syntaxhighlight lang="text"><br />
$arm-xilinx-eabi-gcc -S neon.c -o neon.s<br />
</syntaxhighlight><br />
Locate the NEON instructions and compare them to the ones in <syntaxhighlight lang="text" inline>neon.c</syntaxhighlight>.<br />
<br />
== Matrix Multiplication ==<br />
<br />
We consider the multiplication of 2 matrices <math>A</math> and <math>B</math> of dimension 4x4 into a third matrix <math>C</math>.<br />
<br />
* Create a new project<br />
<br />
* Write on a piece of paper the expression of each element of <math>c_{i,j}</math><br />
<br />
* Modify the <syntaxhighlight lang="text" inline>main()</syntaxhighlight> function to declare 2 matrix <syntaxhighlight lang="text" inline>A</syntaxhighlight> and <syntaxhighlight lang="text" inline>B</syntaxhighlight> initialized and a matrix <syntaxhighlight lang="text" inline>C</syntaxhighlight> (which is not initialized) of size 4x4 where each element is a float (32 bits).<br />
<br />
* Add a function <syntaxhighlight lang="text" inline>mat_product_c()</syntaxhighlight> to compute the matrix product of <syntaxhighlight lang="text" inline>A</syntaxhighlight> and <syntaxhighlight lang="text" inline>B</syntaxhighlight> and store the result in the <syntaxhighlight lang="text" inline>C</syntaxhighlight> matrix.<br />
<br />
* Validate the result by executing your function and measure the execution time of the C function.<br />
<br />
* Add a file <syntaxhighlight lang="text" inline>neon.c</syntaxhighlight> and write a function <syntaxhighlight lang="text" inline>mat_product_ni()</syntaxhighlight> to realize the matrix multiplication using NEON intrinsics. Check the correctness of your program.<br />
<br />
* Determine the execution time and the gain that we can obtain by using the NEON extension.<br />
<br />
== Edge Detection ==<br />
<br />
[[File:Nsew.png|thumb|right|Element position]]<br />
<br />
The goal of this exercise is to detect a large variation of the value of 2 neighboring elements in a 2D array. We which to store the result in a new 2D array composed of only 2 values 0 or 1 (0 if the neighboring elements are closed in value, 1 otherwise).<br />
<br />
For each element <math>C</math>, we can compute the quantity <math>|G|</math>:<br />
<br />
<math><br />
|G| = |E-W|+|N-S|<br />
</math><br />
<br />
where <math>|G|</math> can be viewed as an approximation of the magnitude of the gradient.<br />
<br />
If <math>|G|</math> is higher than a threshold value, then an edge is detected (and we store a 1 in the output array).<br />
If <math>|G|</math> is lower than the threshold value, a 0 has to be placed inside the output array.<br />
<br />
* Create a new project.<br />
<br />
* Modify the <syntaxhighlight lang="text" inline>main()</syntaxhighlight> function to declare 2 2D array <syntaxhighlight lang="text" inline>x</syntaxhighlight> and <syntaxhighlight lang="text" inline>y</syntaxhighlight> of size 10x10 where each element is an 8 bits unsigned integer. Initialize the input array <syntaxhighlight lang="text" inline>x</syntaxhighlight> to 0 for the upper triangular part and 100 for the lower triangular part.<br />
<br />
* Add a function <syntaxhighlight lang="text" inline>edge_c()</syntaxhighlight> to compute the values in the output array <syntaxhighlight lang="text" inline>y</syntaxhighlight> (edge detection).<br />
<br />
* Check the result by executing your program and determine the execution time of the C function<br />
<br />
* Add the file <syntaxhighlight lang="text" inline>neon.c</syntaxhighlight> and write the function <syntaxhighlight lang="text" inline>edge_ni()</syntaxhighlight> to realize the edge detection and store the result in the output array.<br />
<br />
* Determine the execution time and the gain obtained using the NEON extension.<br />
<br />
== Linux Application ==<br />
<br />
[[File:Output_c.png|thumb|right|Edge Detection]]<br />
<br />
The objective of this part is to start a Linux distribution on the Zybo development board and to evaluate the performance of our edge detection application on a bitmap image. Several distribution are available to run over Zynq 7000 SoC. Some of them provide a file system only in the RAM. Some others can use the file system from an external flash memory (SD card).<br />
Linaro distribution is a Ubuntu based distribution and provide the same tools than a desktop distribution (graphical user interface). Before doing the following operations, check that the Zybo board is switch off. Also, this exercise can be realize with a [https://en.wikipedia.org/wiki/Raspberry_Pi Raspberry] Pi 2 or 3 ([https://nicolas-barbot.ovh/wiki/pool/rpi.zip <syntaxhighlight lang="text" inline>rpi.zip</syntaxhighlight>]).<br />
<br />
* Insert the SD card in the slot located under the board.<br />
<br />
* Place jumper JP5 on SD position. The board will now start from the SD card.<br />
<br />
* Connect a USB cable between UART and the PC. Connect the USB hub on the OTG connector. <br />
<br />
* Connect the HDMI output to a screen by using an adaptor.<br />
<br />
* Switch on the board. You should see on the UART output, the startup messages of the kernel and finally the root invite.<br />
<br />
* Go inside the \verb+/home/linaro+ directory and modify the existing project to add your edge detection function (add the C version and the NEON version).<br />
<br />
* Build the project with the Makefile.<br />
<br />
* Start the program with the name of a bitmap image as a second argument. The program should generate the image <syntaxhighlight lang="text" inline>output.bmp</syntaxhighlight>.<br />
<br />
* Check the correctness of your program (adapt the threshold value).<br />
<br />
* We wish to analyze the performance of our program with <syntaxhighlight lang="text" inline>gprof</syntaxhighlight>. This tool is able to periodically interrupt the program under test to evaluate the load of each function on the processor. In order to increase the accuracy of the measurement, add a loop to repeat all the process 100 times. Rebuild your program using the <syntaxhighlight lang="text" inline>-pg</syntaxhighlight> option.<br />
<br />
* Execute your newly generated program (with the <syntaxhighlight lang="text" inline>edge_c()</syntaxhighlight> function). Notice that the compilation process generate now a <syntaxhighlight lang="text" inline>gmon.out</syntaxhighlight> file. This file contains the profiling information. Finally execute the following command:<br />
<syntaxhighlight lang="text"><br />
$ gprof test gmon.out > res<br />
</syntaxhighlight><br />
<br />
* Open the <syntaxhighlight lang="text" inline>res</syntaxhighlight> file in an editor to see the results.<br />
<br />
* Replace the <syntaxhighlight lang="text" inline>edge_c()</syntaxhighlight> function with the <syntaxhighlight lang="text" inline>edge_ni()</syntaxhighlight> function and profile the program again.<br />
<br />
* If you have enough time, replace the functions <syntaxhighlight lang="text" inline>color2gray_c()</syntaxhighlight> and <syntaxhighlight lang="text" inline>gray2color_c()</syntaxhighlight> by new functions using the NEON engine.<br />
<br />
== Conclusion ==<br />
<br />
At the end of these labs, you should now be able to develop, build, and optimize an application using the NEON engine present in Cortex-A processors.<br />
<br />
==References==<br />
<br />
<references /></div>Nicohttps://nicolas-barbot.ovh/wiki/index.php?title=CE515_Advanced_Processor_Architecture_and_SoC_Design&diff=463CE515 Advanced Processor Architecture and SoC Design2021-10-04T16:28:33Z<p>Nico: </p>
<hr />
<div>This course is separated into 2 parts. The first one deals will SoC design and programming and is supervised by David Hély. The second one is focused on the SIMD extension present inside ARM architecture. The goal of this lab is implement and develop algorithms (functions) optimized for the NEON extension included in the architecture ARMv7-A et ARMv7-R. Slides of the course can be found [https://nicolas-barbot.ovh/wiki/pool/neon_en.pdf here]. This course requires the basic knowledge of a micro-controller architecture and classical C programming. Processing will run over a [https://www.xilinx.com/ Xilinx] [https://www.xilinx.com/products/silicon-devices/soc/zynq-7000.html Zynq 7000] SoC which contain an ARM Cortex A9 MP Core. Performance of the NEON engine will be compared to the performance of classical implementation (C function executed on the ARM core).<br />
<br />
== Introduction ==<br />
<br />
[[File:Zynq.png|thumb|right|Zynq 7000 architecture]]<br />
<br />
A lot of peripherals generate (or accept) data whose the size is smaller than the processor register size (e.g., 16 bits ADC and 32 bits processor.) When the CPU process these data, a single data is used at a time and processor register is not used fully which imply that the efficiency of the system is decreased. SIMD technology uses a single instruction to realize the same operation on multiple data (in the same time) which increase the execution speed.<br />
<br />
NEON extension has been introduced in the ARMv7 architecture. This extension adds a set of registers (64 and 128 bits) and a SIMD instruction set <ref> NEON Programmer's Guide Version 1.0 ([https://nicolas-barbot.ovh/wiki/pool/DEN0018A_neon_programmers_guide.pdf ARM DEN0018A])</ref>. NEON instructions and ARM instructions are processed in the same time. Exact execution time depends on the Cortex used by the SoC <ref> Cortex-A9 NEON Media Processing Engine, Technical Reference Manual ([https://nicolas-barbot.ovh/wiki/pool/DDI0409G_cortex_a9_neon_mpe_r3p0_trm.pdf ARM DDI 0409])</ref> but all NEON instructions can be processed by the NEON engine. Classical instructions (ARM, Thumb, Thumb2) are described in the reference manual <ref> ARM Architecture Reference Manual, ARMv7-A and ARMv7-R edition ([https://nicolas-barbot.ovh/wiki/pool/DDI0406C_C_arm_architecture_reference_manual.pdf ARM DDI 0406])</ref>.<br />
<br />
During this lab, we will use the development board Zybo. This board include a Zynq 7000 System on Chip. This Soc is composed of FPGA and a Cortex A9 MP Core. Each core include one NEON engine. Figure 1 presents the system architecture. The four first exercises evaluate the performance of simple processing algorithms without any operating system (baremetal or standalone). The final exercise use the NEON extension in a Linux environment.<br />
<br />
== Standalone Application ==<br />
<br />
In this first exercise, we will develop, build, and run a simple application on the Zybo board.<br />
<br />
* Download the [https://nicolas-barbot.ovh/wiki/pool/void.zip <syntaxhighlight lang="text" inline>void</syntaxhighlight>] project.<br />
* Extract the project into a new directory on your computer.<br />
* Observe the structure of the project and open the <syntaxhighlight lang="text" inline>main.c</syntaxhighlight> source file in an editor.<br />
<br />
<syntaxhighlight lang="C" line><br />
#include <stdio.h><br />
#include "platform.h"<br />
<br />
int main()<br />
{ <br />
init_platform();<br />
<br />
printf("Hello world");<br />
<br />
return 0;<br />
}<br />
</syntaxhighlight><br />
<br />
<syntaxhighlight lang="C" inline>init_platform()</syntaxhighlight> function is defined in <syntaxhighlight lang="text" inline>platform.c</syntaxhighlight> file and permit to activate cache memory on the Cortex A9 MP Core. This function call is not mandatory. <syntaxhighlight lang="C" inline>printf()</syntaxhighlight> allows to send the argument on the UART of the Zynq 7000. This function also supports the classical formatting of numbers.<br />
<br />
* Open a terminal (<syntaxhighlight inline lang="text">cmd.exe</syntaxhighlight>) and go to your project location (using <syntaxhighlight lang="text" inline>cd</syntaxhighlight>).<br />
<br />
* Execute the following script: <syntaxhighlight lang="text" inline>C:\Xilinx\Vitis\2019.2\settings64.bat</syntaxhighlight>. This script modifies the PATH evironment variable and allows to call the Xilinx tools directly form the command line.<br />
<br />
* Build process is fully automatized using [https://en.wikipedia.org/wiki/Make_(software) <syntaxhighlight lang="text" inline>make</syntaxhighlight>]. Open the <syntaxhighlight lang="text" inline>Makefile</syntaxhighlight> in your editor:<br />
<br />
<syntaxhighlight lang="Makefile" line='line'><br />
CC=arm-xilinx-eabi-gcc<br />
CFLAGS=-c -Wall -I./include<br />
LDFLAGS=-Wl,-T -Wl,lscript.ld -L./lib<br />
LIBS=-Wl,--start-group,-lxil,-lgcc,-lc,--end-group<br />
<br />
all: main.elf<br />
<br />
<br />
main.o: main.c<br />
$(CC) $(CFLAGS) -o main.o main.c<br />
<br />
platform.o: platform.c<br />
$(CC) $(CFLAGS) -o platform.o platform.c<br />
<br />
main.elf: main.o platform.o<br />
$(CC) $(LDFLAGS) -o main.elf main.o platform.o $(LIBS)<br />
<br />
clean:<br />
rm *.o main.elf<br />
</syntaxhighlight><br />
<br />
The four first lines are simple variables. The rest of the file is composed of 4 rules. The first line of each rule defines the name of the target and its associated dependencies. For each rule, <syntaxhighlight lang="text" inline>make</syntaxhighlight> checks the modification date of the dependencies compared to the one of the target. If one of the dependencies has been modified after the target, <syntaxhighlight lang="text" inline>make</syntaxhighlight> run the command(s) located after the first line (and which have to begin by tab).<br />
<br />
* To build the project invoke <syntaxhighlight lang="text" inline>make</syntaxhighlight> at the prompt. You should observe the following output:<br />
<br />
<syntaxhighlight lang="text"><br />
$ make<br />
arm-xilinx-eabi-gcc -c -Wall -I./include -o main.o main.c<br />
arm-xilinx-eabi-gcc -Wl,-T -Wl,lscript.ld -L./lib -o main.elf main.o platform.o -Wl,--start-group,-lxil,-lgcc,-lc,--end-group<br />
$<br />
</syntaxhighlight><br />
<br />
If the building process is successful, the executable file <syntaxhighlight lang="text" inline>main.elf</syntaxhighlight> is generated. If the process fails, errors located in the source files (or Makefile) have to be corrected.<br />
<br />
* Check that the file <syntaxhighlight lang="text" inline>main.elf</syntaxhighlight> has been generated in your project directory. Note that this file has been built for the ARM architecture and cannot be executed on your computer.<br />
<br />
Until now, we have successfully built our first application. The following steps allow to transfer the executable file into the memory of the Zynq 7000 and to run the program:<br />
<br />
* Before transferring the executable file on the board, check that jumper JP5 is placed on the JTAG position and connect the PROG UART connector to the PC.<br />
Finally, switch on the SW4 switch (LD11 diode should be on).<br />
<br />
* Start the <syntaxhighlight lang="text" inline>xsct</syntaxhighlight> software in a terminal:<br />
<br />
<syntaxhighlight lang="text"><br />
$ xsct<br />
</syntaxhighlight><br />
<br />
* Type the following commands in xsct (one at a time):<br />
<br />
<syntaxhighlight lang="text"><br />
connect -host localhost -port 3121<br />
targets<br />
targets 2<br />
source ps7_init.tcl<br />
ps7_init<br />
dow main.elf<br />
</syntaxhighlight><br />
<br />
The function <syntaxhighlight lang="text" inline>ps7_init()</syntaxhighlight> permits to activate the clock, the memory controller, and the peripherals (UART).<br />
<br />
* In another terminal, observe the [https://en.wikipedia.org/wiki/Serial_port serial port] with a terminal (e.g. <syntaxhighlight lang="text" inline>putty</syntaxhighlight> in Windows).<br />
For the link settings Baud rate: 115200, 8 bits data, 1 bit stop, without parity check.<br />
<br />
* In <syntaxhighlight lang="text" inline>xmd</syntaxhighlight>, now type the following commands:<br />
<br />
<syntaxhighlight lang="text"><br />
con<br />
stop<br />
</syntaxhighlight><br />
<br />
and observe the results on the serial port.<br />
<br />
* Validate the correct execution of the program.<br />
<br />
Before continuing with the next exercises, open 3 different terminals: the first one will be used to build the executable file (with cs-make); the second one will be used to transfer the program on the board (with <syntaxhighlight lang="text" inline>xmd</syntaxhighlight>); the last one will be used to observe the results. Note that for the second terminal, a single <syntaxhighlight lang="text" inline>xmd</syntaxhighlight> session can be used to transfer multiple programs and that the start command will automatically detect if a new version of the program is available and transfer it on the board.<br />
<br />
== Timming ==<br />
<br />
Programming using NEON is not straight forward and many implementations can be evaluated. In order to compare the performance in between different possible implementations, timming has to be used to accurately estimate the execution time of a given section of code. The Zynq 7000 provides a real-time timer which can be controlled using the Xilinx library. This timer is incremented at a rate which is 2 time lower that the Cortex A9 clock frequency.<br />
<br />
* Add the header file <syntaxhighlight lang="text" inline>xtime_l.h</syntaxhighlight> to <syntaxhighlight lang="text" inline>main.c</syntaxhighlight> by adding the line:<br />
<br />
<syntaxhighlight lang="C" line='line'><br />
#include <xtime_l.h><br />
</syntaxhighlight><br />
<br />
* In the function main.c, declare a variable of type <syntaxhighlight lang="text" inline>XTime</syntaxhighlight><br />
<br />
* Use the functions <syntaxhighlight lang="text" inline>XTime_SetTime(XTime Xtime)</syntaxhighlight> and <syntaxhighlight lang="text" inline>XTime_GetTime(XTime *Xtime)</syntaxhighlight>, to set or get the value inside the timer. <br />
<br />
* Add a dummy loop in main.c and determine the execution time of the associated processing. Note that the micro-controller frequency can be obtained in the macro <syntaxhighlight lang="text" inline>XPAR_CPU_CORTEXA9_CORE_CLOCK_FREQ_HZ</syntaxhighlight> defined in the file <syntaxhighlight lang="text" inline>xparameters.h</syntaxhighlight>.<br />
<br />
We are now ready to develop our first programs using the NEON engine. In each exercises, we will implement a simple algorithm in C and evaluate the performance in term of execution time. Then, we will implement the same algorithm using NEON instruction and compare the execution time. <br />
<br />
== Sum of an array ==<br />
<br />
* Create a new project by copying the <syntaxhighlight lang="text" inline>void</syntaxhighlight> directory under a different name.<br />
<br />
* Include the file <syntaxhighlight lang="text" inline>stdint.h</syntaxhighlight> which give access to sets of integer types having specified widths.<br />
<br />
* Declare an array of size 2048 where each element is a 16 bits signed integer and initialize the array to a default value.<br />
<br />
* Add a function <syntaxhighlight lang="text" inline>sum_c()</syntaxhighlight> which compute the sum of this array.<br />
<br />
* Determine the execution time of this function (this result will be used as a reference later).<br />
<br />
* Add a new file <syntaxhighlight lang="text" inline>neon.c</syntaxhighlight> to your project and write the function <syntaxhighlight lang="text" inline>sum_ni()</syntaxhighlight> which can compute the sum of the same array using NEON intrinsics.<br />
<br />
* Modify <syntaxhighlight lang="text" inline>Makefile</syntaxhighlight> to add a new rule for the file <syntaxhighlight lang="text" inline>neon.c</syntaxhighlight> (don't forget the options <syntaxhighlight lang="text" inline>-mcpu</syntaxhighlight>, <syntaxhighlight lang="text" inline>-mfloat-abi</syntaxhighlight> and <syntaxhighlight lang="text" inline>-mfpu</syntaxhighlight>). Generate the new executable file and check the correctness of your new function. <br />
<br />
* Determine its execution time and compare to the one obtained using the classical implementation in C. Rebuild your application using different optimization option (<syntaxhighlight lang="text" inline>O1</syntaxhighlight>, <syntaxhighlight lang="text" inline>O2</syntaxhighlight> and <syntaxhighlight lang="text" inline>O3</syntaxhighlight>). <br />
<br />
* Observe the assembly routine generated by the compiler with the command:<br />
<syntaxhighlight lang="text"><br />
$arm-xilinx-eabi-gcc -S neon.c -o neon.s<br />
</syntaxhighlight><br />
Locate the NEON instructions and compare them to the ones in <syntaxhighlight lang="text" inline>neon.c</syntaxhighlight>.<br />
<br />
== Matrix Multiplication ==<br />
<br />
We consider the multiplication of 2 matrices <math>A</math> and <math>B</math> of dimension 4x4 into a third matrix <math>C</math>.<br />
<br />
* Create a new project<br />
<br />
* Write on a piece of paper the expression of each element of <math>c_{i,j}</math><br />
<br />
* Modify the <syntaxhighlight lang="text" inline>main()</syntaxhighlight> function to declare 2 matrix <syntaxhighlight lang="text" inline>A</syntaxhighlight> and <syntaxhighlight lang="text" inline>B</syntaxhighlight> initialized and a matrix <syntaxhighlight lang="text" inline>C</syntaxhighlight> (which is not initialized) of size 4x4 where each element is a float (32 bits).<br />
<br />
* Add a function <syntaxhighlight lang="text" inline>mat_product_c()</syntaxhighlight> to compute the matrix product of <syntaxhighlight lang="text" inline>A</syntaxhighlight> and <syntaxhighlight lang="text" inline>B</syntaxhighlight> and store the result in the <syntaxhighlight lang="text" inline>C</syntaxhighlight> matrix.<br />
<br />
* Validate the result by executing your function and measure the execution time of the C function.<br />
<br />
* Add a file <syntaxhighlight lang="text" inline>neon.c</syntaxhighlight> and write a function <syntaxhighlight lang="text" inline>mat_product_ni()</syntaxhighlight> to realize the matrix multiplication using NEON intrinsics. Check the correctness of your program.<br />
<br />
* Determine the execution time and the gain that we can obtain by using the NEON extension.<br />
<br />
== Edge Detection ==<br />
<br />
[[File:Nsew.png|thumb|right|Element position]]<br />
<br />
The goal of this exercise is to detect a large variation of the value of 2 neighboring elements in a 2D array. We which to store the result in a new 2D array composed of only 2 values 0 or 1 (0 if the neighboring elements are closed in value, 1 otherwise).<br />
<br />
For each element <math>C</math>, we can compute the quantity <math>|G|</math>:<br />
<br />
<math><br />
|G| = |E-W|+|N-S|<br />
</math><br />
<br />
where <math>|G|</math> can be viewed as an approximation of the magnitude of the gradient.<br />
<br />
If <math>|G|</math> is higher than a threshold value, then an edge is detected (and we store a 1 in the output array).<br />
If <math>|G|</math> is lower than the threshold value, a 0 has to be placed inside the output array.<br />
<br />
* Create a new project.<br />
<br />
* Modify the <syntaxhighlight lang="text" inline>main()</syntaxhighlight> function to declare 2 2D array <syntaxhighlight lang="text" inline>x</syntaxhighlight> and <syntaxhighlight lang="text" inline>y</syntaxhighlight> of size 10x10 where each element is an 8 bits unsigned integer. Initialize the input array <syntaxhighlight lang="text" inline>x</syntaxhighlight> to 0 for the upper triangular part and 100 for the lower triangular part.<br />
<br />
* Add a function <syntaxhighlight lang="text" inline>edge_c()</syntaxhighlight> to compute the values in the output array <syntaxhighlight lang="text" inline>y</syntaxhighlight> (edge detection).<br />
<br />
* Check the result by executing your program and determine the execution time of the C function<br />
<br />
* Add the file <syntaxhighlight lang="text" inline>neon.c</syntaxhighlight> and write the function <syntaxhighlight lang="text" inline>edge_ni()</syntaxhighlight> to realize the edge detection and store the result in the output array.<br />
<br />
* Determine the execution time and the gain obtained using the NEON extension.<br />
<br />
== Linux Application ==<br />
<br />
[[File:Output_c.png|thumb|right|Edge Detection]]<br />
<br />
The objective of this part is to start a Linux distribution on the Zybo development board and to evaluate the performance of our edge detection application on a bitmap image. Several distribution are available to run over Zynq 7000 SoC. Some of them provide a file system only in the RAM. Some others can use the file system from an external flash memory (SD card).<br />
Linaro distribution is a Ubuntu based distribution and provide the same tools than a desktop distribution (graphical user interface). Before doing the following operations, check that the Zybo board is switch off. Also, this exercise can be realize with a [https://en.wikipedia.org/wiki/Raspberry_Pi Raspberry] Pi 2 or 3 ([https://nicolas-barbot.ovh/wiki/pool/rpi.zip <syntaxhighlight lang="text" inline>rpi.zip</syntaxhighlight>]).<br />
<br />
* Insert the SD card in the slot located under the board.<br />
<br />
* Place jumper JP5 on SD position. The board will now start from the SD card.<br />
<br />
* Connect a USB cable between UART and the PC. Connect the USB hub on the OTG connector. <br />
<br />
* Connect the HDMI output to a screen by using an adaptor.<br />
<br />
* Switch on the board. You should see on the UART output, the startup messages of the kernel and finally the root invite.<br />
<br />
* Go inside the \verb+/home/linaro+ directory and modify the existing project to add your edge detection function (add the C version and the NEON version).<br />
<br />
* Build the project with the Makefile.<br />
<br />
* Start the program with the name of a bitmap image as a second argument. The program should generate the image <syntaxhighlight lang="text" inline>output.bmp</syntaxhighlight>.<br />
<br />
* Check the correctness of your program (adapt the threshold value).<br />
<br />
* We wish to analyze the performance of our program with <syntaxhighlight lang="text" inline>gprof</syntaxhighlight>. This tool is able to periodically interrupt the program under test to evaluate the load of each function on the processor. In order to increase the accuracy of the measurement, add a loop to repeat all the process 100 times. Rebuild your program using the <syntaxhighlight lang="text" inline>-pg</syntaxhighlight> option.<br />
<br />
* Execute your newly generated program (with the <syntaxhighlight lang="text" inline>edge_c()</syntaxhighlight> function). Notice that the compilation process generate now a <syntaxhighlight lang="text" inline>gmon.out</syntaxhighlight> file. This file contains the profiling information. Finally execute the following command:<br />
<syntaxhighlight lang="text"><br />
$ gprof test gmon.out > res<br />
</syntaxhighlight><br />
<br />
* Open the <syntaxhighlight lang="text" inline>res</syntaxhighlight> file in an editor to see the results.<br />
<br />
* Replace the <syntaxhighlight lang="text" inline>edge_c()</syntaxhighlight> function with the <syntaxhighlight lang="text" inline>edge_ni()</syntaxhighlight> function and profile the program again.<br />
<br />
* If you have enough time, replace the functions <syntaxhighlight lang="text" inline>color2gray_c()</syntaxhighlight> and <syntaxhighlight lang="text" inline>gray2color_c()</syntaxhighlight> by new functions using the NEON engine.<br />
<br />
== Conclusion ==<br />
<br />
At the end of these labs, you should now be able to develop, build, and optimize an application using the NEON engine present in Cortex-A processors.<br />
<br />
==References==<br />
<br />
<references /></div>Nicohttps://nicolas-barbot.ovh/wiki/index.php?title=CE515_Advanced_Processor_Architecture_and_SoC_Design&diff=462CE515 Advanced Processor Architecture and SoC Design2021-10-04T13:59:45Z<p>Nico: </p>
<hr />
<div>This course is separated into 2 parts. The first one deals will SoC design and programming and is supervised by David Hély. The second one is focused on the SIMD extension present inside ARM architecture. The goal of this lab is implement and develop algorithms (functions) optimized for the NEON extension included in the architecture ARMv7-A et ARMv7-R. Slides of the course can be found [https://nicolas-barbot.ovh/wiki/pool/neon_en.pdf here]. This course requires the basic knowledge of a micro-controller architecture and classical C programming. Processing will run over a [https://www.xilinx.com/ Xilinx] [https://www.xilinx.com/products/silicon-devices/soc/zynq-7000.html Zynq 7000] SoC which contain an ARM Cortex A9 MP Core. Performance of the NEON engine will be compared to the performance of classical implementation (C function executed on the ARM core).<br />
<br />
== Introduction ==<br />
<br />
[[File:Zynq.png|thumb|right|Zynq 7000 architecture]]<br />
<br />
A lot of peripherals generate (or accept) data whose the size is smaller than the processor register size (e.g., 16 bits ADC and 32 bits processor.) When the CPU process these data, a single data is used at a time and processor register is not used fully which imply that the efficiency of the system is decreased. SIMD technology uses a single instruction to realize the same operation on multiple data (in the same time) which increase the execution speed.<br />
<br />
NEON extension has been introduced in the ARMv7 architecture. This extension adds a set of registers (64 and 128 bits) and a SIMD instruction set <ref> NEON Programmer's Guide Version 1.0 ([https://nicolas-barbot.ovh/wiki/pool/DEN0018A_neon_programmers_guide.pdf ARM DEN0018A])</ref>. NEON instructions and ARM instructions are processed in the same time. Exact execution time depends on the Cortex used by the SoC <ref> Cortex-A9 NEON Media Processing Engine, Technical Reference Manual ([https://nicolas-barbot.ovh/wiki/pool/DDI0409G_cortex_a9_neon_mpe_r3p0_trm.pdf ARM DDI 0409])</ref> but all NEON instructions can be processed by the NEON engine. Classical instructions (ARM, Thumb, Thumb2) are described in the reference manual <ref> ARM Architecture Reference Manual, ARMv7-A and ARMv7-R edition ([https://nicolas-barbot.ovh/wiki/pool/DDI0406C_C_arm_architecture_reference_manual.pdf ARM DDI 0406])</ref>.<br />
<br />
During this lab, we will use the development board Zybo. This board include a Zynq 7000 System on Chip. This Soc is composed of FPGA and a Cortex A9 MP Core. Each core include one NEON engine. Figure 1 presents the system architecture. The four first exercises evaluate the performance of simple processing algorithms without any operating system (baremetal or standalone). The final exercise use the NEON extension in a Linux environment.<br />
<br />
== Standalone Application ==<br />
<br />
In this first exercise, we will develop, build, and run a simple application on the Zybo board.<br />
<br />
* Download the [https://nicolas-barbot.ovh/wiki/pool/void.zip <syntaxhighlight lang="text" inline>void</syntaxhighlight>] project.<br />
* Extract the project into a new directory on your computer.<br />
* Observe the structure of the project and open the <syntaxhighlight lang="text" inline>main.c</syntaxhighlight> source file in an editor.<br />
<br />
<syntaxhighlight lang="C" line><br />
#include <stdio.h><br />
#include "platform.h"<br />
<br />
int main()<br />
{ <br />
init_platform();<br />
<br />
printf("Hello world");<br />
<br />
return 0;<br />
}<br />
</syntaxhighlight><br />
<br />
<syntaxhighlight lang="C" inline>init_platform()</syntaxhighlight> function is defined in <syntaxhighlight lang="text" inline>platform.c</syntaxhighlight> file and permit to activate cache memory on the Cortex A9 MP Core. This function call is not mandatory. <syntaxhighlight lang="C" inline>printf()</syntaxhighlight> allows to send the argument on the UART of the Zynq 7000. This function also supports the classical formatting of numbers.<br />
<br />
* Open a terminal (<syntaxhighlight inline lang="text">cmd.exe</syntaxhighlight>) and go to your project location (using <syntaxhighlight lang="text" inline>cd</syntaxhighlight>).<br />
<br />
* Execute the following script: <syntaxhighlight lang="text" inline>C:\Xilinx\Vitis\2019.2\settings64.bat</syntaxhighlight>. This script modifies the PATH evironment variable and allows to call the Xilinx tools directly form the command line.<br />
<br />
* Build process is fully automatized using [https://en.wikipedia.org/wiki/Make_(software) <syntaxhighlight lang="text" inline>make</syntaxhighlight>]. Open the <syntaxhighlight lang="text" inline>Makefile</syntaxhighlight> in your editor:<br />
<br />
<syntaxhighlight lang="Makefile" line='line'><br />
CC=arm-xilinx-eabi-gcc<br />
CFLAGS=-c -Wall -I./include<br />
LDFLAGS=-Wl,-T -Wl,lscript.ld -L./lib<br />
LIBS=-Wl,--start-group,-lxil,-lgcc,-lc,--end-group<br />
<br />
all: main.elf<br />
<br />
<br />
main.o: main.c<br />
$(CC) $(CFLAGS) -o main.o main.c<br />
<br />
platform.o: platform.c<br />
$(CC) $(CFLAGS) -o platform.o platform.c<br />
<br />
main.elf: main.o platform.o<br />
$(CC) $(LDFLAGS) -o main.elf main.o platform.o $(LIBS)<br />
<br />
clean:<br />
rm *.o main.elf<br />
</syntaxhighlight><br />
<br />
The four first lines are simple variables. The rest of the file is composed of 4 rules. The first line of each rule defines the name of the target and its associated dependencies. For each rule, <syntaxhighlight lang="text" inline>make</syntaxhighlight> checks the modification date of the dependencies compared to the one of the target. If one of the dependencies has been modified after the target, <syntaxhighlight lang="text" inline>make</syntaxhighlight> run the command(s) located after the first line (and which have to begin by tab).<br />
<br />
* To build the project invoke <syntaxhighlight lang="text" inline>cs-make</syntaxhighlight> at the prompt. You should observe the following output:<br />
<br />
<syntaxhighlight lang="text"><br />
$ cs-make<br />
arm-xilinx-eabi-gcc -c -Wall -I./include -o main.o main.c<br />
arm-xilinx-eabi-gcc -Wl,-T -Wl,lscript.ld -L./lib -o main.elf main.o platform.o -Wl,--start-group,-lxil,-lgcc,-lc,--end-group<br />
$<br />
</syntaxhighlight><br />
<br />
If the building process is successful, the executable file <syntaxhighlight lang="text" inline>main.elf</syntaxhighlight> is generated. If the process fails, errors located in the source files (or Makefile) have to be corrected.<br />
<br />
* Check that the file <syntaxhighlight lang="text" inline>main.elf</syntaxhighlight> has been generated in your project directory. Note that this file has been built for the ARM architecture and cannot be executed on your computer.<br />
<br />
Until now, we have successfully built our first application. The following steps allow to transfer the executable file into the memory of the Zynq 7000 and to run the program:<br />
<br />
* Before transferring the executable file on the board, check that jumper JP5 is placed on the JTAG position and connect the PROG UART connector to the PC.<br />
Finally, switch on the SW4 switch (LD11 diode should be on).<br />
<br />
* Start the <syntaxhighlight lang="text" inline>xmd</syntaxhighlight> software in a terminal:<br />
<br />
<syntaxhighlight lang="text"><br />
$ xmd<br />
</syntaxhighlight><br />
<br />
* Type the following commands in xmd:<br />
<br />
<syntaxhighlight lang="text"><br />
connect arm hw<br />
source ps7_init.tcl<br />
ps7_init<br />
dow main.elf<br />
</syntaxhighlight><br />
<br />
The function <syntaxhighlight lang="text" inline>ps7_init()</syntaxhighlight> permits to activate the clock, the memory controller, and the peripherals (UART).<br />
<br />
* In another terminal, observe the [https://en.wikipedia.org/wiki/Serial_port serial port] with a terminal (e.g. <syntaxhighlight lang="text" inline>putty</syntaxhighlight> in Windows).<br />
For the link settings Baud rate: 115200, 8 bits data, 1 bit stop, without parity check.<br />
<br />
* In <syntaxhighlight lang="text" inline>xmd</syntaxhighlight>, now type the following commands:<br />
<br />
<syntaxhighlight lang="text"><br />
start<br />
stop<br />
</syntaxhighlight><br />
<br />
and observe the results on the serial port.<br />
<br />
* Validate the correct execution of the program.<br />
<br />
Before continuing with the next exercises, open 3 different terminals: the first one will be used to build the executable file (with cs-make); the second one will be used to transfer the program on the board (with <syntaxhighlight lang="text" inline>xmd</syntaxhighlight>); the last one will be used to observe the results. Note that for the second terminal, a single <syntaxhighlight lang="text" inline>xmd</syntaxhighlight> session can be used to transfer multiple programs and that the start command will automatically detect if a new version of the program is available and transfer it on the board.<br />
<br />
== Timming ==<br />
<br />
Programming using NEON is not straight forward and many implementations can be evaluated. In order to compare the performance in between different possible implementations, timming has to be used to accurately estimate the execution time of a given section of code. The Zynq 7000 provides a real-time timer which can be controlled using the Xilinx library. This timer is incremented at a rate which is 2 time lower that the Cortex A9 clock frequency.<br />
<br />
* Add the header file <syntaxhighlight lang="text" inline>xtime_l.h</syntaxhighlight> to <syntaxhighlight lang="text" inline>main.c</syntaxhighlight> by adding the line:<br />
<br />
<syntaxhighlight lang="C" line='line'><br />
#include <xtime_l.h><br />
</syntaxhighlight><br />
<br />
* In the function main.c, declare a variable of type <syntaxhighlight lang="text" inline>XTime</syntaxhighlight><br />
<br />
* Use the functions <syntaxhighlight lang="text" inline>XTime_SetTime(XTime Xtime)</syntaxhighlight> and <syntaxhighlight lang="text" inline>XTime_GetTime(XTime *Xtime)</syntaxhighlight>, to set or get the value inside the timer. <br />
<br />
* Add a dummy loop in main.c and determine the execution time of the associated processing. Note that the micro-controller frequency can be obtained in the macro <syntaxhighlight lang="text" inline>XPAR_CPU_CORTEXA9_CORE_CLOCK_FREQ_HZ</syntaxhighlight> defined in the file <syntaxhighlight lang="text" inline>xparameters.h</syntaxhighlight>.<br />
<br />
We are now ready to develop our first programs using the NEON engine. In each exercises, we will implement a simple algorithm in C and evaluate the performance in term of execution time. Then, we will implement the same algorithm using NEON instruction and compare the execution time. <br />
<br />
== Sum of an array ==<br />
<br />
* Create a new project by copying the <syntaxhighlight lang="text" inline>void</syntaxhighlight> directory under a different name.<br />
<br />
* Include the file <syntaxhighlight lang="text" inline>stdint.h</syntaxhighlight> which give access to sets of integer types having specified widths.<br />
<br />
* Declare an array of size 2048 where each element is a 16 bits signed integer and initialize the array to a default value.<br />
<br />
* Add a function <syntaxhighlight lang="text" inline>sum_c()</syntaxhighlight> which compute the sum of this array.<br />
<br />
* Determine the execution time of this function (this result will be used as a reference later).<br />
<br />
* Add a new file <syntaxhighlight lang="text" inline>neon.c</syntaxhighlight> to your project and write the function <syntaxhighlight lang="text" inline>sum_ni()</syntaxhighlight> which can compute the sum of the same array using NEON intrinsics.<br />
<br />
* Modify <syntaxhighlight lang="text" inline>Makefile</syntaxhighlight> to add a new rule for the file <syntaxhighlight lang="text" inline>neon.c</syntaxhighlight> (don't forget the options <syntaxhighlight lang="text" inline>-mcpu</syntaxhighlight>, <syntaxhighlight lang="text" inline>-mfloat-abi</syntaxhighlight> and <syntaxhighlight lang="text" inline>-mfpu</syntaxhighlight>). Generate the new executable file and check the correctness of your new function. <br />
<br />
* Determine its execution time and compare to the one obtained using the classical implementation in C. Rebuild your application using different optimization option (<syntaxhighlight lang="text" inline>O1</syntaxhighlight>, <syntaxhighlight lang="text" inline>O2</syntaxhighlight> and <syntaxhighlight lang="text" inline>O3</syntaxhighlight>). <br />
<br />
* Observe the assembly routine generated by the compiler with the command:<br />
<syntaxhighlight lang="text"><br />
$arm-xilinx-eabi-gcc -S neon.c -o neon.s<br />
</syntaxhighlight><br />
Locate the NEON instructions and compare them to the ones in <syntaxhighlight lang="text" inline>neon.c</syntaxhighlight>.<br />
<br />
== Matrix Multiplication ==<br />
<br />
We consider the multiplication of 2 matrices <math>A</math> and <math>B</math> of dimension 4x4 into a third matrix <math>C</math>.<br />
<br />
* Create a new project<br />
<br />
* Write on a piece of paper the expression of each element of <math>c_{i,j}</math><br />
<br />
* Modify the <syntaxhighlight lang="text" inline>main()</syntaxhighlight> function to declare 2 matrix <syntaxhighlight lang="text" inline>A</syntaxhighlight> and <syntaxhighlight lang="text" inline>B</syntaxhighlight> initialized and a matrix <syntaxhighlight lang="text" inline>C</syntaxhighlight> (which is not initialized) of size 4x4 where each element is a float (32 bits).<br />
<br />
* Add a function <syntaxhighlight lang="text" inline>mat_product_c()</syntaxhighlight> to compute the matrix product of <syntaxhighlight lang="text" inline>A</syntaxhighlight> and <syntaxhighlight lang="text" inline>B</syntaxhighlight> and store the result in the <syntaxhighlight lang="text" inline>C</syntaxhighlight> matrix.<br />
<br />
* Validate the result by executing your function and measure the execution time of the C function.<br />
<br />
* Add a file <syntaxhighlight lang="text" inline>neon.c</syntaxhighlight> and write a function <syntaxhighlight lang="text" inline>mat_product_ni()</syntaxhighlight> to realize the matrix multiplication using NEON intrinsics. Check the correctness of your program.<br />
<br />
* Determine the execution time and the gain that we can obtain by using the NEON extension.<br />
<br />
== Edge Detection ==<br />
<br />
[[File:Nsew.png|thumb|right|Element position]]<br />
<br />
The goal of this exercise is to detect a large variation of the value of 2 neighboring elements in a 2D array. We which to store the result in a new 2D array composed of only 2 values 0 or 1 (0 if the neighboring elements are closed in value, 1 otherwise).<br />
<br />
For each element <math>C</math>, we can compute the quantity <math>|G|</math>:<br />
<br />
<math><br />
|G| = |E-W|+|N-S|<br />
</math><br />
<br />
where <math>|G|</math> can be viewed as an approximation of the magnitude of the gradient.<br />
<br />
If <math>|G|</math> is higher than a threshold value, then an edge is detected (and we store a 1 in the output array).<br />
If <math>|G|</math> is lower than the threshold value, a 0 has to be placed inside the output array.<br />
<br />
* Create a new project.<br />
<br />
* Modify the <syntaxhighlight lang="text" inline>main()</syntaxhighlight> function to declare 2 2D array <syntaxhighlight lang="text" inline>x</syntaxhighlight> and <syntaxhighlight lang="text" inline>y</syntaxhighlight> of size 10x10 where each element is an 8 bits unsigned integer. Initialize the input array <syntaxhighlight lang="text" inline>x</syntaxhighlight> to 0 for the upper triangular part and 100 for the lower triangular part.<br />
<br />
* Add a function <syntaxhighlight lang="text" inline>edge_c()</syntaxhighlight> to compute the values in the output array <syntaxhighlight lang="text" inline>y</syntaxhighlight> (edge detection).<br />
<br />
* Check the result by executing your program and determine the execution time of the C function<br />
<br />
* Add the file <syntaxhighlight lang="text" inline>neon.c</syntaxhighlight> and write the function <syntaxhighlight lang="text" inline>edge_ni()</syntaxhighlight> to realize the edge detection and store the result in the output array.<br />
<br />
* Determine the execution time and the gain obtained using the NEON extension.<br />
<br />
== Linux Application ==<br />
<br />
[[File:Output_c.png|thumb|right|Edge Detection]]<br />
<br />
The objective of this part is to start a Linux distribution on the Zybo development board and to evaluate the performance of our edge detection application on a bitmap image. Several distribution are available to run over Zynq 7000 SoC. Some of them provide a file system only in the RAM. Some others can use the file system from an external flash memory (SD card).<br />
Linaro distribution is a Ubuntu based distribution and provide the same tools than a desktop distribution (graphical user interface). Before doing the following operations, check that the Zybo board is switch off. Also, this exercise can be realize with a [https://en.wikipedia.org/wiki/Raspberry_Pi Raspberry] Pi 2 or 3 ([https://nicolas-barbot.ovh/wiki/pool/rpi.zip <syntaxhighlight lang="text" inline>rpi.zip</syntaxhighlight>]).<br />
<br />
* Insert the SD card in the slot located under the board.<br />
<br />
* Place jumper JP5 on SD position. The board will now start from the SD card.<br />
<br />
* Connect a USB cable between UART and the PC. Connect the USB hub on the OTG connector. <br />
<br />
* Connect the HDMI output to a screen by using an adaptor.<br />
<br />
* Switch on the board. You should see on the UART output, the startup messages of the kernel and finally the root invite.<br />
<br />
* Go inside the \verb+/home/linaro+ directory and modify the existing project to add your edge detection function (add the C version and the NEON version).<br />
<br />
* Build the project with the Makefile.<br />
<br />
* Start the program with the name of a bitmap image as a second argument. The program should generate the image <syntaxhighlight lang="text" inline>output.bmp</syntaxhighlight>.<br />
<br />
* Check the correctness of your program (adapt the threshold value).<br />
<br />
* We wish to analyze the performance of our program with <syntaxhighlight lang="text" inline>gprof</syntaxhighlight>. This tool is able to periodically interrupt the program under test to evaluate the load of each function on the processor. In order to increase the accuracy of the measurement, add a loop to repeat all the process 100 times. Rebuild your program using the <syntaxhighlight lang="text" inline>-pg</syntaxhighlight> option.<br />
<br />
* Execute your newly generated program (with the <syntaxhighlight lang="text" inline>edge_c()</syntaxhighlight> function). Notice that the compilation process generate now a <syntaxhighlight lang="text" inline>gmon.out</syntaxhighlight> file. This file contains the profiling information. Finally execute the following command:<br />
<syntaxhighlight lang="text"><br />
$ gprof test gmon.out > res<br />
</syntaxhighlight><br />
<br />
* Open the <syntaxhighlight lang="text" inline>res</syntaxhighlight> file in an editor to see the results.<br />
<br />
* Replace the <syntaxhighlight lang="text" inline>edge_c()</syntaxhighlight> function with the <syntaxhighlight lang="text" inline>edge_ni()</syntaxhighlight> function and profile the program again.<br />
<br />
* If you have enough time, replace the functions <syntaxhighlight lang="text" inline>color2gray_c()</syntaxhighlight> and <syntaxhighlight lang="text" inline>gray2color_c()</syntaxhighlight> by new functions using the NEON engine.<br />
<br />
== Conclusion ==<br />
<br />
At the end of these labs, you should now be able to develop, build, and optimize an application using the NEON engine present in Cortex-A processors.<br />
<br />
==References==<br />
<br />
<references /></div>Nicohttps://nicolas-barbot.ovh/wiki/index.php?title=Nicolas_Barbot&diff=461Nicolas Barbot2021-10-03T14:46:28Z<p>Nico: </p>
<hr />
<div>{{Infobox person<br />
| name = Nicolas Barbot<br />
| image = File:NBarbot.jpg<br />
| image_size = 220px<br />
| nationality = French<br />
| birth_date = {{Birth date and age|1986|08|11}}<br />
| birth_place = Limoges, France<br />
}}<br />
<br />
'''Nicolas Barbot''' received the M.Sc. degree and Ph.D. degree from the University de Limoges, France. His Ph.D. work in [https://www.xlim.fr/ Xlim] Laboratory was focused on error-correcting codes for the optical wireless channel. He also realized a post-doctoral work in joint source-channel decoding at [https://l2s.centralesupelec.fr/ L2S] Laboratory, in Gif-sur-Yvette, France. Since September 2014, he has been an Assistant Professor at the Université Grenoble Alpes - Grenoble Institute of Technology, in Valence, France. His scientific background at [https://lcis.grenoble-inp.fr/ LCIS] Laboratory covers wireless communications systems based on backscattering principle which include classical RFID and chipless RFID.<br />
<br />
His research interest include transponders which can not be described by linear time-invariant systems. This gathers harmonic transponders which are based on the use of a non-linear component (Schottky diode) or linear time-variant transponders which are based on the modification of their response in the time domain.<br />
He also places special interests on antenna design and instrumentation based on these phenomenons.<br />
<br />
==Education==<br />
<br />
{| class="wikitable" style="text-align: left;width: 80%;"<br />
|-<br />
!Period<br />
!Postion/Diploma<br />
|-<br />
|2014–2021<br />
|align=left|Assistant Professor at Grenoble INP - Esisar, LCIS, Valence, France<br />
|-<br />
|2013–2014<br />
|align=left|Post-Doc at Laboratoire des Signaux et Systèmes (L2S), ''Cross-Layer Design of Wireless Tranceivers'', Gif-sur-Yvette, France<br />
|-<br />
|2010–2013<br />
|align=left|PhD Thesis, Xlim CNRS UMR 7252, ''Channel Coding for Optical Wireless Communications'', Limoges, France<br />
|-<br />
|2009–2010<br />
|align=left|Master Degree, Faculté des Sciences, ''Technologies Hyperfréquences, Électronique et Optique'', Limoges, France<br />
|-<br />
|2007–2010<br />
|align=left|Diplome d'ingénieur, École Nationale Supérieure d’Ingénieurs de Limoges, Électronique et Télécommunications, Limoges, France<br />
|-<br />
|2005–2007<br />
|align=left|DUT Mesures Physiques, IUT du Limousin, Limoges, France<br />
|}<br />
<br />
==Teaching ==<br />
<br />
{| class="wikitable" style="text-align: left;width: 80%;"<br />
|-<br />
!Courses<br />
!Full name<br />
!Grade<br />
!ECTS<br />
|-<br />
|[[CE515 Advanced Processor Architecture and SoC Design|CE515]]<br />
|align=left|Advanced Processor Architecture and SoC Design<br />
|5A<br />
|4<br />
|-<br />
|[[PX505 Innovation Project|PX505]]<br />
|align=left|Innovation Project<br />
|5A<br />
|4<br />
|-<br />
|[[AC469 Introduction to statistical signal processing|AC469]]<br />
|align=left|Introduction to statistical signal processing<br />
|4App<br />
|1.5<br />
|-<br />
|[[SC311 Wireless Communications|SC311]]<br />
|align=left|Wireless Communications<br />
|3A<br />
|2.5<br />
|-<br />
|[[MA331 Information Theory and Channel Coding|MA331]]<br />
|align=left|Information Theory and Channel Coding<br />
|3A<br />
|3<br />
|-<br />
|[[PX302 Introduction to STM32 micro-controllers|PX302]]<br />
|align=left|Introduction to STM32 micro-controllers<br />
|3A<br />
|3<br />
|-<br />
|[[PX212 Mini-Project|PX212]]<br />
|align=left|Mini-Project<br />
|2A<br />
|6<br />
|}<br />
<br />
==Research Activities==<br />
<br />
In the first part of my career, my research activities have been focused on chipless RFID.<br />
This technology allows to reduce the cost of the tags since information can be embedded and transmitted to the reader<br />
without using a silicon chip. However, since these tags are Linear Time-Invariant (LTI) systems<br />
<ref>N. Barbot, O. Rance, and E. Perret, [https://nicolas-barbot.ovh/wiki/pool/range.pdf "Classical RFID vs. chipless RFID read range: Is linearity a friend or a foe?,"]<br />
IEEE Transactions on Microwave Theory and Techniques, pp. 1–1, 2021, early access. doi: 10.1109/TMTT.2021.3077019.</ref>, their backscattered power<br />
are also located in the same bandwidth as the one used by the reader making the reading difficult in non-free space environments.<br />
Consequently, significant limitations appears in term of read range, coding capacity and media access control for any chipless tag.<br />
In order to break these limitations, my research investigations now cover:<br />
* non-linear (or harmonic) transponders which can backscatter a power at <math>n f_0</math>. These transponders are base on a non-linear component (typically a Schottky diode).<br />
* linear time-variant transponders which can backscatter a power around <math>f_0</math> <ref>N. Barbot and E. Perret, [https://nicolas-barbot.ovh/wiki/pool/nl.pdf "Linear time-variant chipless RFID sensor,"] IEEE Journal of Radio Frequency Identification, submitted.</ref>. These transponders can modulate the backscattered signal (classical UHF tags, micro-Doppler or more generally any moving scatterers).<br />
<br />
In these two cases, the tags cannot be described by LTI systems and are not bounded by the previous limitations. They<br />
are also characterized by a non zero delta RCS <math>\sigma_d</math><ref>N. Barbot, O. Rance, and E. Perret, [https://nicolas-barbot.ovh/wiki/pool/delta.pdf "Differential RCS of modulated tag,"] IEEE Transactions on Antennas and Propagation, pp. 1–1, 2021, early access. doi: 10.1109/TAP.2021.3060943.</ref>.<br />
<br />
Additional details can be found [[Research Activities|here]].<br />
<br />
PhD students:<br />
* '''Ashkan Azarfar''', "Détection de tags sans puce basée sur l'effet Doppler pour les applications de reconnaissance de gestes," Directeur: Etienne Perret, Co-directeur: Nicolas Barbot.<br />
<br />
* '''Florian Requena''', "Conception de tags RIFD sans puce, robustes, pour applications capteur," Directeur: Etienne Perret, Co-directeur: Darine Kaddour, Nicolas Barbot.<br />
<br />
* '''Raymundo de Amorim Junior''', "Tags sans puce millimétriques pour applications sécurisées," Directeur: Etienne Perret, Co-directeur: Romain Siragusa, Nicolas Barbot.<br />
<br />
* '''Rahul Unnikrishnan''', "Reconnaissance de gestes avec des tags chipless," Directeur: Etienne Perret, Co-directeur: Nicolas Barbot.<br />
<br />
* '''Raphael Tavares de Alencar''', "Contribution à la conception et la réalisation de tags RFID sans puce compatibles avec des procédés industriels de fabrication," Directeur: Etienne Perret, Co-directeur: Marco Garbati, Nicolas Barbot.<br />
<br />
* '''Florent Bonnefoy''', "Authentification dans le domaine THz," Directeur: Frédéric Garet, Co-directeur: Maxime Bernier, Nicolas Barbot.<br />
<br />
See the complete [[List of Publications]].<br />
<br />
==CV==<br />
<br />
[https://nicolas-barbot.ovh/wiki/pool/cv_en.pdf English Version]<br />
<br />
[https://nicolas-barbot.ovh/wiki/pool/cv.pdf French Version]<br />
<br />
==References==<br />
<br />
<references/><br />
<br />
==External links==<br />
[https://scholar.google.com/citations?user=mMhPOZYAAAAJ&hl=en&oi=ao Google Scholar]<br />
<br />
[https://orcid.org/0000-0001-6355-9109 ORCID ID]</div>Nicohttps://nicolas-barbot.ovh/wiki/index.php?title=List_of_Publications&diff=460List of Publications2021-08-31T19:58:49Z<p>Nico: </p>
<hr />
<div>__FORCETOC__<br />
<br />
==Journal Articles==<br />
<br />
*R. Unnikrishnan, O. Rance, N. Barbot, and E. Perret, “Chipless RFID Label with Identification and Touch-Sensing Capabilities,” Sensors, vol. 21, no. 14, p. 4862, Jul. 2021.<br />
<br />
*Z. Ali, E. Perret, N. Barbot and R. Siragusa, "Extraction of Aspect-Independent Parameters Using Spectrogram Method for Chipless Frequency-Coded RFID," in IEEE Sensors Journal, vol. 21, no. 5, pp. 6530-6542, 1 March, 2021, doi: 10.1109/JSEN.2020.3041574.<br />
<br />
*N. Barbot and E. Perret, “Linear time-variant chipless RFID sensor,” ''IEEE Transactions on Antennas and Propagation'', submitted.<br />
<br />
*F. Requena, N. Barbot, D. Kaddour, and E. Perret, "Thermal Modeling of Resonant Scatterers and Reflectometry approach for Remote Temperature Sensing" IEEE Transactions on Microwave Theory and Techniques'', accepted.<br />
<br />
*N. Barbot, O. Rance, and E. Perret, “Classical RFID vs. chipless RFID read range: Is linearity a friend or a foe?” ''IEEE Transactions on Microwave Theory and Techniques'', accepted.<br />
<br />
*N. Barbot, O. Rance, and E. Perret, “Differential RCS of modulated tag,” ''IEEE Transactions on Antennas and Propagation'', pp. 1–1, 2021, early access. doi: 10.1109/TAP.2021.3060943.<br />
<br />
*R. De Amorim, R. Siragusa, N. Barbot, G. Fontgalland, and E. Perret, “Millimeter wave chipless RFID authentication based on spatial diversity and 2D-classification approach,” ''IEEE Transactions on Antennas and Propagation'', pp. 1–1, 2021, early access. doi: 10.1109/TAP.2021.3060126.<br />
<br />
*Z. Ali, E. Perret, N. Barbot, and R. Siragusa, “Extraction of Aspect-Independent Parameters Using Spectrogram Method for Chipless Frequency-Coded RFID,” ''IEEE Sensors Journal'', pp. 1–1, 2021. doi: 10.1109/JSEN.2020.3041574. [Online]. Available: https://hal.univ-grenoble-alpes.fr/hal-03120442.<br />
<br />
*F. Requena, N. Barbot, D. Kaddour, and E. Perret, “Contactless characterization of metals’ thermal expansion coefficient by a free-space RF measurement,” ''IEEE Transactions on Antennas and Propagation'', vol. 69, no. 2, pp. 1230–1234, 2021. doi: 10.1109/TAP.2020.3010982.<br />
<br />
*N. Barbot, O. Rance, and E. Perret, “Chipless RFID reading method insensitive to tag orientation,” ''IEEE Transactions on Antennas and Propagation'', vol 69, no. 5, pp. 2896–2902, May 2021, doi: 10.1109/TAP.2020.3028187.<br />
<br />
*O. Rance, N. Barbot, and E. Perret, “Design of planar resonant scatterer with roll-invariant cross polarization,” ''IEEE Transactions on Microwave Theory and Techniques'', vol. 68, no. 10, pp. 4305–4313, 2020. doi: 10.1109/TMTT.2020.3014376.<br />
<br />
*R. Tavares de Alencar, Z. Ali, N. Barbot, M. Garbati, and E. Perret, “Practical performance comparison of 1-D and 2-D decoding methods for a chipless RFID system in a real environment,” ''IEEE Journal of Radio Frequency Identification'', vol. 4, no. 4, pp. 532–544, 2020. doi: 10.1109/JRFID.2020.2997988.<br />
<br />
*D. Nastasiu, R. Scripcaru, A. Digulescu, C. Ioana, R. De Amorim, N. Barbot, R. Siragusa, E. Perret, and F. Popescu, “A New Method of Secure Authentication Based on Electromagnetic Signatures of Chipless RFID Tags and Machine Learning Approaches,” ''Sensors'', vol. 20, no. 21, p. 6385, Nov. 2020. doi: 10.3390/s20216385. [Online]. Available: https://hal.archives-ouvertes.fr/hal-03035887.<br />
<br />
*M. M. Ahmed, E. Perret, D. Hely, R. Siragusa, and N. Barbot, “Guided electromagnetic wave technique for IC authentication,” ''Sensors'', vol. 20, no. 7, 2020, issn: 1424-8220. doi: 10.3390/s20072041. [Online]. Available: https://www.mdpi.com/1424-8220/20/7/2041.<br />
<br />
*N. Barbot, O. Rance, and E. Perret, “Angle Sensor Based on Chipless RFID Tag,” ''IEEE Antennas and Wireless Propagation Letters'', 2019. [Online]. Available: https://hal.archives-ouvertes.fr/hal-02377065.<br />
<br />
*Z. Ali, E. Perret, N. Barbot, R. Siragusa, D. Hely, M. Bernier, and F. Garet, “Authentication Using Metallic Inkjet-Printed Chipless RFID Tags,” ''IEEE Transactions on Antennas and Propagation'', pp. 1–1, Oct. 2019. doi: 10.1109/TAP.2019.2948740. [Online]. Available: https://hal.archives-ouvertes.fr/hal-02337466.<br />
<br />
*M. M. Ahmed, D. Hely, E. Perret, N. Barbot, R. Siragusa, M. Bernier, and F. Garet, “Robust and Noninvasive IC Authentication Using Radiated Electromagnetic Emissions,” Journal of Hardware and Systems Security, vol. 3, no. 3, pp. 273–288, Sep. 2019. doi: 10.1007/s41635-019-00072-y. [Online]. Available: https://hal.archives-ouvertes.fr/hal-02296583.<br />
<br />
*Z. Ali, E. Perret, N. Barbot, R. Siragusa, D. Hely, M. Bernier, and F. Garet, “Detection of Natural Randomness by Chipless RFID Approach and Its Application to Authentication,” ''IEEE Transactions on Microwave Theory and Techniques'', pp. 1–15, May 2019. doi: 10.1109/TMTT.2019.2914102. [Online]. Available: https://hal.archives-ouvertes.fr/hal-02132612.<br />
<br />
*M. M. Ahmed, D. Hely, E. Perret, N. Barbot, R. Siragusa, M. Bernier, and F. Garet, “Robust and noninvasive IC authentication using radiated electromagnetic emissions,” ''Journal of Hardware and Systems Security'', vol. 3, no. 3, pp. 273–288, Sep. 2019. <br />
<br />
*N. Barbot and E. Perret, “Accurate Positioning System Based on Chipless Technology,” ''Sensors'', Mar. 2019. doi: 10.3390/s19061341. [Online]. Available: https://hal.archives-ouvertes.fr/hal-02064576.<br />
<br />
*N. Barbot and E. Perret, “A Chipless RFID Method of 2D Localization Based on Phase Acquisition,” ''Journal of Sensors'', vol. 2018, pp. 1–6, Jul. 2018. [Online]. Available: https://hal.univ-grenoble-alpes.fr/hal-01944679.<br />
<br />
*Z. Ali, N. Barbot, R. Siragusa, E. Perret, D. Hély, M. Bernier, and F. Garet, “Detection of Minimum Geometrical Variation by Free-Space-Based Chipless Approach and its Application to Authentication,” ''IEEE Microwave and Wireless Components Letters'', vol. 28, no. 4, pp. 323–325, Jan. 2018. doi: 10.1109/LMWC.2018.2805858. [Online]. Available: https://hal.archives-ouvertes.fr/hal-01800580.<br />
<br />
*M. M. Ahmed, D. Hely, N. Barbot, R. Siragusa, E. Perret, M. Bernier, and F. Garet, “Radiated Electromagnetic Emission for Integrated Circuit Authentication,” ''IEEE Microwave and Wireless Components Letters'', vol. 27, no. 11, pp. 1028–1030, Nov. 2017. doi: 10.1109/LMWC.2017.2750078. [Online]. Available: https://hal.archives-ouvertes.fr/hal-01724143.<br />
<br />
*N. Barbot, S. Sahuguede, A. Julien-Vergonjanne, and J.-P. Cances, “Low-density Parity-check and Fountain Code Performance over Mobile Wireless Optical Channels,” ''Transactions on emerging telecommunications technologies'', vol. 25, no. 6, pp. 638–647, Jun. 2014. doi: 10.1002/ett.2812. [Online]. Available: https://hal.archives-ouvertes.fr/hal-01257508.<br />
<br />
*S. S. Torkestani, N. Barbot, S. Sahuguede, A. Julien-Vergonjanne, and J.-P. Cances, “Transmission Power Analysis of Optical Wireless Based Mobile Healthcare Systems,” ''Int J Wireless Inf Networks'', vol. 19, no. 3, pp. 201–208, Jun. 2012, Springer Science+Business Media, doi: 10.1007/s10776-012-0177-1. [Online]. Available: https://hal.archives-ouvertes.fr/hal-00790442.<br />
<br />
*N. Barbot, S. S. Torkestani, S. Sahuguede, A. Julien-Vergonjanne, and J.-P. Cances, “Maximal rate of mobile wireless optical link in indoor environment,” ''International Journal on Advanced in Telecommunications'', vol. 5, no. 3-4, pp. 274–283, 2012. [Online]. Available: https://hal-unilim.archives-ouvertes.fr/hal-00919839.<br />
<br />
==International Conferences==<br />
<br />
*N. Barbot and Etienne Perret, "Impact of the Polarization over the Read Range in Chipless RFID", in 2021 IEEE International Conference on RFID Technology and Applications<br />
(RFID-TA) (IEEE RFID-TA 2021)", accepted, Oct. 2021,<br />
<br />
*A. Azarfar, N. Barbot, and E. Perret, “Towards chipless RFID technology based on micro-doppler effect for long range applications,” ''in IEEE/MTT-S International Microwave Symposium - IMS 2021'', accepted, Jun. 2021.<br />
<br />
*F. Requena, N. Barbot, D. Kaddour, and E. Perret, “Chipless RFID temperature and humidity sensing,” ''in IEEE/MTT-S International Microwave Symposium - IMS 2021'', accepted, Jun. 2021.<br />
<br />
*N. Barbot, O. Rance, and E. Perret, “Notes on differential RCS of modulated tag,” ''in 2021 IEEE RFID conference'', Atlanta, GA, Apr. 2021 '''Best Poster Award'''<br />
<br />
*R. de Amorim, N. Barbot, R. Siragusa, and E. Perret, “Millimeter-wave chipless RFID tag for authentication applications,” ''in 2020 50th European Microwave Conference (EuMC)'', 2021, pp. 800–803. doi: 10.23919/EuMC48046.2021.9338082.<br />
<br />
*N. Barbot, O. Rance, and E. Perret, “Cross-Polarization Chipless Tag for Orientation Sensing,” ''in European Microwave Conference (EuMC)'', Utrecht, Netherlands, Jan. 2021. [Online]. Available: https://hal.archives-ouvertes.fr/hal-03120671.<br />
<br />
*O. Rance, N. Barbot, and E. Perret, “Monte carlo simulation for chipless RFID orientation sensor,” ''in 2020 IEEE International Symposium on Antennas and Propagation and North American Radio Science Meeting'', 2020, pp. 1199–1200. doi: 10.1109/IEEECONF35879.2020.9329985.<br />
<br />
*N. Barbot, O. Rance, and E. Perret, “Orientation Determination of a Scatterer Based on Polarimetric Radar Measurements,” ''in URSI GASS 2020'', Rome, Italy, Aug. 2020. [Online]. Available: https://hal.archives-ouvertes.fr/hal-02948679.<br />
<br />
*M. M. Ahmed, E. Perret, R. Siragusa, D. Hély, F. Garet, N. Barbot, and M. Bernier, “Implementation of RF communication subsets on common low frequency clocked FPGA,” ''in 2019 49th European Microwave Conference (EuMC)'', Paris, France: IEEE, Oct. 2019, pp. 742–745. doi: 10.23919/EuMC.2019.8910837. [Online]. Available: https://hal.archives-ouvertes.fr/hal-02429327.<br />
<br />
*R. T. d. Alencar, N. Barbot, M. Garbati, and E. Perret, “Practical Comparison of Decoding Methods for Chipless RFID System in Real Environment,” ''in 2019 IEEE International Conference on RFID Technology and Applications (RFID-TA)'', Pisa, Italy: IEEE, Sep. 2019, pp. 207–211. doi: 10.1109/RFID-TA.2019.8892020. [Online]. Available: https://hal.archives-ouvertes.fr/hal-02429346.<br />
<br />
*R. T. de Alencar, N. Barbot, M. Garbati, and E. Perret, “Characterization of chipless RFID tag in a 3-dimensional reading zone,” ''in 2019 IEEE International Symposium on Antennas and Propagation and USNC-URSI Radio Science Meeting'', 2019, pp. 639–640. doi: 10.1109/APUSNCURSINRSM.2019.8888559.<br />
<br />
*S. Salhi, F. Bonnefoy, S. Girard, M. Bernier, N. Barbot, R. Siragusa, E. Perret, and F. Garet, “Enhanced THz tags authentication using multivariate statistical analysis,” ''in IRMMW-THz 2019 - 44th International Conference on Infrared, Millimeter, and Terahertz Waves'', Paris, France, Sep. 2019, pp. 1–2. [Online]. Available: https://hal.archives-ouvertes.fr/hal-02282841.<br />
<br />
*F. Bonnefoy, C. Ioana, M. Bernier, N. Barbot, R. Siragusa, E. Perret, P. Martinez, and F. Garet, “Identification Of Random Internal Structuring THz Tags Using Images Correlation And SIWPD Analysis,” ''in 44th International Conference on Infrared, Millimeter, and Terahertz Waves'', Paris, France: IEEE, Sep. 2019, pp. 1–1. doi: 10.1109/IRMMW-THz.2019.8873800. [Online]. Available: https://hal.univ-grenoble-alpes.fr/hal-02297202.<br />
<br />
*F. Bonnefoy, M. Bernier, F. Garet, N. Barbot, D. Hely, R. Siragusa, and E. Perret, “Diffraction grating tags structures dedicated to authentication in the THz,” ''in French-German THz Conference 2019'', Kaiserslautern, Germany, Apr. 2019. [Online]. Available: https://hal.archives-ouvertes.fr/hal-02436662.<br />
<br />
*M. Hamdi, F. Bonnefoy, M. Bernier, F. Garet, E. Perret, N. Barbot, R. Siragusa, and D. Hely, “Identification in the Terahertz Domain using Low Cost Tags with a Fast Spectrometer,” ''in ASID 2018: 12th IEEE International Conference on Anti-counterfeiting, Security, and Identification'', Xiamen, China, Nov. 2018. doi: 10.1109/ICASID.2018.8693209. [Online]. Available: https://hal.univ-grenoble-alpes.fr/hal-02015383.<br />
<br />
*M. M. Ahmed, D. Hely, E. Perret, N. Barbot, R. Siragusa, M. Bernier, and F. Garet, “Authentication of Microcontroller Board Using Non-Invasive EM Emission Technique,” ''in 2018 IEEE 3rd International Verification and Security Workshop (IVSW)'', Platja d’Aro, Spain: IEEE, Jul. 2018, pp. 25–30. doi: 10.1109/IVSW.2018.8494883. [Online]. Available: https://hal.archives-ouvertes.fr/hal-02014214.<br />
<br />
*Z. Ali, N. Barbot, R. Siragusa, D. Hely, M. Bernier, F. Garet, and E. Perret, “Chipless RFID Tag Discrimination and the Performance of Resemblance Metrics to be used for it,” ''in IEEE/MTT-S International Microwave Symposium - IMS 2018'', Philadelphia, United States: IEEE, Jun. 2018. doi: 10.1109/MWSYM.2018.8439855. [Online]. Available: https://hal.archives-ouvertes.fr/hal-01888533.<br />
<br />
*N. Barbot and E. Perret, “2D Localization using Phase Measurement of Chipless RFID Tags,” ''in 2nd URSI AT-RASC'', Gran Canaria, Spain, May 2018. [Online]. Available: https://hal.univ-grenoble-alpes.fr/hal-02066779.<br />
<br />
*S. Chollet, L. Pion, and N. Barbot, “Secure IoT for a Pervasive Platform,” ''in 2018 IEEE International Conference on Pervasive Computing and Communications Workshops, PerCom Workshops 2018'', Athènes, Greece, Mar. 2018. [Online]. Available: https://hal.archives- ouvertes.fr/hal-01898651.<br />
<br />
*M. M. Ahmed, D. Hely, N. Barbot, R. Siragusa, E. Perret, M. Bernier, and F. Garet, “Towards a robust and efficient EM based authentication of FPGA against counterfeiting and recycling,” ''in 19th International Symposium on Computer Architecture and Digital Systems (CADS)'', Kish Island, Iran: IEEE, Dec. 2017, pp. 1–6. doi: 10.1109/CADS.2017.8310673. [Online]. Available: https://hal.univ-grenoble-alpes.fr/hal-02014230.<br />
<br />
*N. Barbot and E. Perret, “Gesture recognition with the chipless RIFD technology,” ''in 2017 XXXIInd General Assembly and Scientific Symposium of the International Union of Radio Science (URSI GASS)'', Montreal, Canada, Aug. 2017, pp. 19–26. doi: 10.23919/URSIGASS.2017.8104990. [Online]. Available: https://hal.univ-grenoble-alpes.fr/hal-01944690.<br />
<br />
*F. Bonnefoy, M. Hamdi, M. Bernier, N. Barbot, R. Siragusa, D. Hely, E. Perret, and F. Garet, “Authentication in the THz domain: a new tool to fight couterfeiting,” ''in 9th THz days'', Dunkerque, France, Jun. 2017. [Online]. Available: https://hal.univ-grenoble-alpes.fr/hal-02014053.<br />
<br />
*Z. Ali, F. Bonnefoy, R. Siragusa, N. Barbot, D. Hély, E. Perret, M. Bernier, and F. Garet, “Potential of chipless authentication based on randomness inherent in fabrication process for RF and THz,” ''in 11th European Conference on Antennas and Propagation (EUCAP)'', Paris, France, 2017. doi: 10.23919/EuCAP.2017.7928647. [Online]. Available: https://hal.archives-ouvertes.fr/hal-01800579.<br />
<br />
*M. M. Ahmed, D. Hely, R. Siragusa, N. Barbot, E. Perret, M. Bernier, and F. Garet, “Authentication of IC based on Electromagnetic Signature,” ''in 6th Conference on Trustworthy Manufacturing and Utilization of Secure Devices (TRUDEVICE 2016)'', Barcelone, Spain, Nov. 2016. [Online]. Available: https://hal.univ-grenoble-alpes.fr/hal-02014251.<br />
<br />
*N. Barbot, S. Sahuguede, A. Julien-Vergonjanne, and J.-P. Cances, “Outage capacity of mobile wireless optical link in indoor environment,” ''in Application of Information and Communication Technologies (AICT)'', Stuttgart, Germany, Oct. 2012, 5 pages. [Online]. Available: https://hal.archives-ouvertes.fr/hal-00790458.<br />
<br />
*N. Barbot, S. Sahuguede, and A. Julien-Vergonjanne, “Multiple Access Interference Impact on Outage Probability of Wireless Optical CDMA Systems,” ''in Photonics in Switching 2012'', Ajaccio - Corse, France, Sep. 2012, Session 1.5 OFDM, CDMA. [Online]. Available: https://hal-unilim.archives-ouvertes.fr/hal-00793162.<br />
<br />
*N. Barbot, S. Sahuguede, and A. Julien-Vergonjanne, “Performance of a Mobile Wireless Optical CDMA Monitoring System,” ''in The Ninth International Symposium on Wireless Communication Systems (ISWCS)'', ISSN : 2154-0217 E-ISBN : 978-1-4673-0760-4 Print ISBN: 978-1-4673-0761-1, Paris, France, Aug. 2012, pp.666–670. doi: 10.1109/ISWCS.2012.6328451. [Online]. Available: https://hal-unilim.archives-ouvertes.fr/hal-00793183.<br />
<br />
*N. Barbot, S. S. Torkestani, S. Sahuguede, A. Julien-Vergonjanne, and J.-P. Cances, “LT codes performance over indoor mobile wireless optical channel,” ''in Communication Systems, Networks & Digital Signal Processing (CSNDSP)'', 2012 8th International Symposium on, Print ISBN: 978-1-4577-1472-6, Poznan, Germany, Jul. 2012, pp. 1–4. doi: 10.1109/CSNDSP.2012.6292657. [Online]. Available: https://hal.archives-ouvertes.fr/hal-00790453.<br />
<br />
*S. S. Torkestani, N. Barbot, S. Sahuguede, A. Julien-Vergonjanne, and J.-P. Cances, “Performance and Transmission Power Bound Analysis for Optical Wireless based Mobile Healthcare Applications,” ''in 2011 IEEE 22nd International Symposium on'', Toronto, Canada, Sep. 2011, Inconnu. [Online]. Available: https://hal-unilim.archives-ouvertes.fr/hal-00650252.<br />
<br />
*N. Barbot, S. Sahuguede, A. Julien-Vergonjanne, and J.-P. Cances, “Performance Bound for LDPC Codes Over Mobile LOS Wireless Optical Channel,” ''in 2011 IEEE 73rd Vehicular Technology Conference: VTC2011-Spring'', Budapest, Hungary, May 2011, pp. 1–5. doi: 10.1109/VETECS.2011.5956176. [Online]. Available: https://hal-unilim.archives-ouvertes.fr/hal-00649807.<br />
<br />
==National Conferences==<br />
<br />
*M. M. Ahmed, E. Perret, R. Siragusa, N. Barbot, D. Hely, M. Bernier, and F. Garet, "Développement d’une plateforme RF flexible et reconfigurable basée sur un FPGA," ''21èmes Journées Nationales Microondes (JNM)'', Caen, France, May 2019. [Online]. Available: https://hal.archives-ouvertes.fr/hal-02051698.<br />
<br />
*Z. Ali, R. Siragusa, E. Perret, N. Barbot, D. Hely, M. Bernier, and F. Garet, "Méthode d’authentification basée sur des tags RFID sans puce imprimés par jet d’encre conductrice," ''21èmes Journées Nationales Microondes (JNM)'', Caen, France, May 2019. [Online]. Available: https://hal.archives-ouvertes.fr/hal-02017120.<br />
<br />
*N. Barbot and E. Perret, Localisation 2D par Mesures de Phase basée sur la Technologie Chipless, ''21èmes Journées Nationales Microondes (JNM)'', Caen, France, May 2019. [Online]. Available: https://hal.archives-ouvertes.fr/hal-02019490.<br />
<br />
*N. Barbot, S. Sahuguede, and A. Julien-Vergonjanne, Performances du contrôle d’erreur d’une transmission optique sans fil dédiée à une application de télé-surveillance mobile, Brest, France, Sep. 2013. [Online]. Available: https://hal-unilim.archives-ouvertes.fr/hal-00919862.<br />
<br />
*S. S. Torkestani, N. Barbot, S. Sahuguede, and A. Julien-Vergonjanne, Performances d’un système de transmission optique sans fil pour la télésurveillance médicale en milieu sensible confiné, Dijon, France, Sep. 2011. [Online]. Available: https://hal-unilim.archives-ouvertes.fr/hal-00650305.</div>Nicohttps://nicolas-barbot.ovh/wiki/index.php?title=MA331_Information_Theory_and_Channel_Coding&diff=459MA331 Information Theory and Channel Coding2021-08-31T10:59:24Z<p>Nico: </p>
<hr />
<div>The objective of this course is to understand how we can transmit a message in-between a transmitter and a receiver spatially (or temporally) separated. Especially, how we can use coding to realize an error free transmission over noisy channels. This beautiful result has been predicted by C. E. Shannon and relies on two distinct operations which are source coding and channel coding. This course is an introduction to information theory and describe the main algorithms in both source coding and channel coding. This course is related to [[SC311 Wireless Communications]] but tackle the communication problem mainly at the bit level.<br />
<br />
This course is composed of 3 parts. Slides (in french) for each part can be downloaded here:<br />
<br />
# [https://nicolas-barbot.ovh/wiki/pool/introduction.pdf Introduction]<br />
# [https://nicolas-barbot.ovh/wiki/pool/information_theory.pdf Information Theory]<br />
# [https://nicolas-barbot.ovh/wiki/pool/source_coding.pdf Source Coding]<br />
# [https://nicolas-barbot.ovh/wiki/pool/channel_coding.pdf Channel Coding]<br />
<br />
The following of this page corresponds to the labs.<br />
<br />
__TOC__<br />
<br />
This objective of this lab is to allow you to evaluate the performance of classical telecommunication system by simulating the transmission of a large quantity of random data (Monte Carlo method). A special focus is placed on the performance of forward error correcting codes over different channels. The original subject of this lab is based on Matlab (or Octave) and is available [https://nicolas-barbot.ovh/wiki/pool/lab.pdf here] (in French) where the objective is to estimate the performance of the classical Hamming code <math>H(7,4)</math> over the BSC channel of probability <math>f</math>.<br />
<br />
This wiki presents a different approach based on the [http://itpp.sourceforge.net/4.3.1/ IT++] library which allows to generalize the results for any forward error correcting code and any channel.<br />
<br />
== IT++ ==<br />
<br />
IT++ is a C++ library designed to evaluate the performance of different telecommunications systems. Several forward error correction codes have been implemented and can easily be<br />
characterized and compared. All the results presented during the course have been obtained using this library.<br />
<br />
== Hamming Code ==<br />
<br />
* After installing the library (which is maybe the hardest step of this lab), create a file <syntaxhighlight lang="text" inline>main.cpp</syntaxhighlight> and copy the following program.<br />
<br />
<syntaxhighlight lang="C++" line='line'><br />
#include <itpp/itcomm.h><br />
<br />
using namespace itpp;<br />
using std::cout;<br />
using std::endl;<br />
<br />
int main()<br />
{<br />
bvec bits, ebits, dbits;<br />
<br />
Hamming_Code hc(3);<br />
<br />
RNG_randomize();<br />
<br />
bits = randb(4); // Generate 4 random bits<br />
<br />
ebits = hc.encode(bits); // Encode with H(7,4)<br />
<br />
dbits = hc.decode(ebits); // Decode with H(7,4)<br />
<br />
cout << "bits = " << bits << endl;<br />
cout << "ebits = " << ebits << endl;<br />
cout << "dbits = " << dbits << endl;<br />
<br />
return 0;<br />
}<br />
</syntaxhighlight><br />
<br />
The program can be built with the following command:<br />
<br />
<syntaxhighlight lang="text"><br />
$ g++ `pkg-config --cflags itpp` -o main main.cpp `pkg-config --libs itpp`<br />
</syntaxhighlight><br />
<br />
If sucessfull, this command produces the binary file <syntaxhighlight lang="text" inline>main</syntaxhighlight> which can be directly executed by typing:<br />
<br />
<syntaxhighlight lang="text"><br />
$ ./main<br />
</syntaxhighlight><br />
<br />
* Determine the generator matrix <math>G</math> of the Hamming code <math>H(7,4)</math>.<br />
<br />
* Modify the encoded vector by adding 1 error on the codeword and observe the decoded codeword.<br />
<br />
* Same question with 2 errors.<br />
<br />
== Performance over BSC channel ==<br />
<br />
<syntaxhighlight lang="C++" line='line'><br />
#include <itpp/itcomm.h><br />
<br />
#define N 500000<br />
<br />
using namespace itpp;<br />
using std::cout;<br />
using std::endl;<br />
<br />
int main()<br />
{<br />
bvec bits, ebits, rbits, dbits;<br />
vec f = linspace(0.0, 0.5, 20);<br />
vec ber(p.length());<br />
<br />
BSC bsc;<br />
BERC berc;<br />
Hamming_Code hc(3);<br />
it_file ff;<br />
<br />
RNG_randomize();<br />
<br />
for (int i = 0; i < p.length(); i++)<br />
{<br />
bsc.set_prob(f(i)); // Set the error prob of the BSC<br />
bits = randb(N); // Generate N random bits<br />
ebits = hc.encode(bits); // Encode with H(7,4)<br />
rbits = bsc(ebits); // Transmit over BSC<br />
dbits = hc.decode(rbits); // Decode with H(7,4)<br />
berc.clear(); // Reset the counter<br />
berc.count(bits, dbits); // Count the errors<br />
ber(i) = berc.get_errorrate();<br />
}<br />
cout << "BER = " << ber << endl;<br />
ff.open("res.it"); // Save the results<br />
ff << Name("f") << f;<br />
ff << Name("ber") << ber;<br />
ff.close();<br />
<br />
return 0;<br />
}<br />
<br />
</syntaxhighlight><br />
<br />
<br />
Execution takes few seconds and display the BER for the different probabilities <math>f</math> of the BSC channel. Results are also saved in the file <syntaxhighlight lang="text" inline>res.it</syntaxhighlight><br />
and can be easily displayed using the <syntaxhighlight lang="text" inline>itload.m</syntaxhighlight> script using Matlab (or Octave):<br />
<br />
<syntaxhighlight lang="text"><br />
> itload('res.it');<br />
> plot(f, ber);<br />
</syntaxhighlight><br />
<br />
[[File:hamming.png|thumb|right|Performance in term of BER <math>p_b</math> of the Hamming code H(7,4) over BSC of probability <math>f</math>.]]<br />
<br />
Simulated results can also be compared with the theory. Word error probability can be computed by remarking that a received codeword cannot be decoded if it contains 2 or more errors:<br />
<br />
<math><br />
\begin{align}<br />
p_B &= \sum_{i=2}^7 \binom{7}{i} f^i (1-f)^{7-i}\\<br />
&\approx \binom{7}{2} f^2\\<br />
&\approx 21 f^2\\<br />
\end{align}<br />
</math><br />
<br />
Bit error rate can be estimated by noting that when a received codeword contains 2 error, the decoding algorithm will add 1 additional error:<br />
<br />
<math><br />
p_b \approx \frac{3}{7} p_B \approx 9 f^2<br />
</math><br />
<br />
IT++ library supports dozens of different codes, modulations and channels and allows to easily change the simulated system to quickly estimate the achievable performance.</div>Nicohttps://nicolas-barbot.ovh/wiki/index.php?title=MA331_Information_Theory_and_Channel_Coding&diff=458MA331 Information Theory and Channel Coding2021-08-31T10:57:24Z<p>Nico: </p>
<hr />
<div>The objective of this course is to understand how we can transmit a message in-between a transmitter and a receiver spatially (or temporally) separated. Especially, how we can use coding to realize an error free transmission over noisy channels. This beautiful result has been predicted by C. E. Shannon and relies on two distinct operations which are source coding and channel coding. This course is an introduction to information theory and describe the main algorithms in both source coding and channel coding. This course is related to [[SC311 Wireless Communications]] but tackle the communication problem mainly at the bit level.<br />
<br />
This course is composed of 3 parts. Slides (in french) for each part can be downloaded here:<br />
<br />
# [https://nicolas-barbot.ovh/wiki/pool/introduction.pdf Introduction]<br />
# [https://nicolas-barbot.ovh/wiki/pool/information_theory.pdf Information Theory]<br />
# [https://nicolas-barbot.ovh/wiki/pool/source_coding.pdf Source Coding]<br />
# [https://nicolas-barbot.ovh/wiki/pool/channel_coding.pdf Channel Coding]<br />
<br />
The following of this page corresponds to the labs.<br />
<br />
__TOC__<br />
<br />
This objective of this lab is to allow you to evaluate the performance of classical telecommunication system by simulating the transmission of a large quantity of random data (Monte Carlo method). A special focus is placed on the performance of forward error correcting codes over different channels. The original subject of this lab is based on Matlab (or Octave) and is available [https://nicolas-barbot.ovh/wiki/pool/lab.pdf here] (in French) where the objective is to estimate the performance of the classical Hamming code <math>H(7,4)</math> over the BSC channel of probability <math>f</math>.<br />
<br />
This wiki presents a different approach based on the [http://itpp.sourceforge.net/4.3.1/ IT++] library which allows to generalize the results for any forward error correcting code and any channel.<br />
<br />
== IT++ ==<br />
<br />
IT++ is a C++ library designed to evaluate the performance of different telecommunications systems. Several forward error correction codes have been implemented and can easily be<br />
characterized and compared. All the results presented during the course have been obtained using this library.<br />
<br />
== Hamming Code ==<br />
<br />
* After installing the library (which is maybe the hardest step of this lab), create a file <syntaxhighlight lang="text" inline>main.cpp</syntaxhighlight> and copy the following program.<br />
<br />
<syntaxhighlight lang="C++" line='line'><br />
#include <itpp/itcomm.h><br />
<br />
using namespace itpp;<br />
using std::cout;<br />
using std::endl;<br />
<br />
int main()<br />
{<br />
bvec bits, ebits, dbits;<br />
<br />
Hamming_Code hc(3);<br />
<br />
RNG_randomize();<br />
<br />
bits = randb(4); // Generate 4 random bits<br />
<br />
ebits = hc.encode(bits); // Encode with H(7,4)<br />
<br />
dbits = hc.decode(ebits); // Decode with H(7,4)<br />
<br />
cout << "bits = " << bits << endl;<br />
cout << "ebits = " << ebits << endl;<br />
cout << "dbits = " << dbits << endl;<br />
<br />
return 0;<br />
}<br />
</syntaxhighlight><br />
<br />
The program can be built with the following command:<br />
<br />
<syntaxhighlight lang="text"><br />
$ g++ `pkg-config --cflags itpp` -o main main.cpp `pkg-config --libs itpp`<br />
</syntaxhighlight><br />
<br />
If sucessfull, this command produces the binary file <syntaxhighlight lang="text" inline>main</syntaxhighlight> which can be directly executed by typing:<br />
<br />
<syntaxhighlight lang="text"><br />
$ ./main<br />
</syntaxhighlight><br />
<br />
* Determine the generator matrix <math>G</math> of the Hamming code <math>H(7,4)</math>.<br />
<br />
* Modify the encoded vector by adding 1 error on the codeword and observe the decoded codeword.<br />
<br />
* Same question with 2 errors.<br />
<br />
== Performance over BSC channel ==<br />
<br />
<syntaxhighlight lang="C++" line='line'><br />
#include <itpp/itcomm.h><br />
<br />
#define N 500000<br />
<br />
using namespace itpp;<br />
using std::cout;<br />
using std::endl;<br />
<br />
int main()<br />
{<br />
bvec bits, ebits, rbits, dbits;<br />
vec f = linspace(0.0, 0.5, 20);<br />
vec ber(p.length());<br />
<br />
BSC bsc;<br />
BERC berc;<br />
Hamming_Code hc(3);<br />
it_file ff;<br />
<br />
RNG_randomize();<br />
<br />
for (int i = 0; i < p.length(); i++)<br />
{<br />
bsc.set_prob(f(i)); // Set the error prob of the BSC<br />
bits = randb(N); // Generate N random bits<br />
ebits = hc.encode(bits); // Encode with H(7,4)<br />
rbits = bsc(ebits); // Transmit over BSC<br />
dbits = hc.decode(rbits); // Decode with H(7,4)<br />
berc.clear(); // Reset the counter<br />
berc.count(bits, dbits); // Count the errors<br />
ber(i) = berc.get_errorrate();<br />
}<br />
cout << "BER = " << ber << endl;<br />
ff.open("res.it"); // Save the results<br />
ff << Name("f") << f;<br />
ff << Name("ber") << ber;<br />
ff.close();<br />
<br />
return 0;<br />
}<br />
<br />
</syntaxhighlight><br />
<br />
<br />
Execution takes few seconds and display the BER for the different probabilities <math>f</math> of the BSC channel. Results are also saved in the file <syntaxhighlight lang="text" inline>res.it</syntaxhighlight><br />
and can be easily displayed using the <syntaxhighlight lang="text" inline>itload.m</syntaxhighlight> script using Matlab (or Octave):<br />
<br />
<syntaxhighlight lang="text"><br />
> itload('res.it');<br />
> plot(f, ber);<br />
</syntaxhighlight><br />
<br />
[[File:hamming.png|thumb|right|Performance of the Hamming code H(7,4) over BSC of probability <math>f</math>.]]<br />
<br />
Simulated results can also be compared with the theory. Word error probability can be computed by remarking that a received codeword cannot be decoded if it contains 2 or more errors:<br />
<br />
<math><br />
\begin{align}<br />
p_B &= \sum_{i=2}^7 \binom{7}{i} f^i (1-f)^{7-i}\\<br />
&\approx \binom{7}{2} f^2\\<br />
&\approx 21 f^2\\<br />
\end{align}<br />
</math><br />
<br />
Bit error rate can be estimated by noting that when a received codeword contains 2 error, the decoding algorithm will add 1 additional error:<br />
<br />
<math><br />
p_b \approx \frac{3}{7} p_B \approx 9 f^2<br />
</math><br />
<br />
IT++ library supports dozens of different codes, modulations and channels and allows to easily change the simulated system to quickly estimate the achievable performance.</div>Nicohttps://nicolas-barbot.ovh/wiki/index.php?title=MA331_Information_Theory_and_Channel_Coding&diff=457MA331 Information Theory and Channel Coding2021-08-31T10:57:00Z<p>Nico: </p>
<hr />
<div>The objective of this course is to understand how we can transmit a message in-between a transmitter and a receiver spatially (or temporally) separated. Especially, how we can use coding to realize an error free transmission over noisy channels. This beautiful result has been predicted by C. E. Shannon and relies on two distinct operations which are source coding and channel coding. This course is an introduction to information theory and describe the main algorithms in both source coding and channel coding. This course is related to [[SC311 Wireless Communications]] but tackle the communication problem mainly at the bit level.<br />
<br />
This course is composed of 3 parts. Slides (in french) for each part can be downloaded here:<br />
<br />
# [https://nicolas-barbot.ovh/wiki/pool/introduction.pdf Introduction]<br />
<br />
# [https://nicolas-barbot.ovh/wiki/pool/information_theory.pdf Information Theory]<br />
<br />
# [https://nicolas-barbot.ovh/wiki/pool/source_coding.pdf Source Coding]<br />
<br />
# [https://nicolas-barbot.ovh/wiki/pool/channel_coding.pdf Channel Coding]<br />
<br />
The following of this page corresponds to the labs.<br />
<br />
__TOC__<br />
<br />
This objective of this lab is to allow you to evaluate the performance of classical telecommunication system by simulating the transmission of a large quantity of random data (Monte Carlo method). A special focus is placed on the performance of forward error correcting codes over different channels. The original subject of this lab is based on Matlab (or Octave) and is available [https://nicolas-barbot.ovh/wiki/pool/lab.pdf here] (in French) where the objective is to estimate the performance of the classical Hamming code <math>H(7,4)</math> over the BSC channel of probability <math>f</math>.<br />
<br />
This wiki presents a different approach based on the [http://itpp.sourceforge.net/4.3.1/ IT++] library which allows to generalize the results for any forward error correcting code and any channel.<br />
<br />
== IT++ ==<br />
<br />
IT++ is a C++ library designed to evaluate the performance of different telecommunications systems. Several forward error correction codes have been implemented and can easily be<br />
characterized and compared. All the results presented during the course have been obtained using this library.<br />
<br />
== Hamming Code ==<br />
<br />
* After installing the library (which is maybe the hardest step of this lab), create a file <syntaxhighlight lang="text" inline>main.cpp</syntaxhighlight> and copy the following program.<br />
<br />
<syntaxhighlight lang="C++" line='line'><br />
#include <itpp/itcomm.h><br />
<br />
using namespace itpp;<br />
using std::cout;<br />
using std::endl;<br />
<br />
int main()<br />
{<br />
bvec bits, ebits, dbits;<br />
<br />
Hamming_Code hc(3);<br />
<br />
RNG_randomize();<br />
<br />
bits = randb(4); // Generate 4 random bits<br />
<br />
ebits = hc.encode(bits); // Encode with H(7,4)<br />
<br />
dbits = hc.decode(ebits); // Decode with H(7,4)<br />
<br />
cout << "bits = " << bits << endl;<br />
cout << "ebits = " << ebits << endl;<br />
cout << "dbits = " << dbits << endl;<br />
<br />
return 0;<br />
}<br />
</syntaxhighlight><br />
<br />
The program can be built with the following command:<br />
<br />
<syntaxhighlight lang="text"><br />
$ g++ `pkg-config --cflags itpp` -o main main.cpp `pkg-config --libs itpp`<br />
</syntaxhighlight><br />
<br />
If sucessfull, this command produces the binary file <syntaxhighlight lang="text" inline>main</syntaxhighlight> which can be directly executed by typing:<br />
<br />
<syntaxhighlight lang="text"><br />
$ ./main<br />
</syntaxhighlight><br />
<br />
* Determine the generator matrix <math>G</math> of the Hamming code <math>H(7,4)</math>.<br />
<br />
* Modify the encoded vector by adding 1 error on the codeword and observe the decoded codeword.<br />
<br />
* Same question with 2 errors.<br />
<br />
== Performance over BSC channel ==<br />
<br />
<syntaxhighlight lang="C++" line='line'><br />
#include <itpp/itcomm.h><br />
<br />
#define N 500000<br />
<br />
using namespace itpp;<br />
using std::cout;<br />
using std::endl;<br />
<br />
int main()<br />
{<br />
bvec bits, ebits, rbits, dbits;<br />
vec f = linspace(0.0, 0.5, 20);<br />
vec ber(p.length());<br />
<br />
BSC bsc;<br />
BERC berc;<br />
Hamming_Code hc(3);<br />
it_file ff;<br />
<br />
RNG_randomize();<br />
<br />
for (int i = 0; i < p.length(); i++)<br />
{<br />
bsc.set_prob(f(i)); // Set the error prob of the BSC<br />
bits = randb(N); // Generate N random bits<br />
ebits = hc.encode(bits); // Encode with H(7,4)<br />
rbits = bsc(ebits); // Transmit over BSC<br />
dbits = hc.decode(rbits); // Decode with H(7,4)<br />
berc.clear(); // Reset the counter<br />
berc.count(bits, dbits); // Count the errors<br />
ber(i) = berc.get_errorrate();<br />
}<br />
cout << "BER = " << ber << endl;<br />
ff.open("res.it"); // Save the results<br />
ff << Name("f") << f;<br />
ff << Name("ber") << ber;<br />
ff.close();<br />
<br />
return 0;<br />
}<br />
<br />
</syntaxhighlight><br />
<br />
<br />
Execution takes few seconds and display the BER for the different probabilities <math>f</math> of the BSC channel. Results are also saved in the file <syntaxhighlight lang="text" inline>res.it</syntaxhighlight><br />
and can be easily displayed using the <syntaxhighlight lang="text" inline>itload.m</syntaxhighlight> script using Matlab (or Octave):<br />
<br />
<syntaxhighlight lang="text"><br />
> itload('res.it');<br />
> plot(f, ber);<br />
</syntaxhighlight><br />
<br />
[[File:hamming.png|thumb|right|Performance of the Hamming code H(7,4) over BSC of probability <math>f</math>.]]<br />
<br />
Simulated results can also be compared with the theory. Word error probability can be computed by remarking that a received codeword cannot be decoded if it contains 2 or more errors:<br />
<br />
<math><br />
\begin{align}<br />
p_B &= \sum_{i=2}^7 \binom{7}{i} f^i (1-f)^{7-i}\\<br />
&\approx \binom{7}{2} f^2\\<br />
&\approx 21 f^2\\<br />
\end{align}<br />
</math><br />
<br />
Bit error rate can be estimated by noting that when a received codeword contains 2 error, the decoding algorithm will add 1 additional error:<br />
<br />
<math><br />
p_b \approx \frac{3}{7} p_B \approx 9 f^2<br />
</math><br />
<br />
IT++ library supports dozens of different codes, modulations and channels and allows to easily change the simulated system to quickly estimate the achievable performance.</div>Nicohttps://nicolas-barbot.ovh/wiki/index.php?title=MA331_Information_Theory_and_Channel_Coding&diff=456MA331 Information Theory and Channel Coding2021-08-31T09:45:52Z<p>Nico: </p>
<hr />
<div>The objective of this course is to understand how we can transmit a message in-between a transmitter and a receiver spatially (or temporally) separated. Especially, how we can use coding to realize an error free transmission over noisy channels. This beautiful result has been predicted by C. E. Shannon and relies on two distinct operations which are source coding and channel coding. This course is an introduction to information theory and describe the main algorithms in both source coding and channel coding. This course is related to [[SC311 Wireless Communications]] but tackle the communication problem mainly at the bit level.<br />
<br />
This course is composed of 3 parts. Slides (in french) for each part can be downloaded here:<br />
<br />
* [https://nicolas-barbot.ovh/wiki/pool/introduction.pdf 1 Introduction]<br />
<br />
* [https://nicolas-barbot.ovh/wiki/pool/information_theory.pdf 2 Information Theory]<br />
<br />
* [https://nicolas-barbot.ovh/wiki/pool/source_coding.pdf 3 Source Coding]<br />
<br />
* [https://nicolas-barbot.ovh/wiki/pool/channel_coding.pdf 4 Channel Coding]<br />
<br />
The following of this page corresponds to the labs.<br />
<br />
__TOC__<br />
<br />
This objective of this lab is to allow you to evaluate the performance of classical telecommunication system by simulating the transmission of a large quantity of random data (Monte Carlo method). A special focus is placed on the performance of forward error correcting codes over different channels. The original subject of this lab is based on Matlab (or Octave) and is available [https://nicolas-barbot.ovh/wiki/pool/lab.pdf here] (in French) where the objective is to estimate the performance of the classical Hamming code <math>H(7,4)</math> over the BSC channel of probability <math>f</math>.<br />
<br />
This wiki presents a different approach based on the [http://itpp.sourceforge.net/4.3.1/ IT++] library which allows to generalize the results for any forward error correcting code and any channel.<br />
<br />
== IT++ ==<br />
<br />
IT++ is a C++ library designed to evaluate the performance of different telecommunications systems. Several forward error correction codes have been implemented and can easily be<br />
characterized and compared. All the results presented during the course have been obtained using this library.<br />
<br />
== Hamming Code ==<br />
<br />
* After installing the library (which is maybe the hardest step of this lab), create a file <syntaxhighlight lang="text" inline>main.cpp</syntaxhighlight> and copy the following program.<br />
<br />
<syntaxhighlight lang="C++" line='line'><br />
#include <itpp/itcomm.h><br />
<br />
using namespace itpp;<br />
using std::cout;<br />
using std::endl;<br />
<br />
int main()<br />
{<br />
bvec bits, ebits, dbits;<br />
<br />
Hamming_Code hc(3);<br />
<br />
RNG_randomize();<br />
<br />
bits = randb(4); // Generate 4 random bits<br />
<br />
ebits = hc.encode(bits); // Encode with H(7,4)<br />
<br />
dbits = hc.decode(ebits); // Decode with H(7,4)<br />
<br />
cout << "bits = " << bits << endl;<br />
cout << "ebits = " << ebits << endl;<br />
cout << "dbits = " << dbits << endl;<br />
<br />
return 0;<br />
}<br />
</syntaxhighlight><br />
<br />
The program can be built with the following command:<br />
<br />
<syntaxhighlight lang="text"><br />
$ g++ `pkg-config --cflags itpp` -o main main.cpp `pkg-config --libs itpp`<br />
</syntaxhighlight><br />
<br />
If sucessfull, this command produces the binary file <syntaxhighlight lang="text" inline>main</syntaxhighlight> which can be directly executed by typing:<br />
<br />
<syntaxhighlight lang="text"><br />
$ ./main<br />
</syntaxhighlight><br />
<br />
* Determine the generator matrix <math>G</math> of the Hamming code <math>H(7,4)</math>.<br />
<br />
* Modify the encoded vector by adding 1 error on the codeword and observe the decoded codeword.<br />
<br />
* Same question with 2 errors.<br />
<br />
== Performance over BSC channel ==<br />
<br />
<syntaxhighlight lang="C++" line='line'><br />
#include <itpp/itcomm.h><br />
<br />
#define N 500000<br />
<br />
using namespace itpp;<br />
using std::cout;<br />
using std::endl;<br />
<br />
int main()<br />
{<br />
bvec bits, ebits, rbits, dbits;<br />
vec f = linspace(0.0, 0.5, 20);<br />
vec ber(p.length());<br />
<br />
BSC bsc;<br />
BERC berc;<br />
Hamming_Code hc(3);<br />
it_file ff;<br />
<br />
RNG_randomize();<br />
<br />
for (int i = 0; i < p.length(); i++)<br />
{<br />
bsc.set_prob(f(i)); // Set the error prob of the BSC<br />
bits = randb(N); // Generate N random bits<br />
ebits = hc.encode(bits); // Encode with H(7,4)<br />
rbits = bsc(ebits); // Transmit over BSC<br />
dbits = hc.decode(rbits); // Decode with H(7,4)<br />
berc.clear(); // Reset the counter<br />
berc.count(bits, dbits); // Count the errors<br />
ber(i) = berc.get_errorrate();<br />
}<br />
cout << "BER = " << ber << endl;<br />
ff.open("res.it"); // Save the results<br />
ff << Name("f") << f;<br />
ff << Name("ber") << ber;<br />
ff.close();<br />
<br />
return 0;<br />
}<br />
<br />
</syntaxhighlight><br />
<br />
<br />
Execution takes few seconds and display the BER for the different probabilities <math>f</math> of the BSC channel. Results are also saved in the file <syntaxhighlight lang="text" inline>res.it</syntaxhighlight><br />
and can be easily displayed using the <syntaxhighlight lang="text" inline>itload.m</syntaxhighlight> script using Matlab (or Octave):<br />
<br />
<syntaxhighlight lang="text"><br />
> itload('res.it');<br />
> plot(f, ber);<br />
</syntaxhighlight><br />
<br />
[[File:hamming.png|thumb|right|Performance of the Hamming code H(7,4) over BSC of probability <math>f</math>.]]<br />
<br />
Simulated results can also be compared with the theory. Word error probability can be computed by remarking that a received codeword cannot be decoded if it contains 2 or more errors:<br />
<br />
<math><br />
\begin{align}<br />
p_B &= \sum_{i=2}^7 \binom{7}{i} f^i (1-f)^{7-i}\\<br />
&\approx \binom{7}{2} f^2\\<br />
&\approx 21 f^2\\<br />
\end{align}<br />
</math><br />
<br />
Bit error rate can be estimated by noting that when a received codeword contains 2 error, the decoding algorithm will add 1 additional error:<br />
<br />
<math><br />
p_b \approx \frac{3}{7} p_B \approx 9 f^2<br />
</math><br />
<br />
IT++ library supports dozens of different codes, modulations and channels and allows to easily change the simulated system to quickly estimate the achievable performance.</div>Nicohttps://nicolas-barbot.ovh/wiki/index.php?title=MA331_Information_Theory_and_Channel_Coding&diff=455MA331 Information Theory and Channel Coding2021-08-31T09:39:37Z<p>Nico: </p>
<hr />
<div>The objective of this course is to understand how we can transmit a message in-between a transmitter and a receiver spatially (or temporally) separated. Especially, how we can use coding to realize an error free transmission over noisy channels. This beautiful result has been predicted by C. E. Shannon and relies on two distinct operations which are source coding and channel coding. This course is an introduction to information theory and describe the main algorithms in both source coding and channel coding. This course is related to [[SC311 Wireless Communications]] but tackle the communication problem mainly at the bit level.<br />
<br />
This course is composed of 3 parts. Slides (in french) for each part can be downloaded here:<br />
<br />
[https://nicolas-barbot.ovh/wiki/pool/introduction.pdf 1 Introduction]<br />
<br />
[https://nicolas-barbot.ovh/wiki/pool/information_theory.pdf 2 Information Theory]<br />
<br />
[https://nicolas-barbot.ovh/wiki/pool/source_coding.pdf 3 Source Coding]<br />
<br />
[https://nicolas-barbot.ovh/wiki/pool/channel_coding.pdf 4 Channel Coding]<br />
<br />
The following of this page corresponds to the labs.<br />
<br />
__TOC__<br />
<br />
This objective of this lab is to allow you to evaluate the performance of classical telecommunication system by simulating the transmission of a large quantity of random data (Monte Carlo method). A special focus is placed on the performance of forward error correcting codes over different channels. The original subject of this lab is based on Matlab (or Octave) and is available [http://localhost/export/lab.pdf here] (in French) where the objective is to estimate the performance of the classical Hamming code <math>H(7,4)</math> over the BSC channel of probability <math>f</math>.<br />
<br />
This wiki presents a different approach based on the [http://itpp.sourceforge.net/4.3.1/ IT++] library which allows to generalize the results for any forward error correcting code and any channel.<br />
<br />
== IT++ ==<br />
<br />
IT++ is a C++ library designed to evaluate the performance of different telecommunications systems. Several forward error correction codes have been implemented and can easily be<br />
characterized and compared. All the results presented during the course have been obtained using this library.<br />
<br />
== Hamming Code ==<br />
<br />
* After installing the library (which is maybe the hardest step of this lab), create a file <syntaxhighlight lang="text" inline>main.cpp</syntaxhighlight> and copy the following program.<br />
<br />
<syntaxhighlight lang="C++" line='line'><br />
#include <itpp/itcomm.h><br />
<br />
using namespace itpp;<br />
using std::cout;<br />
using std::endl;<br />
<br />
int main()<br />
{<br />
bvec bits, ebits, dbits;<br />
<br />
Hamming_Code hc(3);<br />
<br />
RNG_randomize();<br />
<br />
bits = randb(4); // Generate 4 random bits<br />
<br />
ebits = hc.encode(bits); // Encode with H(7,4)<br />
<br />
dbits = hc.decode(ebits); // Decode with H(7,4)<br />
<br />
cout << "bits = " << bits << endl;<br />
cout << "ebits = " << ebits << endl;<br />
cout << "dbits = " << dbits << endl;<br />
<br />
return 0;<br />
}<br />
</syntaxhighlight><br />
<br />
The program can be built with the following command:<br />
<br />
<syntaxhighlight lang="text"><br />
$ g++ `pkg-config --cflags itpp` -o main main.cpp `pkg-config --libs itpp`<br />
</syntaxhighlight><br />
<br />
If sucessfull, this command produces the binary file <syntaxhighlight lang="text" inline>main</syntaxhighlight> which can be directly executed by typing:<br />
<br />
<syntaxhighlight lang="text"><br />
$ ./main<br />
</syntaxhighlight><br />
<br />
* Determine the generator matrix <math>G</math> of the Hamming code <math>H(7,4)</math>.<br />
<br />
* Modify the encoded vector by adding 1 error on the codeword and observe the decoded codeword.<br />
<br />
* Same question with 2 errors.<br />
<br />
== Performance over BSC channel ==<br />
<br />
<syntaxhighlight lang="C++" line='line'><br />
#include <itpp/itcomm.h><br />
<br />
#define N 500000<br />
<br />
using namespace itpp;<br />
using std::cout;<br />
using std::endl;<br />
<br />
int main()<br />
{<br />
bvec bits, ebits, rbits, dbits;<br />
vec f = linspace(0.0, 0.5, 20);<br />
vec ber(p.length());<br />
<br />
BSC bsc;<br />
BERC berc;<br />
Hamming_Code hc(3);<br />
it_file ff;<br />
<br />
RNG_randomize();<br />
<br />
for (int i = 0; i < p.length(); i++)<br />
{<br />
bsc.set_prob(f(i)); // Set the error prob of the BSC<br />
bits = randb(N); // Generate N random bits<br />
ebits = hc.encode(bits); // Encode with H(7,4)<br />
rbits = bsc(ebits); // Transmit over BSC<br />
dbits = hc.decode(rbits); // Decode with H(7,4)<br />
berc.clear(); // Reset the counter<br />
berc.count(bits, dbits); // Count the errors<br />
ber(i) = berc.get_errorrate();<br />
}<br />
cout << "BER = " << ber << endl;<br />
ff.open("res.it"); // Save the results<br />
ff << Name("f") << f;<br />
ff << Name("ber") << ber;<br />
ff.close();<br />
<br />
return 0;<br />
}<br />
<br />
</syntaxhighlight><br />
<br />
<br />
Execution takes few seconds and display the BER for the different probabilities <math>f</math> of the BSC channel. Results are also saved in the file <syntaxhighlight lang="text" inline>res.it</syntaxhighlight><br />
and can be easily displayed using the <syntaxhighlight lang="text" inline>itload.m</syntaxhighlight> script using Matlab (or Octave):<br />
<br />
<syntaxhighlight lang="text"><br />
> itload('res.it');<br />
> plot(f, ber);<br />
</syntaxhighlight><br />
<br />
[[File:hamming.png|thumb|right|Performance of the Hamming code H(7,4) over BSC of probability <math>f</math>.]]<br />
<br />
Simulated results can also be compared with the theory. Word error probability can be computed by remarking that a received codeword cannot be decoded if it contains 2 or more errors:<br />
<br />
<math><br />
\begin{align}<br />
p_B &= \sum_{i=2}^7 \binom{7}{i} f^i (1-f)^{7-i}\\<br />
&\approx \binom{7}{2} f^2\\<br />
&\approx 21 f^2\\<br />
\end{align}<br />
</math><br />
<br />
Bit error rate can be estimated by noting that when a received codeword contains 2 error, the decoding algorithm will add 1 additional error:<br />
<br />
<math><br />
p_b \approx \frac{3}{7} p_B \approx 9 f^2<br />
</math><br />
<br />
IT++ library supports dozens of different codes, modulations and channels and allows to easily change the simulated system to quickly estimate the achievable performance.</div>Nicohttps://nicolas-barbot.ovh/wiki/index.php?title=MA331_Information_Theory_and_Channel_Coding&diff=454MA331 Information Theory and Channel Coding2021-08-31T09:36:04Z<p>Nico: </p>
<hr />
<div>The objective of this course is to understand how we can transmit a message in-between a transmitter and a receiver spatially (or temporally) separated. Especially, how we can use coding to realize an error free transmission over noisy channels. This beautiful result has been predicted by C. E. Shannon and relies on two distinct operations which are source coding and channel coding. This course is an introduction to information theory and describe the main algorithms in both source coding and channel coding. This course is related to [[SC311 Wireless Communications]] but tackle the communication problem mainly at the bit level.<br />
<br />
This course is composed of 3 parts. Slides (in french) for each part can be downloaded here:<br />
<br />
Introduction<br />
<br />
Information Theory<br />
<br />
Source Coding<br />
<br />
Channel Coding<br />
<br />
The following of this page corresponds to the labs.<br />
<br />
__TOC__<br />
<br />
This objective of this lab is to allow you to evaluate the performance of classical telecommunication system by simulating the transmission of a large quantity of random data (Monte Carlo method). A special focus is placed on the performance of forward error correcting codes over different channels. The original subject of this lab is based on Matlab (or Octave) and is available [http://localhost/export/lab.pdf here] (in French) where the objective is to estimate the performance of the classical Hamming code <math>H(7,4)</math> over the BSC channel of probability <math>f</math>.<br />
<br />
This wiki presents a different approach based on the [http://itpp.sourceforge.net/4.3.1/ IT++] library which allows to generalize the results for any forward error correcting code and any channel.<br />
<br />
== IT++ ==<br />
<br />
IT++ is a C++ library designed to evaluate the performance of different telecommunications systems. Several forward error correction codes have been implemented and can easily be<br />
characterized and compared. All the results presented during the course have been obtained using this library.<br />
<br />
== Hamming Code ==<br />
<br />
* After installing the library (which is maybe the hardest step of this lab), create a file <syntaxhighlight lang="text" inline>main.cpp</syntaxhighlight> and copy the following program.<br />
<br />
<syntaxhighlight lang="C++" line='line'><br />
#include <itpp/itcomm.h><br />
<br />
using namespace itpp;<br />
using std::cout;<br />
using std::endl;<br />
<br />
int main()<br />
{<br />
bvec bits, ebits, dbits;<br />
<br />
Hamming_Code hc(3);<br />
<br />
RNG_randomize();<br />
<br />
bits = randb(4); // Generate 4 random bits<br />
<br />
ebits = hc.encode(bits); // Encode with H(7,4)<br />
<br />
dbits = hc.decode(ebits); // Decode with H(7,4)<br />
<br />
cout << "bits = " << bits << endl;<br />
cout << "ebits = " << ebits << endl;<br />
cout << "dbits = " << dbits << endl;<br />
<br />
return 0;<br />
}<br />
</syntaxhighlight><br />
<br />
The program can be built with the following command:<br />
<br />
<syntaxhighlight lang="text"><br />
$ g++ `pkg-config --cflags itpp` -o main main.cpp `pkg-config --libs itpp`<br />
</syntaxhighlight><br />
<br />
If sucessfull, this command produces the binary file <syntaxhighlight lang="text" inline>main</syntaxhighlight> which can be directly executed by typing:<br />
<br />
<syntaxhighlight lang="text"><br />
$ ./main<br />
</syntaxhighlight><br />
<br />
* Determine the generator matrix <math>G</math> of the Hamming code <math>H(7,4)</math>.<br />
<br />
* Modify the encoded vector by adding 1 error on the codeword and observe the decoded codeword.<br />
<br />
* Same question with 2 errors.<br />
<br />
== Performance over BSC channel ==<br />
<br />
<syntaxhighlight lang="C++" line='line'><br />
#include <itpp/itcomm.h><br />
<br />
#define N 500000<br />
<br />
using namespace itpp;<br />
using std::cout;<br />
using std::endl;<br />
<br />
int main()<br />
{<br />
bvec bits, ebits, rbits, dbits;<br />
vec f = linspace(0.0, 0.5, 20);<br />
vec ber(p.length());<br />
<br />
BSC bsc;<br />
BERC berc;<br />
Hamming_Code hc(3);<br />
it_file ff;<br />
<br />
RNG_randomize();<br />
<br />
for (int i = 0; i < p.length(); i++)<br />
{<br />
bsc.set_prob(f(i)); // Set the error prob of the BSC<br />
bits = randb(N); // Generate N random bits<br />
ebits = hc.encode(bits); // Encode with H(7,4)<br />
rbits = bsc(ebits); // Transmit over BSC<br />
dbits = hc.decode(rbits); // Decode with H(7,4)<br />
berc.clear(); // Reset the counter<br />
berc.count(bits, dbits); // Count the errors<br />
ber(i) = berc.get_errorrate();<br />
}<br />
cout << "BER = " << ber << endl;<br />
ff.open("res.it"); // Save the results<br />
ff << Name("f") << f;<br />
ff << Name("ber") << ber;<br />
ff.close();<br />
<br />
return 0;<br />
}<br />
<br />
</syntaxhighlight><br />
<br />
<br />
Execution takes few seconds and display the BER for the different probabilities <math>f</math> of the BSC channel. Results are also saved in the file <syntaxhighlight lang="text" inline>res.it</syntaxhighlight><br />
and can be easily displayed using the <syntaxhighlight lang="text" inline>itload.m</syntaxhighlight> script using Matlab (or Octave):<br />
<br />
<syntaxhighlight lang="text"><br />
> itload('res.it');<br />
> plot(f, ber);<br />
</syntaxhighlight><br />
<br />
[[File:hamming.png|thumb|right|Performance of the Hamming code H(7,4) over BSC of probability <math>f</math>.]]<br />
<br />
Simulated results can also be compared with the theory. Word error probability can be computed by remarking that a received codeword cannot be decoded if it contains 2 or more errors:<br />
<br />
<math><br />
\begin{align}<br />
p_B &= \sum_{i=2}^7 \binom{7}{i} f^i (1-f)^{7-i}\\<br />
&\approx \binom{7}{2} f^2\\<br />
&\approx 21 f^2\\<br />
\end{align}<br />
</math><br />
<br />
Bit error rate can be estimated by noting that when a received codeword contains 2 error, the decoding algorithm will add 1 additional error:<br />
<br />
<math><br />
p_b \approx \frac{3}{7} p_B \approx 9 f^2<br />
</math><br />
<br />
IT++ library supports dozens of different codes, modulations and channels and allows to easily change the simulated system to quickly estimate the achievable performance.</div>Nicohttps://nicolas-barbot.ovh/wiki/index.php?title=MA331_Information_Theory_and_Channel_Coding&diff=453MA331 Information Theory and Channel Coding2021-08-27T15:56:26Z<p>Nico: </p>
<hr />
<div>The objective of this course is to understand how we can transmit a message in-between a transmitter and a receiver spatially (or temporally) separated. Especially, how we can use coding to realize an error free transmission over noisy channels. This beautiful result has been predicted by C. E. Shannon and relies on two distinct operations which are source coding and channel coding. This course is an introduction to information theory and describe the main algorithms in both source coding and channel coding. This course is related to [[SC311 Wireless Communications]] but tackle the communication problem mainly at the bit level.<br />
<br />
Slides of the course can be downloaded here. Exercises can be downloaded here. The following of this page corresponds to the labs.<br />
<br />
__TOC__<br />
<br />
This objective of this lab is to allow you to evaluate the performance of classical telecommunication system by simulating the transmission of a large quantity of random data (Monte Carlo method). A special focus is placed on the performance of forward error correcting codes over different channels. The original subject of this lab is based on Matlab (or Octave) and is available [http://localhost/export/lab.pdf here] (in French) where the objective is to estimate the performance of the classical Hamming code <math>H(7,4)</math> over the BSC channel of probability <math>f</math>.<br />
<br />
This wiki presents a different approach based on the [http://itpp.sourceforge.net/4.3.1/ IT++] library which allows to generalize the results for any forward error correcting code and any channel.<br />
<br />
== IT++ ==<br />
<br />
IT++ is a C++ library designed to evaluate the performance of different telecommunications systems. Several forward error correction codes have been implemented and can easily be<br />
characterized and compared. All the results presented during the course have been obtained using this library.<br />
<br />
== Hamming Code ==<br />
<br />
* After installing the library (which is maybe the hardest step of this lab), create a file <syntaxhighlight lang="text" inline>main.cpp</syntaxhighlight> and copy the following program.<br />
<br />
<syntaxhighlight lang="C++" line='line'><br />
#include <itpp/itcomm.h><br />
<br />
using namespace itpp;<br />
using std::cout;<br />
using std::endl;<br />
<br />
int main()<br />
{<br />
bvec bits, ebits, dbits;<br />
<br />
Hamming_Code hc(3);<br />
<br />
RNG_randomize();<br />
<br />
bits = randb(4); // Generate 4 random bits<br />
<br />
ebits = hc.encode(bits); // Encode with H(7,4)<br />
<br />
dbits = hc.decode(ebits); // Decode with H(7,4)<br />
<br />
cout << "bits = " << bits << endl;<br />
cout << "ebits = " << ebits << endl;<br />
cout << "dbits = " << dbits << endl;<br />
<br />
return 0;<br />
}<br />
</syntaxhighlight><br />
<br />
The program can be built with the following command:<br />
<br />
<syntaxhighlight lang="text"><br />
$ g++ `pkg-config --cflags itpp` -o main main.cpp `pkg-config --libs itpp`<br />
</syntaxhighlight><br />
<br />
If sucessfull, this command produces the binary file <syntaxhighlight lang="text" inline>main</syntaxhighlight> which can be directly executed by typing:<br />
<br />
<syntaxhighlight lang="text"><br />
$ ./main<br />
</syntaxhighlight><br />
<br />
* Determine the generator matrix <math>G</math> of the Hamming code <math>H(7,4)</math>.<br />
<br />
* Modify the encoded vector by adding 1 error on the codeword and observe the decoded codeword.<br />
<br />
* Same question with 2 errors.<br />
<br />
== Performance over BSC channel ==<br />
<br />
<syntaxhighlight lang="C++" line='line'><br />
#include <itpp/itcomm.h><br />
<br />
#define N 500000<br />
<br />
using namespace itpp;<br />
using std::cout;<br />
using std::endl;<br />
<br />
int main()<br />
{<br />
bvec bits, ebits, rbits, dbits;<br />
vec f = linspace(0.0, 0.5, 20);<br />
vec ber(p.length());<br />
<br />
BSC bsc;<br />
BERC berc;<br />
Hamming_Code hc(3);<br />
it_file ff;<br />
<br />
RNG_randomize();<br />
<br />
for (int i = 0; i < p.length(); i++)<br />
{<br />
bsc.set_prob(f(i)); // Set the error prob of the BSC<br />
bits = randb(N); // Generate N random bits<br />
ebits = hc.encode(bits); // Encode with H(7,4)<br />
rbits = bsc(ebits); // Transmit over BSC<br />
dbits = hc.decode(rbits); // Decode with H(7,4)<br />
berc.clear(); // Reset the counter<br />
berc.count(bits, dbits); // Count the errors<br />
ber(i) = berc.get_errorrate();<br />
}<br />
cout << "BER = " << ber << endl;<br />
ff.open("res.it"); // Save the results<br />
ff << Name("f") << f;<br />
ff << Name("ber") << ber;<br />
ff.close();<br />
<br />
return 0;<br />
}<br />
<br />
</syntaxhighlight><br />
<br />
<br />
Execution takes few seconds and display the BER for the different probabilities <math>f</math> of the BSC channel. Results are also saved in the file <syntaxhighlight lang="text" inline>res.it</syntaxhighlight><br />
and can be easily displayed using the <syntaxhighlight lang="text" inline>itload.m</syntaxhighlight> script using Matlab (or Octave):<br />
<br />
<syntaxhighlight lang="text"><br />
> itload('res.it');<br />
> plot(f, ber);<br />
</syntaxhighlight><br />
<br />
[[File:hamming.png|thumb|right|Performance of the Hamming code H(7,4) over BSC of probability <math>f</math>.]]<br />
<br />
Simulated results can also be compared with the theory. Word error probability can be computed by remarking that a received codeword cannot be decoded if it contains 2 or more errors:<br />
<br />
<math><br />
\begin{align}<br />
p_B &= \sum_{i=2}^7 \binom{7}{i} f^i (1-f)^{7-i}\\<br />
&\approx \binom{7}{2} f^2\\<br />
&\approx 21 f^2\\<br />
\end{align}<br />
</math><br />
<br />
Bit error rate can be estimated by noting that when a received codeword contains 2 error, the decoding algorithm will add 1 additional error:<br />
<br />
<math><br />
p_b \approx \frac{3}{7} p_B \approx 9 f^2<br />
</math><br />
<br />
IT++ library supports dozens of different codes, modulations and channels and allows to easily change the simulated system to quickly estimate the achievable performance.</div>Nicohttps://nicolas-barbot.ovh/wiki/index.php?title=MA331_Information_Theory_and_Channel_Coding&diff=452MA331 Information Theory and Channel Coding2021-08-27T07:51:27Z<p>Nico: </p>
<hr />
<div>The objective of this course is to understand how we can transmit a message in-between a transmitter and a receiver spatially (or temporally) separated. Especially, how we can use coding to adapt (i.e. remove redundancy form the source and add redundancy to protect the information from the channel) the message to realize the transmission over (theoretical) simple channels. This course describes the processes realized at a bit level and can be related to [[SC311 Wireless Communications]] (which presents the specific problem at a lower level).<br />
<br />
Slides of the course can be downloaded here. Exercises can be downloaded here. The following of this page corresponds to the labs.<br />
<br />
__TOC__<br />
<br />
This objective of this lab is to allow you to evaluate the performance of classical telecommunication system by simulating the transmission of a large quantity of random data (Monte Carlo method). A special focus is placed on the performance of forward error correcting codes over different channels. The original subject of this lab is based on Matlab (or Octave) and is available [http://localhost/export/lab.pdf here] (in French) where the objective is to estimate the performance of the classical Hamming code <math>H(7,4)</math> over the BSC channel of probability <math>f</math>.<br />
<br />
This wiki presents a different approach based on the [http://itpp.sourceforge.net/4.3.1/ IT++] library which allows to generalize the results for any forward error correcting code and any channel.<br />
<br />
== IT++ ==<br />
<br />
IT++ is a C++ library designed to evaluate the performance of different telecommunications systems. Several forward error correction codes have been implemented and can easily be<br />
characterized and compared. All the results presented during the course have been obtained using this library.<br />
<br />
== Hamming Code ==<br />
<br />
* After installing the library (which is maybe the hardest step of this lab), create a file <syntaxhighlight lang="text" inline>main.cpp</syntaxhighlight> and copy the following program.<br />
<br />
<syntaxhighlight lang="C++" line='line'><br />
#include <itpp/itcomm.h><br />
<br />
using namespace itpp;<br />
using std::cout;<br />
using std::endl;<br />
<br />
int main()<br />
{<br />
bvec bits, ebits, dbits;<br />
<br />
Hamming_Code hc(3);<br />
<br />
RNG_randomize();<br />
<br />
bits = randb(4); // Generate 4 random bits<br />
<br />
ebits = hc.encode(bits); // Encode with H(7,4)<br />
<br />
dbits = hc.decode(ebits); // Decode with H(7,4)<br />
<br />
cout << "bits = " << bits << endl;<br />
cout << "ebits = " << ebits << endl;<br />
cout << "dbits = " << dbits << endl;<br />
<br />
return 0;<br />
}<br />
</syntaxhighlight><br />
<br />
The program can be built with the following command:<br />
<br />
<syntaxhighlight lang="text"><br />
$ g++ `pkg-config --cflags itpp` -o main main.cpp `pkg-config --libs itpp`<br />
</syntaxhighlight><br />
<br />
If sucessfull, this command produces the binary file <syntaxhighlight lang="text" inline>main</syntaxhighlight> which can be directly executed by typing:<br />
<br />
<syntaxhighlight lang="text"><br />
$ ./main<br />
</syntaxhighlight><br />
<br />
* Determine the generator matrix <math>G</math> of the Hamming code <math>H(7,4)</math>.<br />
<br />
* Modify the encoded vector by adding 1 error on the codeword and observe the decoded codeword.<br />
<br />
* Same question with 2 errors.<br />
<br />
== Performance over BSC channel ==<br />
<br />
<syntaxhighlight lang="C++" line='line'><br />
#include <itpp/itcomm.h><br />
<br />
#define N 500000<br />
<br />
using namespace itpp;<br />
using std::cout;<br />
using std::endl;<br />
<br />
int main()<br />
{<br />
bvec bits, ebits, rbits, dbits;<br />
vec f = linspace(0.0, 0.5, 20);<br />
vec ber(p.length());<br />
<br />
BSC bsc;<br />
BERC berc;<br />
Hamming_Code hc(3);<br />
it_file ff;<br />
<br />
RNG_randomize();<br />
<br />
for (int i = 0; i < p.length(); i++)<br />
{<br />
bsc.set_prob(f(i)); // Set the error prob of the BSC<br />
bits = randb(N); // Generate N random bits<br />
ebits = hc.encode(bits); // Encode with H(7,4)<br />
rbits = bsc(ebits); // Transmit over BSC<br />
dbits = hc.decode(rbits); // Decode with H(7,4)<br />
berc.clear(); // Reset the counter<br />
berc.count(bits, dbits); // Count the errors<br />
ber(i) = berc.get_errorrate();<br />
}<br />
cout << "BER = " << ber << endl;<br />
ff.open("res.it"); // Save the results<br />
ff << Name("f") << f;<br />
ff << Name("ber") << ber;<br />
ff.close();<br />
<br />
return 0;<br />
}<br />
<br />
</syntaxhighlight><br />
<br />
<br />
Execution takes few seconds and display the BER for the different probabilities <math>f</math> of the BSC channel. Results are also saved in the file <syntaxhighlight lang="text" inline>res.it</syntaxhighlight><br />
and can be easily displayed using the <syntaxhighlight lang="text" inline>itload.m</syntaxhighlight> script using Matlab (or Octave):<br />
<br />
<syntaxhighlight lang="text"><br />
> itload('res.it');<br />
> plot(f, ber);<br />
</syntaxhighlight><br />
<br />
[[File:hamming.png|thumb|right|Performance of the Hamming code H(7,4) over BSC of probability <math>f</math>.]]<br />
<br />
Simulated results can also be compared with the theory. Word error probability can be computed by remarking that a received codeword cannot be decoded if it contains 2 or more errors:<br />
<br />
<math><br />
\begin{align}<br />
p_B &= \sum_{i=2}^7 \binom{7}{i} f^i (1-f)^{7-i}\\<br />
&\approx \binom{7}{2} f^2\\<br />
&\approx 21 f^2\\<br />
\end{align}<br />
</math><br />
<br />
Bit error rate can be estimated by noting that when a received codeword contains 2 error, the decoding algorithm will add 1 additional error:<br />
<br />
<math><br />
p_b \approx \frac{3}{7} p_B \approx 9 f^2<br />
</math><br />
<br />
IT++ library supports dozens of different codes, modulations and channels and allows to easily change the simulated system to quickly estimate the achievable performance.</div>Nicohttps://nicolas-barbot.ovh/wiki/index.php?title=File:Fm1.png&diff=451File:Fm1.png2021-08-22T13:45:14Z<p>Nico: </p>
<hr />
<div></div>Nicohttps://nicolas-barbot.ovh/wiki/index.php?title=SC311_Wireless_Communications&diff=450SC311 Wireless Communications2021-08-22T13:42:54Z<p>Nico: </p>
<hr />
<div>The objective of this course is to understand how we can transmit a message in-between a transmitter and a receiver spatially separated. Especially, how we can use signal processing operations to adapt (i.e. modulate and demodulate) the message to realize the transmission over wired or wireless channels. This course describes the processes realized at a signal level and can be related to [[MA331 Information Theory and Channel Coding]] (which presents the general problem at a higher level).<br />
<br />
Slides of the course can be downloaded here. Exercises can be downloaded here. The following of this page corresponds to the labs.<br />
<br />
__TOC__<br />
<br />
In this labs, we will realize different modulations and demodulations used to transmit and receive analog and digital messages.<br />
Spectrum (or power spectral density) will also be determined.<br />
Finally, performance, in term of Sinal to Noise Ratio (SNR) or Bit Error Rate (BER) will be estimated in each case.<br />
<br />
These labs are based on [https://www.gnuradio.org/ GNU Radio] which is a free software that provides a large number of software blocks to perform most signal processing operations. The blocks are mostly written in C ++. It is possible to use these blocks directly from Python to simulate or create telecommunication systems.<br />
In addition, to make it easier to get started, GNU Radio also provides a utility called <syntaxhighlight lang="text" inline>gnuradio-companion</syntaxhighlight> to assemble blocks graphically and to generate the corresponding python script. This subject have been written for GNU Radio, but it can be equivalently realized using [https://www.gnu.org/software/octave/index Octave], or [http://itpp.sourceforge.net/4.3.1/ IT++] library.<br />
<br />
== Getting Started ==<br />
<br />
* Open a terminal.<br />
<br />
* Create a working directory in which you will place your scripts.<br />
<br />
* Run <syntaxhighlight lang="text" inline>gnuradio-companion</syntaxhighlight>.<br />
<br />
This software allows you to use blocks (available in the right column) and to connect them to realize any complex signal processing operations. Resulting program is called a flowgraph in GNU Radio language.<br />
<br />
For any flowgraph, there is basically 3 types of blocks: sources (which produce samples and have at least 1 output), sinks (which consume samples and have at least 1 input) and processing block (which have at least 1 input and 1 output). Blocks are simply connected by creating a link in-between an output of a block and an input of another block.<br />
<br />
* Create the flowgraph presented in Fig. 1.<br />
<br />
[[File:Im1.png|frame|center|Fig. 1: Simple generation and data plotting]]<br />
<br />
The <syntaxhighlight lang="text" inline>Signal Source</syntaxhighlight> block generates an infinity of sinusoidal samples (or other) from the different parameters. These samples are displayed according to the time using the <syntaxhighlight lang="text" inline>Scope Sink</syntaxhighlight> block. <syntaxhighlight lang="text" inline>Throttle</syntaxhighlight> block does not modify the samples but allows to perform a flow control on all the data circulating between the source and the sink. Last, be careful to the color of the input and output of each block since they represent the type of data flowing on the link. The following table presents main data type and associated used by GNU Radio. Also, since Python is strongly typed, colors located at both ends of a wire have to be the same.<br />
<br />
{| class="wikitable" style="text-align: left;"<br />
|-<br />
!Color<br />
!Type<br />
!Size<br />
|-<br />
|style="background: #3399ff;"|<br />
|Complex<br />
|2 x 64 bits<br />
|-<br />
|style="background: #f57c00;"|<br />
|Float<br />
|64 bits<br />
|-<br />
|style="background: #009688;"|<br />
|Int<br />
|64/32 bits<br />
|-<br />
|style="background: #ffeb3b;"|<br />
|Short<br />
|16 bits<br />
|-<br />
|style="background: #d500f9;"|<br />
|Char<br />
|8 bits<br />
|}<br />
<br />
* Save the flowgraph under your directory. This file is saved with a <syntaxhighlight lang="text" inline>.grc</syntaxhighlight> extension.<br />
<br />
* Generate the associated Python script associated to your flowgraph using the "blue to red" button. If errors are present, the script is not generated and full listing is present under the no entry sign. When successful, observe the python script named <syntaxhighlight lang="text" inline>top_block.py</syntaxhighlight> in your directory.<br />
<br />
* Execute the script by pressing the run button. Equivalently, you can also invoke <syntaxhighlight lang="text" inline>python top_block.py</syntaxhighlight>.<br />
<br />
The execution should display an oscilloscope-like widow with the corresponding signal (a cosine function). You can stop the execution by closing the window or by pressing the stop button.<br />
<br />
* Check the amplitude and the period of the generated signal.<br />
<br />
* Finally, add a <syntaxhighlight lang="text" inline>Slider</syntaxhighlight> block to modify the frequency of the signal in real time (without recompiling the flowgraph) and check the operation on the scope. Save the flowgraph.<br />
<br />
Note that the source simply generates samples which are plotted by the sink, however, this source and this sink can produce and consume as much data that your CPU can handle (data are just generated and plotted iteratively as fast as possible). To overcome this issue, the <syntaxhighlight lang="text" inline>Throttle</syntaxhighlight> block is used to process a given number of sample per second, thus lowering the CPU load to few percents. Most of the blocks in GNU Radio do not fixed the rate at which samples are processed: when sufficient number of samples are present at the input, the considered function is called and produces samples at the output which are then available for the other blocks. Usually, this rate is fixed when we work with real devices (for example an audio card can acquire samples at a given frequency e.g. 48 kHz) which fixed the rate for the whole flowgraph. In our example, we do not use any real device so the rate has to be fixed using the <syntaxhighlight lang="text" inline>Throttle</syntaxhighlight> block. Also, for each flowgraph, a single rate has to be used thus if we work with a real device, the <syntaxhighlight lang="text" inline>Throttle</syntaxhighlight> block is not needed anymore and has to be removed.<br />
<br />
<br />
* Create the flowgraph presented in Fig. 2.<br />
<br />
[[File:Im2.png|frame|center|Fig. 2: Simple operations on signals]]<br />
<br />
* Add a <syntaxhighlight lang="text" inline>FFT Sink</syntaxhighlight> to observe the signal spectrum. On the graph, the two peaks are very close and seem to be confused. Reduce the frequency sampling to increase the frequency resolution. Explain the phenomenum.<br />
<br />
* What is the minimum value of the sampling frequency? Observe the signal (in time and in frequency) for frequencies below this limit.<br />
<br />
* Replace the <syntaxhighlight lang="text" inline>Add</syntaxhighlight> block with a multiplier block <syntaxhighlight lang="text" inline>Mult</syntaxhighlight>. Predict the position of the peaks in the output signal. Check your results.<br />
<br />
* Add a filter (block <syntaxhighlight lang="text" inline>Low Pass Filter</syntaxhighlight>) to recover the low frequency part of the signal. Check your results in the time and frequency domain. Repeat the manipulation to keep the high frequency part.<br />
<br />
The <syntaxhighlight lang="text" inline>Low Pass Filter</syntaxhighlight> (and <syntaxhighlight lang="text" inline>High Pass Filter</syntaxhighlight>) blocks are high-level blocks which realize the design (i.e. determining the coefficients of the filter) as well as the filtering (i.e. the convolution). The filter design can also be done with <syntaxhighlight lang="text" inline>gr_filter_design</syntaxhighlight> to obtain the coefficients. These coefficients can then be used directly by the blocks <syntaxhighlight lang="text" inline>FIR Filter</syntaxhighlight> and <syntaxhighlight lang="text" inline>IIR Filter</syntaxhighlight>.<br />
<br />
== Amplitude Modulation ==<br />
<br />
=== Double side band without carrier ===<br />
<br />
* Realize the modulation of a signal <math>m(t)=\cos 2\pi f_m t</math> using a double side band without carrier. Note that transmitted signal can be expressed as<br />
<br />
<math><br />
s(t) = A m(t) \cos 2 \pi f_0 t<br />
</math><br />
<br />
* Observe the signal in both time and frequency domain.<br />
<br />
* Give the architecture of a coherent detector used to recover the message <math>m(t)</math> from <math>x(t)</math>.<br />
<br />
* Implement this detector to demodulate the signal and verify the good operation. You can use 2 different flowgraphs (1 for the transmission and 1 for the reception) using a <syntaxhighlight lang="text" inline>File Sink</syntaxhighlight> and <syntaxhighlight lang="text" inline>File Source</syntaxhighlight> respectively.<br />
<br />
=== Double side band without carrier ===<br />
<br />
* Realize the modulation of a signal <math>m(t)=\cos 2\pi f_m t</math> using a double side band with carrier. Note that transmitted signal can be expressed as<br />
<br />
[[File:Env.png|thumb|right|Fig. 3: Envelope detector used for AM signals.]]<br />
<br />
<math><br />
s(t) = A (1 + k_a m(t)) \cos 2 \pi f_0 t<br />
</math><br />
<br />
* Observe the signal in both time and frequency domain.<br />
<br />
* Modify the modulation index <math>k_a</math> using a slider and observe the modification of the signal.<br />
<br />
* AM signals are usually demodulted using a simple envelope detector. The architecture of this decoder is presented in Fig. 3.<br />
<br />
* Implement this detector to demodulate the signal and verify the good operation.<br />
<br />
* Check also if the AM signal can be decoded using the coherent detector.<br />
<br />
* Finally, download the file [https://nicolas-barbot.ovh/wiki/pool/am_usrp710.dat <syntaxhighlight lang="text" inline>am_usrp710.dat</syntaxhighlight>]. This file contains the complex envelope (I and Q channels) received by a USRP around the frequency 710 kHz with a sampling frequency of 256 kHz. Visualize the data with a block <syntaxhighlight lang="text" inline>FFT Sink</syntaxhighlight> (insert a block <syntaxhighlight lang="text" inline>Throttle</syntaxhighlight> to avoid overloading the processor). On the graph, we can see two stations transmit at 710 kHz (center) and 790 kHz (to the right). Knowing that the bandwidth of an AM signal is 10 kHz, insert a low pass filter allowing to select the station located around 710 kHz. Check that the filter is working properly on the graph. Insert the envelope detector at the output of the filter and a block <syntaxhighlight lang="text" inline>Rational Resampler</syntaxhighlight> to adapt the bit rate to the sound card (48 kHz) using an <syntaxhighlight lang="text" inline>Audio Sink</syntaxhighlight>.<br />
<br />
* Check the correct operation on the PC speakers (add if needed a <syntaxhighlight lang="text" inline>Multiply Const.</syntaxhighlight> block to set the volume of the station).<br />
<br />
* Bonus: Demodulate the station at 790 kHz.<br />
<br />
== Frequency Modulation ==<br />
<br />
Expression of a frequency modulated signal is given by:<br />
<br />
<math><br />
s(t) = A \cos(2\pi f_0 t + 2\pi k_f \int_0^t m(u) du)<br />
</math><br />
<br />
Spectrum for general signal is usually unknown unless for very simple cases.<br />
<br />
* Create the following flowgraph to generate a frequency (or phase) modulated signal.<br />
<br />
[[File:Fm1.png|frame|center|Fig. 4: Frequency modulation generation.]]<br />
<br />
* Observe the transmitted spectrum.<br />
<br />
* Find the values of the modulation index <math>\beta</math> to cancel the power at <math>f_0</math>, <math>f_0\pm f_m</math>, <math>f_0\pm 2f_m</math>...<br />
<br />
* Create a decoder for the transmitted signal. Check the correct operation for different messages <math>m(t)</math><br />
<br />
== Digital Communication ==</div>Nicohttps://nicolas-barbot.ovh/wiki/index.php?title=SC311_Wireless_Communications&diff=449SC311 Wireless Communications2021-08-22T13:13:47Z<p>Nico: </p>
<hr />
<div>The objective of this course is to understand how we can transmit a message in-between a transmitter and a receiver spatially separated. Especially, how we can use signal processing operations to adapt (i.e. modulate and demodulate) the message to realize the transmission over wired or wireless channels. This course describes the processes realized at a signal level and can be related to [[MA331 Information Theory and Channel Coding]] (which presents the general problem at a higher level).<br />
<br />
Slides of the course can be downloaded here. Exercises can be downloaded here. The following of this page corresponds to the labs.<br />
<br />
__TOC__<br />
<br />
In this labs, we will realize different modulations and demodulations used to transmit and receive analog and digital messages.<br />
Spectrum (or power spectral density) will also be determined.<br />
Finally, performance, in term of Sinal to Noise Ratio (SNR) or Bit Error Rate (BER) will be estimated in each case.<br />
<br />
These labs are based on [https://www.gnuradio.org/ GNU Radio] which is a free software that provides a large number of software blocks to perform most signal processing operations. The blocks are mostly written in C ++. It is possible to use these blocks directly from Python to simulate or create telecommunication systems.<br />
In addition, to make it easier to get started, GNU Radio also provides a utility called <syntaxhighlight lang="text" inline>gnuradio-companion</syntaxhighlight> to assemble blocks graphically and to generate the corresponding python script. This subject have been written for GNU Radio, but it can be equivalently realized using [https://www.gnu.org/software/octave/index Octave], or [http://itpp.sourceforge.net/4.3.1/ IT++] library.<br />
<br />
== Getting Started ==<br />
<br />
* Open a terminal.<br />
<br />
* Create a working directory in which you will place your scripts.<br />
<br />
* Run <syntaxhighlight lang="text" inline>gnuradio-companion</syntaxhighlight>.<br />
<br />
This software allows you to use blocks (available in the right column) and to connect them to realize any complex signal processing operations. Resulting program is called a flowgraph in GNU Radio language.<br />
<br />
For any flowgraph, there is basically 3 types of blocks: sources (which produce samples and have at least 1 output), sinks (which consume samples and have at least 1 input) and processing block (which have at least 1 input and 1 output). Blocks are simply connected by creating a link in-between an output of a block and an input of another block.<br />
<br />
* Create the flowgraph presented in Fig. 1.<br />
<br />
[[File:Im1.png|frame|center|Fig. 1: Simple generation and data plotting]]<br />
<br />
The <syntaxhighlight lang="text" inline>Signal Source</syntaxhighlight> block generates an infinity of sinusoidal samples (or other) from the different parameters. These samples are displayed according to the time using the <syntaxhighlight lang="text" inline>Scope Sink</syntaxhighlight> block. <syntaxhighlight lang="text" inline>Throttle</syntaxhighlight> block does not modify the samples but allows to perform a flow control on all the data circulating between the source and the sink. Last, be careful to the color of the input and output of each block since they represent the type of data flowing on the link. The following table presents main data type and associated used by GNU Radio. Also, since Python is strongly typed, colors located at both ends of a wire have to be the same.<br />
<br />
{| class="wikitable" style="text-align: left;"<br />
|-<br />
!Color<br />
!Type<br />
!Size<br />
|-<br />
|style="background: #3399ff;"|<br />
|Complex<br />
|2 x 64 bits<br />
|-<br />
|style="background: #f57c00;"|<br />
|Float<br />
|64 bits<br />
|-<br />
|style="background: #009688;"|<br />
|Int<br />
|64/32 bits<br />
|-<br />
|style="background: #ffeb3b;"|<br />
|Short<br />
|16 bits<br />
|-<br />
|style="background: #d500f9;"|<br />
|Char<br />
|8 bits<br />
|}<br />
<br />
* Save the flowgraph under your directory. This file is saved with a <syntaxhighlight lang="text" inline>.grc</syntaxhighlight> extension.<br />
<br />
* Generate the associated Python script associated to your flowgraph using the "blue to red" button. If errors are present, the script is not generated and full listing is present under the no entry sign. When successful, observe the python script named <syntaxhighlight lang="text" inline>top_block.py</syntaxhighlight> in your directory.<br />
<br />
* Execute the script by pressing the run button. Equivalently, you can also invoke <syntaxhighlight lang="text" inline>python top_block.py</syntaxhighlight>.<br />
<br />
The execution should display an oscilloscope-like widow with the corresponding signal (a cosine function). You can stop the execution by closing the window or by pressing the stop button.<br />
<br />
* Check the amplitude and the period of the generated signal.<br />
<br />
* Finally, add a <syntaxhighlight lang="text" inline>Slider</syntaxhighlight> block to modify the frequency of the signal in real time (without recompiling the flowgraph) and check the operation on the scope. Save the flowgraph.<br />
<br />
Note that the source simply generates samples which are plotted by the sink, however, this source and this sink can produce and consume as much data that your CPU can handle (data are just generated and plotted iteratively as fast as possible). To overcome this issue, the <syntaxhighlight lang="text" inline>Throttle</syntaxhighlight> block is used to process a given number of sample per second, thus lowering the CPU load to few percents. Most of the blocks in GNU Radio do not fixed the rate at which samples are processed: when sufficient number of samples are present at the input, the considered function is called and produces samples at the output which are then available for the other blocks. Usually, this rate is fixed when we work with real devices (for example an audio card can acquire samples at a given frequency e.g. 48 kHz) which fixed the rate for the whole flowgraph. In our example, we do not use any real device so the rate has to be fixed using the <syntaxhighlight lang="text" inline>Throttle</syntaxhighlight> block. Also, for each flowgraph, a single rate has to be used thus if we work with a real device, the <syntaxhighlight lang="text" inline>Throttle</syntaxhighlight> block is not needed anymore and has to be removed.<br />
<br />
<br />
* Create the flowgraph presented in Fig. 2.<br />
<br />
[[File:Im2.png|frame|center|Fig. 2: Simple operations on signals]]<br />
<br />
* Add a <syntaxhighlight lang="text" inline>FFT Sink</syntaxhighlight> to observe the signal spectrum. On the graph, the two peaks are very close and seem to be confused. Reduce the frequency sampling to increase the frequency resolution. Explain the phenomenum.<br />
<br />
* What is the minimum value of the sampling frequency? Observe the signal (in time and in frequency) for frequencies below this limit.<br />
<br />
* Replace the <syntaxhighlight lang="text" inline>Add</syntaxhighlight> block with a multiplier block <syntaxhighlight lang="text" inline>Mult</syntaxhighlight>. Predict the position of the peaks in the output signal. Check your results.<br />
<br />
* Add a filter (block <syntaxhighlight lang="text" inline>Low Pass Filter</syntaxhighlight>) to recover the low frequency part of the signal. Check your results in the time and frequency domain. Repeat the manipulation to keep the high frequency part.<br />
<br />
The <syntaxhighlight lang="text" inline>Low Pass Filter</syntaxhighlight> (and <syntaxhighlight lang="text" inline>High Pass Filter</syntaxhighlight>) blocks are high-level blocks which realize the design (i.e. determining the coefficients of the filter) as well as the filtering (i.e. the convolution). The filter design can also be done with <syntaxhighlight lang="text" inline>gr_filter_design</syntaxhighlight> to obtain the coefficients. These coefficients can then be used directly by the blocks <syntaxhighlight lang="text" inline>FIR Filter</syntaxhighlight> and <syntaxhighlight lang="text" inline>IIR Filter</syntaxhighlight>.<br />
<br />
== Amplitude Modulation ==<br />
<br />
=== Double side band without carrier ===<br />
<br />
* Realize the modulation of a signal <math>m(t)=\cos 2\pi f_m t</math> using a double side band without carrier. Note that transmitted signal can be expressed as<br />
<br />
<math><br />
x(t) = A m(t) \cos 2 \pi f_0 t<br />
</math><br />
<br />
* Observe the signal in both time and frequency domain.<br />
<br />
* Give the architecture of a coherent detector used to recover the message <math>m(t)</math> from <math>x(t)</math>.<br />
<br />
* Implement this detector to demodulate the signal and verify the good operation. You can use 2 different flowgraphs (1 for the transmission and 1 for the reception) using a <syntaxhighlight lang="text" inline>File Sink</syntaxhighlight> and <syntaxhighlight lang="text" inline>File Source</syntaxhighlight> respectively.<br />
<br />
=== Double side band without carrier ===<br />
<br />
* Realize the modulation of a signal <math>m(t)=\cos 2\pi f_m t</math> using a double side band with carrier. Note that transmitted signal can be expressed as<br />
<br />
[[File:Env.png|thumb|right|Fig. 3: Envelope detector used for AM signals.]]<br />
<br />
<math><br />
x(t) = A (1 + k_a m(t)) \cos 2 \pi f_0 t<br />
</math><br />
<br />
* Observe the signal in both time and frequency domain.<br />
<br />
* Modify the modulation index <math>k_a</math> using a slider and observe the modification of the signal.<br />
<br />
* AM signals are usually demodulted using a simple envelope detector. The architecture of this decoder is presented in Fig. 3.<br />
<br />
* Implement this detector to demodulate the signal and verify the good operation.<br />
<br />
* Check also if the AM signal can be decoded using the coherent detector.<br />
<br />
* Finally, download the file [https://nicolas-barbot.ovh/wiki/pool/am_usrp710.dat <syntaxhighlight lang="text" inline>am_usrp710.dat</syntaxhighlight>]. This file contains the complex envelope (I and Q channels) received by a USRP around the frequency 710 kHz with a sampling frequency of 256 kHz. Visualize the data with a block <syntaxhighlight lang="text" inline>FFT Sink</syntaxhighlight> (insert a block <syntaxhighlight lang="text" inline>Throttle</syntaxhighlight> to avoid overloading the processor). On the graph, we can see two stations transmit at 710 kHz (center) and 790 kHz (to the right). Knowing that the bandwidth of an AM signal is 10 kHz, insert a low pass filter allowing to select the station located around 710 kHz. Check that the filter is working properly on the graph. Insert the envelope detector at the output of the filter and a block <syntaxhighlight lang="text" inline>Rational Resampler</syntaxhighlight> to adapt the bit rate to the sound card (48 kHz) using an <syntaxhighlight lang="text" inline>Audio Sink</syntaxhighlight>.<br />
<br />
* Check the correct operation on the PC speakers (add if needed a <syntaxhighlight lang="text" inline>Multiply Const.</syntaxhighlight> block to set the volume of the station).<br />
<br />
* Bonus: Demodulate the station at 790 kHz.<br />
<br />
== Frequency Modulation ==<br />
<br />
== Digital Communication ==</div>Nicohttps://nicolas-barbot.ovh/wiki/index.php?title=SC311_Wireless_Communications&diff=448SC311 Wireless Communications2021-08-20T21:08:33Z<p>Nico: </p>
<hr />
<div>The objective of this course is to understand how we can transmit a message in-between a transmitter and a receiver spatially separated. Especially, how we can use signal processing operations to adapt (i.e. modulate and demodulate) the message to realize the transmission over wired or wireless channels. This course describes the processes realized at a signal level and can be related to [[MA331 Information Theory and Channel Coding]] (which presents the general problem at a higher level).<br />
<br />
Slides of the course can be downloaded here. Exercises can be downloaded here. The following of this page corresponds to the labs.<br />
<br />
__TOC__<br />
<br />
In this labs, we will realize different modulations and demodulations used to transmit and receive analog and digital messages.<br />
Spectrum (or power spectral density) will also be determined.<br />
Finally, performance, in term of Sinal to Noise Ratio (SNR) or Bit Error Rate (BER) will be estimated in each case.<br />
<br />
These labs are based on [https://www.gnuradio.org/ GNU Radio] which is a free software that provides a large number of software blocks to perform most signal processing operations. The blocks are mostly written in C ++. It is possible to use these blocks directly from Python to simulate or create telecommunication systems.<br />
In addition, to make it easier to get started, GNU Radio also provides a utility called <syntaxhighlight lang="text" inline>gnuradio-companion</syntaxhighlight> to assemble blocks graphically and to generate the corresponding python script. This subject have been written for GNU Radio, but it can be equivalently realized using [https://www.gnu.org/software/octave/index Octave], or [http://itpp.sourceforge.net/4.3.1/ IT++] library.<br />
<br />
== Getting Started ==<br />
<br />
* Open a terminal<br />
<br />
* Create a working directory in which you will place your scripts.<br />
<br />
* Run <syntaxhighlight lang="text" inline>gnuradio-companion</syntaxhighlight>.<br />
<br />
This software allows you to use blocks (available in the right column) and to connect them to realize any complex signal processing operations. Resulting program is called a flowgraph in GNU Radio language.<br />
<br />
For any flowgraph, there is basically 3 types of blocks: sources (which produce samples and have at least 1 output), sinks (which consume samples and have at least 1 input) and processing block (which have at least 1 input and 1 output). Blocks are simply connected by creating a link in-between an output of a block and an input of another block.<br />
<br />
* Create the flowgraph presented in Fig. 1.<br />
<br />
[[File:Im1.png|frame|center|Fig. 1: Simple generation and data plotting]]<br />
<br />
The <syntaxhighlight lang="text" inline>Signal Source</syntaxhighlight> block generates an infinity of sinusoidal samples (or other) from the different parameters. These samples are displayed according to the time using the <syntaxhighlight lang="text" inline>Scope Sink</syntaxhighlight> block. <syntaxhighlight lang="text" inline>Throttle</syntaxhighlight> block does not modify the samples but allows to perform a flow control on all the data circulating between the source and the sink. Last, be careful to the color of the input and output of each block since they represent the type of data flowing on the link. The following table presents main data type and associated used by GNU Radio. Also, since Python is strongly typed, colors located at both ends of a wire have to be the same.<br />
<br />
{| class="wikitable" style="text-align: left;"<br />
|-<br />
!Color<br />
!Type<br />
!Size<br />
|-<br />
|style="background: #3399ff;"|<br />
|Complex<br />
|2 x 64 bits<br />
|-<br />
|style="background: #f57c00;"|<br />
|Float<br />
|64 bits<br />
|-<br />
|style="background: #009688;"|<br />
|Int<br />
|64/32 bits<br />
|-<br />
|style="background: #ffeb3b;"|<br />
|Short<br />
|16 bits<br />
|-<br />
|style="background: #d500f9;"|<br />
|Char<br />
|8 bits<br />
|}<br />
<br />
* Save the flowgraph under your directory. This file is saved with a <syntaxhighlight lang="text" inline>.grc</syntaxhighlight> extension.<br />
<br />
* Generate the associated Python script associated to your flowgraph using the "blue to red" button. If errors are present, the script is not generated and full listing is present under the no entry sign. When successful, observe the python script named <syntaxhighlight lang="text" inline>top_block.py</syntaxhighlight> in your directory.<br />
<br />
* Execute the script by pressing the run button. Equivalently, you can also invoke <syntaxhighlight lang="text" inline>python top_block.py</syntaxhighlight>.<br />
<br />
The execution should display an oscilloscope-like widow with the corresponding signal (a cosine function). You can stop the execution by closing the window or by pressing the stop button.<br />
<br />
* Check the amplitude and the period of the generated signal.<br />
<br />
* Finally, add a <syntaxhighlight lang="text" inline>Slider</syntaxhighlight> block to modify the frequency of the signal in real time (without recompiling the flowgraph) and check the operation on the scope. Save the flowgraph.<br />
<br />
Note that the source simply generates samples which are plotted by the sink, however, this source and this sink can produce and consume as much data that your CPU can handle (data are just generated and plotted iteratively as fast as possible). To overcome this issue, the <syntaxhighlight lang="text" inline>Throttle</syntaxhighlight> block is used to process a given number of sample per second, thus lowering the CPU load to few percents. Most of the blocks in GNU Radio do not fixed the rate at which samples are processed: when sufficient number of samples are present at the input, the considered function is called and produces samples at the output which are then available for the other blocks. Usually, this rate is fixed when we work with real devices (for example an audio card can acquire samples at a given frequency e.g. 48 kHz) which fixed the rate for the whole flowgraph. In our example, we do not use any real device so the rate has to be fixed using the <syntaxhighlight lang="text" inline>Throttle</syntaxhighlight> block. Also, for each flowgraph, a single rate has to be used thus if we work with a real device, the <syntaxhighlight lang="text" inline>Throttle</syntaxhighlight> block is not needed anymore and has to be removed.<br />
<br />
<br />
* Create the flowgraph presented in Fig. 2.<br />
<br />
[[File:Im2.png|frame|center|Fig. 2: Simple operations on signals]]<br />
<br />
* Add a <syntaxhighlight lang="text" inline>FFT Sink</syntaxhighlight> to observe the signal spectrum. On the graph, the two peaks are very close and seem to be confused. Reduce the frequency sampling to increase the frequency resolution. Explain the phenomenum.<br />
<br />
* What is the minimum value of the sampling frequency? Observe the signal (in time and in frequency) for frequencies below this limit.<br />
<br />
* Replace the <syntaxhighlight lang="text" inline>Add</syntaxhighlight> block with a multiplier block <syntaxhighlight lang="text" inline>Mult</syntaxhighlight>. Predict the position of the peaks in the output signal. Check your results.<br />
<br />
* Add a filter (block <syntaxhighlight lang="text" inline>Low Pass Filter</syntaxhighlight>) to recover the low frequency part of the signal. Check your results in the time and frequency domain. Repeat the manipulation to keep the high frequency part.<br />
<br />
The <syntaxhighlight lang="text" inline>Low Pass Filter</syntaxhighlight> (and <syntaxhighlight lang="text" inline>High Pass Filter</syntaxhighlight>) blocks are high-level blocks which realize the design (i.e. determining the coefficients of the filter) as well as the filtering (i.e. the convolution). The filter design can also be done with <syntaxhighlight lang="text" inline>gr_filter_design</syntaxhighlight> to obtain the coefficients. These coefficients can then be used directly by the blocks <syntaxhighlight lang="text" inline>FIR Filter</syntaxhighlight> and <syntaxhighlight lang="text" inline>IIR Filter</syntaxhighlight>.<br />
<br />
== Amplitude Modulation ==<br />
<br />
=== Double side band without carrier ===<br />
<br />
* Realize the modulation of a signal <math>m(t)=\cos 2\pi f_m t</math> using a double side band without carrier. Note that transmitted signal can be expressed as<br />
<br />
<math><br />
x(t) = A m(t) \cos 2 \pi f_0 t<br />
</math><br />
<br />
* Observe the signal in both time and frequency domain.<br />
<br />
* Give the architecture of a coherent detector used to recover the message <math>m(t)</math> from <math>x(t)</math>.<br />
<br />
* Implement this detector to demodulate the signal and verify the good operation. You can use 2 different flowgraphs (1 for the transmission and 1 for the reception) using a <syntaxhighlight lang="text" inline>File Sink</syntaxhighlight> and <syntaxhighlight lang="text" inline>File Source</syntaxhighlight> respectively.<br />
<br />
=== Double side band without carrier ===<br />
<br />
* Realize the modulation of a signal <math>m(t)=\cos 2\pi f_m t</math> using a double side band with carrier. Note that transmitted signal can be expressed as<br />
<br />
[[File:Env.png|thumb|right|Fig. 3: Envelope detector used for AM signals.]]<br />
<br />
<math><br />
x(t) = A (1 + k_a m(t)) \cos 2 \pi f_0 t<br />
</math><br />
<br />
* Observe the signal in both time and frequency domain.<br />
<br />
* Modify the modulation index <math>k_a</math> using a slider and observe the modification of the signal.<br />
<br />
* AM signals are usually demodulted using a simple envelope detector. The architecture of this decoder is presented in Fig. 3.<br />
<br />
* Implement this detector to demodulate the signal and verify the good operation.<br />
<br />
* Check also if the AM signal can be decoded using the coherent detector.<br />
<br />
* Finally, download the file [https://nicolas-barbot.ovh/wiki/pool/am_usrp710.dat <syntaxhighlight lang="text" inline>am_usrp710.dat</syntaxhighlight>]. This file contains the complex envelope (I and Q channels) received by a USRP around the frequency 710 kHz with a sampling frequency of 256 kHz. Visualize the data with a block <syntaxhighlight lang="text" inline>FFT Sink</syntaxhighlight> (insert a block <syntaxhighlight lang="text" inline>Throttle</syntaxhighlight> to avoid overloading the processor). On the graph, we can see two stations transmit at 710 kHz (center) and 790 kHz (to the right). Knowing that the bandwidth of an AM signal is 10 kHz, insert a low pass filter allowing to select the station located around 710 kHz. Check that the filter is working properly on the graph. Insert the envelope detector at the output of the filter and a block <syntaxhighlight lang="text" inline>Rational Resampler</syntaxhighlight> to adapt the bit rate to the sound card (48 kHz) using an <syntaxhighlight lang="text" inline>Audio Sink</syntaxhighlight>.<br />
<br />
* Check the correct operation on the PC speakers (add if needed a <syntaxhighlight lang="text" inline>Multiply Const.</syntaxhighlight> block to set the volume of the station).<br />
<br />
== Frequency Modulation ==<br />
<br />
== Digital Communication ==</div>Nicohttps://nicolas-barbot.ovh/wiki/index.php?title=SC311_Wireless_Communications&diff=447SC311 Wireless Communications2021-08-20T21:02:52Z<p>Nico: </p>
<hr />
<div>The objective of this course is to understand how we can transmit a message in-between a transmitter and a receiver spatially separated. Especially, how we can use signal processing operations to adapt (i.e. modulate and demodulate) the message to realize the transmission over wired or wireless channels. This course describes the processes realized at a signal level and can be related to [[MA331 Information Theory and Channel Coding]] (which presents the general problem at a higher level).<br />
<br />
Slides of the course can be downloaded here. Exercises can be downloaded here. The following of this page corresponds to the labs.<br />
<br />
__TOC__<br />
<br />
In this labs, we will realize different modulations and demodulations used to transmit and receive analog and digital messages.<br />
Spectrum (or power spectral density) will also be determined.<br />
Finally, performance, in term of Sinal to Noise Ratio (SNR) or Bit Error Rate (BER) will be estimated in each case.<br />
<br />
These labs are based on [https://www.gnuradio.org/ GNU Radio] which is a free software that provides a large number of software blocks to perform most signal processing operations. The blocks are mostly written in C ++. It is possible to use these blocks directly from Python to simulate or create telecommunication systems.<br />
In addition, to make it easier to get started, GNU Radio also provides a utility called <syntaxhighlight lang="text" inline>gnuradio-companion</syntaxhighlight> to assemble blocks graphically and to generate the corresponding python script. This subject have been written for GNU Radio, but it can be equivalently realized using [https://www.gnu.org/software/octave/index Octave], or [http://itpp.sourceforge.net/4.3.1/ IT++] library.<br />
<br />
== Getting Started ==<br />
<br />
* Open a terminal<br />
<br />
* Create a working directory in which you will place your scripts.<br />
<br />
* Run <syntaxhighlight lang="text" inline>gnuradio-companion</syntaxhighlight>.<br />
<br />
This software allows you to use blocks (available in the right column) and to connect them to realize any complex signal processing operations. Resulting program is called a flowgraph in GNU Radio language.<br />
<br />
For any flowgraph, there is basically 3 types of blocks: sources (which produce samples and have at least 1 output), sinks (which consume samples and have at least 1 input) and processing block (which have at least 1 input and 1 output). Blocks are simply connected by creating a link in-between an output of a block and an input of another block.<br />
<br />
* Create the flowgraph presented in Fig. 1.<br />
<br />
[[File:Im1.png|frame|center|Fig. 1: Simple generation and data plotting]]<br />
<br />
The <syntaxhighlight lang="text" inline>Signal Source</syntaxhighlight> block generates an infinity of sinusoidal samples (or other) from the different parameters. These samples are displayed according to the time using the <syntaxhighlight lang="text" inline>Scope Sink</syntaxhighlight> block. <syntaxhighlight lang="text" inline>Throttle</syntaxhighlight> block does not modify the samples but allows to perform a flow control on all the data circulating between the source and the sink. Last, be careful to the color of the input and output of each block since they represent the type of data flowing on the link. The following table presents main data type and associated used by GNU Radio. Also, since Python is strongly typed, colors located at both ends of a wire have to be the same.<br />
<br />
{| class="wikitable" style="text-align: left;"<br />
|-<br />
!Color<br />
!Type<br />
!Size<br />
|-<br />
|style="background: #3399ff;"|<br />
|Complex<br />
|2 x 64 bits<br />
|-<br />
|style="background: #f57c00;"|<br />
|Float<br />
|64 bits<br />
|-<br />
|style="background: #009688;"|<br />
|Int<br />
|64/32 bits<br />
|-<br />
|style="background: #ffeb3b;"|<br />
|Short<br />
|16 bits<br />
|-<br />
|style="background: #d500f9;"|<br />
|Char<br />
|8 bits<br />
|}<br />
<br />
* Save the flowgraph under your directory. This file is saved with a <syntaxhighlight lang="text" inline>.grc</syntaxhighlight> extension.<br />
<br />
* Generate the associated Python script associated to your flowgraph using the "blue to red" button. If errors are present, the script is not generated and full listing is present under the no entry sign. When successful, observe the python script named <syntaxhighlight lang="text" inline>top_block.py</syntaxhighlight> in your directory.<br />
<br />
* Execute the script by pressing the run button. Equivalently, you can also invoke <syntaxhighlight lang="text" inline>python top_block.py</syntaxhighlight>.<br />
<br />
The execution should display an oscilloscope-like widow with the corresponding signal (a cosine function). You can stop the execution by closing the window or by pressing the stop button.<br />
<br />
* Check the amplitude and the period of the generated signal.<br />
<br />
* Finally, add a <syntaxhighlight lang="text" inline>Slider</syntaxhighlight> block to modify the frequency of the signal in real time (without recompiling the flowgraph) and check the operation on the scope. Save the flowgraph.<br />
<br />
Note that the source simply generates samples which are plotted by the sink, however, this source and this sink can produce and consume as much data that your CPU can handle (data are just generated and plotted iteratively as fast as possible). To overcome this issue, the <syntaxhighlight lang="text" inline>Throttle</syntaxhighlight> block is used to process a given number of sample per second, thus lowering the CPU load to few percents. Most of the blocks in GNU Radio do not fixed the rate at which samples are processed: when sufficient number of samples are present at the input, the considered function is called and produces samples at the output which are then available for the other blocks. Usually, this rate is fixed when we work with real devices (for example an audio card can acquire samples at a given frequency e.g. 48 kHz) which fixed the rate for the whole flowgraph. In our example, we do not use any real device so the rate has to be fixed using the <syntaxhighlight lang="text" inline>Throttle</syntaxhighlight> block. Also, for each flowgraph, a single rate has to be used thus if we work with a real device, the <syntaxhighlight lang="text" inline>Throttle</syntaxhighlight> block is not needed anymore and has to be removed.<br />
<br />
<br />
* Create the flowgraph presented in Fig. 2.<br />
<br />
[[File:Im2.png|frame|center|Fig. 2: Simple operations on signals]]<br />
<br />
* Add a <syntaxhighlight lang="text" inline>FFT Sink</syntaxhighlight> to observe the signal spectrum. On the graph, the two peaks are very close and seem to be confused. Reduce the frequency sampling to increase the frequency resolution. Explain the phenomenum.<br />
<br />
* What is the minimum value of the sampling frequency? Observe the signal (in time and in frequency) for frequencies below this limit.<br />
<br />
* Replace the <syntaxhighlight lang="text" inline>Add</syntaxhighlight> block with a multiplier block <syntaxhighlight lang="text" inline>Mult</syntaxhighlight>. Predict the position of the peaks in the output signal. Check your results.<br />
<br />
* Add a filter (block <syntaxhighlight lang="text" inline>Low Pass Filter</syntaxhighlight>) to recover the low frequency part of the signal. Check your results in the time and frequency domain. Repeat the manipulation to keep the high frequency part.<br />
<br />
The <syntaxhighlight lang="text" inline>Low Pass Filter</syntaxhighlight> (and <syntaxhighlight lang="text" inline>High Pass Filter</syntaxhighlight>) blocks are high-level blocks which realize the design (i.e. determining the coefficients of the filter) as well as the filtering (i.e. the convolution). The filter design can also be done with <syntaxhighlight lang="text" inline>gr_filter_design</syntaxhighlight> to obtain the coefficients. These coefficients can then be used directly by the blocks <syntaxhighlight lang="text" inline>FIR Filter</syntaxhighlight> and <syntaxhighlight lang="text" inline>IIR Filter</syntaxhighlight>.<br />
<br />
== Amplitude Modulation ==<br />
<br />
=== Double side band without carrier ===<br />
<br />
* Realize the modulation of a signal <math>m(t)=\cos 2\pi f_m t</math> using a double side band without carrier. Note that transmitted signal can be expressed as<br />
<br />
<math><br />
x(t) = A m(t) \cos 2 \pi f_0 t<br />
</math><br />
<br />
* Observe the signal in both time and frequency domain.<br />
<br />
* Give the architecture of a coherent detector used to recover the message <math>m(t)</math> from <math>x(t)</math>.<br />
<br />
* Implement this detector to demodulate the signal and verify the good operation. You can use 2 different flowgraphs (1 for the transmission and 1 for the reception) using a <syntaxhighlight lang="text" inline>File Sink</syntaxhighlight> and <syntaxhighlight lang="text" inline>File Source</syntaxhighlight> respectively.<br />
<br />
=== Double side band without carrier ===<br />
<br />
* Realize the modulation of a signal <math>m(t)=\cos 2\pi f_m t</math> using a double side band with carrier. Note that transmitted signal can be expressed as<br />
<br />
[[File:Env.png|thumb|right|Fig. 3: Envelope detector used for AM signals.]]<br />
<br />
<math><br />
x(t) = A (1 + k_a m(t)) \cos 2 \pi f_0 t<br />
</math><br />
<br />
* Observe the signal in both time and frequency domain.<br />
<br />
* Modify the modulation index <math>k_a</math> using a slider and observe the modification of the signal.<br />
<br />
* AM signals are usually demodulted using a simple envelope detector. The architecture of this decoder is presented in Fig. 3.<br />
<br />
* Implement this detector to demodulate the signal and verify the good operation.<br />
<br />
* Check also if the AM signal can be decoded using the coherent detector.<br />
<br />
* Finally, download the file <syntaxhighlight lang="text" inline>am_usrp710.dat</syntaxhighlight>. This file contains the complex envelope (I and Q channels) received by a USRP around the frequency 710 kHz with a sampling frequency of 256 kHz. Visualize the data with a block <syntaxhighlight lang="text" inline>FFT Sink</syntaxhighlight> (insert a block <syntaxhighlight lang="text" inline>Throttle</syntaxhighlight> to avoid overloading the processor). On the graph, we can see two stations transmit at 710 kHz (center) and 790 kHz (to the right). Knowing that the bandwidth of an AM signal is 10 kHz, insert a low pass filter allowing to select the station located around 710 kHz. Check that the filter is working properly on the graph. Insert the envelope detector at the output of the filter and a block <syntaxhighlight lang="text" inline>Rational Resampler</syntaxhighlight> to adapt the bit rate to the sound card (48 kHz) using an <syntaxhighlight lang="text" inline>Audio Sink</syntaxhighlight>.<br />
<br />
* Check the correct operation on the PC speakers (add if needed a <syntaxhighlight lang="text" inline>Multiply Const.</syntaxhighlight> block to set the volume of the station).<br />
<br />
== Frequency Modulation ==<br />
<br />
== Digital Communication ==</div>Nicohttps://nicolas-barbot.ovh/wiki/index.php?title=SC311_Wireless_Communications&diff=446SC311 Wireless Communications2021-08-20T20:55:59Z<p>Nico: </p>
<hr />
<div>The objective of this course is to understand how we can transmit a message in-between a transmitter and a receiver spatially separated. Especially, how we can use signal processing operations to adapt (i.e. modulate and demodulate) the message to realize the transmission over wired or wireless channels. This course describes the processes realized at a signal level and can be related to [[MA331 Information Theory and Channel Coding]] (which presents the general problem at a higher level).<br />
<br />
Slides of the course can be downloaded here. Exercises can be downloaded here. The following of this page corresponds to the labs.<br />
<br />
__TOC__<br />
<br />
In this labs, we will realize different modulations and demodulations used to transmit and receive analog and digital messages.<br />
Spectrum (or power spectral density) will also be determined.<br />
Finally, performance, in term of Sinal to Noise Ratio (SNR) or Bit Error Rate (BER) will be estimated in each case.<br />
<br />
These labs are based on [https://www.gnuradio.org/ GNU Radio] which is a free software that provides a large number of software blocks to perform most signal processing operations. The blocks are mostly written in C ++. It is possible to use these blocks directly from Python to simulate or create telecommunication systems.<br />
In addition, to make it easier to get started, GNU Radio also provides a utility called <syntaxhighlight lang="text" inline>gnuradio-companion</syntaxhighlight> to assemble blocks graphically and to generate the corresponding python script. This subject have been written for GNU Radio, but it can be equivalently realized using [https://www.gnu.org/software/octave/index Octave], or [http://itpp.sourceforge.net/4.3.1/ IT++] library.<br />
<br />
== Getting Started ==<br />
<br />
* Open a terminal<br />
<br />
* Create a working directory in which you will place your scripts.<br />
<br />
* Run <syntaxhighlight lang="text" inline>gnuradio-companion</syntaxhighlight>.<br />
<br />
This software allows you to use blocks (available in the right column) and to connect them to realize any complex signal processing operations. Resulting program is called a flowgraph in GNU Radio language.<br />
<br />
For any flowgraph, there is basically 3 types of blocks: sources (which produce samples and have at least 1 output), sinks (which consume samples and have at least 1 input) and processing block (which have at least 1 input and 1 output). Blocks are simply connected by creating a link in-between an output of a block and an input of another block.<br />
<br />
* Create the flowgraph presented in Fig. 1.<br />
<br />
[[File:Im1.png|frame|center|Fig. 1: Simple generation and data plotting]]<br />
<br />
The <syntaxhighlight lang="text" inline>Signal Source</syntaxhighlight> block generates an infinity of sinusoidal samples (or other) from the different parameters. These samples are displayed according to the time using the <syntaxhighlight lang="text" inline>Scope Sink</syntaxhighlight> block. <syntaxhighlight lang="text" inline>Throttle</syntaxhighlight> block does not modify the samples but allows to perform a flow control on all the data circulating between the source and the sink. Last, be careful to the color of the input and output of each block since they represent the type of data flowing on the link. The following table presents main data type and associated used by GNU Radio. Also, since Python is strongly typed, colors located at both ends of a wire have to be the same.<br />
<br />
{| class="wikitable" style="text-align: left;"<br />
|-<br />
!Color<br />
!Type<br />
!Size<br />
|-<br />
|style="background: #000;"|<br />
|Complex<br />
|2 x 64 bits<br />
|-<br />
|Orange<br />
|Float<br />
|64 bits<br />
|-<br />
|Green<br />
|Int<br />
|64/32 bits<br />
|-<br />
|Yellow<br />
|Short<br />
|16 bits<br />
|-<br />
|Purple<br />
|Char<br />
|8 bits<br />
|}<br />
<br />
* Save the flowgraph under your directory. This file is saved with a <syntaxhighlight lang="text" inline>.grc</syntaxhighlight> extension.<br />
<br />
* Generate the associated Python script associated to your flowgraph using the "blue to red" button. If errors are present, the script is not generated and full listing is present under the no entry sign. When successful, observe the python script named <syntaxhighlight lang="text" inline>top_block.py</syntaxhighlight> in your directory.<br />
<br />
* Execute the script by pressing the run button. Equivalently, you can also invoke <syntaxhighlight lang="text" inline>python top_block.py</syntaxhighlight>.<br />
<br />
The execution should display an oscilloscope-like widow with the corresponding signal (a cosine function). You can stop the execution by closing the window or by pressing the stop button.<br />
<br />
* Check the amplitude and the period of the generated signal.<br />
<br />
* Finally, add a <syntaxhighlight lang="text" inline>Slider</syntaxhighlight> block to modify the frequency of the signal in real time (without recompiling the flowgraph) and check the operation on the scope. Save the flowgraph.<br />
<br />
Note that the source simply generates samples which are plotted by the sink, however, this source and this sink can produce and consume as much data that your CPU can handle (data are just generated and plotted iteratively as fast as possible). To overcome this issue, the <syntaxhighlight lang="text" inline>Throttle</syntaxhighlight> block is used to process a given number of sample per second, thus lowering the CPU load to few percents. Most of the blocks in GNU Radio do not fixed the rate at which samples are processed: when sufficient number of samples are present at the input, the considered function is called and produces samples at the output which are then available for the other blocks. Usually, this rate is fixed when we work with real devices (for example an audio card can acquire samples at a given frequency e.g. 48 kHz) which fixed the rate for the whole flowgraph. In our example, we do not use any real device so the rate has to be fixed using the <syntaxhighlight lang="text" inline>Throttle</syntaxhighlight> block. Also, for each flowgraph, a single rate has to be used thus if we work with a real device, the <syntaxhighlight lang="text" inline>Throttle</syntaxhighlight> block is not needed anymore and has to be removed.<br />
<br />
<br />
* Create the flowgraph presented in Fig. 2.<br />
<br />
[[File:Im2.png|frame|center|Fig. 2: Simple operations on signals]]<br />
<br />
* Add a <syntaxhighlight lang="text" inline>FFT Sink</syntaxhighlight> to observe the signal spectrum. On the graph, the two peaks are very close and seem to be confused. Reduce the frequency sampling to increase the frequency resolution. Explain the phenomenum.<br />
<br />
* What is the minimum value of the sampling frequency? Observe the signal (in time and in frequency) for frequencies below this limit.<br />
<br />
* Replace the <syntaxhighlight lang="text" inline>Add</syntaxhighlight> block with a multiplier block <syntaxhighlight lang="text" inline>Mult</syntaxhighlight>. Predict the position of the peaks in the output signal. Check your results.<br />
<br />
* Add a filter (block <syntaxhighlight lang="text" inline>Low Pass Filter</syntaxhighlight>) to recover the low frequency part of the signal. Check your results in the time and frequency domain. Repeat the manipulation to keep the high frequency part.<br />
<br />
The <syntaxhighlight lang="text" inline>Low Pass Filter</syntaxhighlight> (and <syntaxhighlight lang="text" inline>High Pass Filter</syntaxhighlight>) blocks are high-level blocks which realize the design (i.e. determining the coefficients of the filter) as well as the filtering (i.e. the convolution). The filter design can also be done with <syntaxhighlight lang="text" inline>gr_filter_design</syntaxhighlight> to obtain the coefficients. These coefficients can then be used directly by the blocks <syntaxhighlight lang="text" inline>FIR Filter</syntaxhighlight> and <syntaxhighlight lang="text" inline>IIR Filter</syntaxhighlight>.<br />
<br />
== Amplitude Modulation ==<br />
<br />
=== Double side band without carrier ===<br />
<br />
* Realize the modulation of a signal <math>m(t)=\cos 2\pi f_m t</math> using a double side band without carrier. Note that transmitted signal can be expressed as<br />
<br />
<math><br />
x(t) = A m(t) \cos 2 \pi f_0 t<br />
</math><br />
<br />
* Observe the signal in both time and frequency domain.<br />
<br />
* Give the architecture of a coherent detector used to recover the message <math>m(t)</math> from <math>x(t)</math>.<br />
<br />
* Implement this detector to demodulate the signal and verify the good operation. You can use 2 different flowgraphs (1 for the transmission and 1 for the reception) using a <syntaxhighlight lang="text" inline>File Sink</syntaxhighlight> and <syntaxhighlight lang="text" inline>File Source</syntaxhighlight> respectively.<br />
<br />
=== Double side band without carrier ===<br />
<br />
* Realize the modulation of a signal <math>m(t)=\cos 2\pi f_m t</math> using a double side band with carrier. Note that transmitted signal can be expressed as<br />
<br />
[[File:Env.png|thumb|right|Fig. 3: Envelope detector used for AM signals.]]<br />
<br />
<math><br />
x(t) = A (1 + k_a m(t)) \cos 2 \pi f_0 t<br />
</math><br />
<br />
* Observe the signal in both time and frequency domain.<br />
<br />
* Modify the modulation index <math>k_a</math> using a slider and observe the modification of the signal.<br />
<br />
* AM signals are usually demodulted using a simple envelope detector. The architecture of this decoder is presented in Fig. 3.<br />
<br />
* Implement this detector to demodulate the signal and verify the good operation.<br />
<br />
* Check also if the AM signal can be decoded using the coherent detector.<br />
<br />
* Finally, download the file <syntaxhighlight lang="text" inline>am_usrp710.dat</syntaxhighlight>. This file contains the complex envelope (I and Q channels) received by a USRP around the frequency 710 kHz with a sampling frequency of 256 kHz. Visualize the data with a block <syntaxhighlight lang="text" inline>FFT Sink</syntaxhighlight> (insert a block <syntaxhighlight lang="text" inline>Throttle</syntaxhighlight> to avoid overloading the processor). On the graph, we can see two stations transmit at 710 kHz (center) and 790 kHz (to the right). Knowing that the bandwidth of an AM signal is 10 kHz, insert a low pass filter allowing to select the station located around 710 kHz. Check that the filter is working properly on the graph. Insert the envelope detector at the output of the filter and a block <syntaxhighlight lang="text" inline>Rational Resampler</syntaxhighlight> to adapt the bit rate to the sound card (48 kHz) using an <syntaxhighlight lang="text" inline>Audio Sink</syntaxhighlight>.<br />
<br />
* Check the correct operation on the PC speakers (add if needed a <syntaxhighlight lang="text" inline>Multiply Const.</syntaxhighlight> block to set the volume of the station).<br />
<br />
== Frequency Modulation ==<br />
<br />
== Digital Communication ==</div>Nicohttps://nicolas-barbot.ovh/wiki/index.php?title=SC311_Wireless_Communications&diff=445SC311 Wireless Communications2021-08-20T20:55:28Z<p>Nico: </p>
<hr />
<div>The objective of this course is to understand how we can transmit a message in-between a transmitter and a receiver spatially separated. Especially, how we can use signal processing operations to adapt (i.e. modulate and demodulate) the message to realize the transmission over wired or wireless channels. This course describes the processes realized at a signal level and can be related to [[MA331 Information Theory and Channel Coding]] (which presents the general problem at a higher level).<br />
<br />
Slides of the course can be downloaded here. Exercises can be downloaded here. The following of this page corresponds to the labs.<br />
<br />
__TOC__<br />
<br />
In this labs, we will realize different modulations and demodulations used to transmit and receive analog and digital messages.<br />
Spectrum (or power spectral density) will also be determined.<br />
Finally, performance, in term of Sinal to Noise Ratio (SNR) or Bit Error Rate (BER) will be estimated in each case.<br />
<br />
These labs are based on [https://www.gnuradio.org/ GNU Radio] which is a free software that provides a large number of software blocks to perform most signal processing operations. The blocks are mostly written in C ++. It is possible to use these blocks directly from Python to simulate or create telecommunication systems.<br />
In addition, to make it easier to get started, GNU Radio also provides a utility called <syntaxhighlight lang="text" inline>gnuradio-companion</syntaxhighlight> to assemble blocks graphically and to generate the corresponding python script. This subject have been written for GNU Radio, but it can be equivalently realized using [https://www.gnu.org/software/octave/index Octave], or [http://itpp.sourceforge.net/4.3.1/ IT++] library.<br />
<br />
== Getting Started ==<br />
<br />
* Open a terminal<br />
<br />
* Create a working directory in which you will place your scripts.<br />
<br />
* Run <syntaxhighlight lang="text" inline>gnuradio-companion</syntaxhighlight>.<br />
<br />
This software allows you to use blocks (available in the right column) and to connect them to realize any complex signal processing operations. Resulting program is called a flowgraph in GNU Radio language.<br />
<br />
For any flowgraph, there is basically 3 types of blocks: sources (which produce samples and have at least 1 output), sinks (which consume samples and have at least 1 input) and processing block (which have at least 1 input and 1 output). Blocks are simply connected by creating a link in-between an output of a block and an input of another block.<br />
<br />
* Create the flowgraph presented in Fig. 1.<br />
<br />
[[File:Im1.png|frame|center|Fig. 1: Simple generation and data plotting]]<br />
<br />
The <syntaxhighlight lang="text" inline>Signal Source</syntaxhighlight> block generates an infinity of sinusoidal samples (or other) from the different parameters. These samples are displayed according to the time using the <syntaxhighlight lang="text" inline>Scope Sink</syntaxhighlight> block. <syntaxhighlight lang="text" inline>Throttle</syntaxhighlight> block does not modify the samples but allows to perform a flow control on all the data circulating between the source and the sink. Last, be careful to the color of the input and output of each block since they represent the type of data flowing on the link. The following table presents main data type and associated used by GNU Radio. Also, since Python is strongly typed, colors located at both ends of a wire have to be the same.<br />
<br />
{| class="wikitable" style="text-align: left;"<br />
|-<br />
!Color<br />
!Type<br />
!Size<br />
|-<br />
|style="background: #f8f9fa;"|<br />
|Complex<br />
|2 x 64 bits<br />
|-<br />
|Orange<br />
|Float<br />
|64 bits<br />
|-<br />
|Green<br />
|Int<br />
|64/32 bits<br />
|-<br />
|Yellow<br />
|Short<br />
|16 bits<br />
|-<br />
|Purple<br />
|Char<br />
|8 bits<br />
|}<br />
<br />
* Save the flowgraph under your directory. This file is saved with a <syntaxhighlight lang="text" inline>.grc</syntaxhighlight> extension.<br />
<br />
* Generate the associated Python script associated to your flowgraph using the "blue to red" button. If errors are present, the script is not generated and full listing is present under the no entry sign. When successful, observe the python script named <syntaxhighlight lang="text" inline>top_block.py</syntaxhighlight> in your directory.<br />
<br />
* Execute the script by pressing the run button. Equivalently, you can also invoke <syntaxhighlight lang="text" inline>python top_block.py</syntaxhighlight>.<br />
<br />
The execution should display an oscilloscope-like widow with the corresponding signal (a cosine function). You can stop the execution by closing the window or by pressing the stop button.<br />
<br />
* Check the amplitude and the period of the generated signal.<br />
<br />
* Finally, add a <syntaxhighlight lang="text" inline>Slider</syntaxhighlight> block to modify the frequency of the signal in real time (without recompiling the flowgraph) and check the operation on the scope. Save the flowgraph.<br />
<br />
Note that the source simply generates samples which are plotted by the sink, however, this source and this sink can produce and consume as much data that your CPU can handle (data are just generated and plotted iteratively as fast as possible). To overcome this issue, the <syntaxhighlight lang="text" inline>Throttle</syntaxhighlight> block is used to process a given number of sample per second, thus lowering the CPU load to few percents. Most of the blocks in GNU Radio do not fixed the rate at which samples are processed: when sufficient number of samples are present at the input, the considered function is called and produces samples at the output which are then available for the other blocks. Usually, this rate is fixed when we work with real devices (for example an audio card can acquire samples at a given frequency e.g. 48 kHz) which fixed the rate for the whole flowgraph. In our example, we do not use any real device so the rate has to be fixed using the <syntaxhighlight lang="text" inline>Throttle</syntaxhighlight> block. Also, for each flowgraph, a single rate has to be used thus if we work with a real device, the <syntaxhighlight lang="text" inline>Throttle</syntaxhighlight> block is not needed anymore and has to be removed.<br />
<br />
<br />
* Create the flowgraph presented in Fig. 2.<br />
<br />
[[File:Im2.png|frame|center|Fig. 2: Simple operations on signals]]<br />
<br />
* Add a <syntaxhighlight lang="text" inline>FFT Sink</syntaxhighlight> to observe the signal spectrum. On the graph, the two peaks are very close and seem to be confused. Reduce the frequency sampling to increase the frequency resolution. Explain the phenomenum.<br />
<br />
* What is the minimum value of the sampling frequency? Observe the signal (in time and in frequency) for frequencies below this limit.<br />
<br />
* Replace the <syntaxhighlight lang="text" inline>Add</syntaxhighlight> block with a multiplier block <syntaxhighlight lang="text" inline>Mult</syntaxhighlight>. Predict the position of the peaks in the output signal. Check your results.<br />
<br />
* Add a filter (block <syntaxhighlight lang="text" inline>Low Pass Filter</syntaxhighlight>) to recover the low frequency part of the signal. Check your results in the time and frequency domain. Repeat the manipulation to keep the high frequency part.<br />
<br />
The <syntaxhighlight lang="text" inline>Low Pass Filter</syntaxhighlight> (and <syntaxhighlight lang="text" inline>High Pass Filter</syntaxhighlight>) blocks are high-level blocks which realize the design (i.e. determining the coefficients of the filter) as well as the filtering (i.e. the convolution). The filter design can also be done with <syntaxhighlight lang="text" inline>gr_filter_design</syntaxhighlight> to obtain the coefficients. These coefficients can then be used directly by the blocks <syntaxhighlight lang="text" inline>FIR Filter</syntaxhighlight> and <syntaxhighlight lang="text" inline>IIR Filter</syntaxhighlight>.<br />
<br />
== Amplitude Modulation ==<br />
<br />
=== Double side band without carrier ===<br />
<br />
* Realize the modulation of a signal <math>m(t)=\cos 2\pi f_m t</math> using a double side band without carrier. Note that transmitted signal can be expressed as<br />
<br />
<math><br />
x(t) = A m(t) \cos 2 \pi f_0 t<br />
</math><br />
<br />
* Observe the signal in both time and frequency domain.<br />
<br />
* Give the architecture of a coherent detector used to recover the message <math>m(t)</math> from <math>x(t)</math>.<br />
<br />
* Implement this detector to demodulate the signal and verify the good operation. You can use 2 different flowgraphs (1 for the transmission and 1 for the reception) using a <syntaxhighlight lang="text" inline>File Sink</syntaxhighlight> and <syntaxhighlight lang="text" inline>File Source</syntaxhighlight> respectively.<br />
<br />
=== Double side band without carrier ===<br />
<br />
* Realize the modulation of a signal <math>m(t)=\cos 2\pi f_m t</math> using a double side band with carrier. Note that transmitted signal can be expressed as<br />
<br />
[[File:Env.png|thumb|right|Fig. 3: Envelope detector used for AM signals.]]<br />
<br />
<math><br />
x(t) = A (1 + k_a m(t)) \cos 2 \pi f_0 t<br />
</math><br />
<br />
* Observe the signal in both time and frequency domain.<br />
<br />
* Modify the modulation index <math>k_a</math> using a slider and observe the modification of the signal.<br />
<br />
* AM signals are usually demodulted using a simple envelope detector. The architecture of this decoder is presented in Fig. 3.<br />
<br />
* Implement this detector to demodulate the signal and verify the good operation.<br />
<br />
* Check also if the AM signal can be decoded using the coherent detector.<br />
<br />
* Finally, download the file <syntaxhighlight lang="text" inline>am_usrp710.dat</syntaxhighlight>. This file contains the complex envelope (I and Q channels) received by a USRP around the frequency 710 kHz with a sampling frequency of 256 kHz. Visualize the data with a block <syntaxhighlight lang="text" inline>FFT Sink</syntaxhighlight> (insert a block <syntaxhighlight lang="text" inline>Throttle</syntaxhighlight> to avoid overloading the processor). On the graph, we can see two stations transmit at 710 kHz (center) and 790 kHz (to the right). Knowing that the bandwidth of an AM signal is 10 kHz, insert a low pass filter allowing to select the station located around 710 kHz. Check that the filter is working properly on the graph. Insert the envelope detector at the output of the filter and a block <syntaxhighlight lang="text" inline>Rational Resampler</syntaxhighlight> to adapt the bit rate to the sound card (48 kHz) using an <syntaxhighlight lang="text" inline>Audio Sink</syntaxhighlight>.<br />
<br />
* Check the correct operation on the PC speakers (add if needed a <syntaxhighlight lang="text" inline>Multiply Const.</syntaxhighlight> block to set the volume of the station).<br />
<br />
== Frequency Modulation ==<br />
<br />
== Digital Communication ==</div>Nicohttps://nicolas-barbot.ovh/wiki/index.php?title=SC311_Wireless_Communications&diff=444SC311 Wireless Communications2021-08-20T20:54:07Z<p>Nico: </p>
<hr />
<div>The objective of this course is to understand how we can transmit a message in-between a transmitter and a receiver spatially separated. Especially, how we can use signal processing operations to adapt (i.e. modulate and demodulate) the message to realize the transmission over wired or wireless channels. This course describes the processes realized at a signal level and can be related to [[MA331 Information Theory and Channel Coding]] (which presents the general problem at a higher level).<br />
<br />
Slides of the course can be downloaded here. Exercises can be downloaded here. The following of this page corresponds to the labs.<br />
<br />
__TOC__<br />
<br />
In this labs, we will realize different modulations and demodulations used to transmit and receive analog and digital messages.<br />
Spectrum (or power spectral density) will also be determined.<br />
Finally, performance, in term of Sinal to Noise Ratio (SNR) or Bit Error Rate (BER) will be estimated in each case.<br />
<br />
These labs are based on [https://www.gnuradio.org/ GNU Radio] which is a free software that provides a large number of software blocks to perform most signal processing operations. The blocks are mostly written in C ++. It is possible to use these blocks directly from Python to simulate or create telecommunication systems.<br />
In addition, to make it easier to get started, GNU Radio also provides a utility called <syntaxhighlight lang="text" inline>gnuradio-companion</syntaxhighlight> to assemble blocks graphically and to generate the corresponding python script. This subject have been written for GNU Radio, but it can be equivalently realized using [https://www.gnu.org/software/octave/index Octave], or [http://itpp.sourceforge.net/4.3.1/ IT++] library.<br />
<br />
== Getting Started ==<br />
<br />
* Open a terminal<br />
<br />
* Create a working directory in which you will place your scripts.<br />
<br />
* Run <syntaxhighlight lang="text" inline>gnuradio-companion</syntaxhighlight>.<br />
<br />
This software allows you to use blocks (available in the right column) and to connect them to realize any complex signal processing operations. Resulting program is called a flowgraph in GNU Radio language.<br />
<br />
For any flowgraph, there is basically 3 types of blocks: sources (which produce samples and have at least 1 output), sinks (which consume samples and have at least 1 input) and processing block (which have at least 1 input and 1 output). Blocks are simply connected by creating a link in-between an output of a block and an input of another block.<br />
<br />
* Create the flowgraph presented in Fig. 1.<br />
<br />
[[File:Im1.png|frame|center|Fig. 1: Simple generation and data plotting]]<br />
<br />
The <syntaxhighlight lang="text" inline>Signal Source</syntaxhighlight> block generates an infinity of sinusoidal samples (or other) from the different parameters. These samples are displayed according to the time using the <syntaxhighlight lang="text" inline>Scope Sink</syntaxhighlight> block. <syntaxhighlight lang="text" inline>Throttle</syntaxhighlight> block does not modify the samples but allows to perform a flow control on all the data circulating between the source and the sink. Last, be careful to the color of the input and output of each block since they represent the type of data flowing on the link. The following table presents main data type and associated used by GNU Radio. Also, since Python is strongly typed, colors located at both ends of a wire have to be the same.<br />
<br />
{| class="wikitable" style="text-align: left;"<br />
|-<br />
!Color<br />
!Type<br />
!Size<br />
|-<br />
|style="background: #000;"<br />
|Complex<br />
|2 x 64 bits<br />
|-<br />
|Orange<br />
|Float<br />
|64 bits<br />
|-<br />
|Green<br />
|Int<br />
|64/32 bits<br />
|-<br />
|Yellow<br />
|Short<br />
|16 bits<br />
|-<br />
|Purple<br />
|Char<br />
|8 bits<br />
|}<br />
<br />
* Save the flowgraph under your directory. This file is saved with a <syntaxhighlight lang="text" inline>.grc</syntaxhighlight> extension.<br />
<br />
* Generate the associated Python script associated to your flowgraph using the "blue to red" button. If errors are present, the script is not generated and full listing is present under the no entry sign. When successful, observe the python script named <syntaxhighlight lang="text" inline>top_block.py</syntaxhighlight> in your directory.<br />
<br />
* Execute the script by pressing the run button. Equivalently, you can also invoke <syntaxhighlight lang="text" inline>python top_block.py</syntaxhighlight>.<br />
<br />
The execution should display an oscilloscope-like widow with the corresponding signal (a cosine function). You can stop the execution by closing the window or by pressing the stop button.<br />
<br />
* Check the amplitude and the period of the generated signal.<br />
<br />
* Finally, add a <syntaxhighlight lang="text" inline>Slider</syntaxhighlight> block to modify the frequency of the signal in real time (without recompiling the flowgraph) and check the operation on the scope. Save the flowgraph.<br />
<br />
Note that the source simply generates samples which are plotted by the sink, however, this source and this sink can produce and consume as much data that your CPU can handle (data are just generated and plotted iteratively as fast as possible). To overcome this issue, the <syntaxhighlight lang="text" inline>Throttle</syntaxhighlight> block is used to process a given number of sample per second, thus lowering the CPU load to few percents. Most of the blocks in GNU Radio do not fixed the rate at which samples are processed: when sufficient number of samples are present at the input, the considered function is called and produces samples at the output which are then available for the other blocks. Usually, this rate is fixed when we work with real devices (for example an audio card can acquire samples at a given frequency e.g. 48 kHz) which fixed the rate for the whole flowgraph. In our example, we do not use any real device so the rate has to be fixed using the <syntaxhighlight lang="text" inline>Throttle</syntaxhighlight> block. Also, for each flowgraph, a single rate has to be used thus if we work with a real device, the <syntaxhighlight lang="text" inline>Throttle</syntaxhighlight> block is not needed anymore and has to be removed.<br />
<br />
<br />
* Create the flowgraph presented in Fig. 2.<br />
<br />
[[File:Im2.png|frame|center|Fig. 2: Simple operations on signals]]<br />
<br />
* Add a <syntaxhighlight lang="text" inline>FFT Sink</syntaxhighlight> to observe the signal spectrum. On the graph, the two peaks are very close and seem to be confused. Reduce the frequency sampling to increase the frequency resolution. Explain the phenomenum.<br />
<br />
* What is the minimum value of the sampling frequency? Observe the signal (in time and in frequency) for frequencies below this limit.<br />
<br />
* Replace the <syntaxhighlight lang="text" inline>Add</syntaxhighlight> block with a multiplier block <syntaxhighlight lang="text" inline>Mult</syntaxhighlight>. Predict the position of the peaks in the output signal. Check your results.<br />
<br />
* Add a filter (block <syntaxhighlight lang="text" inline>Low Pass Filter</syntaxhighlight>) to recover the low frequency part of the signal. Check your results in the time and frequency domain. Repeat the manipulation to keep the high frequency part.<br />
<br />
The <syntaxhighlight lang="text" inline>Low Pass Filter</syntaxhighlight> (and <syntaxhighlight lang="text" inline>High Pass Filter</syntaxhighlight>) blocks are high-level blocks which realize the design (i.e. determining the coefficients of the filter) as well as the filtering (i.e. the convolution). The filter design can also be done with <syntaxhighlight lang="text" inline>gr_filter_design</syntaxhighlight> to obtain the coefficients. These coefficients can then be used directly by the blocks <syntaxhighlight lang="text" inline>FIR Filter</syntaxhighlight> and <syntaxhighlight lang="text" inline>IIR Filter</syntaxhighlight>.<br />
<br />
== Amplitude Modulation ==<br />
<br />
=== Double side band without carrier ===<br />
<br />
* Realize the modulation of a signal <math>m(t)=\cos 2\pi f_m t</math> using a double side band without carrier. Note that transmitted signal can be expressed as<br />
<br />
<math><br />
x(t) = A m(t) \cos 2 \pi f_0 t<br />
</math><br />
<br />
* Observe the signal in both time and frequency domain.<br />
<br />
* Give the architecture of a coherent detector used to recover the message <math>m(t)</math> from <math>x(t)</math>.<br />
<br />
* Implement this detector to demodulate the signal and verify the good operation. You can use 2 different flowgraphs (1 for the transmission and 1 for the reception) using a <syntaxhighlight lang="text" inline>File Sink</syntaxhighlight> and <syntaxhighlight lang="text" inline>File Source</syntaxhighlight> respectively.<br />
<br />
=== Double side band without carrier ===<br />
<br />
* Realize the modulation of a signal <math>m(t)=\cos 2\pi f_m t</math> using a double side band with carrier. Note that transmitted signal can be expressed as<br />
<br />
[[File:Env.png|thumb|right|Fig. 3: Envelope detector used for AM signals.]]<br />
<br />
<math><br />
x(t) = A (1 + k_a m(t)) \cos 2 \pi f_0 t<br />
</math><br />
<br />
* Observe the signal in both time and frequency domain.<br />
<br />
* Modify the modulation index <math>k_a</math> using a slider and observe the modification of the signal.<br />
<br />
* AM signals are usually demodulted using a simple envelope detector. The architecture of this decoder is presented in Fig. 3.<br />
<br />
* Implement this detector to demodulate the signal and verify the good operation.<br />
<br />
* Check also if the AM signal can be decoded using the coherent detector.<br />
<br />
* Finally, download the file <syntaxhighlight lang="text" inline>am_usrp710.dat</syntaxhighlight>. This file contains the complex envelope (I and Q channels) received by a USRP around the frequency 710 kHz with a sampling frequency of 256 kHz. Visualize the data with a block <syntaxhighlight lang="text" inline>FFT Sink</syntaxhighlight> (insert a block <syntaxhighlight lang="text" inline>Throttle</syntaxhighlight> to avoid overloading the processor). On the graph, we can see two stations transmit at 710 kHz (center) and 790 kHz (to the right). Knowing that the bandwidth of an AM signal is 10 kHz, insert a low pass filter allowing to select the station located around 710 kHz. Check that the filter is working properly on the graph. Insert the envelope detector at the output of the filter and a block <syntaxhighlight lang="text" inline>Rational Resampler</syntaxhighlight> to adapt the bit rate to the sound card (48 kHz) using an <syntaxhighlight lang="text" inline>Audio Sink</syntaxhighlight>.<br />
<br />
* Check the correct operation on the PC speakers (add if needed a <syntaxhighlight lang="text" inline>Multiply Const.</syntaxhighlight> block to set the volume of the station).<br />
<br />
== Frequency Modulation ==<br />
<br />
== Digital Communication ==</div>Nicohttps://nicolas-barbot.ovh/wiki/index.php?title=SC311_Wireless_Communications&diff=443SC311 Wireless Communications2021-08-20T20:52:42Z<p>Nico: </p>
<hr />
<div>The objective of this course is to understand how we can transmit a message in-between a transmitter and a receiver spatially separated. Especially, how we can use signal processing operations to adapt (i.e. modulate and demodulate) the message to realize the transmission over wired or wireless channels. This course describes the processes realized at a signal level and can be related to [[MA331 Information Theory and Channel Coding]] (which presents the general problem at a higher level).<br />
<br />
Slides of the course can be downloaded here. Exercises can be downloaded here. The following of this page corresponds to the labs.<br />
<br />
__TOC__<br />
<br />
In this labs, we will realize different modulations and demodulations used to transmit and receive analog and digital messages.<br />
Spectrum (or power spectral density) will also be determined.<br />
Finally, performance, in term of Sinal to Noise Ratio (SNR) or Bit Error Rate (BER) will be estimated in each case.<br />
<br />
These labs are based on [https://www.gnuradio.org/ GNU Radio] which is a free software that provides a large number of software blocks to perform most signal processing operations. The blocks are mostly written in C ++. It is possible to use these blocks directly from Python to simulate or create telecommunication systems.<br />
In addition, to make it easier to get started, GNU Radio also provides a utility called <syntaxhighlight lang="text" inline>gnuradio-companion</syntaxhighlight> to assemble blocks graphically and to generate the corresponding python script. This subject have been written for GNU Radio, but it can be equivalently realized using [https://www.gnu.org/software/octave/index Octave], or [http://itpp.sourceforge.net/4.3.1/ IT++] library.<br />
<br />
== Getting Started ==<br />
<br />
* Open a terminal<br />
<br />
* Create a working directory in which you will place your scripts.<br />
<br />
* Run <syntaxhighlight lang="text" inline>gnuradio-companion</syntaxhighlight>.<br />
<br />
This software allows you to use blocks (available in the right column) and to connect them to realize any complex signal processing operations. Resulting program is called a flowgraph in GNU Radio language.<br />
<br />
For any flowgraph, there is basically 3 types of blocks: sources (which produce samples and have at least 1 output), sinks (which consume samples and have at least 1 input) and processing block (which have at least 1 input and 1 output). Blocks are simply connected by creating a link in-between an output of a block and an input of another block.<br />
<br />
* Create the flowgraph presented in Fig. 1.<br />
<br />
[[File:Im1.png|frame|center|Fig. 1: Simple generation and data plotting]]<br />
<br />
The <syntaxhighlight lang="text" inline>Signal Source</syntaxhighlight> block generates an infinity of sinusoidal samples (or other) from the different parameters. These samples are displayed according to the time using the <syntaxhighlight lang="text" inline>Scope Sink</syntaxhighlight> block. <syntaxhighlight lang="text" inline>Throttle</syntaxhighlight> block does not modify the samples but allows to perform a flow control on all the data circulating between the source and the sink. Last, be careful to the color of the input and output of each block since they represent the type of data flowing on the link. The following table presents main data type and associated used by GNU Radio. Also, since Python is strongly typed, colors located at both ends of a wire have to be the same.<br />
<br />
{| class="wikitable" style="text-align: left;"<br />
|-<br />
!Color<br />
!Type<br />
!Size<br />
|-<br />
|style="background: Black<br />
|Complex<br />
|2 x 64 bits<br />
|-<br />
|Orange<br />
|Float<br />
|64 bits<br />
|-<br />
|Green<br />
|Int<br />
|64/32 bits<br />
|-<br />
|Yellow<br />
|Short<br />
|16 bits<br />
|-<br />
|Purple<br />
|Char<br />
|8 bits<br />
|}<br />
<br />
* Save the flowgraph under your directory. This file is saved with a <syntaxhighlight lang="text" inline>.grc</syntaxhighlight> extension.<br />
<br />
* Generate the associated Python script associated to your flowgraph using the "blue to red" button. If errors are present, the script is not generated and full listing is present under the no entry sign. When successful, observe the python script named <syntaxhighlight lang="text" inline>top_block.py</syntaxhighlight> in your directory.<br />
<br />
* Execute the script by pressing the run button. Equivalently, you can also invoke <syntaxhighlight lang="text" inline>python top_block.py</syntaxhighlight>.<br />
<br />
The execution should display an oscilloscope-like widow with the corresponding signal (a cosine function). You can stop the execution by closing the window or by pressing the stop button.<br />
<br />
* Check the amplitude and the period of the generated signal.<br />
<br />
* Finally, add a <syntaxhighlight lang="text" inline>Slider</syntaxhighlight> block to modify the frequency of the signal in real time (without recompiling the flowgraph) and check the operation on the scope. Save the flowgraph.<br />
<br />
Note that the source simply generates samples which are plotted by the sink, however, this source and this sink can produce and consume as much data that your CPU can handle (data are just generated and plotted iteratively as fast as possible). To overcome this issue, the <syntaxhighlight lang="text" inline>Throttle</syntaxhighlight> block is used to process a given number of sample per second, thus lowering the CPU load to few percents. Most of the blocks in GNU Radio do not fixed the rate at which samples are processed: when sufficient number of samples are present at the input, the considered function is called and produces samples at the output which are then available for the other blocks. Usually, this rate is fixed when we work with real devices (for example an audio card can acquire samples at a given frequency e.g. 48 kHz) which fixed the rate for the whole flowgraph. In our example, we do not use any real device so the rate has to be fixed using the <syntaxhighlight lang="text" inline>Throttle</syntaxhighlight> block. Also, for each flowgraph, a single rate has to be used thus if we work with a real device, the <syntaxhighlight lang="text" inline>Throttle</syntaxhighlight> block is not needed anymore and has to be removed.<br />
<br />
<br />
* Create the flowgraph presented in Fig. 2.<br />
<br />
[[File:Im2.png|frame|center|Fig. 2: Simple operations on signals]]<br />
<br />
* Add a <syntaxhighlight lang="text" inline>FFT Sink</syntaxhighlight> to observe the signal spectrum. On the graph, the two peaks are very close and seem to be confused. Reduce the frequency sampling to increase the frequency resolution. Explain the phenomenum.<br />
<br />
* What is the minimum value of the sampling frequency? Observe the signal (in time and in frequency) for frequencies below this limit.<br />
<br />
* Replace the <syntaxhighlight lang="text" inline>Add</syntaxhighlight> block with a multiplier block <syntaxhighlight lang="text" inline>Mult</syntaxhighlight>. Predict the position of the peaks in the output signal. Check your results.<br />
<br />
* Add a filter (block <syntaxhighlight lang="text" inline>Low Pass Filter</syntaxhighlight>) to recover the low frequency part of the signal. Check your results in the time and frequency domain. Repeat the manipulation to keep the high frequency part.<br />
<br />
The <syntaxhighlight lang="text" inline>Low Pass Filter</syntaxhighlight> (and <syntaxhighlight lang="text" inline>High Pass Filter</syntaxhighlight>) blocks are high-level blocks which realize the design (i.e. determining the coefficients of the filter) as well as the filtering (i.e. the convolution). The filter design can also be done with <syntaxhighlight lang="text" inline>gr_filter_design</syntaxhighlight> to obtain the coefficients. These coefficients can then be used directly by the blocks <syntaxhighlight lang="text" inline>FIR Filter</syntaxhighlight> and <syntaxhighlight lang="text" inline>IIR Filter</syntaxhighlight>.<br />
<br />
== Amplitude Modulation ==<br />
<br />
=== Double side band without carrier ===<br />
<br />
* Realize the modulation of a signal <math>m(t)=\cos 2\pi f_m t</math> using a double side band without carrier. Note that transmitted signal can be expressed as<br />
<br />
<math><br />
x(t) = A m(t) \cos 2 \pi f_0 t<br />
</math><br />
<br />
* Observe the signal in both time and frequency domain.<br />
<br />
* Give the architecture of a coherent detector used to recover the message <math>m(t)</math> from <math>x(t)</math>.<br />
<br />
* Implement this detector to demodulate the signal and verify the good operation. You can use 2 different flowgraphs (1 for the transmission and 1 for the reception) using a <syntaxhighlight lang="text" inline>File Sink</syntaxhighlight> and <syntaxhighlight lang="text" inline>File Source</syntaxhighlight> respectively.<br />
<br />
=== Double side band without carrier ===<br />
<br />
* Realize the modulation of a signal <math>m(t)=\cos 2\pi f_m t</math> using a double side band with carrier. Note that transmitted signal can be expressed as<br />
<br />
[[File:Env.png|thumb|right|Fig. 3: Envelope detector used for AM signals.]]<br />
<br />
<math><br />
x(t) = A (1 + k_a m(t)) \cos 2 \pi f_0 t<br />
</math><br />
<br />
* Observe the signal in both time and frequency domain.<br />
<br />
* Modify the modulation index <math>k_a</math> using a slider and observe the modification of the signal.<br />
<br />
* AM signals are usually demodulted using a simple envelope detector. The architecture of this decoder is presented in Fig. 3.<br />
<br />
* Implement this detector to demodulate the signal and verify the good operation.<br />
<br />
* Check also if the AM signal can be decoded using the coherent detector.<br />
<br />
* Finally, download the file <syntaxhighlight lang="text" inline>am_usrp710.dat</syntaxhighlight>. This file contains the complex envelope (I and Q channels) received by a USRP around the frequency 710 kHz with a sampling frequency of 256 kHz. Visualize the data with a block <syntaxhighlight lang="text" inline>FFT Sink</syntaxhighlight> (insert a block <syntaxhighlight lang="text" inline>Throttle</syntaxhighlight> to avoid overloading the processor). On the graph, we can see two stations transmit at 710 kHz (center) and 790 kHz (to the right). Knowing that the bandwidth of an AM signal is 10 kHz, insert a low pass filter allowing to select the station located around 710 kHz. Check that the filter is working properly on the graph. Insert the envelope detector at the output of the filter and a block <syntaxhighlight lang="text" inline>Rational Resampler</syntaxhighlight> to adapt the bit rate to the sound card (48 kHz) using an <syntaxhighlight lang="text" inline>Audio Sink</syntaxhighlight>.<br />
<br />
* Check the correct operation on the PC speakers (add if needed a <syntaxhighlight lang="text" inline>Multiply Const.</syntaxhighlight> block to set the volume of the station).<br />
<br />
== Frequency Modulation ==<br />
<br />
== Digital Communication ==</div>Nicohttps://nicolas-barbot.ovh/wiki/index.php?title=SC311_Wireless_Communications&diff=442SC311 Wireless Communications2021-08-20T20:51:30Z<p>Nico: </p>
<hr />
<div>The objective of this course is to understand how we can transmit a message in-between a transmitter and a receiver spatially separated. Especially, how we can use signal processing operations to adapt (i.e. modulate and demodulate) the message to realize the transmission over wired or wireless channels. This course describes the processes realized at a signal level and can be related to [[MA331 Information Theory and Channel Coding]] (which presents the general problem at a higher level).<br />
<br />
Slides of the course can be downloaded here. Exercises can be downloaded here. The following of this page corresponds to the labs.<br />
<br />
__TOC__<br />
<br />
In this labs, we will realize different modulations and demodulations used to transmit and receive analog and digital messages.<br />
Spectrum (or power spectral density) will also be determined.<br />
Finally, performance, in term of Sinal to Noise Ratio (SNR) or Bit Error Rate (BER) will be estimated in each case.<br />
<br />
These labs are based on [https://www.gnuradio.org/ GNU Radio] which is a free software that provides a large number of software blocks to perform most signal processing operations. The blocks are mostly written in C ++. It is possible to use these blocks directly from Python to simulate or create telecommunication systems.<br />
In addition, to make it easier to get started, GNU Radio also provides a utility called <syntaxhighlight lang="text" inline>gnuradio-companion</syntaxhighlight> to assemble blocks graphically and to generate the corresponding python script. This subject have been written for GNU Radio, but it can be equivalently realized using [https://www.gnu.org/software/octave/index Octave], or [http://itpp.sourceforge.net/4.3.1/ IT++] library.<br />
<br />
== Getting Started ==<br />
<br />
* Open a terminal<br />
<br />
* Create a working directory in which you will place your scripts.<br />
<br />
* Run <syntaxhighlight lang="text" inline>gnuradio-companion</syntaxhighlight>.<br />
<br />
This software allows you to use blocks (available in the right column) and to connect them to realize any complex signal processing operations. Resulting program is called a flowgraph in GNU Radio language.<br />
<br />
For any flowgraph, there is basically 3 types of blocks: sources (which produce samples and have at least 1 output), sinks (which consume samples and have at least 1 input) and processing block (which have at least 1 input and 1 output). Blocks are simply connected by creating a link in-between an output of a block and an input of another block.<br />
<br />
* Create the flowgraph presented in Fig. 1.<br />
<br />
[[File:Im1.png|frame|center|Fig. 1: Simple generation and data plotting]]<br />
<br />
The <syntaxhighlight lang="text" inline>Signal Source</syntaxhighlight> block generates an infinity of sinusoidal samples (or other) from the different parameters. These samples are displayed according to the time using the <syntaxhighlight lang="text" inline>Scope Sink</syntaxhighlight> block. <syntaxhighlight lang="text" inline>Throttle</syntaxhighlight> block does not modify the samples but allows to perform a flow control on all the data circulating between the source and the sink. Last, be careful to the color of the input and output of each block since they represent the type of data flowing on the link. The following table presents main data type and associated used by GNU Radio. Also, since Python is strongly typed, colors located at both ends of a wire have to be the same.<br />
<br />
{| class="wikitable" style="text-align: left;"<br />
|-<br />
!Color<br />
!Type<br />
!Size<br />
|-<br />
|style="background: #000;"| || #000 || Black<br />
|Complex<br />
|2 x 64 bits<br />
|-<br />
|Orange<br />
|Float<br />
|64 bits<br />
|-<br />
|Green<br />
|Int<br />
|64/32 bits<br />
|-<br />
|Yellow<br />
|Short<br />
|16 bits<br />
|-<br />
|Purple<br />
|Char<br />
|8 bits<br />
|}<br />
<br />
* Save the flowgraph under your directory. This file is saved with a <syntaxhighlight lang="text" inline>.grc</syntaxhighlight> extension.<br />
<br />
* Generate the associated Python script associated to your flowgraph using the "blue to red" button. If errors are present, the script is not generated and full listing is present under the no entry sign. When successful, observe the python script named <syntaxhighlight lang="text" inline>top_block.py</syntaxhighlight> in your directory.<br />
<br />
* Execute the script by pressing the run button. Equivalently, you can also invoke <syntaxhighlight lang="text" inline>python top_block.py</syntaxhighlight>.<br />
<br />
The execution should display an oscilloscope-like widow with the corresponding signal (a cosine function). You can stop the execution by closing the window or by pressing the stop button.<br />
<br />
* Check the amplitude and the period of the generated signal.<br />
<br />
* Finally, add a <syntaxhighlight lang="text" inline>Slider</syntaxhighlight> block to modify the frequency of the signal in real time (without recompiling the flowgraph) and check the operation on the scope. Save the flowgraph.<br />
<br />
Note that the source simply generates samples which are plotted by the sink, however, this source and this sink can produce and consume as much data that your CPU can handle (data are just generated and plotted iteratively as fast as possible). To overcome this issue, the <syntaxhighlight lang="text" inline>Throttle</syntaxhighlight> block is used to process a given number of sample per second, thus lowering the CPU load to few percents. Most of the blocks in GNU Radio do not fixed the rate at which samples are processed: when sufficient number of samples are present at the input, the considered function is called and produces samples at the output which are then available for the other blocks. Usually, this rate is fixed when we work with real devices (for example an audio card can acquire samples at a given frequency e.g. 48 kHz) which fixed the rate for the whole flowgraph. In our example, we do not use any real device so the rate has to be fixed using the <syntaxhighlight lang="text" inline>Throttle</syntaxhighlight> block. Also, for each flowgraph, a single rate has to be used thus if we work with a real device, the <syntaxhighlight lang="text" inline>Throttle</syntaxhighlight> block is not needed anymore and has to be removed.<br />
<br />
<br />
* Create the flowgraph presented in Fig. 2.<br />
<br />
[[File:Im2.png|frame|center|Fig. 2: Simple operations on signals]]<br />
<br />
* Add a <syntaxhighlight lang="text" inline>FFT Sink</syntaxhighlight> to observe the signal spectrum. On the graph, the two peaks are very close and seem to be confused. Reduce the frequency sampling to increase the frequency resolution. Explain the phenomenum.<br />
<br />
* What is the minimum value of the sampling frequency? Observe the signal (in time and in frequency) for frequencies below this limit.<br />
<br />
* Replace the <syntaxhighlight lang="text" inline>Add</syntaxhighlight> block with a multiplier block <syntaxhighlight lang="text" inline>Mult</syntaxhighlight>. Predict the position of the peaks in the output signal. Check your results.<br />
<br />
* Add a filter (block <syntaxhighlight lang="text" inline>Low Pass Filter</syntaxhighlight>) to recover the low frequency part of the signal. Check your results in the time and frequency domain. Repeat the manipulation to keep the high frequency part.<br />
<br />
The <syntaxhighlight lang="text" inline>Low Pass Filter</syntaxhighlight> (and <syntaxhighlight lang="text" inline>High Pass Filter</syntaxhighlight>) blocks are high-level blocks which realize the design (i.e. determining the coefficients of the filter) as well as the filtering (i.e. the convolution). The filter design can also be done with <syntaxhighlight lang="text" inline>gr_filter_design</syntaxhighlight> to obtain the coefficients. These coefficients can then be used directly by the blocks <syntaxhighlight lang="text" inline>FIR Filter</syntaxhighlight> and <syntaxhighlight lang="text" inline>IIR Filter</syntaxhighlight>.<br />
<br />
== Amplitude Modulation ==<br />
<br />
=== Double side band without carrier ===<br />
<br />
* Realize the modulation of a signal <math>m(t)=\cos 2\pi f_m t</math> using a double side band without carrier. Note that transmitted signal can be expressed as<br />
<br />
<math><br />
x(t) = A m(t) \cos 2 \pi f_0 t<br />
</math><br />
<br />
* Observe the signal in both time and frequency domain.<br />
<br />
* Give the architecture of a coherent detector used to recover the message <math>m(t)</math> from <math>x(t)</math>.<br />
<br />
* Implement this detector to demodulate the signal and verify the good operation. You can use 2 different flowgraphs (1 for the transmission and 1 for the reception) using a <syntaxhighlight lang="text" inline>File Sink</syntaxhighlight> and <syntaxhighlight lang="text" inline>File Source</syntaxhighlight> respectively.<br />
<br />
=== Double side band without carrier ===<br />
<br />
* Realize the modulation of a signal <math>m(t)=\cos 2\pi f_m t</math> using a double side band with carrier. Note that transmitted signal can be expressed as<br />
<br />
[[File:Env.png|thumb|right|Fig. 3: Envelope detector used for AM signals.]]<br />
<br />
<math><br />
x(t) = A (1 + k_a m(t)) \cos 2 \pi f_0 t<br />
</math><br />
<br />
* Observe the signal in both time and frequency domain.<br />
<br />
* Modify the modulation index <math>k_a</math> using a slider and observe the modification of the signal.<br />
<br />
* AM signals are usually demodulted using a simple envelope detector. The architecture of this decoder is presented in Fig. 3.<br />
<br />
* Implement this detector to demodulate the signal and verify the good operation.<br />
<br />
* Check also if the AM signal can be decoded using the coherent detector.<br />
<br />
* Finally, download the file <syntaxhighlight lang="text" inline>am_usrp710.dat</syntaxhighlight>. This file contains the complex envelope (I and Q channels) received by a USRP around the frequency 710 kHz with a sampling frequency of 256 kHz. Visualize the data with a block <syntaxhighlight lang="text" inline>FFT Sink</syntaxhighlight> (insert a block <syntaxhighlight lang="text" inline>Throttle</syntaxhighlight> to avoid overloading the processor). On the graph, we can see two stations transmit at 710 kHz (center) and 790 kHz (to the right). Knowing that the bandwidth of an AM signal is 10 kHz, insert a low pass filter allowing to select the station located around 710 kHz. Check that the filter is working properly on the graph. Insert the envelope detector at the output of the filter and a block <syntaxhighlight lang="text" inline>Rational Resampler</syntaxhighlight> to adapt the bit rate to the sound card (48 kHz) using an <syntaxhighlight lang="text" inline>Audio Sink</syntaxhighlight>.<br />
<br />
* Check the correct operation on the PC speakers (add if needed a <syntaxhighlight lang="text" inline>Multiply Const.</syntaxhighlight> block to set the volume of the station).<br />
<br />
== Frequency Modulation ==<br />
<br />
== Digital Communication ==</div>Nicohttps://nicolas-barbot.ovh/wiki/index.php?title=SC311_Wireless_Communications&diff=441SC311 Wireless Communications2021-08-20T20:47:52Z<p>Nico: </p>
<hr />
<div>The objective of this course is to understand how we can transmit a message in-between a transmitter and a receiver spatially separated. Especially, how we can use signal processing operations to adapt (i.e. modulate and demodulate) the message to realize the transmission over wired or wireless channels. This course describes the processes realized at a signal level and can be related to [[MA331 Information Theory and Channel Coding]] (which presents the general problem at a higher level).<br />
<br />
Slides of the course can be downloaded here. Exercises can be downloaded here. The following of this page corresponds to the labs.<br />
<br />
__TOC__<br />
<br />
In this labs, we will realize different modulations and demodulations used to transmit and receive analog and digital messages.<br />
Spectrum (or power spectral density) will also be determined.<br />
Finally, performance, in term of Sinal to Noise Ratio (SNR) or Bit Error Rate (BER) will be estimated in each case.<br />
<br />
These labs are based on [https://www.gnuradio.org/ GNU Radio] which is a free software that provides a large number of software blocks to perform most signal processing operations. The blocks are mostly written in C ++. It is possible to use these blocks directly from Python to simulate or create telecommunication systems.<br />
In addition, to make it easier to get started, GNU Radio also provides a utility called <syntaxhighlight lang="text" inline>gnuradio-companion</syntaxhighlight> to assemble blocks graphically and to generate the corresponding python script. This subject have been written for GNU Radio, but it can be equivalently realized using [https://www.gnu.org/software/octave/index Octave], or [http://itpp.sourceforge.net/4.3.1/ IT++] library.<br />
<br />
== Getting Started ==<br />
<br />
* Open a terminal<br />
<br />
* Create a working directory in which you will place your scripts.<br />
<br />
* Run <syntaxhighlight lang="text" inline>gnuradio-companion</syntaxhighlight>.<br />
<br />
This software allows you to use blocks (available in the right column) and to connect them to realize any complex signal processing operations. Resulting program is called a flowgraph in GNU Radio language.<br />
<br />
For any flowgraph, there is basically 3 types of blocks: sources (which produce samples and have at least 1 output), sinks (which consume samples and have at least 1 input) and processing block (which have at least 1 input and 1 output). Blocks are simply connected by creating a link in-between an output of a block and an input of another block.<br />
<br />
* Create the flowgraph presented in Fig. 1.<br />
<br />
[[File:Im1.png|frame|center|Fig. 1: Simple generation and data plotting]]<br />
<br />
The <syntaxhighlight lang="text" inline>Signal Source</syntaxhighlight> block generates an infinity of sinusoidal samples (or other) from the different parameters. These samples are displayed according to the time using the <syntaxhighlight lang="text" inline>Scope Sink</syntaxhighlight> block. <syntaxhighlight lang="text" inline>Throttle</syntaxhighlight> block does not modify the samples but allows to perform a flow control on all the data circulating between the source and the sink. Last, be careful to the color of the input and output of each block since they represent the type of data flowing on the link. The following table presents main data type and associated used by GNU Radio. Also, since Python is strongly typed, colors located at both ends of a wire have to be the same.<br />
<br />
{| class="wikitable" style="text-align: left;"<br />
|-<br />
!Color<br />
!Type<br />
!Size<br />
|-<br />
| <svg width="400" height="110"> <rect width="300" height="100" style="fill:rgb(0,0,255);stroke-width:3;stroke:rgb(0,0,0)" /> </svg> <br />
|Complex<br />
|2 x 64 bits<br />
|-<br />
|Orange<br />
|Float<br />
|64 bits<br />
|-<br />
|Green<br />
|Int<br />
|64/32 bits<br />
|-<br />
|Yellow<br />
|Short<br />
|16 bits<br />
|-<br />
|Purple<br />
|Char<br />
|8 bits<br />
|}<br />
<br />
* Save the flowgraph under your directory. This file is saved with a <syntaxhighlight lang="text" inline>.grc</syntaxhighlight> extension.<br />
<br />
* Generate the associated Python script associated to your flowgraph using the "blue to red" button. If errors are present, the script is not generated and full listing is present under the no entry sign. When successful, observe the python script named <syntaxhighlight lang="text" inline>top_block.py</syntaxhighlight> in your directory.<br />
<br />
* Execute the script by pressing the run button. Equivalently, you can also invoke <syntaxhighlight lang="text" inline>python top_block.py</syntaxhighlight>.<br />
<br />
The execution should display an oscilloscope-like widow with the corresponding signal (a cosine function). You can stop the execution by closing the window or by pressing the stop button.<br />
<br />
* Check the amplitude and the period of the generated signal.<br />
<br />
* Finally, add a <syntaxhighlight lang="text" inline>Slider</syntaxhighlight> block to modify the frequency of the signal in real time (without recompiling the flowgraph) and check the operation on the scope. Save the flowgraph.<br />
<br />
Note that the source simply generates samples which are plotted by the sink, however, this source and this sink can produce and consume as much data that your CPU can handle (data are just generated and plotted iteratively as fast as possible). To overcome this issue, the <syntaxhighlight lang="text" inline>Throttle</syntaxhighlight> block is used to process a given number of sample per second, thus lowering the CPU load to few percents. Most of the blocks in GNU Radio do not fixed the rate at which samples are processed: when sufficient number of samples are present at the input, the considered function is called and produces samples at the output which are then available for the other blocks. Usually, this rate is fixed when we work with real devices (for example an audio card can acquire samples at a given frequency e.g. 48 kHz) which fixed the rate for the whole flowgraph. In our example, we do not use any real device so the rate has to be fixed using the <syntaxhighlight lang="text" inline>Throttle</syntaxhighlight> block. Also, for each flowgraph, a single rate has to be used thus if we work with a real device, the <syntaxhighlight lang="text" inline>Throttle</syntaxhighlight> block is not needed anymore and has to be removed.<br />
<br />
<br />
* Create the flowgraph presented in Fig. 2.<br />
<br />
[[File:Im2.png|frame|center|Fig. 2: Simple operations on signals]]<br />
<br />
* Add a <syntaxhighlight lang="text" inline>FFT Sink</syntaxhighlight> to observe the signal spectrum. On the graph, the two peaks are very close and seem to be confused. Reduce the frequency sampling to increase the frequency resolution. Explain the phenomenum.<br />
<br />
* What is the minimum value of the sampling frequency? Observe the signal (in time and in frequency) for frequencies below this limit.<br />
<br />
* Replace the <syntaxhighlight lang="text" inline>Add</syntaxhighlight> block with a multiplier block <syntaxhighlight lang="text" inline>Mult</syntaxhighlight>. Predict the position of the peaks in the output signal. Check your results.<br />
<br />
* Add a filter (block <syntaxhighlight lang="text" inline>Low Pass Filter</syntaxhighlight>) to recover the low frequency part of the signal. Check your results in the time and frequency domain. Repeat the manipulation to keep the high frequency part.<br />
<br />
The <syntaxhighlight lang="text" inline>Low Pass Filter</syntaxhighlight> (and <syntaxhighlight lang="text" inline>High Pass Filter</syntaxhighlight>) blocks are high-level blocks which realize the design (i.e. determining the coefficients of the filter) as well as the filtering (i.e. the convolution). The filter design can also be done with <syntaxhighlight lang="text" inline>gr_filter_design</syntaxhighlight> to obtain the coefficients. These coefficients can then be used directly by the blocks <syntaxhighlight lang="text" inline>FIR Filter</syntaxhighlight> and <syntaxhighlight lang="text" inline>IIR Filter</syntaxhighlight>.<br />
<br />
== Amplitude Modulation ==<br />
<br />
=== Double side band without carrier ===<br />
<br />
* Realize the modulation of a signal <math>m(t)=\cos 2\pi f_m t</math> using a double side band without carrier. Note that transmitted signal can be expressed as<br />
<br />
<math><br />
x(t) = A m(t) \cos 2 \pi f_0 t<br />
</math><br />
<br />
* Observe the signal in both time and frequency domain.<br />
<br />
* Give the architecture of a coherent detector used to recover the message <math>m(t)</math> from <math>x(t)</math>.<br />
<br />
* Implement this detector to demodulate the signal and verify the good operation. You can use 2 different flowgraphs (1 for the transmission and 1 for the reception) using a <syntaxhighlight lang="text" inline>File Sink</syntaxhighlight> and <syntaxhighlight lang="text" inline>File Source</syntaxhighlight> respectively.<br />
<br />
=== Double side band without carrier ===<br />
<br />
* Realize the modulation of a signal <math>m(t)=\cos 2\pi f_m t</math> using a double side band with carrier. Note that transmitted signal can be expressed as<br />
<br />
[[File:Env.png|thumb|right|Fig. 3: Envelope detector used for AM signals.]]<br />
<br />
<math><br />
x(t) = A (1 + k_a m(t)) \cos 2 \pi f_0 t<br />
</math><br />
<br />
* Observe the signal in both time and frequency domain.<br />
<br />
* Modify the modulation index <math>k_a</math> using a slider and observe the modification of the signal.<br />
<br />
* AM signals are usually demodulted using a simple envelope detector. The architecture of this decoder is presented in Fig. 3.<br />
<br />
* Implement this detector to demodulate the signal and verify the good operation.<br />
<br />
* Check also if the AM signal can be decoded using the coherent detector.<br />
<br />
* Finally, download the file <syntaxhighlight lang="text" inline>am_usrp710.dat</syntaxhighlight>. This file contains the complex envelope (I and Q channels) received by a USRP around the frequency 710 kHz with a sampling frequency of 256 kHz. Visualize the data with a block <syntaxhighlight lang="text" inline>FFT Sink</syntaxhighlight> (insert a block <syntaxhighlight lang="text" inline>Throttle</syntaxhighlight> to avoid overloading the processor). On the graph, we can see two stations transmit at 710 kHz (center) and 790 kHz (to the right). Knowing that the bandwidth of an AM signal is 10 kHz, insert a low pass filter allowing to select the station located around 710 kHz. Check that the filter is working properly on the graph. Insert the envelope detector at the output of the filter and a block <syntaxhighlight lang="text" inline>Rational Resampler</syntaxhighlight> to adapt the bit rate to the sound card (48 kHz) using an <syntaxhighlight lang="text" inline>Audio Sink</syntaxhighlight>.<br />
<br />
* Check the correct operation on the PC speakers (add if needed a <syntaxhighlight lang="text" inline>Multiply Const.</syntaxhighlight> block to set the volume of the station).<br />
<br />
== Frequency Modulation ==<br />
<br />
== Digital Communication ==</div>Nicohttps://nicolas-barbot.ovh/wiki/index.php?title=SC311_Wireless_Communications&diff=440SC311 Wireless Communications2021-08-20T20:45:07Z<p>Nico: </p>
<hr />
<div>The objective of this course is to understand how we can transmit a message in-between a transmitter and a receiver spatially separated. Especially, how we can use signal processing operations to adapt (i.e. modulate and demodulate) the message to realize the transmission over wired or wireless channels. This course describes the processes realized at a signal level and can be related to [[MA331 Information Theory and Channel Coding]] (which presents the general problem at a higher level).<br />
<br />
Slides of the course can be downloaded here. Exercises can be downloaded here. The following of this page corresponds to the labs.<br />
<br />
__TOC__<br />
<br />
In this labs, we will realize different modulations and demodulations used to transmit and receive analog and digital messages.<br />
Spectrum (or power spectral density) will also be determined.<br />
Finally, performance, in term of Sinal to Noise Ratio (SNR) or Bit Error Rate (BER) will be estimated in each case.<br />
<br />
These labs are based on [https://www.gnuradio.org/ GNU Radio] which is a free software that provides a large number of software blocks to perform most signal processing operations. The blocks are mostly written in C ++. It is possible to use these blocks directly from Python to simulate or create telecommunication systems.<br />
In addition, to make it easier to get started, GNU Radio also provides a utility called <syntaxhighlight lang="text" inline>gnuradio-companion</syntaxhighlight> to assemble blocks graphically and to generate the corresponding python script. This subject have been written for GNU Radio, but it can be equivalently realized using [https://www.gnu.org/software/octave/index Octave], or [http://itpp.sourceforge.net/4.3.1/ IT++] library.<br />
<br />
== Getting Started ==<br />
<br />
* Open a terminal<br />
<br />
* Create a working directory in which you will place your scripts.<br />
<br />
* Run <syntaxhighlight lang="text" inline>gnuradio-companion</syntaxhighlight>.<br />
<br />
This software allows you to use blocks (available in the right column) and to connect them to realize any complex signal processing operations. Resulting program is called a flowgraph in GNU Radio language.<br />
<br />
For any flowgraph, there is basically 3 types of blocks: sources (which produce samples and have at least 1 output), sinks (which consume samples and have at least 1 input) and processing block (which have at least 1 input and 1 output). Blocks are simply connected by creating a link in-between an output of a block and an input of another block.<br />
<br />
* Create the flowgraph presented in Fig. 1.<br />
<br />
[[File:Im1.png|frame|center|Fig. 1: Simple generation and data plotting]]<br />
<br />
The <syntaxhighlight lang="text" inline>Signal Source</syntaxhighlight> block generates an infinity of sinusoidal samples (or other) from the different parameters. These samples are displayed according to the time using the <syntaxhighlight lang="text" inline>Scope Sink</syntaxhighlight> block. <syntaxhighlight lang="text" inline>Throttle</syntaxhighlight> block does not modify the samples but allows to perform a flow control on all the data circulating between the source and the sink. Last, be careful to the color of the input and output of each block since they represent the type of data flowing on the link. The following table presents main data type and associated used by GNU Radio. Also, since Python is strongly typed, colors located at both ends of a wire have to be the same.<br />
<br />
{| class="wikitable" style="text-align: left;"<br />
|-<br />
!Color<br />
!Type<br />
!Size<br />
|-<br />
|<div id="rectangle" style="width:200 px; height:100 px; background-color:blue"></div><br />
|Complex<br />
|2 x 64 bits<br />
|-<br />
|Orange<br />
|Float<br />
|64 bits<br />
|-<br />
|Green<br />
|Int<br />
|64/32 bits<br />
|-<br />
|Yellow<br />
|Short<br />
|16 bits<br />
|-<br />
|Purple<br />
|Char<br />
|8 bits<br />
|}<br />
<br />
* Save the flowgraph under your directory. This file is saved with a <syntaxhighlight lang="text" inline>.grc</syntaxhighlight> extension.<br />
<br />
* Generate the associated Python script associated to your flowgraph using the "blue to red" button. If errors are present, the script is not generated and full listing is present under the no entry sign. When successful, observe the python script named <syntaxhighlight lang="text" inline>top_block.py</syntaxhighlight> in your directory.<br />
<br />
* Execute the script by pressing the run button. Equivalently, you can also invoke <syntaxhighlight lang="text" inline>python top_block.py</syntaxhighlight>.<br />
<br />
The execution should display an oscilloscope-like widow with the corresponding signal (a cosine function). You can stop the execution by closing the window or by pressing the stop button.<br />
<br />
* Check the amplitude and the period of the generated signal.<br />
<br />
* Finally, add a <syntaxhighlight lang="text" inline>Slider</syntaxhighlight> block to modify the frequency of the signal in real time (without recompiling the flowgraph) and check the operation on the scope. Save the flowgraph.<br />
<br />
Note that the source simply generates samples which are plotted by the sink, however, this source and this sink can produce and consume as much data that your CPU can handle (data are just generated and plotted iteratively as fast as possible). To overcome this issue, the <syntaxhighlight lang="text" inline>Throttle</syntaxhighlight> block is used to process a given number of sample per second, thus lowering the CPU load to few percents. Most of the blocks in GNU Radio do not fixed the rate at which samples are processed: when sufficient number of samples are present at the input, the considered function is called and produces samples at the output which are then available for the other blocks. Usually, this rate is fixed when we work with real devices (for example an audio card can acquire samples at a given frequency e.g. 48 kHz) which fixed the rate for the whole flowgraph. In our example, we do not use any real device so the rate has to be fixed using the <syntaxhighlight lang="text" inline>Throttle</syntaxhighlight> block. Also, for each flowgraph, a single rate has to be used thus if we work with a real device, the <syntaxhighlight lang="text" inline>Throttle</syntaxhighlight> block is not needed anymore and has to be removed.<br />
<br />
<br />
* Create the flowgraph presented in Fig. 2.<br />
<br />
[[File:Im2.png|frame|center|Fig. 2: Simple operations on signals]]<br />
<br />
* Add a <syntaxhighlight lang="text" inline>FFT Sink</syntaxhighlight> to observe the signal spectrum. On the graph, the two peaks are very close and seem to be confused. Reduce the frequency sampling to increase the frequency resolution. Explain the phenomenum.<br />
<br />
* What is the minimum value of the sampling frequency? Observe the signal (in time and in frequency) for frequencies below this limit.<br />
<br />
* Replace the <syntaxhighlight lang="text" inline>Add</syntaxhighlight> block with a multiplier block <syntaxhighlight lang="text" inline>Mult</syntaxhighlight>. Predict the position of the peaks in the output signal. Check your results.<br />
<br />
* Add a filter (block <syntaxhighlight lang="text" inline>Low Pass Filter</syntaxhighlight>) to recover the low frequency part of the signal. Check your results in the time and frequency domain. Repeat the manipulation to keep the high frequency part.<br />
<br />
The <syntaxhighlight lang="text" inline>Low Pass Filter</syntaxhighlight> (and <syntaxhighlight lang="text" inline>High Pass Filter</syntaxhighlight>) blocks are high-level blocks which realize the design (i.e. determining the coefficients of the filter) as well as the filtering (i.e. the convolution). The filter design can also be done with <syntaxhighlight lang="text" inline>gr_filter_design</syntaxhighlight> to obtain the coefficients. These coefficients can then be used directly by the blocks <syntaxhighlight lang="text" inline>FIR Filter</syntaxhighlight> and <syntaxhighlight lang="text" inline>IIR Filter</syntaxhighlight>.<br />
<br />
== Amplitude Modulation ==<br />
<br />
=== Double side band without carrier ===<br />
<br />
* Realize the modulation of a signal <math>m(t)=\cos 2\pi f_m t</math> using a double side band without carrier. Note that transmitted signal can be expressed as<br />
<br />
<math><br />
x(t) = A m(t) \cos 2 \pi f_0 t<br />
</math><br />
<br />
* Observe the signal in both time and frequency domain.<br />
<br />
* Give the architecture of a coherent detector used to recover the message <math>m(t)</math> from <math>x(t)</math>.<br />
<br />
* Implement this detector to demodulate the signal and verify the good operation. You can use 2 different flowgraphs (1 for the transmission and 1 for the reception) using a <syntaxhighlight lang="text" inline>File Sink</syntaxhighlight> and <syntaxhighlight lang="text" inline>File Source</syntaxhighlight> respectively.<br />
<br />
=== Double side band without carrier ===<br />
<br />
* Realize the modulation of a signal <math>m(t)=\cos 2\pi f_m t</math> using a double side band with carrier. Note that transmitted signal can be expressed as<br />
<br />
[[File:Env.png|thumb|right|Fig. 3: Envelope detector used for AM signals.]]<br />
<br />
<math><br />
x(t) = A (1 + k_a m(t)) \cos 2 \pi f_0 t<br />
</math><br />
<br />
* Observe the signal in both time and frequency domain.<br />
<br />
* Modify the modulation index <math>k_a</math> using a slider and observe the modification of the signal.<br />
<br />
* AM signals are usually demodulted using a simple envelope detector. The architecture of this decoder is presented in Fig. 3.<br />
<br />
* Implement this detector to demodulate the signal and verify the good operation.<br />
<br />
* Check also if the AM signal can be decoded using the coherent detector.<br />
<br />
* Finally, download the file <syntaxhighlight lang="text" inline>am_usrp710.dat</syntaxhighlight>. This file contains the complex envelope (I and Q channels) received by a USRP around the frequency 710 kHz with a sampling frequency of 256 kHz. Visualize the data with a block <syntaxhighlight lang="text" inline>FFT Sink</syntaxhighlight> (insert a block <syntaxhighlight lang="text" inline>Throttle</syntaxhighlight> to avoid overloading the processor). On the graph, we can see two stations transmit at 710 kHz (center) and 790 kHz (to the right). Knowing that the bandwidth of an AM signal is 10 kHz, insert a low pass filter allowing to select the station located around 710 kHz. Check that the filter is working properly on the graph. Insert the envelope detector at the output of the filter and a block <syntaxhighlight lang="text" inline>Rational Resampler</syntaxhighlight> to adapt the bit rate to the sound card (48 kHz) using an <syntaxhighlight lang="text" inline>Audio Sink</syntaxhighlight>.<br />
<br />
* Check the correct operation on the PC speakers (add if needed a <syntaxhighlight lang="text" inline>Multiply Const.</syntaxhighlight> block to set the volume of the station).<br />
<br />
== Frequency Modulation ==<br />
<br />
== Digital Communication ==</div>Nicohttps://nicolas-barbot.ovh/wiki/index.php?title=SC311_Wireless_Communications&diff=439SC311 Wireless Communications2021-08-20T20:43:56Z<p>Nico: </p>
<hr />
<div>The objective of this course is to understand how we can transmit a message in-between a transmitter and a receiver spatially separated. Especially, how we can use signal processing operations to adapt (i.e. modulate and demodulate) the message to realize the transmission over wired or wireless channels. This course describes the processes realized at a signal level and can be related to [[MA331 Information Theory and Channel Coding]] (which presents the general problem at a higher level).<br />
<br />
Slides of the course can be downloaded here. Exercises can be downloaded here. The following of this page corresponds to the labs.<br />
<br />
__TOC__<br />
<br />
In this labs, we will realize different modulations and demodulations used to transmit and receive analog and digital messages.<br />
Spectrum (or power spectral density) will also be determined.<br />
Finally, performance, in term of Sinal to Noise Ratio (SNR) or Bit Error Rate (BER) will be estimated in each case.<br />
<br />
These labs are based on [https://www.gnuradio.org/ GNU Radio] which is a free software that provides a large number of software blocks to perform most signal processing operations. The blocks are mostly written in C ++. It is possible to use these blocks directly from Python to simulate or create telecommunication systems.<br />
In addition, to make it easier to get started, GNU Radio also provides a utility called <syntaxhighlight lang="text" inline>gnuradio-companion</syntaxhighlight> to assemble blocks graphically and to generate the corresponding python script. This subject have been written for GNU Radio, but it can be equivalently realized using [https://www.gnu.org/software/octave/index Octave], or [http://itpp.sourceforge.net/4.3.1/ IT++] library.<br />
<br />
== Getting Started ==<br />
<br />
* Open a terminal<br />
<br />
* Create a working directory in which you will place your scripts.<br />
<br />
* Run <syntaxhighlight lang="text" inline>gnuradio-companion</syntaxhighlight>.<br />
<br />
This software allows you to use blocks (available in the right column) and to connect them to realize any complex signal processing operations. Resulting program is called a flowgraph in GNU Radio language.<br />
<br />
For any flowgraph, there is basically 3 types of blocks: sources (which produce samples and have at least 1 output), sinks (which consume samples and have at least 1 input) and processing block (which have at least 1 input and 1 output). Blocks are simply connected by creating a link in-between an output of a block and an input of another block.<br />
<br />
* Create the flowgraph presented in Fig. 1.<br />
<br />
[[File:Im1.png|frame|center|Fig. 1: Simple generation and data plotting]]<br />
<br />
The <syntaxhighlight lang="text" inline>Signal Source</syntaxhighlight> block generates an infinity of sinusoidal samples (or other) from the different parameters. These samples are displayed according to the time using the <syntaxhighlight lang="text" inline>Scope Sink</syntaxhighlight> block. <syntaxhighlight lang="text" inline>Throttle</syntaxhighlight> block does not modify the samples but allows to perform a flow control on all the data circulating between the source and the sink. Last, be careful to the color of the input and output of each block since they represent the type of data flowing on the link. The following table presents main data type and associated used by GNU Radio. Also, since Python is strongly typed, colors located at both ends of a wire have to be the same.<br />
<br />
{| class="wikitable" style="text-align: left;"<br />
|-<br />
!Color<br />
!Type<br />
!Size<br />
|-<br />
|<div id="rectangle" style="width:20 px; height:10 px; background-color:blue"></div><br />
|Complex<br />
|2 x 64 bits<br />
|-<br />
|Orange<br />
|Float<br />
|64 bits<br />
|-<br />
|Green<br />
|Int<br />
|64/32 bits<br />
|-<br />
|Yellow<br />
|Short<br />
|16 bits<br />
|-<br />
|Purple<br />
|Char<br />
|8 bits<br />
|}<br />
<br />
* Save the flowgraph under your directory. This file is saved with a <syntaxhighlight lang="text" inline>.grc</syntaxhighlight> extension.<br />
<br />
* Generate the associated Python script associated to your flowgraph using the "blue to red" button. If errors are present, the script is not generated and full listing is present under the no entry sign. When successful, observe the python script named <syntaxhighlight lang="text" inline>top_block.py</syntaxhighlight> in your directory.<br />
<br />
* Execute the script by pressing the run button. Equivalently, you can also invoke <syntaxhighlight lang="text" inline>python top_block.py</syntaxhighlight>.<br />
<br />
The execution should display an oscilloscope-like widow with the corresponding signal (a cosine function). You can stop the execution by closing the window or by pressing the stop button.<br />
<br />
* Check the amplitude and the period of the generated signal.<br />
<br />
* Finally, add a <syntaxhighlight lang="text" inline>Slider</syntaxhighlight> block to modify the frequency of the signal in real time (without recompiling the flowgraph) and check the operation on the scope. Save the flowgraph.<br />
<br />
Note that the source simply generates samples which are plotted by the sink, however, this source and this sink can produce and consume as much data that your CPU can handle (data are just generated and plotted iteratively as fast as possible). To overcome this issue, the <syntaxhighlight lang="text" inline>Throttle</syntaxhighlight> block is used to process a given number of sample per second, thus lowering the CPU load to few percents. Most of the blocks in GNU Radio do not fixed the rate at which samples are processed: when sufficient number of samples are present at the input, the considered function is called and produces samples at the output which are then available for the other blocks. Usually, this rate is fixed when we work with real devices (for example an audio card can acquire samples at a given frequency e.g. 48 kHz) which fixed the rate for the whole flowgraph. In our example, we do not use any real device so the rate has to be fixed using the <syntaxhighlight lang="text" inline>Throttle</syntaxhighlight> block. Also, for each flowgraph, a single rate has to be used thus if we work with a real device, the <syntaxhighlight lang="text" inline>Throttle</syntaxhighlight> block is not needed anymore and has to be removed.<br />
<br />
<br />
* Create the flowgraph presented in Fig. 2.<br />
<br />
[[File:Im2.png|frame|center|Fig. 2: Simple operations on signals]]<br />
<br />
* Add a <syntaxhighlight lang="text" inline>FFT Sink</syntaxhighlight> to observe the signal spectrum. On the graph, the two peaks are very close and seem to be confused. Reduce the frequency sampling to increase the frequency resolution. Explain the phenomenum.<br />
<br />
* What is the minimum value of the sampling frequency? Observe the signal (in time and in frequency) for frequencies below this limit.<br />
<br />
* Replace the <syntaxhighlight lang="text" inline>Add</syntaxhighlight> block with a multiplier block <syntaxhighlight lang="text" inline>Mult</syntaxhighlight>. Predict the position of the peaks in the output signal. Check your results.<br />
<br />
* Add a filter (block <syntaxhighlight lang="text" inline>Low Pass Filter</syntaxhighlight>) to recover the low frequency part of the signal. Check your results in the time and frequency domain. Repeat the manipulation to keep the high frequency part.<br />
<br />
The <syntaxhighlight lang="text" inline>Low Pass Filter</syntaxhighlight> (and <syntaxhighlight lang="text" inline>High Pass Filter</syntaxhighlight>) blocks are high-level blocks which realize the design (i.e. determining the coefficients of the filter) as well as the filtering (i.e. the convolution). The filter design can also be done with <syntaxhighlight lang="text" inline>gr_filter_design</syntaxhighlight> to obtain the coefficients. These coefficients can then be used directly by the blocks <syntaxhighlight lang="text" inline>FIR Filter</syntaxhighlight> and <syntaxhighlight lang="text" inline>IIR Filter</syntaxhighlight>.<br />
<br />
== Amplitude Modulation ==<br />
<br />
=== Double side band without carrier ===<br />
<br />
* Realize the modulation of a signal <math>m(t)=\cos 2\pi f_m t</math> using a double side band without carrier. Note that transmitted signal can be expressed as<br />
<br />
<math><br />
x(t) = A m(t) \cos 2 \pi f_0 t<br />
</math><br />
<br />
* Observe the signal in both time and frequency domain.<br />
<br />
* Give the architecture of a coherent detector used to recover the message <math>m(t)</math> from <math>x(t)</math>.<br />
<br />
* Implement this detector to demodulate the signal and verify the good operation. You can use 2 different flowgraphs (1 for the transmission and 1 for the reception) using a <syntaxhighlight lang="text" inline>File Sink</syntaxhighlight> and <syntaxhighlight lang="text" inline>File Source</syntaxhighlight> respectively.<br />
<br />
=== Double side band without carrier ===<br />
<br />
* Realize the modulation of a signal <math>m(t)=\cos 2\pi f_m t</math> using a double side band with carrier. Note that transmitted signal can be expressed as<br />
<br />
[[File:Env.png|thumb|right|Fig. 3: Envelope detector used for AM signals.]]<br />
<br />
<math><br />
x(t) = A (1 + k_a m(t)) \cos 2 \pi f_0 t<br />
</math><br />
<br />
* Observe the signal in both time and frequency domain.<br />
<br />
* Modify the modulation index <math>k_a</math> using a slider and observe the modification of the signal.<br />
<br />
* AM signals are usually demodulted using a simple envelope detector. The architecture of this decoder is presented in Fig. 3.<br />
<br />
* Implement this detector to demodulate the signal and verify the good operation.<br />
<br />
* Check also if the AM signal can be decoded using the coherent detector.<br />
<br />
* Finally, download the file <syntaxhighlight lang="text" inline>am_usrp710.dat</syntaxhighlight>. This file contains the complex envelope (I and Q channels) received by a USRP around the frequency 710 kHz with a sampling frequency of 256 kHz. Visualize the data with a block <syntaxhighlight lang="text" inline>FFT Sink</syntaxhighlight> (insert a block <syntaxhighlight lang="text" inline>Throttle</syntaxhighlight> to avoid overloading the processor). On the graph, we can see two stations transmit at 710 kHz (center) and 790 kHz (to the right). Knowing that the bandwidth of an AM signal is 10 kHz, insert a low pass filter allowing to select the station located around 710 kHz. Check that the filter is working properly on the graph. Insert the envelope detector at the output of the filter and a block <syntaxhighlight lang="text" inline>Rational Resampler</syntaxhighlight> to adapt the bit rate to the sound card (48 kHz) using an <syntaxhighlight lang="text" inline>Audio Sink</syntaxhighlight>.<br />
<br />
* Check the correct operation on the PC speakers (add if needed a <syntaxhighlight lang="text" inline>Multiply Const.</syntaxhighlight> block to set the volume of the station).<br />
<br />
== Frequency Modulation ==<br />
<br />
== Digital Communication ==</div>Nicohttps://nicolas-barbot.ovh/wiki/index.php?title=SC311_Wireless_Communications&diff=438SC311 Wireless Communications2021-08-20T16:43:41Z<p>Nico: </p>
<hr />
<div>The objective of this course is to understand how we can transmit a message in-between a transmitter and a receiver spatially separated. Especially, how we can use signal processing operations to adapt (i.e. modulate and demodulate) the message to realize the transmission over wired or wireless channels. This course describes the processes realized at a signal level and can be related to [[MA331 Information Theory and Channel Coding]] (which presents the general problem at a higher level).<br />
<br />
Slides of the course can be downloaded here. Exercises can be downloaded here. The following of this page corresponds to the labs.<br />
<br />
__TOC__<br />
<br />
In this labs, we will realize different modulations and demodulations used to transmit and receive analog and digital messages.<br />
Spectrum (or power spectral density) will also be determined.<br />
Finally, performance, in term of Sinal to Noise Ratio (SNR) or Bit Error Rate (BER) will be estimated in each case.<br />
<br />
These labs are based on [https://www.gnuradio.org/ GNU Radio] which is a free software that provides a large number of software blocks to perform most signal processing operations. The blocks are mostly written in C ++. It is possible to use these blocks directly from Python to simulate or create telecommunication systems.<br />
In addition, to make it easier to get started, GNU Radio also provides a utility called <syntaxhighlight lang="text" inline>gnuradio-companion</syntaxhighlight> to assemble blocks graphically and to generate the corresponding python script. This subject have been written for GNU Radio, but it can be equivalently realized using [https://www.gnu.org/software/octave/index Octave], or [http://itpp.sourceforge.net/4.3.1/ IT++] library.<br />
<br />
== Getting Started ==<br />
<br />
* Open a terminal<br />
<br />
* Create a working directory in which you will place your scripts.<br />
<br />
* Run <syntaxhighlight lang="text" inline>gnuradio-companion</syntaxhighlight>.<br />
<br />
This software allows you to use blocks (available in the right column) and to connect them to realize any complex signal processing operations. Resulting program is called a flowgraph in GNU Radio language.<br />
<br />
For any flowgraph, there is basically 3 types of blocks: sources (which produce samples and have at least 1 output), sinks (which consume samples and have at least 1 input) and processing block (which have at least 1 input and 1 output). Blocks are simply connected by creating a link in-between an output of a block and an input of another block.<br />
<br />
* Create the flowgraph presented in Fig. 1.<br />
<br />
[[File:Im1.png|frame|center|Fig. 1: Simple generation and data plotting]]<br />
<br />
The <syntaxhighlight lang="text" inline>Signal Source</syntaxhighlight> block generates an infinity of sinusoidal samples (or other) from the different parameters. These samples are displayed according to the time using the <syntaxhighlight lang="text" inline>Scope Sink</syntaxhighlight> block. <syntaxhighlight lang="text" inline>Throttle</syntaxhighlight> block does not modify the samples but allows to perform a flow control on all the data circulating between the source and the sink. Last, be careful to the color of the input and output of each block since they represent the type of data flowing on the link. The following table presents main data type and associated used by GNU Radio. Also, since Python is strongly typed, colors located at both ends of a wire have to be the same.<br />
<br />
{| class="wikitable" style="text-align: left;"<br />
|-<br />
!Color<br />
!Type<br />
!Size<br />
|-<br />
|Blue<br />
|Complex<br />
|2 x 64 bits<br />
|-<br />
|Orange<br />
|Float<br />
|64 bits<br />
|-<br />
|Green<br />
|Int<br />
|64/32 bits<br />
|-<br />
|Yellow<br />
|Short<br />
|16 bits<br />
|-<br />
|Purple<br />
|Char<br />
|8 bits<br />
|}<br />
<br />
* Save the flowgraph under your directory. This file is saved with a <syntaxhighlight lang="text" inline>.grc</syntaxhighlight> extension.<br />
<br />
* Generate the associated Python script associated to your flowgraph using the "blue to red" button. If errors are present, the script is not generated and full listing is present under the no entry sign. When successful, observe the python script named <syntaxhighlight lang="text" inline>top_block.py</syntaxhighlight> in your directory.<br />
<br />
* Execute the script by pressing the run button. Equivalently, you can also invoke <syntaxhighlight lang="text" inline>python top_block.py</syntaxhighlight>.<br />
<br />
The execution should display an oscilloscope-like widow with the corresponding signal (a cosine function). You can stop the execution by closing the window or by pressing the stop button.<br />
<br />
* Check the amplitude and the period of the generated signal.<br />
<br />
* Finally, add a <syntaxhighlight lang="text" inline>Slider</syntaxhighlight> block to modify the frequency of the signal in real time (without recompiling the flowgraph) and check the operation on the scope. Save the flowgraph.<br />
<br />
Note that the source simply generates samples which are plotted by the sink, however, this source and this sink can produce and consume as much data that your CPU can handle (data are just generated and plotted iteratively as fast as possible). To overcome this issue, the <syntaxhighlight lang="text" inline>Throttle</syntaxhighlight> block is used to process a given number of sample per second, thus lowering the CPU load to few percents. Most of the blocks in GNU Radio do not fixed the rate at which samples are processed: when sufficient number of samples are present at the input, the considered function is called and produces samples at the output which are then available for the other blocks. Usually, this rate is fixed when we work with real devices (for example an audio card can acquire samples at a given frequency e.g. 48 kHz) which fixed the rate for the whole flowgraph. In our example, we do not use any real device so the rate has to be fixed using the <syntaxhighlight lang="text" inline>Throttle</syntaxhighlight> block. Also, for each flowgraph, a single rate has to be used thus if we work with a real device, the <syntaxhighlight lang="text" inline>Throttle</syntaxhighlight> block is not needed anymore and has to be removed.<br />
<br />
<br />
* Create the flowgraph presented in Fig. 2.<br />
<br />
[[File:Im2.png|frame|center|Fig. 2: Simple operations on signals]]<br />
<br />
* Add a <syntaxhighlight lang="text" inline>FFT Sink</syntaxhighlight> to observe the signal spectrum. On the graph, the two peaks are very close and seem to be confused. Reduce the frequency sampling to increase the frequency resolution. Explain the phenomenum.<br />
<br />
* What is the minimum value of the sampling frequency? Observe the signal (in time and in frequency) for frequencies below this limit.<br />
<br />
* Replace the <syntaxhighlight lang="text" inline>Add</syntaxhighlight> block with a multiplier block <syntaxhighlight lang="text" inline>Mult</syntaxhighlight>. Predict the position of the peaks in the output signal. Check your results.<br />
<br />
* Add a filter (block <syntaxhighlight lang="text" inline>Low Pass Filter</syntaxhighlight>) to recover the low frequency part of the signal. Check your results in the time and frequency domain. Repeat the manipulation to keep the high frequency part.<br />
<br />
The <syntaxhighlight lang="text" inline>Low Pass Filter</syntaxhighlight> (and <syntaxhighlight lang="text" inline>High Pass Filter</syntaxhighlight>) blocks are high-level blocks which realize the design (i.e. determining the coefficients of the filter) as well as the filtering (i.e. the convolution). The filter design can also be done with <syntaxhighlight lang="text" inline>gr_filter_design</syntaxhighlight> to obtain the coefficients. These coefficients can then be used directly by the blocks <syntaxhighlight lang="text" inline>FIR Filter</syntaxhighlight> and <syntaxhighlight lang="text" inline>IIR Filter</syntaxhighlight>.<br />
<br />
== Amplitude Modulation ==<br />
<br />
=== Double side band without carrier ===<br />
<br />
* Realize the modulation of a signal <math>m(t)=\cos 2\pi f_m t</math> using a double side band without carrier. Note that transmitted signal can be expressed as<br />
<br />
<math><br />
x(t) = A m(t) \cos 2 \pi f_0 t<br />
</math><br />
<br />
* Observe the signal in both time and frequency domain.<br />
<br />
* Give the architecture of a coherent detector used to recover the message <math>m(t)</math> from <math>x(t)</math>.<br />
<br />
* Implement this detector to demodulate the signal and verify the good operation. You can use 2 different flowgraphs (1 for the transmission and 1 for the reception) using a <syntaxhighlight lang="text" inline>File Sink</syntaxhighlight> and <syntaxhighlight lang="text" inline>File Source</syntaxhighlight> respectively.<br />
<br />
=== Double side band without carrier ===<br />
<br />
* Realize the modulation of a signal <math>m(t)=\cos 2\pi f_m t</math> using a double side band with carrier. Note that transmitted signal can be expressed as<br />
<br />
[[File:Env.png|thumb|right|Fig. 3: Envelope detector used for AM signals.]]<br />
<br />
<math><br />
x(t) = A (1 + k_a m(t)) \cos 2 \pi f_0 t<br />
</math><br />
<br />
* Observe the signal in both time and frequency domain.<br />
<br />
* Modify the modulation index <math>k_a</math> using a slider and observe the modification of the signal.<br />
<br />
* AM signals are usually demodulted using a simple envelope detector. The architecture of this decoder is presented in Fig. 3.<br />
<br />
* Implement this detector to demodulate the signal and verify the good operation.<br />
<br />
* Check also if the AM signal can be decoded using the coherent detector.<br />
<br />
* Finally, download the file <syntaxhighlight lang="text" inline>am_usrp710.dat</syntaxhighlight>. This file contains the complex envelope (I and Q channels) received by a USRP around the frequency 710 kHz with a sampling frequency of 256 kHz. Visualize the data with a block <syntaxhighlight lang="text" inline>FFT Sink</syntaxhighlight> (insert a block <syntaxhighlight lang="text" inline>Throttle</syntaxhighlight> to avoid overloading the processor). On the graph, we can see two stations transmit at 710 kHz (center) and 790 kHz (to the right). Knowing that the bandwidth of an AM signal is 10 kHz, insert a low pass filter allowing to select the station located around 710 kHz. Check that the filter is working properly on the graph. Insert the envelope detector at the output of the filter and a block <syntaxhighlight lang="text" inline>Rational Resampler</syntaxhighlight> to adapt the bit rate to the sound card (48 kHz) using an <syntaxhighlight lang="text" inline>Audio Sink</syntaxhighlight>.<br />
<br />
* Check the correct operation on the PC speakers (add if needed a <syntaxhighlight lang="text" inline>Multiply Const.</syntaxhighlight> block to set the volume of the station).<br />
<br />
== Frequency Modulation ==<br />
<br />
== Digital Communication ==</div>Nicohttps://nicolas-barbot.ovh/wiki/index.php?title=SC311_Wireless_Communications&diff=437SC311 Wireless Communications2021-08-20T16:42:23Z<p>Nico: </p>
<hr />
<div>The objective of this course is to understand how we can transmit a message in-between a transmitter and a receiver spatially separated. Especially, how we can use signal processing operations to adapt (i.e. modulate and demodulate) the message to realize the transmission over wired or wireless channels. This course describes the processes realized at a signal level and can be related to [[MA331 Information Theory and Channel Coding]] (which presents the general problem at a higher level).<br />
<br />
Slides of the course can be downloaded here. Exercises can be downloaded here. The following of this page corresponds to the labs.<br />
<br />
__TOC__<br />
<br />
In this labs, we will realize different modulations and demodulations used to transmit and receive analog and digital messages.<br />
Spectrum (or power spectral density) will also be determined.<br />
Finally, performance, in term of Sinal to Noise Ratio (SNR) or Bit Error Rate (BER) will be estimated in each case.<br />
<br />
These labs are based on [https://www.gnuradio.org/ GNU Radio] which is a free software that provides a large number of software blocks to perform most signal processing operations. The blocks are mostly written in C ++. It is possible to use these blocks directly from Python to simulate or create telecommunication systems.<br />
In addition, to make it easier to get started, GNU Radio also provides a utility called <syntaxhighlight lang="text" inline>gnuradio-companion</syntaxhighlight> to assemble blocks graphically and to generate the corresponding python script. This subject have been written for GNU Radio, but it can be equivalently realized using [https://www.gnu.org/software/octave/index Octave], or [http://itpp.sourceforge.net/4.3.1/ IT++] library.<br />
<br />
== Getting Started ==<br />
<br />
* Open a terminal<br />
<br />
* Create a working directory in which you will place your scripts.<br />
<br />
* Run <syntaxhighlight lang="text" inline>gnuradio-companion</syntaxhighlight>.<br />
<br />
This software allows you to use blocks (available in the right column) and to connect them to realize any complex signal processing operations. Resulting program is called a flowgraph in GNU Radio language.<br />
<br />
For any flowgraph, there is basically 3 types of blocks: sources (which produce samples and have at least 1 output), sinks (which consume samples and have at least 1 input) and processing block (which have at least 1 input and 1 output). Blocks are simply connected by creating a link in-between an output of a block and an input of another block.<br />
<br />
* Create the flowgraph presented in Fig. 1.<br />
<br />
[[File:Im1.png|frame|center|Fig. 1: Simple generation and data plotting]]<br />
<br />
The <syntaxhighlight lang="text" inline>Signal Source</syntaxhighlight> block generates an infinity of sinusoidal samples (or other) from the different parameters. These samples are displayed according to the time using the <syntaxhighlight lang="text" inline>Scope Sink</syntaxhighlight> block. <syntaxhighlight lang="text" inline>Throttle</syntaxhighlight> block does not modify the samples but allows to perform a flow control on all the data circulating between the source and the sink. Last, be careful to the color of the input and output of each block since they represent the type of data flowing on the link. The following table presents main data type and associated used by GNU Radio. Also, since Python is strongly typed, colors located at both ends of a wire have to be the same.<br />
<br />
{| class="wikitable" style="text-align: left;"<br />
|-<br />
!Color<br />
!Type<br />
!Size<br />
|-<br />
|Blue<br />
|Complex<br />
|2 x 64 bits<br />
|-<br />
|Orange<br />
|Float<br />
|64 bits<br />
|-<br />
|Green<br />
|Int<br />
|64/32 bits<br />
|-<br />
|Yellow<br />
|Short<br />
|16 bits<br />
|-<br />
|Purple<br />
|Char<br />
|8 bits<br />
|}<br />
<br />
* Save the flowgraph under your directory. This file is saved with a <syntaxhighlight lang="text" inline>.grc</syntaxhighlight> extension.<br />
<br />
* Generate the associated Python script associated to your flowgraph using the "blue to red" button. If errors are present, the script is not generated and full listing is present under the no entry sign. When successful, observe the python script named <syntaxhighlight lang="text" inline>top_block.py</syntaxhighlight> in your directory.<br />
<br />
* Execute the script by pressing the run button. Equivalently, you can also invoke <syntaxhighlight lang="text" inline>python top_block.py</syntaxhighlight>.<br />
<br />
The execution should display an oscilloscope-like widow with the corresponding signal (a cosine function). You can stop the execution by closing the window or by pressing the stop button.<br />
<br />
* Check the amplitude and the period of the generated signal.<br />
<br />
* Finally, add a <syntaxhighlight lang="text" inline>Slider</syntaxhighlight> block to modify the frequency of the signal in real time (without recompiling the flowgraph) and check the operation on the scope. Save the flowgraph.<br />
<br />
Note that the source simply generates samples which are plotted by the sink, however, this source and this sink can produce and consume as much data that your CPU can handle (data are just generated and plotted iteratively as fast as possible). To overcome this issue, the <syntaxhighlight lang="text" inline>Throttle</syntaxhighlight> block is used to process a given number of sample per second, thus lowering the CPU load to few percents. Most of the blocks in GNU Radio do not fixed the rate at which samples are processed: when sufficient number of samples are present at the input, the considered function is called and produces samples at the output which are then available for the other blocks. Usually, this rate is fixed when we work with real devices (for example an audio card can acquire samples at a given frequency e.g. 48 kHz) which fixed the rate for the whole flowgraph. In our example, we do not use any real device so the rate has to be fixed using the <syntaxhighlight lang="text" inline>Throttle</syntaxhighlight> block. Also, for each flowgraph, a single rate has to be used thus if we work with a real device, the <syntaxhighlight lang="text" inline>Throttle</syntaxhighlight> block is not needed anymore and has to be removed.<br />
<br />
<br />
* Create the flowgraph presented in Fig. 2.<br />
<br />
[[File:Im2.png|frame|center|Fig. 2: Simple operations on signals]]<br />
<br />
* Add a <syntaxhighlight lang="text" inline>FFT Sink</syntaxhighlight> to observe the signal spectrum. On the graph, the two peaks are very close and seem to be confused. Reduce the frequency sampling to increase the frequency resolution. Explain the phenomenum.<br />
<br />
* What is the minimum value of the sampling frequency? Observe the signal (in time and in frequency) for frequencies below this limit.<br />
<br />
* Replace the <syntaxhighlight lang="text" inline>Add</syntaxhighlight> block with a multiplier block <syntaxhighlight lang="text" inline>Mult</syntaxhighlight>. Predict the position of the peaks in the output signal. Check your results.<br />
<br />
* Add a filter (block <syntaxhighlight lang="text" inline>Low Pass Filter</syntaxhighlight>) to recover the low frequency part of the signal. Check your results in the time and frequency domain. Repeat the manipulation to keep the high frequency part.<br />
<br />
The <syntaxhighlight lang="text" inline>Low Pass Filter</syntaxhighlight> (and <syntaxhighlight lang="text" inline>High Pass Filter</syntaxhighlight>) blocks are high-level blocks which realize the design (i.e. determining the coefficients of the filter) as well as the filtering (i.e. the convolution). The filter design can also be done with <syntaxhighlight lang="text" inline>gr_filter_design</syntaxhighlight> to obtain the coefficients. These coefficients can then be used directly by the blocks <syntaxhighlight lang="text" inline>FIR Filter</syntaxhighlight> and <syntaxhighlight lang="text" inline>IIR Filter</syntaxhighlight>.<br />
<br />
== Amplitude Modulation ==<br />
<br />
=== Double side band without carrier ===<br />
<br />
* Realize the modulation of a signal <math>m(t)=\cos 2\pi f_m t</math> using a double side band without carrier. Note that transmitted signal can be expressed as<br />
<br />
<math><br />
x(t) = A m(t) \cos 2 \pi f_0 t<br />
</math><br />
<br />
* Observe the signal in both time and frequency domain.<br />
<br />
* Give the architecture of a coherent detector used to recover the message <math>m(t)</math> from <math>x(t)</math>.<br />
<br />
* Implement this detector to demodulate the signal and verify the good operation. You can use 2 different flowgraphs (1 for the transmission and 1 for the reception) using a <syntaxhighlight lang="text" inline>File Sink</syntaxhighlight> and <syntaxhighlight lang="text" inline>File Source</syntaxhighlight> respectively.<br />
<br />
=== Double side band without carrier ===<br />
<br />
* Realize the modulation of a signal <math>m(t)=\cos 2\pi f_m t</math> using a double side band with carrier. Note that transmitted signal can be expressed as<br />
<br />
[[File:Env.png|thumb|right|Fig. 3: Envelope detector used for AM signals.]]<br />
<br />
<math><br />
x(t) = A (1 + k_a m(t)) \cos 2 \pi f_0 t<br />
</math><br />
<br />
* Observe the signal in both time and frequency domain.<br />
<br />
* Modify the modulation index <math>k_a</math> using a slider and observe the modification of the signal.<br />
<br />
* AM signals are usually demodulted using a simple envelope detector. The architecture of this decoder is presented in Fig. 3.<br />
<br />
* Implement this detector to demodulate the signal and verify the good operation.<br />
<br />
* Check also if the AM signal can be decoded using the coherent detector.<br />
<br />
* Finally, download the file <syntaxhighlight lang="text" inline>am_usrp710.dat</syntaxhighlight>. This file contains the complex envelope (I and Q channels) received by a USRP around the frequency 710 kHz with a sampling frequency of 256 kHz. Visualize the data with a block <syntaxhighlight lang="text" inline>FFT Sink</syntaxhighlight> (insert a block <syntaxhighlight lang="text" inline>Throttle</syntaxhighlight> to avoid overloading the processor). On the graph, we can see two stations transmit at 710 kHz (center) and 790 kHz (to the right). Knowing that the bandwidth of an AM signal is 10 kHz, insert a low pass filter allowing to select the station located around 710 kHz. Check that the filter is working properly on the graph. Insert the envelope detector at the output of the filter and a block <syntaxhighlight lang="text" inline>Rational Resampler</syntaxhighlight> to adapt the bit rate to the sound card (48 kHz) using an <syntaxhighlight lang="text" inline>Audio Sink</syntaxhighlight>. Check the correct operation on the PC speakers (add if needed a <syntaxhighlight lang="text" inline>Multiply Const.</syntaxhighlight> block to set the volume of the station).<br />
<br />
== Frequency Modulation ==<br />
<br />
== Digital Communication ==</div>Nicohttps://nicolas-barbot.ovh/wiki/index.php?title=SC311_Wireless_Communications&diff=436SC311 Wireless Communications2021-08-20T16:41:11Z<p>Nico: </p>
<hr />
<div>The objective of this course is to understand how we can transmit a message in-between a transmitter and a receiver spatially separated. Especially, how we can use signal processing operations to adapt (i.e. modulate and demodulate) the message to realize the transmission over wired or wireless channels. This course describes the processes realized at a signal level and can be related to [[MA331 Information Theory and Channel Coding]] (which presents the general problem at a higher level).<br />
<br />
Slides of the course can be downloaded here. Exercises can be downloaded here. The following of this page corresponds to the labs.<br />
<br />
__TOC__<br />
<br />
In this labs, we will realize different modulations and demodulations used to transmit and receive analog and digital messages.<br />
Spectrum (or power spectral density) will also be determined.<br />
Finally, performance, in term of Sinal to Noise Ratio (SNR) or Bit Error Rate (BER) will be estimated in each case.<br />
<br />
These labs are based on [https://www.gnuradio.org/ GNU Radio] which is a free software that provides a large number of software blocks to perform most signal processing operations. The blocks are mostly written in C ++. It is possible to use these blocks directly from Python to simulate or create telecommunication systems.<br />
In addition, to make it easier to get started, GNU Radio also provides a utility called <syntaxhighlight lang="text" inline>gnuradio-companion</syntaxhighlight> to assemble blocks graphically and to generate the corresponding python script. This subject have been written for GNU Radio, but it can be equivalently realized using [https://www.gnu.org/software/octave/index Octave], or [http://itpp.sourceforge.net/4.3.1/ IT++] library.<br />
<br />
== Getting Started ==<br />
<br />
* Open a terminal<br />
<br />
* Create a working directory in which you will place your scripts.<br />
<br />
* Run <syntaxhighlight lang="text" inline>gnuradio-companion</syntaxhighlight>.<br />
<br />
This software allows you to use blocks (available in the right column) and to connect them to realize any complex signal processing operations. Resulting program is called a flowgraph in GNU Radio language.<br />
<br />
For any flowgraph, there is basically 3 types of blocks: sources (which produce samples and have at least 1 output), sinks (which consume samples and have at least 1 input) and processing block (which have at least 1 input and 1 output). Blocks are simply connected by creating a link in-between an output of a block and an input of another block.<br />
<br />
* Create the flowgraph presented in Fig. 1.<br />
<br />
[[File:Im1.png|frame|center|Fig. 1: Simple generation and data plotting]]<br />
<br />
The <syntaxhighlight lang="text" inline>Signal Source</syntaxhighlight> block generates an infinity of sinusoidal samples (or other) from the different parameters. These samples are displayed according to the time using the <syntaxhighlight lang="text" inline>Scope Sink</syntaxhighlight> block. <syntaxhighlight lang="text" inline>Throttle</syntaxhighlight> block does not modify the samples but allows to perform a flow control on all the data circulating between the source and the sink. Last, be careful to the color of the input and output of each block since they represent the type of data flowing on the link. The following table presents main data type and associated used by GNU Radio. Also, since Python is strongly typed, colors located at both ends of a wire have to be the same.<br />
<br />
{| class="wikitable" style="text-align: left;"<br />
|-<br />
!Color<br />
!Type<br />
!Size<br />
|-<br />
|Blue<br />
|Complex<br />
|2 x 64 bits<br />
|-<br />
|Orange<br />
|Float<br />
|64 bits<br />
|-<br />
|Green<br />
|Int<br />
|64/32 bits<br />
|-<br />
|Yellow<br />
|Short<br />
|16 bits<br />
|-<br />
|Purple<br />
|Char<br />
|8 bits<br />
|}<br />
<br />
* Save the flowgraph under your directory. This file is saved with a <syntaxhighlight lang="text" inline>.grc</syntaxhighlight> extension.<br />
<br />
* Generate the associated Python script associated to your flowgraph using the "blue to red" button. If errors are present, the script is not generated and full listing is present under the no entry sign. When successful, observe the python script named <syntaxhighlight lang="text" inline>top_block.py</syntaxhighlight> in your directory.<br />
<br />
* Execute the script by pressing the run button. Equivalently, you can also invoke <syntaxhighlight lang="text" inline>python top_block.py</syntaxhighlight>.<br />
<br />
The execution should display an oscilloscope-like widow with the corresponding signal (a cosine function). You can stop the execution by closing the window or by pressing the stop button.<br />
<br />
* Check the amplitude and the period of the generated signal.<br />
<br />
* Finally, add a <syntaxhighlight lang="text" inline>Slider</syntaxhighlight> block to modify the frequency of the signal in real time (without recompiling the flowgraph) and check the operation on the scope. Save the flowgraph.<br />
<br />
Note that the source simply generates samples which are plotted by the sink, however, this source and this sink can produce and consume as much data that your CPU can handle (data are just generated and plotted iteratively as fast as possible). To overcome this issue, the <syntaxhighlight lang="text" inline>Throttle</syntaxhighlight> block is used to process a given number of sample per second, thus lowering the CPU load to few percents. Most of the blocks in GNU Radio do not fixed the rate at which samples are processed: when sufficient number of samples are present at the input, the considered function is called and produces samples at the output which are then available for the other blocks. Usually, this rate is fixed when we work with real devices (for example an audio card can acquire samples at a given frequency e.g. 48 kHz) which fixed the rate for the whole flowgraph. In our example, we do not use any real device so the rate has to be fixed using the <syntaxhighlight lang="text" inline>Throttle</syntaxhighlight> block. Also, for each flowgraph, a single rate has to be used thus if we work with a real device, the <syntaxhighlight lang="text" inline>Throttle</syntaxhighlight> block is not needed anymore and has to be removed.<br />
<br />
<br />
* Create the flowgraph presented in Fig. 2.<br />
<br />
[[File:Im2.png|frame|center|Fig. 2: Simple operations on signals]]<br />
<br />
* Add a <syntaxhighlight lang="text" inline>FFT Sink</syntaxhighlight> to observe the signal spectrum. On the graph, the two peaks are very close and seem to be confused. Reduce the frequency sampling to increase the frequency resolution. Explain the phenomenum.<br />
<br />
* What is the minimum value of the sampling frequency? Observe the signal (in time and in frequency) for frequencies below this limit.<br />
<br />
* Replace the <syntaxhighlight lang="text" inline>Add</syntaxhighlight> block with a multiplier block <syntaxhighlight lang="text" inline>Mult</syntaxhighlight>. Predict the position of the peaks in the output signal. Check your results.<br />
<br />
* Add a filter (block <syntaxhighlight lang="text" inline>Low Pass Filter</syntaxhighlight>) to recover the low frequency part of the signal. Check your results in the time and frequency domain. Repeat the manipulation to keep the high frequency part.<br />
<br />
The <syntaxhighlight lang="text" inline>Low Pass Filter</syntaxhighlight> (and <syntaxhighlight lang="text" inline>High Pass Filter</syntaxhighlight>) blocks are high-level blocks which realize the design (i.e. determining the coefficients of the filter) as well as the filtering (i.e. the convolution). The filter design can also be done with <syntaxhighlight lang="text" inline>gr_filter_design</syntaxhighlight> to obtain the coefficients. These coefficients can then be used directly by the blocks <syntaxhighlight lang="text" inline>FIR Filter</syntaxhighlight> and <syntaxhighlight lang="text" inline>IIR Filter</syntaxhighlight>.<br />
<br />
== Amplitude Modulation ==<br />
<br />
=== Double side band without carrier ===<br />
<br />
* Realize the modulation of a signal <math>m(t)=\cos 2\pi f_m t</math> using a double side band without carrier. Note that transmitted signal can be expressed as<br />
<br />
<math><br />
x(t) = A m(t) \cos 2 \pi f_0 t<br />
</math><br />
<br />
* Observe the signal in both time and frequency domain.<br />
<br />
* Give the architecture of a coherent detector used to recover the message <math>m(t)</math> from <math>x(t)</math>.<br />
<br />
* Implement this detector to demodulate the signal and verify the good operation. You can use 2 different flowgraphs (1 for the transmission and 1 for the reception) using a <syntaxhighlight lang="text" inline>File Sink</syntaxhighlight> and <syntaxhighlight lang="text" inline>File Source</syntaxhighlight> respectively.<br />
<br />
=== Double side band without carrier ===<br />
<br />
* Realize the modulation of a signal <math>m(t)=\cos 2\pi f_m t</math> using a double side band with carrier. Note that transmitted signal can be expressed as<br />
<br />
<math><br />
x(t) = A (1 + k_a m(t)) \cos 2 \pi f_0 t<br />
</math><br />
<br />
* Observe the signal in both time and frequency domain.<br />
<br />
* Modify the modulation index <math>k_a</math> using a slider and observe the modification of the signal.<br />
<br />
* AM signals are usually demodulted using a simple envelope detector. The architecture of this decoder is presented in Fig. 3.<br />
<br />
[[File:Env.png|thumb|right|Fig. 3: Envelope detector used for AM signals.]]<br />
<br />
* Implement this detector to demodulate the signal and verify the good operation.<br />
<br />
* Check also if the AM signal can be decoded using the coherent detector.<br />
<br />
* Finally, download the file <syntaxhighlight lang="text" inline>am_usrp710.dat</syntaxhighlight>. This file contains the complex envelope (I and Q channels) received by a USRP around the frequency 710 kHz with a sampling frequency of 256 kHz. Visualize the data with a block <syntaxhighlight lang="text" inline>FFT Sink</syntaxhighlight> (insert a block <syntaxhighlight lang="text" inline>Throttle</syntaxhighlight> to avoid overloading the processor). On the graph, we can see two stations transmit at 710 kHz (center) and 790 kHz (to the right). Knowing that the bandwidth of an AM signal is 10 kHz, insert a low pass filter allowing to select the station located around 710 kHz. Check that the filter is working properly on the graph. Insert the envelope detector at the output of the filter and a block <syntaxhighlight lang="text" inline>Rational Resampler</syntaxhighlight> to adapt the bit rate to the sound card (48 kHz) using an <syntaxhighlight lang="text" inline>Audio Sink</syntaxhighlight>. Check the correct operation on the PC speakers (add if needed a <syntaxhighlight lang="text" inline>Multiply Const.</syntaxhighlight> block to set the volume of the station).<br />
<br />
== Frequency Modulation ==<br />
<br />
== Digital Communication ==</div>Nicohttps://nicolas-barbot.ovh/wiki/index.php?title=File:Env.png&diff=435File:Env.png2021-08-20T16:24:45Z<p>Nico: </p>
<hr />
<div></div>Nicohttps://nicolas-barbot.ovh/wiki/index.php?title=SC311_Wireless_Communications&diff=434SC311 Wireless Communications2021-08-20T16:23:48Z<p>Nico: </p>
<hr />
<div>The objective of this course is to understand how we can transmit a message in-between a transmitter and a receiver spatially separated. Especially, how we can use signal processing operations to adapt (i.e. modulate and demodulate) the message to realize the transmission over wired or wireless channels. This course describes the processes realized at a signal level and can be related to [[MA331 Information Theory and Channel Coding]] (which presents the general problem at a higher level).<br />
<br />
Slides of the course can be downloaded here. Exercises can be downloaded here. The following of this page corresponds to the labs.<br />
<br />
__TOC__<br />
<br />
In this labs, we will realize different modulations and demodulations used to transmit and receive analog and digital messages.<br />
Spectrum (or power spectral density) will also be determined.<br />
Finally, performance, in term of Sinal to Noise Ratio (SNR) or Bit Error Rate (BER) will be estimated in each case.<br />
<br />
These labs are based on [https://www.gnuradio.org/ GNU Radio] which is a free software that provides a large number of software blocks to perform most signal processing operations. The blocks are mostly written in C ++. It is possible to use these blocks directly from Python to simulate or create telecommunication systems.<br />
In addition, to make it easier to get started, GNU Radio also provides a utility called <syntaxhighlight lang="text" inline>gnuradio-companion</syntaxhighlight> to assemble blocks graphically and to generate the corresponding python script. This subject have been written for GNU Radio, but it can be equivalently realized using [https://www.gnu.org/software/octave/index Octave], or [http://itpp.sourceforge.net/4.3.1/ IT++] library.<br />
<br />
== Getting Started ==<br />
<br />
* Open a terminal<br />
<br />
* Create a working directory in which you will place your scripts.<br />
<br />
* Run <syntaxhighlight lang="text" inline>gnuradio-companion</syntaxhighlight>.<br />
<br />
This software allows you to use blocks (available in the right column) and to connect them to realize any complex signal processing operations. Resulting program is called a flowgraph in GNU Radio language.<br />
<br />
For any flowgraph, there is basically 3 types of blocks: sources (which produce samples and have at least 1 output), sinks (which consume samples and have at least 1 input) and processing block (which have at least 1 input and 1 output). Blocks are simply connected by creating a link in-between an output of a block and an input of another block.<br />
<br />
* Create the flowgraph presented in Fig. 1.<br />
<br />
[[File:Im1.png|frame|center|Fig. 1: Simple generation and data plotting]]<br />
<br />
The <syntaxhighlight lang="text" inline>Signal Source</syntaxhighlight> block generates an infinity of sinusoidal samples (or other) from the different parameters. These samples are displayed according to the time using the <syntaxhighlight lang="text" inline>Scope Sink</syntaxhighlight> block. <syntaxhighlight lang="text" inline>Throttle</syntaxhighlight> block does not modify the samples but allows to perform a flow control on all the data circulating between the source and the sink. Last, be careful to the color of the input and output of each block since they represent the type of data flowing on the link. The following table presents main data type and associated used by GNU Radio. Also, since Python is strongly typed, colors located at both ends of a wire have to be the same.<br />
<br />
{| class="wikitable" style="text-align: left;"<br />
|-<br />
!Color<br />
!Type<br />
!Size<br />
|-<br />
|Blue<br />
|Complex<br />
|2 x 64 bits<br />
|-<br />
|Orange<br />
|Float<br />
|64 bits<br />
|-<br />
|Green<br />
|Int<br />
|64/32 bits<br />
|-<br />
|Yellow<br />
|Short<br />
|16 bits<br />
|-<br />
|Purple<br />
|Char<br />
|8 bits<br />
|}<br />
<br />
* Save the flowgraph under your directory. This file is saved with a <syntaxhighlight lang="text" inline>.grc</syntaxhighlight> extension.<br />
<br />
* Generate the associated Python script associated to your flowgraph using the "blue to red" button. If errors are present, the script is not generated and full listing is present under the no entry sign. When successful, observe the python script named <syntaxhighlight lang="text" inline>top_block.py</syntaxhighlight> in your directory.<br />
<br />
* Execute the script by pressing the run button. Equivalently, you can also invoke <syntaxhighlight lang="text" inline>python top_block.py</syntaxhighlight>.<br />
<br />
The execution should display an oscilloscope-like widow with the corresponding signal (a cosine function). You can stop the execution by closing the window or by pressing the stop button.<br />
<br />
* Check the amplitude and the period of the generated signal.<br />
<br />
* Finally, add a <syntaxhighlight lang="text" inline>Slider</syntaxhighlight> block to modify the frequency of the signal in real time (without recompiling the flowgraph) and check the operation on the scope. Save the flowgraph.<br />
<br />
Note that the source simply generates samples which are plotted by the sink, however, this source and this sink can produce and consume as much data that your CPU can handle (data are just generated and plotted iteratively as fast as possible). To overcome this issue, the <syntaxhighlight lang="text" inline>Throttle</syntaxhighlight> block is used to process a given number of sample per second, thus lowering the CPU load to few percents. Most of the blocks in GNU Radio do not fixed the rate at which samples are processed: when sufficient number of samples are present at the input, the considered function is called and produces samples at the output which are then available for the other blocks. Usually, this rate is fixed when we work with real devices (for example an audio card can acquire samples at a given frequency e.g. 48 kHz) which fixed the rate for the whole flowgraph. In our example, we do not use any real device so the rate has to be fixed using the <syntaxhighlight lang="text" inline>Throttle</syntaxhighlight> block. Also, for each flowgraph, a single rate has to be used thus if we work with a real device, the <syntaxhighlight lang="text" inline>Throttle</syntaxhighlight> block is not needed anymore and has to be removed.<br />
<br />
<br />
* Create the flowgraph presented in Fig. 2.<br />
<br />
[[File:Im2.png|frame|center|Fig. 2: Simple operations on signals]]<br />
<br />
* Add a <syntaxhighlight lang="text" inline>FFT Sink</syntaxhighlight> to observe the signal spectrum. On the graph, the two peaks are very close and seem to be confused. Reduce the frequency sampling to increase the frequency resolution. Explain the phenomenum.<br />
<br />
* What is the minimum value of the sampling frequency? Observe the signal (in time and in frequency) for frequencies below this limit.<br />
<br />
* Replace the <syntaxhighlight lang="text" inline>Add</syntaxhighlight> block with a multiplier block <syntaxhighlight lang="text" inline>Mult</syntaxhighlight>. Predict the position of the peaks in the output signal. Check your results.<br />
<br />
* Add a filter (block <syntaxhighlight lang="text" inline>Low Pass Filter</syntaxhighlight>) to recover the low frequency part of the signal. Check your results in the time and frequency domain. Repeat the manipulation to keep the high frequency part.<br />
<br />
The <syntaxhighlight lang="text" inline>Low Pass Filter</syntaxhighlight> (and <syntaxhighlight lang="text" inline>High Pass Filter</syntaxhighlight>) blocks are high-level blocks which realize the design (i.e. determining the coefficients of the filter) as well as the filtering (i.e. the convolution). The filter design can also be done with <syntaxhighlight lang="text" inline>gr_filter_design</syntaxhighlight> to obtain the coefficients. These coefficients can then be used directly by the blocks <syntaxhighlight lang="text" inline>FIR Filter</syntaxhighlight> and <syntaxhighlight lang="text" inline>IIR Filter</syntaxhighlight>.<br />
<br />
== Amplitude Modulation ==<br />
<br />
=== Double side band without carrier ===<br />
<br />
* Realize the modulation of a signal <math>m(t)=\cos 2\pi f_m t</math> using a double side band without carrier. Note that transmitted signal can be expressed as<br />
<br />
<math><br />
x(t) = A m(t) \cos 2 \pi f_0 t<br />
</math><br />
<br />
* Observe the signal in both time and frequency domain.<br />
<br />
* Give the architecture of a coherent detector used to recover the message <math>m(t)</math> from <math>x(t)</math>.<br />
<br />
* Implement this detector to demodulate the signal and verify the good operation. You can use 2 different flowgraphs (1 for the transmission and 1 for the reception) using a <syntaxhighlight lang="text" inline>File Sink</syntaxhighlight> and <syntaxhighlight lang="text" inline>File Source</syntaxhighlight> respectively.<br />
<br />
=== Double side band without carrier ===<br />
<br />
* Realize the modulation of a signal <math>m(t)=\cos 2\pi f_m t</math> using a double side band with carrier. Note that transmitted signal can be expressed as<br />
<br />
<math><br />
x(t) = A (1 + k_a m(t)) \cos 2 \pi f_0 t<br />
</math><br />
<br />
* Observe the signal in both time and frequency domain.<br />
<br />
* Modify the modulation index <math>k_a</math> using a slider and observe the modification of the signal.<br />
<br />
* AM signals are usually demodulted using a simple envelope detector. The architecture of this decoder is presented in Fig. 3.<br />
<br />
[[File:Env.png|thumb|right|Fig. 3: Envelope detector used for AM signals.]]<br />
<br />
* Implement this detector to demodulate the signal and verify the good operation.<br />
<br />
* Check also if the AM signal can be decoded using the coherent detector.<br />
<br />
== Frequency Modulation ==<br />
<br />
== Digital Communication ==</div>Nico