From 586591f8deebe33eb69101af8458010737ccde11 Mon Sep 17 00:00:00 2001 From: Jonas Schievink Date: Mon, 13 Jul 2020 17:06:35 +0200 Subject: [PATCH 1/4] Fix grammar "pins have been configured" --- embedded-workshop-book/src/using-hal.md | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/embedded-workshop-book/src/using-hal.md b/embedded-workshop-book/src/using-hal.md index a2b4118..13c10a5 100644 --- a/embedded-workshop-book/src/using-hal.md +++ b/embedded-workshop-book/src/using-hal.md @@ -19,8 +19,8 @@ Check the API docs of the `Led` abstraction then run the `led` program. Two of t Now, uncomment the `log::set_max_level` line. This will make the logs more verbose; they will now include logs from the board initialization function (`dk::init`) and from the `Led` API. -Among the logs you'll find the line "I/O pins have been configured for digital output". At this point the electrical pins of the nRF52840 microcontroller has been configured to drive the 4 LEDs on the board. +Among the logs you'll find the line "I/O pins have been configured for digital output". At this point the electrical pins of the nRF52840 microcontroller have been configured to drive the 4 LEDs on the board. After the `dk::init` logs you'll find logs about the `Led` API. As the logs indicate an LED becomes active when the output of the pin is a *logical zero*, which is also referred as the "low" state. This "active low" configuration does not apply to all boards: it depends on how the pins have been wired to the LEDs. You should refer to the [board documentation] to find out which pins are connected to LEDs and whether "active low" or "active high" applies to it. -[board documentation]: https://infocenter.nordicsemi.com/index.jsp?topic=%2Fug_nrf52840_dk%2FUG%2Fnrf52840_DK%2Fintro.html \ No newline at end of file +[board documentation]: https://infocenter.nordicsemi.com/index.jsp?topic=%2Fug_nrf52840_dk%2FUG%2Fnrf52840_DK%2Fintro.html From ac3a6644a9a05476abfb18e21a58eef07ec52373 Mon Sep 17 00:00:00 2001 From: Jonas Schievink Date: Mon, 13 Jul 2020 17:07:24 +0200 Subject: [PATCH 2/4] Fix loopback program output --- embedded-workshop-book/src/dongle.md | 2 +- embedded-workshop-book/src/radio-out.md | 2 +- 2 files changed, 2 insertions(+), 2 deletions(-) diff --git a/embedded-workshop-book/src/dongle.md b/embedded-workshop-book/src/dongle.md index 70c1b6a..fbef5df 100644 --- a/embedded-workshop-book/src/dongle.md +++ b/embedded-workshop-book/src/dongle.md @@ -56,7 +56,7 @@ If you run the `serial-term` application you should see the following output: ``` console $ serial-term -deviceid=588c06af0877c8f2 channel=20 TxPower=+8dBm +deviceid=588c06af0877c8f2 channel=20 TxPower=+8dBm app=loopback.hex (..) ``` diff --git a/embedded-workshop-book/src/radio-out.md b/embedded-workshop-book/src/radio-out.md index f850198..7f85b28 100644 --- a/embedded-workshop-book/src/radio-out.md +++ b/embedded-workshop-book/src/radio-out.md @@ -8,7 +8,7 @@ First run the program as it is. You should new output in the output of the `seri ``` console $ serial-term -deviceid=588c06af0877c8f2 channel=20 TxPower=+8dBm +deviceid=588c06af0877c8f2 channel=20 TxPower=+8dBm app=loopback.hex received 5 bytes (LQI=49) ``` From 259e688293f21b0afe2afaece67caf3b359556d0 Mon Sep 17 00:00:00 2001 From: Jonas Schievink Date: Mon, 13 Jul 2020 17:16:44 +0200 Subject: [PATCH 3/4] Add a comma --- embedded-workshop-book/src/radio-out.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/embedded-workshop-book/src/radio-out.md b/embedded-workshop-book/src/radio-out.md index 7f85b28..1951a3c 100644 --- a/embedded-workshop-book/src/radio-out.md +++ b/embedded-workshop-book/src/radio-out.md @@ -111,6 +111,6 @@ Take note of how LQI changes with these changes. Do packet loss occur in any of ## 802.15.4 compatibility -The radio API we are using follows the PHY layer of the IEEE 802.15.4 specification but it's missing MAC level features like addressing (each device gets its own address), opt-in acknowledgment (a transmitted packet must be acknowledged with a response acknowledgment packet; the packet is re-transmitted if the packet is not acknowledged in time). These MAC level features are not implemented *in hardware* (in the nRF52840 Radio peripheral) so they would need to be implemented in software to be fully IEEE 802.15.4 compliant. +The radio API we are using follows the PHY layer of the IEEE 802.15.4 specification, but it's missing MAC level features like addressing (each device gets its own address), opt-in acknowledgment (a transmitted packet must be acknowledged with a response acknowledgment packet; the packet is re-transmitted if the packet is not acknowledged in time). These MAC level features are not implemented *in hardware* (in the nRF52840 Radio peripheral) so they would need to be implemented in software to be fully IEEE 802.15.4 compliant. This is not an issue for the workshop exercises but it's something to consider if you would like to continue from here and build a 802.15.4 compliant network API. From e011e08566983f03b7f145db7e02ecc9b3deb29e Mon Sep 17 00:00:00 2001 From: Jonas Schievink Date: Mon, 13 Jul 2020 17:18:59 +0200 Subject: [PATCH 4/4] "Do packet loss" => "Does packet loss" --- embedded-workshop-book/src/radio-out.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/embedded-workshop-book/src/radio-out.md b/embedded-workshop-book/src/radio-out.md index 1951a3c..3c424a0 100644 --- a/embedded-workshop-book/src/radio-out.md +++ b/embedded-workshop-book/src/radio-out.md @@ -103,7 +103,7 @@ Now run the `radio-send` program several times with different variations: - change the length of the packet - different combinations of all of the above -Take note of how LQI changes with these changes. Do packet loss occur in any of these configurations? +Take note of how LQI changes with these changes. Does packet loss occur in any of these configurations? > NOTE if you decide to send many packets in a single program then you should use the `Timer` API to insert a delay of at least five milliseconds between the transmissions. This is required because the Dongle will use the radio medium right after it receives a packet. Not including the delay will result in the Dongle missing packets