diff --git a/doc/lab03-silly_led/main.typ b/doc/lab03-silly_led/main.typ
index 259d36a..f9c0864 100644
--- a/doc/lab03-silly_led/main.typ
+++ b/doc/lab03-silly_led/main.typ
@@ -2,47 +2,40 @@
 
 = Linux System Programming
 
-== File system
-This laboratory is focused on the user space. We make an application to change the blinking frequency of a led with button.
-
-=== Buttons
-
-// TODO
-
-It has some difficulties to locate the button on the GPIOs. Because this is not
-the same as we have done in the module in the precedent laboratory.
--> explain
-
-Discover the epoll to trigg on file modification
-
-discover the timer_fd
-
-all is file
-
-all can be in the epoll to manage all event from files
+This laboratory implements a user-space application for the NanoPi NEO Plus2 that controls the blinking frequency of the status LED using three push buttons. The main goal was to replace a CPU-intensive busy loop with an event-driven design.
 
 
-=== timer
-- epoll
-- thread
-- 1 consumer, 1 provider, no need mutex
+== Design
+The application is based on multithreading: one thread handles the LED timing, while another handles button events. GPIOs are accessed through sysfs, which allows the LED and buttons to be managed as file descriptors. A key design choice was to centralize all events with a single epoll instance, so both timer events and button events can be processed efficiently. 
 
-- create timer empty
-- set timer with `timerfd_set_time`
-- definition of the initial time and not the repetition time, to use only one timer
-- link to epoll
+All logs are done using the syslog at info level:
+```c
+syslog(LOG_INFO, "Start logging silly led-controller"); // INFO level
+```
 
+== Difficulties
+The most difficult part was understanding the GPIO mapping between the physical pins and the sysfs GPIO numbers. All can be found in the #link("https://linux-sunxi.org/GPIO", [*sunxi driver*]) which is the driver for GPIO.
 
-=== syslog
-- one opening
-```c openlog("CSEL Logs", LOG_PID, LOG_USER);```
-LOG_PID is used to keep the PID of the process in the log, and LOG_USER is used to specify the facility of the log (what type of programme).
+== Results
+We can demonstracte that the application works in an efficient than the silly led controller given:
 
-```c syslog(LOG_INFO, "Start logging silly led-controller"); // INFO level```
+#table(
+    columns: (1fr, 1fr),
+    align: center + horizon,
+    stroke: none,
+    [
+        #figure(
+            image("test-silly.png"),
+            caption:[Run silly led controller on nanopi]
+        )<fig-silly>
+        
+    ],[
+        #figure(
+            image("test-epoll.png"),
+            caption:[Run epoll led controller on nanopi]
+        )<fig-epoll>
+    ]
+)
 
+We can see the difference between @fig-silly and @fig-epoll. One is using a core at 100% and the other one not.
 
-=== Multithreading
-- one thread for the button, one for the led
-- button write time
-- led read time and sleep for this time
-- no mutex because we have only one provider
\ No newline at end of file
diff --git a/doc/lab03-silly_led/test-epoll.png b/doc/lab03-silly_led/test-epoll.png
new file mode 100644
index 0000000..a023ca3
Binary files /dev/null and b/doc/lab03-silly_led/test-epoll.png differ
diff --git a/doc/lab03-silly_led/test-silly.png b/doc/lab03-silly_led/test-silly.png
new file mode 100644
index 0000000..47df01d
Binary files /dev/null and b/doc/lab03-silly_led/test-silly.png differ