You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Copy file name to clipboardExpand all lines: content/learn/02.microcontrollers/04.debugging/debugging.md
+6-9Lines changed: 6 additions & 9 deletions
Original file line number
Diff line number
Diff line change
@@ -212,17 +212,13 @@ void myFunction() {
212
212
213
213
Now let us talk about **wireless communications**. Wireless communications are a key feature in developing new Internet of Things (IoT) devices with different requirements or specifications and for different purposes. Wireless communication is present on many embedded systems, and Arduino® hardware is no exception for this feature. The question now is: how do we debug wireless communications between devices?
214
214
215
-
A simple technique used to debug wireless communications between devices consists of using **acknowledge flags**. Acknowledge flags are used to verify successful communication between devices; this process is found on physical communication layers, such as I2C or SPI, providing the present status between these devices. This is a technique that is common for debugging external devices in bridge and aids to get a clear understanding of the device's behaviour when establishing physical layer of communication. Hardware tools mentioned earlier, which are multimeter, oscilloscope, and a logic analyzer, provides more in-depth details and adds more value to this debugging style. Hence, it grants much more refined device software overall.
215
+
A simple and common technique used to debug wireless communications between two or more devices consists of using **acknowledge flags**. Using acknowledge flags aids in understanding the device's behavior when communication is established between them by providing their current status. This process is also found on physical communication protocols, such as I2C or SPI. Because of the different protocol types in wireless communications, using acknowledge flags as a debugging method can be applied but differ in their own rules. The easiest way to confirm that the data exchange was successful is to check the data log on each end device. Hardware tools mentioned earlier (DMMs, oscilloscopes, and logic analyzers) can be used to provide more in-depth details and add more value to this type of debugging technique.
216
216
217
-
However, not everything is connected on a physical layer, but on an **abstract layer**. The abstract layer can be seen as an example of frequency spectrum playground. The layer where the device establishes communication via air, or in a wireless architecture. Regularly it would not require to somehow debug the data found in the air nor verify on top of the already certified wireless devices, due to complexity involved in this types devices. Because of different protocol types in wireless communication, acknowledge methods can be applied but may differ in its own rules; the easiest way to confirm the data exchange was successful is to check the log on each end device.
217
+
However, not everything is connected on a physical layer, but on an **abstract layer**. This abstract layer in wireless communications is where electromagnetic waves propagate through space. Why would we need to debug electromagnetic waves propagating through space? Sometimes, we need to verify that the wireless transceiver configuration of a particular embedded system is correct, for example, its **transmission power**. SDRs can be helpful in this situation: SDRs can be used as cheap **spectrum analyzers**. A spectrum analyzer is a hardware tool that measures the magnitude of a signal versus the frequency; this tool is mainly used to measure a signal's power spectrum. Using SDRs as spectrum analyzers is usually an optional debugging method in the development process, ensuring a more robust system design.
218
218
219
-
So why would we need to debug on a radio frequency spectrum that is working correctly? It is to verify that the transceiver configuration is correct, mainly its transmission power. Also depending on the preciseness and absolute zero fault requirement in the system with wireless capability, needs a tool that is able to provide this insight. This is where an advanced debugging method comes in by presenting Software Defined Radios.
219
+
***Several programs can be used with SDRs; [GQRX](https://gqrx.dk/)is one of the most popular software; GQRX is open-source and with cross-platform support (Linux and macOS). [AirSpy](https://airspy.com/) and [CubicSDR](https://cubicsdr.com/) are other popular software used with SDRs and cross-platform support (Windows, Linux, and macOS).***
220
220
221
-
It is an optional debugging method on a development process usually, but it ensures much more robust system design. There are several software to assist this process and one of them is GQRX supported on OSX and Linux. For the Windows operating system, AirSpy could be software of choice to assist for this type of task. The SDR via USB stick can be used as a low cost spectrum analyzer, using the user's computer as a hot for radio station. The devices to be debugged are powered on while SDR takes care of catching any present transmission on the air and display it on the screen.
222
-
223
-
Shown visual representation of the signal via SDR software can now be used to verify the transmission power outputted by the device and the amount of data that flew on the air. This will help to visualize the properties of the device's wireless communication configuration. It will be possible to verify the transmission and reception power, the amount of bytes transmitted, and the frequency on which it is supposed to be transmitting. A very handy tool to debug wireless communication states of the devices.
224
-
225
-
All these properties can be debugged through the radio frequency spectrum and refined to provide edge wireless communication performance on embedded systems.
221
+
Shown visual representation of the signal via SDR software can now be used to verify the transmission power outputted by the device and the amount of data transmitted. This will help visualize the device's wireless communication configuration properties. It will be possible to verify the transmission and reception power, the number of bytes transmitted, and the frequency it is supposed to transmit. These properties can be debugged through the frequency spectrum and refined to provide edge wireless communication performance on embedded systems.
226
222
227
223
## Debugging Techniques Example
228
224
@@ -232,7 +228,8 @@ A simple example will be used to demonstrate implementation of different debuggi
232
228
/*
233
229
LSM9DS1 accelerometer, gyroscope, and magnetometer tasks operation with debugging.
234
230
235
-
This example combines data from the LSM9DS1 accelerometer, gyroscope, and magnetometer into a single code. On top of it,
231
+
Description:
232
+
- This example combines data from the LSM9DS1 accelerometer, gyroscope, and magnetometer into a single code. On top of it,
236
233
it helps to understand different methods and techniques of debugging when the code structure combines multiple tasks.
0 commit comments