Week 11 — Networking and communications¶
Global Class¶
This week focused on how devices communicate across different scales, from chip-level connections to distributed network systems.
The concept of a “society of things” was introduced, where devices interact within layered infrastructures:
- chip-to-chip communication
- device-to-device communication
- large-scale networked systems
The session emphasized the shift from isolated electronic components to interconnected and modular systems.
Eric Pan — Architectures of Digital Dialogue¶
Eric Pan presented a structured overview of communication systems, framing networking as a layered and scalable architecture.
1. The OSI Model¶
Communication is organized into layers, from physical signals to application-level protocols.
- Physical → electrical signals (voltage, frequency)
- Data Link → local communication rules (MAC)
- Network → addressing and routing (IP)
- Transport → reliability and delivery (TCP vs UDP)
- Application → protocols such as HTTP and MQTT
Key idea:
- each layer operates independently
- systems can evolve without affecting the entire stack
2. Wired Communication — Core Protocols¶
UART (Asynchronous)¶
- TX / RX communication
- no clock signal
- requires predefined baud rate
- used for debugging and simple point-to-point links
I2C (Bus Communication)¶
- 2 wires: SDA (data), SCL (clock)
- multiple devices on the same bus
- devices identified by address
- requires pull-up resistors
SPI (High-Speed Communication)¶
- multiple lines (clock, data in/out, chip select)
- high-speed communication
- point-to-point architecture
- used for memory, displays, and fast peripherals
Key insight:
- protocol selection depends on speed, topology, and number of devices
3. Wireless Communication¶
Wireless communication involves balancing key parameters:
- range
- power consumption
- data rate
- signal robustness
Key principle:
- longer range → lower data rate
- higher speed → shorter range
Examples:
- Bluetooth (BLE) → short range, low power
- Wi-Fi → high throughput, higher power consumption
- LoRa → long range, low power, low data rate
4. Network Architecture — System Design¶
Communication systems can be structured as:
- centralized systems (cloud-based)
- decentralized systems (edge computing)
Devices must:
- agree on communication protocols
- synchronize timing
- define roles (client/server or peer-to-peer)
5. Designing a Network¶
Effective communication design requires:
- selecting the appropriate abstraction layer
- choosing suitable protocols
- managing timing and synchronization
- ensuring reliable data exchange
Local Class¶
The local session focused on practical implementation of communication between microcontrollers.
The objective was to understand how two devices can exchange data using serial communication, and how this interaction can be tested both in simulation and with real hardware.
Reference System — Smart Citizen Platform¶
As reference system, the Smart Citizen device from IaaC was again presented showing a real-life implementation of a networked devices.
The system integrates:
- multiple sensors
- communication modules
- data aggregation and transmission
Concept — Network Representation¶
A visual representation of distributed nodes was introduced to explain how multiple devices interact within a network.
Each node represents a device capable of sending and receiving data, illustrating:
- distributed communication
- modular system design
- scalability of connected devices
Simulation — Wokwi Environment¶
A first test was performed using Wokwi to simulate communication between two devices.
The simulation included:
- two microcontroller instances
- UART communication (TX/RX) between devices
- monitoring of transmitted values using a logic analyzer
This allowed quick validation of:
- signal flow
- data transmission behavior
- debugging without hardware constraints
Hardware Implementation — Device-to-Device Communication¶
The simulation was then translated into a physical setup using two development boards.
Setup:
- two microcontroller boards connected via UART
- TX of one board connected to RX of the other
- common GND shared between both devices
- USB used for power and programming
This configuration enabled:
- real-time data exchange
- verification of communication reliability
- comparison with simulated behavior
Weekly Assignment¶
Dishwasher Reverse Engineering — System Breakdown¶
This teardown started from a practical situation: my dishwasher stopped working properly and began throwing multiple error codes.
The machine is a Bosch SM58M78EU (~2010), so already around 15 years old.
Reported errors¶
-
E09 → heating failure
Likely caused by a burnt or open-circuit heater inside the heat pump.
Standard fix: replace full heat pump assembly (not designed to be repaired) -
E15 → leak detected
Water in the base tray triggered the safety system
Likely due to internal leakage -
E23 → drain pump fault
Possible blockage or failing drain pump
Decision¶
At this stage, the situation was that the machine technically repairable, but multiple components failing and replacement parts required -heat pump, possibly pump, seals- which didn’t justify the cost for a 15-year-old machine
What started as a failed repair turned into a reverse engineering exercise, inspired by the global class link on hacking machines:
The goal was to understand how a real-world, mass produced system is engineered and built:
- opening a complete product
- identifying subsystems
- tracing connections
- understanding how everything communicates
Full Teardown¶
The teardown process was quite improvised — removing panels, disconnecting wiring, and progressively exposing internal systems.
Main observations:
- everything is tightly packed and optimized for space
- systems are highly integrated
- components are distributed physically but centrally controlled
The key aspect of this exercise is that I didn’t have to rebuild or fix the machine, so I could keep tearing it apart to its last component.
Main Control Board¶
This is the core of the system.
Observations:
- dense PCB with mixed components
- connectors linking to all subsystems
- clear separation between power electronics and logic
Key elements identified:
- microcontroller (central control)
- relays / switching components
- power regulation
This is a centralized architecture where one board controls everything and there are no independent nodes.
Wiring Harness (System Backbone)¶
The wiring connects all subsystems.
Observations:
- color-coded cables
- multiple connectors
- point-to-point connections
- physical communication layer
Water Level Sensor¶
Located in a side chamber connected to water flow to detect water level via pressure or float mechanism
Observations:
- small sensing component inside plastic housing
- connected via simple wiring
- analog signal to main board
User Interface / Panel Board¶
This is the interface between user and machine.
Observations:
- multiple buttons
- compact PCB
- separated from main board
- receives user input
- provides feedback (LEDs, indicators)
Pump + Motor System¶
Main mechanical actuator of the system.
Observations:
- strong copper windings
- integrated pump and motor
- circulates water through the system
- contains heating element also
- controlled via power switching
Propeller / Internal Pump Components¶
Internal parts connected to fluid movement.
Observations:
- compact assembly
- integrated with motor system
- convert rotational motion into water flow
Heating Element¶
One of the most interesting discoveries.
Observations:
- cylindrical flexible element
- wrapped heater integrated inside pump housing
- heats water directly within the flow
- it is embedded into the hydraulic system
- integration between thermal and mechanical systems
Solenoid Valve¶
Controls water intake.
Observations:
- coil + spring + plunger mechanism
- opens/closes water flow
- simple ON/OFF control
Structural Elements¶
Additional mechanical components like weights and casing used for stability
Networking Perspective¶
Mapping to networking concepts:
| Dishwasher | Equivalent |
|---|---|
| Main MCU | Central server |
| Sensors | Input nodes |
| Actuators | Output nodes |
| Wiring | Physical layer |
| Signals | Simple protocol |
Learnings & Takeaways¶
The teardown exercise helped me debrief a lot of the concepts learned so far in the program, especially the electronic side and particularly this weeks focus on networks and communications.
Everything inside the dishwasher is:
- centralized
- tightly integrated
- voltage signals
- direct wiring
- simple ON/OFF control
No nodes talking to each other, no protocols — just one main controller and a bunch of passive components.
By breaking things open, following wires, identifying components and systems, I was able to figure out and understand the errors the machine was signaling that didn’t make it work properly beforehand.
Finding the heating system inside the pump was revealing as how deeply integrated mechanical, electrical, and thermal systems could potentially work for my final project.
Another important realization was how appliances often fail:
Even when most of the system is still working — structure, materials, molded parts, metal components — failure in electronics forces replacement of entire assemblies or even the full machine.
In this case, replacing a faulty electronic board ~€150 or heat pump ~€200 in a machine that costs ~€300 new does not make much sense.
Instead of discarding fully functional parts, A more modular design would allow:
- replacing only the faulty electronics
- or only the mechanical component that failed
This is directly relevant to ASFALT:
→ repurpose, upgrade equipment, don’t replace.
Finally, there’s something very satisfying and therapeutic about destroying a machine to understand how it works.