All Articles
Webhooks and HTTP Push Features of Security Cameras
This article introduces the Webhooks and HTTP Push features supported by some security camera products for third-party alarm platforms, along with the implementation architecture and communication workflow best practices. Camera Webhooks and HTTP Push Alarm Features Conventional cameras, upon detecting events via PIR or AI (such as human detection, facial recognition, license plate recognition), can push event messages and recorded videos to their own cloud platforms, which then forward them to the user's mobile app. All event pushing workflows and related event recording files are confined within the closed ecosystem of the camera manufacturer. Compared to this traditional closed ecosystem that only binds to proprietary apps, pushing event notifications externally via Webhook or HTTP Push means that the camera device can directly integrate into third-party central control systems or security alarm platforms. _In fact, Webhook itself is not an advanced new protocol or technology; its underlying logic is simply: When a specific event occurs, the system automatically sends an HTTP request (usually POST) to a pre-configured HTTP Server to notify it of the event information. Therefore, in some system configurations, this feature is also referred to as HTTP PUSH or Alarm Upload._ !6f83a518-7eb6-4b00-b356-b3cf0b863d8f.png In reality, the vast majority of enterprise-grade (B2B/SMB) and high-end commercial brands (such as Hikvision, Dahua, Axis, Meraki) natively support Webhook/HTTP request pushing, while pure consumer-grade (B2C) brands (such as Ring, Arlo, Nest, Eufy, Wyze) tend to build closed ecosystems and do not natively open Webhooks, thereby locking users into their own app ecosystems and promoting cloud storage subscription services. The following is a typical Webhooks configuration interface for a security camera system: !c00a0634-a6f1-481c-af0e-44f589234235.png Two Architectural Solutions for Webhook Implementation Regarding the specific implementation of Webhooks or HTTP Push, there are two main technical approaches: edge-side direct push and cloud-side forwarding, tailored for different application scenarios. Edge-Side Direct Push The architecture of the edge-side direct push solution is as follows: The URL of the third-party alarm server is directly configured on the camera. The internal firmware of the camera directly initiates an HTTP POST request, pushing the data directly to the third-party URL via its own network. !ca544108-6ceb-4f9b-8640-225d345f28e7.png This solution is applicable to scenarios with extremely high data privacy requirements (pure LAN or prohibited data passing through third-party clouds) and permanently powered IPC devices. Its advantage lies in having the simplest architectural design. This feature does not rely on dedicated cloud services deployed by the manufacturer, and customer data does not pass through intermediate cloud servers, offering the best privacy. The disadvantages are also obvious: every triggered alarm event requires establishing a TLS/HTTPS handshake on the edge side, a process that is extremely power-consuming for low-power battery-powered IPCs. Moreover, if the third-party server goes down, the internal system on the camera edge side struggles to maintain a long-term exponential backoff retry queue, making message loss very likely. Cloud-Side Forwarding The architecture of the cloud-side forwarding solution is as follows: The URL of the third-party server is configured in the cloud. The camera sends alarm signals to the manufacturer's cloud server using a lightweight persistent connection protocol (such as MQTT or WebSocket), and the manufacturer's cloud server then organizes a standard HTTP POST Webhook to push to the third-party client server. !19174867-adc4-4e9f-8e1e-a97065931363.png This solution is suitable for scenarios such as battery-powered low-power cameras and commercial projects requiring high-reliability message delivery. Naturally, it is also the more reliable option by comparison. Its advantages include better power efficiency; the camera edge side only needs to send a very small MQTT payload (or even just a trigger signal) and can then quickly re-enter sleep mode. Furthermore, the cloud possesses powerful message queue processing capabilities (such as Kafka or RabbitMQ), easily implementing failure retries and dead-letter queues to ensure 100% delivery of alarm messages to third-party servers. Additionally, this cloud-to-cloud interaction approach offers better security, allowing the cloud to centrally manage Webhook URLs, keys, and certificates for various batches of devices. Security Mechanisms of Webhooks Features Since communication takes place with third-party servers, a major security risk when receiving event alarm notifications via Webhook is malicious alarm spoofing. Therefore, the system design for third-party alarm integration must include at least the following security mechanisms (primarily designed on the third-party alarm server side): - Mandatory HTTPS Encryption: This means the Webhook target URL must use https:// to prevent man-in-the-middle attacks on the communication link. Communication between the camera/ODM manufacturer's server and the third-party alarm server must be encrypted via HTTPS, and the server's identity must be verified. - Alarm Message Encryption Protection via Signature Mechanism (HMAC-SHA256): Typically, an X-Signature field is included in the HTTP message header. This field is calculated by performing an HMAC-SHA256 operation on the Request Body using the Secret Key configured by the customer in the backend. Upon receiving the message, the third-party server uses the same key to verify the signature, confirming that the message genuinely originates from a legitimate device or the ODM manufacturer's cloud. The Webhook payload needs to be clearly structured for easy parsing by the server side. In addition, because event thumbnails and video files associated with alarm events are relatively large, Webhook JSON structures typically contain only thumbnail URLs or video download links. After receiving the Webhook, the third-party system fetches media files on demand using the links included in the payload. The following is a reference for the current industry-standard JSON definition: References - How-to Setup IP Camera API Webhook Events
Summary of 5G/LTE Working Modes
Power management of 5G and LTE modules is a core component in hardware design and BSP driver development. To strike a balance between responding to the network at any time and maximizing power savings, these modules typically follow 3GPP specifications combined with hardware interfaces, resulting in several tiered working modes. This article summarizes these working modes. From high power consumption to low power consumption, 5G/LTE modules generally include the following core working modes: - Active Mode - Idle Mode - Sleep Mode - Flight Mode !image.png Active Mode Active mode is the full-speed operating state of the module. When the device is making a voice call or sending/receiving network data packets (such as transmitting production test data or video streams via a socket), the module is in this mode. In this working mode, the module's RF transceiver is fully active, the baseband processor operates at high speed, and the module maintains a continuous RRC Connected state with the base station. This means that an exclusive signaling channel has been established between the module and the base station, and the base station has allocated dedicated physical layer resources (such as specific frequency bands and time slots) to the module. In other words, the module is not only connected to the network, but the base station has also reserved dedicated channel resources for data transmission and reception, allowing the two to interact with data at any time. In this Active state, the specific operating status of the module's RF link is as follows: - RX (Receiver): Continuously active. - TX (Transmitter): Not continuously enabled, but pulses on-demand. When there is business data to send, the module requests resources from the base station. Once approved by the base station, the TX PA (Power Amplifier) turns on instantaneously within the specified microsecond-level time slot to transmit the packet, and then immediately turns off the PA to save power. When there is no business data, the TX is basically silent; however, to maintain the RRC Connected state, the TX will still periodically turn on briefly to transmit some underlying control signaling. For the RF link, power consumption primarily originates from the TX section. In the RRC Connected Active mode, even if there is no business data to send, as long as it does not fall back to the Idle mode, the TX will still periodically communicate with the base station. This is why the noise-floor power consumption remains at hundreds of milliamperes even when no data is being sent in the Connected state. Additionally, in hardware specifications from module vendors such as Qualcomm, Quectel, and Fibocom, Active mode is further divided into several sub-cases: LTE Max. Power Mode, LTE Max. Throughput Mode, SA SISO Max. Power Mode, and SA Max. Throughput Mode. The core difference among these sub-modes is: whether the current power consumption bottleneck of the module lies in the RF front-end PA (Power Amplifier) or the core baseband DSP (Digital Signal Processor). !5G_LTE_Power_Modes.png Power consumption data in these working modes is crucial when performing system hardware power evaluations and power distribution network (PDN) design: if the device is in Max Power state, the power supply must be able to withstand instantaneous large current fluctuations (e.g., requiring larger tantalum capacitors to prevent brownouts); whereas if it is in Max Throughput state, since the current remains at a relatively high average, the primary focus shifts to solving the thermal management of the board during long-term operation. IDLE Mode To minimize the communication power consumption of LTE/5G modules, when data transmission ends, the module releases the RRC connection with the base station and enters the IDLE state. In the IDLE state: - The RF transmitter TX is completely turned off, but the receiver RX periodically and briefly turns on to listen for paging messages from the base station. This mechanism is called DRX (Discontinuous Reception). In this state, the module remains attached to the network, so it can quickly resume Active mode at any time. - Power consumption performance in IDLE state: Moderate. Typically between tens of milliamperes (mA), depending on the DRX cycle length configured by the network (longer cycles save more power). > 💡 As can be seen from this DRX workflow, this mechanism is very similar to the DTIM mechanism in Wi-Fi low-power modes. !image.png How to Switch from Active Mode to IDLE Mode? The decision to enter the IDLE state rests entirely with the base station (network side). The module itself cannot unilaterally disconnect and enter sleep mode; otherwise, the network will consider the module to have dropped abnormally. The base station side typically maintains an Inactivity Timer: - Every time data is sent or received between the module and the base station (whether uplink or downlink), this timer on the base station is cleared and reset. - When data transmission stops, the timer starts counting. If there is no data interaction beyond the set time (usually ranging from a few seconds to over ten seconds, configured by the operator's core network), the base station assumes the device temporarily does not need to communicate. - At this point, the base station sends an RRC Connection Release message to the module via the control channel. Upon receiving this command, the module actively releases the physical layer resources, turns off the transmitter (TX), and officially enters the RRC IDLE state. !image.png Furthermore, for even more extreme power savings, 3GPP introduced the RAI (Release Assistance Indication) feature in the latest low-power IoT specifications (such as NB-IoT/Cat.M). The module can attach a flag when sending the last packet of data to proactively inform the base station that communication is complete. Upon receiving this, the base station immediately issues a Release message, significantly reducing the module's waiting time in the Active state. DRX and eDRX The DRX mechanism of LTE modules is essentially similar to the DTIM logic of Wi-Fi modules, allowing the module to periodically sleep and wake up to minimize RF link power consumption while maintaining a connection with the base station. Under this working mechanism, the module's RX is turned off for most of the time (Sleep Duration), but wakes up at fixed intervals to listen to the base station's broadcast signals to check for incoming data packets. This mechanism drastically reduces power consumption without missing pages. In the power consumption section of LTE module datasheets, we often see conditions like DRX=64/128/256. These numbers refer to the DRX Cycle Length. In LTE and 5G networks, the duration of 1 radio frame is fixed at 10 milliseconds (10 ms). Therefore, converting these parameters into actual physical time is very straightforward: - DRX = 64: 64 * 10 ms = 640 ms (i.e., wakes up to listen once every 0.64 seconds) - DRX = 128: 128 * 10 ms = 1.28 s (i.e., wakes up to listen once every 1.28 seconds) - DRX = 256: 256 * 10 ms = 2.56 s (i.e., wakes up to listen once every 2.56 seconds) With the explosion of IoT (such as NB-IoT, LTE Cat.M, and even Cat.1 bis), some devices (like smart water meters) only need to transmit data once a day. Waking up the RX every few hundred milliseconds or seconds is still too power-intensive. To address this issue, 3GPP introduced eDRX in the Rel-13 standard. The core of eDRX is greatly multiplied sleep time. Building upon traditional DRX, it introduces the concept of PTW (Paging Time Window). The module can sleep deeply for tens of minutes or even hours. Upon waking up, it performs traditional DRX listening a few times within the PTW window, and then enters another long period of deep sleep. In this eDRX mode, the module and the core network negotiate the eDRX cycle length (e.g., 41 seconds, or even tens of minutes) when establishing a connection. Before the module enters sleep, the base station and the module perform a hash calculation based on the last few digits of the IMSI in the module's SIM card to determine the time slot for each paging time window. Once the module enters sleep, the base station caches the paging messages destined for this module until that specific time slot arrives, at which point it broadcasts them via the antenna. The module similarly turns on its receiving antenna at the arrival of the same time slot to receive messages from the base station. !image.png Sleep Mode First of all, for the RF front-end, there is no difference between IDLE mode and Sleep mode. In both modes, the network-side state is RRC Idle, and the module's RF receiver (RX) executes the exact same DRX cycle monitoring. The fundamental difference between these two modes lies in: whether the baseband SoC (digital core) inside the LTE/5G module and the peripheral buses connected to the host processor are in a suspended state. Consequently, power consumption influencing factors regarding sleep/wake-up involve the following aspects: - Peripheral Interfaces and Buses: In IDLE mode, the USB bus is active at full or high speed; simply maintaining a high-speed USB connection typically consumes 10mA to 20mA of current. In Sleep mode, the USB interface enters the Suspend state, and the USB PHY is powered down or enters an ultra-low-power mode. - Internal Main CPU of the Module: In IDLE mode, although there is no network data transmission, the module's internal main CPU (usually an ARM core) maintains a relatively high clock frequency and operates normally (idling). In Sleep mode, the module's operating system enters a low-level sleep state, and the main CPU scales down its frequency significantly or enters sleep. - Internal DDR of the Module: In IDLE mode, the module's internal DDR/LPDDR memory undergoes normal read/write refresh cycles. In Sleep mode, the memory controller enters Self-Refresh mode, retaining only a minimal baseline current to prevent data loss. Through these power optimization measures, an LTE module in Sleep Mode can typically reduce its consumption to around 2mA to 5mA. So, when the module is in Sleep Mode and there is a demand for data transmission, how is the module awakened? This wake-up logic can be divided into two aspects: the network side and the host side. - Network-side Wake-up: If there is an incoming call or downlink data, the module is awakened by a base station page, and subsequently wakes up the host through a dedicated hardware pin (such as the RI ring indicator pin) or via a USB Resume interrupt. - Host-side Wake-up: If the host needs to send data, it typically pulls a dedicated GPIO (such as the DTR pin) low/high or triggers a USB wake-up signal to rouse the module's CPU from the Sleep state. Flight Mode Flight Mode is relatively straightforward. It is generally triggered via AT commands (such as AT+CFUN=4) or dedicated hardware pins (such as W_DISABLE#). When the module is in Flight Mode, it directly cuts off the power supply to the RF circuitry, thereby disconnecting the module from the base station. However, other parts of the baseband processor (such as the SIM card interface and certain peripherals) may still be functioning, and the host can still communicate with the module via AT commands. Afterward, the module can be set back to Active mode via AT commands. References - https://www.rfwireless-world.com/tutorials/lte-rrc-state-diagram-idle-connected - 4G | ShareTechnote
How is Millimeter Wave Radar Point Cloud Data Constructed?
The articles A Detailed Summary of Millimeter-Wave Radar FMCW Working Principles and Calculation Process and How Millimeter-Wave Radar Measures and Calculates Angle Information have comprehensively summarized the complete workflow for measuring, deriving, and calculating distance, velocity, and angular direction information using millimeter-wave radar. This article, from the perspective of using millimeter-wave radar chips and modules, summarizes how the radar's output point cloud data is actually constructed. Millimeter Wave Radar Output Point Cloud Data Simply put, the point cloud data output by a millimeter-wave radar refers to a collection of data representing effective reflective targets in space, extracted from the echo radio frequency (RF) signals received by the radar's receiving antenna after undergoing underlying digital signal processing (DSP or hardware accelerator). !image.png For a typical 4D millimeter-wave radar chip or module, each frame's output point cloud consists of multiple points. The data for each point is typically a vector containing multiple dimensions of information: . - Spatial Coordinates (): The three-dimensional spatial position of the detected target relative to the radar sensor. This is resolved by calculating the signal's time-of-flight (range) and the phase difference between different receiving antennas (azimuth and elevation angles). How the radar measures these data points has been thoroughly summarized and explained in the articles A Detailed Summary of Millimeter-Wave Radar FMCW Working Principles and Calculation Process and How Millimeter-Wave Radar Measures and Calculates Angle Information. - Radial Velocity (): This is where millimeter-wave radar holds a competitive advantage. Relying on the Doppler effect, the radar can relatively accurately measure the instantaneous speed at which a point is approaching or receding from the sensor at a low level. It does not require estimating velocity by comparing consecutive frames, as visual algorithms do. - Signal-to-Noise Ratio / Reflection Intensity ( or , optional): Represents the strength of the signal reflected from the point. Metal objects exhibit higher reflection intensity, while objects like human bodies and fabrics show weaker reflection. For 3D millimeter-wave radar, which only possesses a multiple-input multiple-output (MIMO) antenna array in the horizontal direction and lacks vertical antenna placement, it can only measure Range, Velocity, and Azimuth. In a Cartesian coordinate system, its output data is therefore limited to . Radar Chip and Module Data Output Format Regarding the output data format for radar chips and modules, there is currently no universal data protocol or format across brands and industries. Therefore, the specific message structures output via serial port or CAN bus by different chip manufacturers (e.g., TI, NXP, Infineon) or module packagers (e.g., Sensortek, Zongmu, etc.) are proprietary. Nevertheless, the data and information content that radar chips and modules need to output are inevitably those mentioned in the preceding sections. Consequently, the core information structure of their output data is highly consistent within the industry: most consumer-grade and automotive-grade radar modules adopt the TLV (Type-Length-Value) data structure to package point cloud frames. The following section will illustrate the radar's output data situation using the example of the TI mmWave sensor's UART output data organization format, as provided in Reference [2]. Each time the radar finishes processing a frame of RF signals, it sends out a data packet. This data packet employs a classic design consisting of a fixed-length frame header plus variable-length TLV data blocks. !d84769d5-6ac8-4f1c-8000-5dff98fbb5dc.png Every frame of data output begins with a fixed-length 40-byte Frame Header structure, which serves as the anchor point for parsing the radar's data output: the total size of the data frame and the number of TLV structures contained within this frame are both defined in the Frame Header. !72144cc0-7681-4e3a-87cb-ae50f9ecaf8b.png Note that Num TLVs describes how many different types of data blocks are contained in this frame data packet. Through TI's guiMonitor command, the radar can be requested to output multiple types of data simultaneously in a single output frame, such as point cloud data (Type 1), target tracking lists (Type 1010), system status information (Type 6), etc. Each data type corresponds to one TLV structure. Meanwhile, Num Detected Obj represents the number of valid reflective points actually detected by the radar in the physical space of the current frame. This variable is primarily used for parsing Type = 1 (Detected Points) or similar point cloud TLV data. When parsing the TLV structure containing point cloud data in a program, this variable can be used to quickly retrieve the point cloud data for all detected points. For each TLV structure, its beginning consists of a fixed 8-byte header, which contains the Type and Length information for that structure: !3815ec78-ee1c-4b05-a4ab-1f77faab2a98.png For the TLV structure of point cloud data, the Type field is fixed at 1, and Length represents the Data Length of this TLV structure, excluding the TLV Header. The Data section of the TLV structure consists of contiguous point cloud data. Each point cloud data structure represents a valid detected point, with a fixed length of 16 bytes. All 4 core physical quantities for a detected point are represented using standard single-precision floating-point numbers (IEEE 754 standard). Therefore, the length of this section is 4 Bytes * Num Detected Obj. !7e1c6452-7075-4d1d-a761-99e1c75795d3.png Construction of Radar Point Cloud Information In the real physical world, frequency-modulated continuous wave (FMCW) signals emitted by radar strike cars, pedestrians, trees, the ground, and even raindrops, and are reflected simultaneously. The radar's receiving antenna (Rx) ultimately receives a complex analog electromagnetic wave, which is a mixture of all these reflected signals. So, how exactly does the radar chip internally extract distinct point cloud data from this complex mixed signal? In fact, the general calculation process has already been thoroughly summarized in the articles A Detailed Summary of Millimeter-Wave Radar FMCW Working Principles and Calculation Process and How Millimeter-Wave Radar Measures and Calculates Angle Information. Here, we will summarize the process of constructing point cloud data from the perspective of complete point cloud information generation: - 1D FFT (Range Dimension): After the analog signal, mixed with various echoes, is sampled by the radar's ADC and converted into a digital signal, the first thing the DSP does is perform a Fast Fourier Transform (Range FFT). Since the frequency difference of FMCW radar echoes directly corresponds to physical distance, this step effectively slices the space by range, thus preliminarily separating objects at different distances. - 2D FFT (Velocity Dimension): To accurately measure velocity information, the radar continuously transmits a sequence of chirps (e.g., 128 chirps forming one frame). Then, for these 128 results, another Fourier Transform (the so-called Doppler FFT) is performed in the time dimension. Because moving objects generate tiny phase differences between consecutive chirps, 2D FFT can convert these phase differences into velocity information. After the 2D FFT, the data transforms into a two-dimensional heatmap. !image.png - CFAR (Constant False Alarm Rate Detection): The two-dimensional heatmap obtained from the second step, filled with varying energy levels, contains not only targets but also a significant amount of environmental background noise and ground clutter reflections. The radar must determine which are true detection targets and which are merely noise. This is where the CFAR (Constant False Alarm Rate) algorithm comes into play: when it examines a specific cell (Cell Under Test, CUT), it first evaluates the average noise level of the cells surrounding it. Only when the energy of the CUT is significantly higher than the average noise of its surrounding environment, plus a pre-set threshold, does the radar identify it as a true detection point. - After processing with the CFAR algorithm, the radar's detection results become discrete detection points with independent coordinates. This is the origin of millimeter-wave radar point cloud output data. !image.png - 3D FFT (Angle Resolution): Through the calculations of the preceding three steps, the distance and velocity information of discrete detection points (point clouds) are obtained. In the final step, the radar only needs to focus on those few points that passed CFAR detection, extract the signal phase differences between different receiving antennas (Rx), and perform a third Fourier Transform to calculate the azimuth and elevation angles for that point. Finally, each isolated detection point and energy peak possesses complete information regarding distance, velocity, angles (azimuth and elevation), and reflection intensity. This information is then packaged into standard TLV Type 1 data and transmitted via the serial port according to the protocol format described above. !image.png References - Lidar Popular Science | Lidar, Camera, Millimeter-Wave Radar: Which is the True Eye of Smart Cars? - Understanding UART Data Output Format
How Do mmWave Radars Measure and Calculate Angle Information?
In the article Detailed Summary of FMCW mmWave Radar Sensing Workflow and Calculations, we covered the theoretical derivations and mathematical formulas for detecting target range and velocity using millimeter-wave (mmWave) radar. This article provides a comprehensive breakdown of the angle concepts within mmWave radar point cloud data, as well as the complete calculation workflow for angle estimation. Definition of Angle In the point cloud data output by mmWave radar, the embedded angle information essentially refers to the Angle of Arrival (AoA) of the electromagnetic waves reflected back from the target. In 3D spatial applications, this angle information typically covers two dimensions: 1. Azimuth (Horizontal Angle): The angular displacement of the target relative to the radar's horizontal plane (left/right). For example, the radar detects a vehicle 15° to the left of dead center. 2. Elevation (Vertical Angle): The angular displacement of the target relative to the radar's vertical plane (up/down). For example, the radar detects an overpass or road sign 10° above dead center. With the three spherical coordinates—range R, azimuth φ, and elevation θ—combined with the radar's own position, we can convert these values into Cartesian coordinates (x, y, z). This coordinate transformation is precisely why the radar's point cloud output can render spatial contours of targets in 3D space. !image.png Working Principle of Radar Angle Estimation A single radar antenna relies on the frequency difference of Frequency-Modulated Continuous Waves (FMCW) to measure range, and Doppler frequency shifts (phase differences) to measure velocity. However, a single antenna alone cannot estimate angles. To obtain angle information, a radar must rely on multi-antenna arrays (MIMO technology, i.e., multiple transmit antennas TX and multiple receive antennas RX). The core angle estimation technique is based on phase-difference-based Angle of Arrival (AoA) measurement. When the electromagnetic waves emitted by the radar's transmit antenna hit a target and bounce back, the reflected signal reaches the radar's multiple receive antennas as a set of roughly parallel electromagnetic waves (plane waves). Suppose a target object is located at an angle relative to the radar's boresight. Because the receive antennas on the radar board are spaced at a fixed physical distance (typically designed as half a wavelength ), there will be a tiny time difference between when the echo reaches adjacent antennas: after reaching the first receive antenna (RX1), the wave must travel a tiny additional distance before reaching the second receive antenna (RX2). Assuming the physical distance between two receive antennas is , trigonometric functions on a right triangle tell us that this additional path length (path length difference) is . !image.png Because electromagnetic waves are sinusoidal, traveling this extra distance manifests as a phase shift in the received signal (meaning there is a constant phase difference between the signals received by the two antennas). A full wavelength corresponds to a complete cycle ( phase). Thus, traveling an extra distance corresponds to a phase difference of: Next, we solve for the angle from the equation above. Since the radar hardware chip can accurately measure the phase difference between the signals received by RX1 and RX2 (by sampling and running an FFT on the waveforms received by RX1 and RX2—similar to range calculation—extracting the phase from the FFT results, and then calculating the phase difference), the inter-antenna spacing is fixed by design, and the wavelength of the emitted electromagnetic wave is also constant, we can easily calculate the target angle using the formula below: This is the underlying essence of radar angle estimation: measuring the phase difference between signals received by different antennas and using trigonometric functions to calculate the target's angle. 3D Radar vs. 4D Radar The angle measurement principle outlined above is quite straightforward, but there is an important caveat: if the radar's receive antennas are arranged in a single horizontal row, it can only measure the azimuth (horizontal angle). This is what is known as a 3D radar. The reason is simple: when all receive antennas are aligned along the same horizontal line, there is only horizontal spacing between them. Under these conditions: - When a target moves left or right (azimuth), the path lengths traveled by the electromagnetic wave to each antenna vary, creating phase differences. The radar can then compute the azimuth angle following the workflow described above. - However, when a target moves up or down (elevation), because the reflected electromagnetic plane wave arrives in parallel from above or below, the distance it travels to each horizontally aligned antenna is identical. Consequently, the phase difference generated in the vertical direction is zero. The radar cannot distinguish whether the target is overhead or on the ground. This explains why traditional 3D radars in automotive applications often confuse overhead bridges with road-level obstacles. 4D radar introduces vertical sensing capability on top of 3D radar capabilities. In practical system design, clever 2D Planar Arrays or MIMO (Multiple-Input Multiple-Output) virtual antenna techniques are typically employed. In terms of antenna array design, the transmit (TX) and receive (RX) antennas are arranged in a staggered pattern, with intentional height differences designed into the transmit antennas. When multiple transmit and receive antennas operate simultaneously, algorithms combine them to synthesize a larger number of virtual antenna points, forming a two-dimensional planar array in both horizontal and vertical directions. !image.png The horizontally extended virtual antenna array leverages horizontal distance differences to measure the horizontal azimuth, while the vertically extended virtual array (with height offsets) leverages vertical distance differences to measure the vertical elevation. To summarize, the radar industry defines radar dimensions (D) as follows: - 3D Radar measures 3 dimensions: Range, Velocity (Doppler), and Azimuth. - 4D Radar measures 4 dimensions: Range, Velocity, Azimuth, and Elevation. _The 3D spatial coordinates (X, Y, Z) commonly seen in radar point cloud data are calculated precisely from these three physical quantities—range, azimuth, and elevation—using trigonometric transformations._ Radar Angular Resolution Just like range and velocity measurements, radar angle measurement also has a concept of minimum resolution: angular resolution. In radar engineering, Angular Resolution refers to the minimum angular separation required between two adjacent targets at the same range and velocity for the radar to distinguish them as separate entities. If two targets (such as a pedestrian and a parked car next to them) have an angular separation smaller than the radar's angular resolution, the radar's DSP will treat them as a single echo peak, outputting a single merged point in the point cloud data rather than two distinct targets. Modern 4D imaging radars mostly adopt single-chip large array designs (such as 4TX/4RX or 4TX/6RX) or even multi-chip cascaded antenna designs (e.g., combining 4 chips to achieve 12TX/16RX). Their horizontal azimuth resolution can reach high precisions of 1° to 1.5°, while vertical elevation resolution typically falls between 2° and 5°. How to Calculate Angular Resolution? In radar and antenna theory, angular resolution is fundamentally determined by the mainlobe width of the antenna array. Rayleigh's criterion in physics states that two targets are resolvable when the peak of one target's beam pattern coincides with the first null (zero point) of the other. !image.png For a uniform linear array (ULA) of length , its antenna pattern (beam shape) can be described using a function. The theoretical formula for its 3dB beamwidth (the angular width where power drops by half, defined as the angular resolution in engineering) is: !image.png For quick engineering estimations, the factor is often omitted, yielding the approximation: Since , 1 radian . Substituting this into the equation above gives the formula in degrees: Assuming there are receive antennas spaced at , the effective aperture length of the array is: Substituting back into the degree-based resolution formula yields: This serves as a rule-of-thumb formula for quickly calculating radar angular resolution in engineering practice. As shown, the only way to improve angular resolution is to increase the number of receive antennas . According to this quick formula, achieving a 1° angular resolution would require 114 receive antennas spaced at —which is practically impossible on a compact circuit board. This brings us to MIMO (Multiple-Input Multiple-Output) and Virtual Antenna Array technology. MIMO Virtual Antenna Arrays In radar antenna design, packing a massive number of physical receive antennas into hardware is impractical. However, in engineering practice, a small number of transmit (TX) and receive (RX) antennas can be multiplied together to synthesize a large virtual antenna array within the radar processing pipeline, thereby dramatically boosting angular resolution. The general workflow is as follows: - Transmit antenna TX1 sends a chirp signal, and the 4 physical receive antennas (RX1–RX4) on the board capture the reflection. At this moment, the system acquires 4 spatial phase samples. - A fraction of a second later, TX1 stops and TX2 transmits a signal. During PCB layout design, TX2's physical position is intentionally shifted laterally by a precise distance (typically 4 times half a wavelength). Thus, when TX2 transmits a signal that hits the target and reflects back to RX1–RX4, the electromagnetic wave travels an extra distance due to TX2's spatial offset. - When the radar's DSP processes the signal, the phases received by RX1–RX4 during TX2's transmission are mathematically equivalent to phases that would be received by 4 new virtual receive antennas (RX5–RX8) placed directly to the right of TX1. !image.png Therefore, by having 3 TX antennas transmit sequentially in time combined with 4 RX antennas receiving, the radar software successfully reconstructs phase data for virtual antennas. Using flagship single-chip solutions from vendors like TI or NXP (e.g., 4TX / 4RX), MIMO techniques can synthesize up to 16 virtual antennas ( resolution). Furthermore, if 4 such chips are cascaded (e.g., achieving 12TX and 16RX), they can synthesize virtual antennas. This virtual antenna approach is precisely how modern flagship 4D imaging radars achieve high-precision horizontal and vertical angular resolutions. References - How to track multiple targets using mmWave radar point clouds? - EET China - Understanding mmWave Radar in One Article (Including 4D mmWave Radar) - Zhihu - Understanding mmWave Radar: From Principles to Applications - YOUUAV - Radar Principles Part 1 - Blog Garden - Miscellaneous Notes on MIMO Radar Technology - Blog Garden
Detailed Summary of FMCW mmWave Radar Principles and Calculation Process
In the article Understanding the Principles and Applications of mmWave Sensing Radar, we briefly summarized the fundamental principles of radar and millimeter-wave (mmWave) radar, as well as the calculation processes for its two operating modes. This article provides a detailed summary of the working principles, range, and velocity calculation workflows of the FMCW mode in mmWave sensing. This will help build a deeper understanding of the concepts and operating procedures of this radar mode. Structure and Organization of FMCW Transmit Signals As summarized in Understanding the Principles and Applications of mmWave Sensing Radar, in the FMCW (Frequency Modulated Continuous Wave) mode of mmWave radar, the radar does not transmit traditional discrete pulses. Instead, it transmits a continuous sine wave whose frequency increases linearly over time, known as a Chirp signal. !image.png The core physical characteristics of a chirp can be defined by the following parameters: - Start Frequency (): e.g., 77 GHz. - Bandwidth (): The frequency sweep range, e.g., 4 GHz. Bandwidth determines the radar's Range Resolution. A higher bandwidth yields a finer range resolution, making it easier to distinguish two closely spaced objects. - Ramp Time / Duration (): The time taken for the frequency to sweep from to , e.g., 40 µs. - Frequency Slope (): The rate of frequency change, calculated as . A single chirp is sufficient if you only need to measure the distance to a static object. However, to measure the velocity of a moving object, multiple consecutive chirps are required. Therefore, radar data is organized into frames (Frames). Each Frame contains multiple consecutive chirp signals, facilitating periodic data throughput and object detection for subsequent processing by an NPU or DSP. For a single chirp signal, its microscopic timeline mainly consists of the following two phases: - Inter Chirp Idle Time: The transmitter does not transmit active signals, and the frequency synthesizer quickly ramps back down and locks onto the start frequency . - Tx Start: The transmitter turns on, and the frequency begins to rise linearly from to . A Frame consists of a sequence of identical, consecutive chirp signals. The key parameters of a Frame are as follows: - Number of Chirps (per frame): e.g., 128 chirps per frame. This value determines the radar's velocity resolution. - Frame Periodicity: e.g., 33 ms (corresponding to approximately 30 FPS). - Active Frame Time: The duration occupied by transmitting 128 chirps consecutively. - Inter-Frame Time: The gap between the end of one frame and the start of the next. During this time, the radar's RF front-end typically enters a low-power state, while the backend processor (such as a DSP, ARM, or NPU) works at full speed to process the raw ADC data generated during the active frame. The figure below shows the timeline structure of a Frame containing consecutive chirp signals: !image.png Below is an example illustrating the timeline of chirps and frames transmitted by the radar: - Chirp Duration (): 50 µs - Chirp Idle Time: 10 µs _(Thus, the total period to transmit a single complete chirp is 60 µs)_ - Number of Chirps per Frame: 128 - Active Transmission Time: ms - Frame Periodicity: 33 ms Based on these parameters, the transmitter operation workflow of the radar system is as follows: within every 33 ms period, the transmitter only operates during the first 7.68 ms, transmitting 128 chirps continuously at rapid intervals (60 µs). During the remaining ~25 ms, the transmitter is turned off, waiting for the next frame trigger. Radar System Architecture and Intermediate Frequency (IF) Signal The architecture of an FMCW mmWave radar system is shown in the diagram below: !image.png The Mixer in this block diagram multiplies (mixes) the current transmitted signal with the received echo signal. The mixed signal then passes through a low-pass filter to generate an Intermediate Frequency (IF) signal, which is used for subsequent calculations. Suppose the transmitted signal at the current moment is , and the received echo signal is . The intermediate frequency (IF) signal obtained after mixing and low-pass filtering is: Subsequent calculations for range, velocity, and angle are all performed based on this IF signal. Range Calculation Workflow The key to understanding range calculation is that the received RX signal is a time-delayed version of the transmitted TX signal. !0dd49612-962a-4e37-8697-ff2711848792.png Assuming the round-trip time-of-flight of the electromagnetic wave from the transmitter to the target and back to the receiver is , the time delay formula is , where is the distance to the object and is the speed of light. Since the frequency of the TX signal increases linearly with time, subtracting the RX signal (which is delayed by ) from the TX signal at any given instant yields a constant frequency difference. This frequency difference is the frequency of the IF signal. Based on geometric similarity, the frequency of the IF signal is equal to the slope multiplied by the time delay . Combining this with the time delay formula above yields the final range calculation formula: Thus, by extracting the frequency of the IF signal, the system can directly compute the range to the target. DSP Computation Workflow The DSP computation workflow for range is as follows: - ADC Sampling: The analog mixer outputs an analog intermediate frequency (IF) sine wave, which the DSP must first digitize using an ADC (Analog-to-Digital Converter). Given an ADC sampling rate (e.g., 6.4 Msps) and the number of sample points per chirp (e.g., 256 points), this step yields an array of length . - Signal Windowing: Before performing the FFT, to mitigate spectral leakage caused by computing FFTs on finite-length arrays, the sample points are typically multiplied by a window function of the same length (such as a Hanning or Blackman window). - FFT Execution: The DSP's hardware accelerator (HWA) or DSP core performs a Discrete Fourier Transform (DFT/FFT) on the windowed time-domain data points. This produces a frequency-domain array of complex numbers (real + imaginary parts). According to the Nyquist theorem, we typically only need to inspect the first points. In radar terminology, these points are referred to as Range Bins or Index . - Magnitude Calculation & Peak Detection: The FFT output is in the complex domain, representing both phase and magnitude. The DSP traverses these Range Bins and calculates the magnitude of each point as . In the simplified scenario of a single detected target, the DSP only needs to identify the bin with the largest value (highest energy) among the points and record its index, denoted as Index . - If multiple targets are present, scanning the FFT magnitudes will reveal multiple peaks. In this case, the DSP records the indices of all these peak points. - Physical Metric Conversion: This step converts the index obtained in the previous step into a physical distance in meters (m), using the following conversion workflow. !cd67c01b-6957-40fe-8ce8-615c3c75addd.png The frequency span represented by each bin (frequency resolution ) is determined by the ADC parameters: , where is the ADC sampling rate. Therefore, the IF frequency corresponding to the peak (located at Range Bin index ) is: . Combining this with the radar range formula () and rearranging for distance yields: . The final range calculation formula is: The term in parentheses is a constant determined during radar initialization. This constant represents the radar's range resolution per single bin (). Velocity Calculation Workflow Since the range of an object can be determined from a single chirp measurement, can we easily calculate the velocity of a moving object by comparing the range across multiple chirps? The answer is no. Suppose a target is moving at velocity , and the radar transmits two identical, consecutive chirps separated by an interval of (the chirp period). Within the extremely short interval between the first and second chirp (e.g., 60 µs), the target moves only an infinitesimally small distance: . For typical moving objects, this distance is on the scale of micrometers. Such a tiny difference in distance is invisible as a frequency shift on the 1D FFT spectrum; hence, the peaks of both chirps will still appear in the exact same Range Bin. However, because the wavelength of the millimeter wave is extremely short (approximately 3.9 mm at 77 GHz), this minute difference in distance produces a prominent phase shift between the IF signals of the two chirps in the complex domain. As an electromagnetic wave travels a physical distance in space, its phase changes by: Suppose the physical distance between the radar and the target is . However, the transmitted chirp signal must travel to the target and then reflect back to the receiving antenna. Thus, the actual total round-trip path of the electromagnetic wave through the air is . Substituting the total path distance into the initial equation, and considering the tiny distance moved by the target , we derive the physical formula for the phase difference in the received signals: From this formula, we can back-calculate the target velocity : Based on the formula above, the velocity of the target can be calculated as long as we extract the phase difference between the two chirp signals. !ca6da295-8d3b-4131-9c26-244d9ac8c5d0.png > 💡 Here, the concept of Maximum Unambiguous Velocity () comes into play. Since phase is calculated via trigonometric functions, it is periodic. To guarantee uniqueness in velocity measurement (preventing velocity ambiguity), the absolute phase difference between two consecutive samples must be less than . From this, we can derive the maximum relative velocity the radar can measure: . This implies that a shorter chirp period (more densely spaced transmissions) enables the measurement of higher maximum velocities. DSP Computation Workflow The DSP computation workflow for velocity is as follows: - Constructing the Radar Data Matrix: Within a single frame, the ADC collects chirps (e.g., 128), with each chirp containing sample points (e.g., 256). The DSP first performs a 1D FFT (Range FFT) on the 256 time-domain sample points of each chirp. The complex FFT outputs (containing magnitude and phase) for each chirp are written to memory and assembled into a 2D matrix of size . - Range Bin Locking & Data Extraction: Within the brief duration of a single frame (which is typically only a few milliseconds), the physical displacement of a normally moving target is extremely small, meaning it generally will not cross the radar's range resolution cells. Assuming that the target's energy peak is found at the -th Range Bin across the FFT output sequences of all chirps, this step extracts the complex data (containing both magnitude and phase) at this -th bin across all chirps, forming a new 1D complex array of length . - Windowing: Similar to the range calculation logic, to prevent spectral leakage during the subsequent 2D FFT calculation, the DSP multiplies each element of this 1D complex array of length by the coefficients of a 1-dimensional window function (e.g., a Hanning window). - 2D FFT (Doppler FFT) Execution: The DSP's Fourier transform unit performs an -point FFT (commonly referred to as a 2D FFT) on this windowed complex array of length . The result is a complex array of length , where each element represents a specific Doppler Bin. - Peak Detection & Velocity Metric Conversion: The DSP calculates the magnitude of each element in the 2D FFT output array () to construct a velocity power spectrum. It then identifies the index of the Doppler Bin with the highest energy, denoted as Index . The velocity power spectrum calculated through the 2D FFT contains bins, which physically corresponds to dividing the full phase cycle into discrete parts. Based on the phase difference formula above, the equation for each phase step is: Thus, the resulting velocity resolution (which represents the physical velocity step per bin in the velocity power spectrum) is: Given that the peak in the velocity power spectrum lies at the -th bin, the corresponding target velocity is calculated as: What If There Are Multiple Targets? The summary of range and velocity calculations above assumed a simplified scenario containing only a single target. What happens if there are multiple targets in the scene simultaneously? In this scenario, measuring the distances to the targets is relatively straightforward. If multiple targets are present, after receiving the reflected echoes, sampling via the ADC, and performing the 1D FFT on the DSP, multiple distinct peaks at different indices will emerge on the range spectrum (Range Bins). Each peak corresponds to the distance of a specific detected target. However, if two objects are located too close together—closer than the radar's range resolution limit—they will merge into the same Range Bin index. In this case, the radar cannot resolve them separately, and they will be represented as a single target. !7a57f0d5-8c03-444f-b34d-b653813d82aa.png But what if two targets are at the exact same distance but moving at different velocities? Since their signals share a single Range Bin, the extracted phase sequence will be a convoluted overlay of both target phases, preventing the radar from correctly resolving and identifying their individual velocities. To measure velocity under these conditions, instead of first finding peak bins in the range spectrum and only calculating the 2D FFT for those specific bins across all chirps, the system must perform the following: - Perform a 1D FFT (Range FFT) on all chirps within the entire frame and stack the results to construct a 2D Radar Data Matrix (where rows represent Range Bins and columns represent Chirps). - Each column of this 2D matrix corresponds to a single chirp. Looking across columns for a specific Range Bin reveals how the magnitude and phase of the detected target evolve over consecutive chirps within a frame. Because the frame duration is very short, the magnitude changes in this sequence are negligible, but the phase exhibits significant variation depending on the target's velocity. - If a single Range Bin contains multiple targets, the phase and amplitude in this sequence represent the superimposed vector sum of those targets. - Execute a 2D FFT (Doppler FFT) across every row (each Range Bin) of the Data Matrix. - If a Range Bin contains only one target, the 2D FFT maps its phase variation to its corresponding velocity. - If a Range Bin contains multiple targets, the 2D FFT can successfully decompose and separate the phase shifts caused by their distinct velocities. - After performing the 2D FFT on the entire matrix, the DSP generates a 2D Range-Doppler heat map in memory, where the horizontal axis represents range, the vertical axis represents velocity, and the color intensity denotes energy (amplitude). - Finally, the system performs peak detection directly on this 2D heat map. Each 2D peak corresponds to the range and velocity data of an individual detected target. As shown, on this heat map, two objects situated at the exact same Range Bin but moving at different velocities can be clearly resolved and identified. !6334ac9c-e43c-4b20-83d8-a8aaef4c58bb.png References - The fundamentals of millimeter wave radar sensors, Texas Instruments.
Understanding the Working Principles of mmWave Sensing Radar Technology
In essence, radar (originally an acronym for 'radio detection and ranging') is a device that detects a target's distance, velocity, and direction by transmitting electromagnetic waves (radio waves) towards it and then measuring the reflected radio waves. In the history of radar technology development, the Pulse Method and Frequency Modulated Continuous Wave (FMCW) are two of the most classic and distinct systems. The Pulse Method is the cornerstone of traditional radar (such as large military radar, early weather radar), while FMCW is the absolute mainstream for modern consumer and automotive millimeter-wave radar applications. This article provides a detailed summary of the working principles of the Pulse Method and the widely applied FMCW mode in the field of millimeter-wave radar. What is Millimeter Wave? Millimeter wave (mmWave), as the name suggests, refers to electromagnetic waves with wavelengths between 1 mm and 10 mm, corresponding to a frequency range of approximately 30 GHz to 300 GHz. They are called millimeter waves precisely because their wavelengths are measured in millimeters (mm). > In fact, the frequency range of millimeter waves does not have a strict definition. For example, the 26 GHz and 28 GHz bands currently allocated for global 5G communications are also considered millimeter waves. Currently, in consumer and automotive electronics, the most commonly engineered frequency bands are 24 GHz (gradually being phased out), 60 GHz, 77 GHz, and 79-81 GHz. The figure below shows the frequency band and wavelength range of millimeter waves in the classification of radio waves. They are called millimeter waves precisely because their wavelengths are measured in millimeters (mm). !4ac5c170-7f85-4611-916c-6edef73c9c73.png Working Principle of the Pulse Method The working principle and process of the pulse method are quite intuitive. Its core idea is that radar transmits an extremely short, high-power electromagnetic wave pulse, and then passively waits to receive the reflected signal. It should be noted that in the pulse method operating mode, each extremely short pulse emitted by the radar (e.g., lasting 1 microsecond) contains high-frequency oscillating electromagnetic waves. The frequency of this wave is the carrier frequency, which typically remains constant during the pulse duration. This means that each time the radar transmits, it emits an electromagnetic wave signal with a fixed carrier frequency within this very short period (like the blue pulse in the figure below), and the received echo naturally has the same carrier frequency. !4f728773-1635-4da8-b096-849e907b5378.png Therefore, the working principle of ranging using the pulse method relies on the time difference (ToF) between the transmitted and received signals. Electromagnetic waves propagate at the speed of light . The radar records the time of transmitting the pulse and the time of receiving the reflected pulse, calculates the time difference (i.e., Time of Flight), and then uses the following formula to calculate the distance to the object: For velocity measurement using the pulse method, Doppler Phase Shift is required. The working principle is: if the target is moving, a single pulse can only measure distance, not directly measure velocity. To measure velocity in this scenario, the radar must transmit a pulse train. When the target moves, the round-trip distance for adjacent pulses changes slightly, which causes a change in the phase of the reflected electromagnetic waves. By comparing the received phase difference of consecutive pulses, the radar calculates the target's radial velocity using the Doppler effect. How Does Radar Measure the Distance to Multiple Targets Simultaneously? Once the radar pulse is transmitted, the radar receiver remains continuously active, and its corresponding high-speed ADC continuously records the received signal voltage. At this point, all targets within the radar's coverage area, located at different distances, reflect their respective echoes back to the receiver, causing multiple peaks to appear on the receiver's voltage curve. Naturally, there is a concept here called Range Resolution. This concept refers to the radar's ability to distinguish between two closely spaced objects. For example, in the context of automotive radar detection, if a person is standing very close to a car, will the radar display one large dot or two distinct small dots on the screen? If the distance between them is too close, the echoes received by the radar receiver cannot be distinguished, and they will be perceived as a single target. As long as the spatial separation between these objects is greater than the radar's range resolution, the radar receiver will detect distinct, non-overlapping echoes arriving sequentially. The radar's DSP simply needs to identify the number of peaks on this time axis and their respective timestamps to simultaneously calculate the distances to all targets. !cd2e2f7-ef26-4379-8eb4-17727a7ac8b3.png Why Can't Consumer/Automotive Radars Use the Pulse Method? This is primarily because: millimeter-wave radar typically requires centimeter-level range resolution. In pulse radar, to distinguish between two targets, their respective reflected echoes (pulses) must absolutely not overlap on the time axis; that is, the distance between these two targets must be greater than the radar system's range resolution. Suppose two objects are separated by a distance . For the electromagnetic wave to hit the farther object and return, it needs to travel an additional distance of . This extra travel time is: And for the echo from the first object to completely finish before the echo from the second object begins, the duration of the radar's transmitted pulse (pulse width ) must be less than this time difference . According to the formula and theory above, if the minimum distance between two targets to be distinguished is 15 cm, then the pulse width emitted by the radar transmitter must satisfy the following condition: However, processing 1 ns signals on low-cost automotive-grade and consumer-grade radar chips presents significant problems: - The range of radar detection depends on the total transmitted energy (Energy = Power Time). If there is only 1 ns to transmit energy, to ensure sufficient echo for electromagnetic waves traveling 100 meters away, the system must unleash instantaneous peak power of hundreds or even thousands of watts within this extremely brief 1 ns. This is not feasible with traditional CMOS-based chips. - Problems also exist at the receiver end: According to the Nyquist sampling theorem, to reconstruct a 1-nanosecond-wide waveform in the digital domain, the radar receiver ADC's sampling rate must be at least several GSPS. This is also impractical for low-cost chips used in consumer and automotive electronics, which cost only a few dollars. - Furthermore, to accurately calculate time differences on the order of tens of picoseconds ( seconds) for ranging, the radar system's internal clock requirements are extremely high. The on-chip clocks (PLL/VCO) must be exceptionally stable with minimal jitter. Such high-precision clock networks are challenging to implement on low-cost SoCs. This is why, in the fields of consumer and automotive electronics, millimeter-wave radar ultimately abandoned the simpler pulse method and turned to FMCW (Frequency Modulated Continuous Wave). Working Principle of FMCW Mode The most prevalent millimeter-wave radar technology in consumer and automotive sectors currently is FMCW (Frequency Modulated Continuous Wave). The figure below shows a typical system block diagram of an FMCW millimeter-wave radar: !c75428c7-bf61-48d9-bb3a-25919bfa5f1d.png In FMCW mode, the entire radar system operates as follows: - Step 1: Transmit Wave Generation. The synthesizer in the system generates a specific frequency millimeter-wave signal. This signal is split into two paths by a splitter: one path goes to the transmit antenna (Tx antenna) for outward transmission. The other path goes to the mixer as a reference signal for subsequent processing. - Step 2: Millimeter-Wave Transmission. The millimeter-wave signal, amplified by an amplifier (Amp), is transmitted by the transmit antenna towards the target (e.g., a car). - Step 3: Receive Reflected Wave. The target object reflects a portion of the millimeter-wave signal. The reflected wave is received by the receive antenna (Rx antenna), amplified by an amplifier, and then fed into the mixer. - Step 4: Mixing and Signal Processing. In the mixer, the received reflected wave is mixed (multiplied) with the reference signal. After filtering out the high-frequency components, a low-frequency Intermediate Frequency (IF) Signal is obtained. This IF signal is then sent to a Digital Signal Processor (DSP), which calculates target information such as distance and velocity. It is important to note that in this mode, millimeter-wave radar does not transmit short electromagnetic pulses like pulse radar. Instead, it continuously and uninterruptedly transmits a continuous wave whose frequency changes linearly with time. This waveform is known as a Chirp (linear frequency modulated pulse). !fig-mmwave-003-en.png Calculation Process and Working Principle of the IF Signal For a very brief instant, the transmitted signal (Tx) and received signal (Rx) can be regarded as two high-frequency cosine waves (the same applies to sine waves). Suppose at a certain moment: • Transmitted Signal (Tx): Frequency is (e.g., 77.005 GHz), expressed as • Received Signal (Rx): Frequency is (e.g., 77.000 GHz), expressed as For a mixer in radar hardware, its physical function is to perform multiplication on these two voltage signals. According to the product-to-sum trigonometric identity: Substituting the expressions for Tx and Rx above, the raw output signal of the mixer becomes: The result of this formula, after multiplying two single high-frequency waves, yields two new waves: - Sum Frequency Component (): These two frequencies add up to become an ultra-high-frequency signal of approximately 154 GHz. - Difference Frequency Component (): These two frequencies subtract to become a low-frequency signal of only 5 MHz (). At the output of the mixer, the hardware circuit is always followed by a low-pass filter. The effect of this low-pass filter is to filter out the ultra-high-frequency sum frequency signal, retaining only the difference frequency component. This difference frequency signal is the Intermediate Frequency (IF) signal subsequently used for distance and velocity calculations. After the above processing, this IF signal is only 5 MHz, which can be easily handled by low-cost processors. !e6ffd6c7-fec8-43d7-86bc-0a56bd967181.png Calculating Distance and Velocity from the IF Signal The process of calculating distance based on the obtained IF signal is relatively straightforward. Since the IF signal's frequency is essentially the difference between the transmit and receive signal frequencies, this frequency is perfectly proportional to the target's distance . Where is the Chirp slope (), and is the speed of light. Thus, after the radar receiver receives the echo signal and samples its generated IF signal, by performing a one-dimensional Fast Fourier Transform (FFT) on the sampled points of each Chirp to convert the time-domain IF signal to the frequency domain and obtain the IF signal's frequency , the distance can be calculated using the formula above. Therefore, a single Chirp signal is sufficient to calculate the target's distance. Calculating velocity is slightly more complex, requiring the calculation results from two consecutive Chirp signal sequences. If the target is moving, due to the very short time interval between two consecutive Chirps, it will generally undergo an extremely small displacement (typically on the micron scale) between successive Chirps. While this minute displacement does not significantly alter the calculated distance, it causes a certain linear shift in the complex phase at the FFT peak for adjacent Chirps. The phase difference between two adjacent Chirps can be expressed using the following formula: Where is the target's relative velocity, is the Chirp period, and is the electromagnetic wave's wavelength. Therefore, by calculating the phase difference of the FFT peaks from two consecutive Chirp sequences, the target's relative velocity can be inversely calculated using the formula above. References - What Is mmWave Radar? Principles and Usage Examples | Murata Manufacturing Articles
Why Are DDR and LPDDR Incompatible with Each Other?
Are DDR and LPDDR mutually compatible during system design? For a main host SoC, how do we make the correct selection and design decisions between DDR and LPDDR? This article attempts to explain and summarize these DDR and LPDDR compatibility issues in detail. DDR and LPDDR Are Not Directly Compatible The DDR and LPDDR memory standards we encounter in electronic system design are targeted at completely different application scenarios. - Standard DDR primarily targets applications such as PCs and servers, which are insensitive to power consumption but demand extreme capacity and versatility. - LPDDR (Low Power DDR), on the other hand, is specifically designed for power- and space-constrained scenarios such as smartphones, laptops, wearables, and various edge computing devices. Although both belong to the category of SDRAM (Synchronous Dynamic Random-Access Memory) and share similar names, in actual hardware design and component selection, DDR and LPDDR are absolutely not directly compatible or interchangeable. !image.png Why Are DDR and LPDDR Incompatible? The reasons for the incompatibility between DDR and LPDDR manifest in multiple aspects. These include both the electrical specifications implemented by the DDR controller and Physical Layer (PHY), as well as their internal block architectures. This has been briefly introduced in the articles Can PSRAM Be a Solution for DDR Shortages? and How Do PSRAM and LPDDR Reduce Power Consumption?. Below is a detailed breakdown and summary of the specific reasons behind this incompatibility. Different Electrical Voltage Levels As summarized in the article How Do PSRAM and LPDDR Reduce Power Consumption?, LPDDR drops its standard IO operating voltage below 1V to further reduce power consumption. - Pure Standard DDR Controller: Its internal PHY (Physical Layer) is designed for standard DDR. Taking DDR4 as an example, the default I/O voltage (VDDQ) output by the controller is 1.2V (using the POD signaling standard). This standard allows for a larger signal swing and strong driving capability to cope with parasitic capacitance and signal attenuation caused by longer PCB traces and DIMM slots. Consequently, its PCB routing requirements are relatively relaxed. - LPDDR Chip: Taking LPDDR4X as an example, while its core voltage might be 1.1V, its I/O pins (VDDQ) for receiving data and commands are extremely delicate, with a standard operating voltage of 0.6V (using the LVSTL signaling standard). The signal voltage swing under this standard is tiny (typically only a few hundred millivolts). Such weak signals cannot drive long-distance traces. Therefore, LPDDR's physical layer is designed for short-distance transmission, making impedance control in PCB routing extremely demanding. Different Bus Pin Definitions Standard DDR utilizes a split-bus design. The address lines (A0-A17), command lines (RAS, CAS, WE), and data lines (DQ) connected between the host SoC and the DDR are all separated, resulting in an extremely high pin count. To squeeze the PCB footprint of smart devices to the absolute limit, the LPDDR standard compresses all of the aforementioned independent control and address lines into a single CA (Command/Address) bus of 10-bit (LPDDR2/3), 6-bit (LPDDR4), or 7-bit (LPDDR5). Consequently, the SoC must integrate a complex LPDDR protocol controller to split memory read/write commands and transmit them over these few CA lines across multiple cycles using both the rising and falling edges of the clock. Inside the LPDDR chip, a decoding circuit is required to reconstruct the original commands. The figure below shows the external interface definition of DDR3/DDR4: !image.png The figure below shows the interface definition of LPDDR4: !image.png Different Channel Architectures Furthermore, DDR and LPDDR exhibit fundamental differences in their underlying data transmission channel architectures. Standard DDR typically utilizes a single 64-bit channel design (which evolved into dual 32-bit channels in DDR5), aiming to deliver massive single-transaction data throughput. In the PC industry, PC CPU memory controllers typically operate on a 64-bit baseline. Thus, a standard DDR4 DIMM is consistently 64-bit (72-bit with ECC). In the manufacturing ecosystem of standard DDR, to control cost, package size, and yield, individual memory dies (chips) usually do not have very wide data interfaces. The most common data widths for a single chip are 4-bit, 8-bit, and 16-bit. A standard DDR controller inside a host SoC is natively designed to process 64-bit data transactions, which necessitates connecting multiple DDR chips in parallel. For example, if we use 8-bit memory chips, we must parallelize 8 of them to fill the 64-bit channel (8 bits/chip × 8 chips = 64 bits). During PCB routing, the SoC's controller sends identical address and control commands (such as sharing RAS, CAS, CS) to all 8 chips simultaneously. However, the first chip is connected to the SoC's DQ0~DQ7, the second to DQ8~DQ15, and so on, up to the eighth chip connected to DQ56~DQ63. When the controller issues a read command, all 8 chips output data simultaneously, forming a unified 64-bit data stream on the bus. !image.png > Of course, on consumer electronics and smart hardware mainboards, embedded applications do not require exceptionally high memory bandwidth. Since more physical pins mean larger chip packages, increased PCB layout complexity, and higher power consumption, chip manufacturers tailor their SoC designs to the application's actual bandwidth needs. Instead of directly adopting the 64-bit data width common in PCs, they more frequently use 32-bit or even 16-bit widths. LPDDR, conversely, adopts a completely different design architecture for its data transmission channels. To maintain high bandwidth under low power consumption, it employs a multi-channel, narrow-width architecture. For example, a single LPDDR4 chip typically consists of two independent 16-bit channels (32-bit total). As shown in the figure below, the interior of an LPDDR4 chip is split into two completely separate channels. This allows the memory controller, within the same clock cycle, to have Channel A respond to an NPU read request while Channel B responds to a CPU write request, achieving superior concurrency. !image.png This architecture allows the SoC to schedule memory more flexibly, reducing the power overhead associated with waking up the entire memory chip. For instance, if the current system load is light, the SoC can put Channel B into a deep sleep state (such as Self-Refresh or Power Down) while keeping only Channel A active. LPDDR Initialization Timing Issues As summarized in the article How Do PSRAM and LPDDR Reduce Power Consumption?, LPDDR eliminates the internal DLL (Delay-Locked Loop) module to save power. To resolve high-frequency clock signal alignment issues without an internal DLL, it requires the host SoC's memory controller to perform active phase measurement and compensation via software algorithms inside the SoC's LPDDR controller during system boot. - For a pure DDR controller: The controller assumes the target memory chip has an internal DLL. Thus, after sending basic reset and Mode Register Set (MRS) configurations during the bootloader stage, it naturally assumes that clock alignment has been established inside the DDR chip and immediately begins high-speed data transceiver operations. - For LPDDR: Because LPDDR lacks an internal DLL, every time it powers up, it must wait for the SoC's LPDDR controller to execute a complex Link Training algorithm. The SoC must actively probe the clock signal propagation delay and apply phase compensation. A pure DDR controller does not implement these complex Link Training algorithms at all (since standard DDR does not require them). Consequently, if you connect an LPDDR chip to a standard DDR controller, the handshake phase will fail, and the system will hang during the memory initialization phase. Different Power Delivery Networks and Power Management Mechanisms DDR and LPDDR are completely incompatible in terms of hardware Power Tree design. Standard DDR typically requires fewer power rails (e.g., VDD, VPP). LPDDR, for aggressive power savings, generally requires multiple low-voltage rails (e.g., VDD1, VDD2, VDDQ), and these voltages are usually significantly lower than those of contemporary standard DDR. To achieve highly granular power management, the LPDDR specification integrates extremely complex internal power state machines. It supports advanced low-power features such as Deep Power Down and Partial Array Self-Refresh (PASR). These features require the SoC to control them via specific protocols, which standard DDR does not support. Why Do Some SoCs Support Both DDR and LPDDR? Based on the differences between DDR and LPDDR summarized across these various dimensions, we can conclude that the two are indeed mutually exclusive and entirely non-interchangeable. However, we do see in some SoC datasheets (such as the Rockchip processors shown below) that they can support both DDR and LPDDR memory chips. Why is this the case? !image.png This is because chip manufacturers, in order to support a wider selection of memory components for diverse industry applications, integrate expensive and complex Combo DDR Controllers & PHYs (compatible memory controllers and physical layers) inside the SoC. To enable a single SoC to support both DDR and LPDDR—which have vastly different physical characteristics—the internal Combo design must implement specialized logic in at least three key areas: - Logical Control Layer: The DDR memory controller inside the SoC is no longer hard-wired. Instead, it contains two complete protocol state machines, allowing it to be configured for either DDR or LPDDR modes. - Physical Interface Layer (PHY): To accommodate two completely different electrical standards, the I/O pads behind the external data (DQ) and control pins on the SoC must be designed with highly complex combinational circuitry. They must integrate both high-voltage, high-drive transistors for standard DDR (corresponding to SSTL signaling, such as 1.2V) and low-voltage, micro-drive transistors for LPDDR (corresponding to LVSTL signaling, such as 0.6V). - Pin Mapping: Since their pin definitions are entirely different, the SoC utilizes a pin "superset" alongside internal multiplexing (MUX) to route connections to external DDR or LPDDR chips using the same physical pins. The SoC's package provides a pin count matching the more demanding standard (usually standard DDR) while using internal multiplexers to remap the functionality of specific pins (such as the CA bus) based on the active mode. It is worth noting that while an SoC's memory subsystem can support both DDR and LPDDR through these methods, in actual product design, once the memory chip selection is finalized, the Combo PHY and PCB layout must commit exclusively to either DDR or LPDDR. Therefore, if LPDDR4 is selected during the schematic design phase, unused pins must be left floating, the motherboard's power tree must be designed to supply multi-rail power (e.g., 1.1V/0.6V), and the BootROM configuration pins must be strapped high or low to set the host's DDR controller to LPDDR4 mode. Once the physical hardware is manufactured, it is absolutely impossible to switch back to DDR4 via a software or firmware update. References - ddr - lpddr2 interface differences between different memory controllers? - Electrical Engineering Stack Exchange - Rockchip SoC Platform DDR Adaptation Acceleration! Issue 15: RK3588/RK3588S: LP4/4X, LP5...
A Beginner's Guide to NFC Technology
NFC (Near Field Communication) is a high-frequency RFID (Radio Frequency Identification) technology widely used in today's consumer electronics. This article provides a comprehensive summary of the foundational theory and application knowledge associated with this technology, helping to establish a basic understanding of NFC. NFC Technology Basics and Comparison with RFID NFC technical specifications operate in the globally unlicensed 13.56 MHz frequency band. Unlike Bluetooth or Wi-Fi, which communicate by actively emitting electromagnetic waves (far-field radiation), NFC relies on inductive coupling (near-field principle) to exchange information. > Inductive coupling can be thought of as an air-core transformer. During communication, the antenna coil of the reader (initiator/master device) generates an alternating magnetic field. When a tag (target/slave device) is brought close, its antenna coil induces a current. This process not only transmits data but can also supply power to passive tags. !image.png Looking solely at the working principle of inductive coupling, one might find that NFC technology is virtually identical to ordinary RFID as well as the communication technologies used in automotive keyless systems like RKE/PEPS. So, specifically, what makes NFC unique in its applications? The following table compares the technical specifications and application fields of these three technologies: !f85c44ab-817f-4e3c-ba85-3c6c3e291820.png Specifically, the main differences are: - NFC operates exclusively in the 13.56 MHz band, whereas the other two have multiple frequency bands available. - NFC is designed for a communication distance of less than 10 cm (in actual products, this is typically restricted to 1–3 cm to pass certifications). This extremely short range serves as an intentional physical security barrier, ensuring that every data exchange requires a deliberate, subjective physical touch ("Tap") by the user, thereby preventing malicious long-range eavesdropping. In contrast, traditional RFID and automotive PEPS systems generally have communication ranges of dozens of meters. - NFC offers more flexible operating modes, supporting three distinct operating modes and role-switching during communication. Traditional RFID and automotive PEPS systems, on the other hand, maintain a static relationship between a fixed reader and tag (i.e., transmitter and receiver). - The core value of NFC lies in its ability to transmit rich text data, whereas the tags in the other two technologies typically only store a very simple UID (Unique Identifier) or a few encrypted keys used solely for identity verification. NFC System Architecture and Operating Modes In PCB-level designs for consumer electronics, a complete NFC RF front-end system typically comprises the following three core components: !image.png - NFC Controller (NFC Controller IC): This integrates an RF transceiver, modem, and protocol-processing microcontroller. The controller module typically communicates with the host controller (MCU/SoC) via an I2C or SPI interface. High-end NFC controllers feature built-in firmware that directly outputs the standard NCI (NFC Controller Interface) instruction set, significantly easing the burden of low-level driver development on the host. - EMC Filter and Antenna Matching Network: The signals output by NFC chips are square waves containing many harmonics. Therefore, during hardware debugging, an LC filter circuit (to filter out interference outside 13.56 MHz) and an impedance-matching network must be designed between the chip's Tx/Rx pins and the antenna. This ensures conjugate matching between the chip's output impedance and the antenna's impedance, achieving maximum power transfer efficiency. - NFC Antenna: This is usually an inductive coil with a few turns. In consumer electronics, the antenna can be a PCB trace (lowest cost but occupies a large area), an FPC (flexible printed circuit, often adhered to the inside of the device housing), or a customized ferrite-backed wire-wound antenna (suitable for metal environments). Modern full-featured NFC chips (such as the PN7160 or ST25R3916) feature a symmetric internal RF architecture, meaning they contain both transmission (Tx) and reception (Rx) paths. During communication, the chip uses low-level switch matrices and state machines to dynamically assume initiator (master) or target (slave) roles. The RF pins of these full-featured NFC chips typically interface with two sets of RF paths: - Tx Path (Transmitter): This contains an internal Power Amplifier (PA) powered by VDD_PA. Its job is to drive the external LC resonant antenna, radiating an alternating 13.56 MHz magnetic field. - Rx Path (Receiver): This includes a highly sensitive detector and demodulator inside, responsible for monitoring minute voltage amplitude changes or phase shifts on the antenna. Thus, if the NFC chip in a product is a full-featured chip, it means its physical RF architecture is complete, capable of both transmitting (generating a field) and receiving (sensing a field). Conversely, passive NFC tags (such as consumable stickers) have a pared-down hardware architecture. They lack an internally powered Tx PA, containing only an antenna coil, a rectifier circuit (to harvest power from the magnetic field), and an electronic switch to modulate their own impedance—essentially having only Rx capabilities. The Three Communication Modes of NFC In system development, NFC supports three standard operating modes: !image.png - Reader/Writer Mode: The most common mode. The device actively generates a magnetic field to read from or write to a passive NFC tag or smart card. In this mode, the local device's NFC chip enables its internal PA, continuously pumping energy through the Tx pin to the antenna to generate a stable 13.56 MHz magnetic field. Throughout the subsequent communication, even when reading data, the device must maintain an active Tx magnetic field. - Card Emulation Mode: The device behaves like a standard contactless smart card (such as an access card, transit card, or bank card), with the magnetic field provided by an external reader (such as a turnstile). In this mode, the device's NFC chip completely turns off its Tx PA and no longer radiates energy, saving power. The turnstile's magnetic field induces a voltage on the card device's antenna. The energy harvesting pin (or a dedicated wake-up pin) on the NFC chip detects this field and wakes up the host controller. - Peer-to-Peer (P2P) Mode: Two active NFC devices establish a bidirectional communication channel to exchange data when brought close to each other. (Note that in modern consumer hardware, this mode is rarely used as the primary data transfer channel; it is mostly used for handshaking, such as bootstrapping a Wi-Fi connection). Both devices are full-featured NFC devices. When they get close, they negotiate their roles for subsequent communication through a handshake, establishing one as the Initiator and the other as the Target. The next question arises: _Given that the RF link design of full-featured NFC is symmetric and supports these three operating modes, how does a full-featured NFC device actively or passively choose which mode and role to operate in during runtime?_ The answer is: It relies on the NFC Discovery Loop and active configuration intervention by the host controller (MCU). For a full-featured NFC controller whose mode is not restricted by the host controller (MCU), it automatically runs a time-division-multiplexed state machine at the physical layer upon powering up into standby. This state machine is called the Discovery Loop. The basic operational logic is that this state machine switches frequently among three states: Poll, Listen, and Sleep—typically with a full cycle lasting a few hundred milliseconds. If it detects a passive tag while in the Poll state during this transition, it operates in Reader/Writer mode. If it detects an external reader/turnstile, it operates in Card Emulation mode. !b78ed372-8f4f-42a0-aac6-cd8a710780cf.png In practical product development, leaving all modes enabled to loop indefinitely is both power-inefficient and prone to unnecessary interaction conflicts. Usually, the application scenario for a product's NFC functionality is clear and predefined. Therefore, during system implementation, the host MCU's application should actively configure the routing table and discovery rules during system initialization based on business logic requirements, instead of letting the chip poll inefficiently in the background without restriction. - If the primary use case of the product's NFC functionality is to read passive NFC tags and there is no need for it to be read as a card by phones or turnstiles, the MCU can send NCI commands to the NFC chip to disable the Listen State and P2P mode. Consequently, the chip's Discovery Loop will only contain Poll and Sleep, turning it into a pure active reader/writer. - If the product's use case requires it to act both as a reader (reading a user's physical access card) and as a card (allowing a phone with NFC card-emulation to tap and open a door), then the complete Discovery Loop must be preserved. Regardless, in battery-powered electronic products, to achieve extreme power savings, the Poll state is typically replaced by LPCD (Low Power Card Detection). In the LPCD state, the device's transmitter (Tx) no longer sends full protocol packets. Instead, it emits an extremely short pulse field every few hundred milliseconds to detect whether the antenna's inductance has shifted slightly (since metal or an approaching card causes antenna detuning). If detuning is detected, the chip fully wakes up to execute the complete Poll process. Consequently, the chip only powers up to generate a full RF field when someone actually taps a card against the antenna, reducing standby power consumption from tens of milliamperes to the microampere range. What is the NCI Instruction Set? As mentioned above, some high-end NFC controllers run internal firmware that supports the standard NCI (NFC Controller Interface) instruction set. When configuring the NFC operating modes, the host MCU interacts with the NFC chip by sending NCI commands over hardware interfaces like I2C or SPI. So, what exactly is this NCI instruction set? Before the standardization of the NCI (NFC Controller Interface) instruction set, the low-level registers and control logic of different NFC chip manufacturers varied wildly. If software engineers wanted to switch to a different NFC chip, they had to rewrite almost the entire driver layer. To address this, the NFC Forum established the NCI standard, with the goal of completely abstracting away the complexities of low-level RF timing and physical links. Empowered by the NCI instruction set, the host processor only needs to send standardized NCI byte streams to the NFC chip via I2C or SPI. The chip then automatically handles complex tasks like RF wake-up, collision detection, and low-level protocol validation. Consequently, if you need to switch the NFC chip during product development, you only need to swap in another chip that supports the same NCI instruction set. The driver and application layers on the host side require virtually no changes. (Of course, in reality, things are rarely so ideal, as some manufacturers append proprietary custom commands to the NCI framework, requiring extra debugging.) The NCI specification strictly classifies packets transmitted over physical buses (such as I2C or SPI) into four types: - CMD (Command): Host (MCU/SoC) NFC chip. These are action instructions issued by the host. - RSP (Response): NFC chip Host. A synchronous response to a CMD. The chip must reply with an RSP within a very short time after receiving a CMD. - NTF (Notification): NFC chip Host. Asynchronous events actively reported by the chip. - DATA: Bidirectional. Pure payload pass-through for the application layer. Once a low-level connection is established, the actual data read from or written to the card/external device (such as NDEF rich text or URLs) is encapsulated in DATA packets. !image.png During the software development phase, the standardization of NCI offers immense convenience for team division of labor: - BSP / Driver Layer: Driver engineers do not need to understand any of the NFC protocol stack logic. They only need to bring up the I2C or SPI interface in Linux/RTOS and configure a GPIO interrupt pin (used to trigger an interrupt when the NFC chip sends an NTF notification to the host). In Linux, this typically manifests as a simple character device node (e.g., /dev/pn544 or a device registered via the I2C core layer). The sole purpose of this node is the transparent transmission of NCI byte streams. - Protocol Stack (Middleware): The parsing and assembly of NCI packets are handled by middleware. For instance, NXP provides the Linux-based libnfc-nci library. For Android systems, the AOSP source tree built-in system/nfc already contains a highly mature and comprehensive NCI protocol stack. - Linux Application Layer / Apps: Application developers can directly call high-level APIs exposed by the protocol stack/middleware, such as nfc_enable(), nfc_read_ndef(), and so on. MIFARE / FeliCa / ISO/IEC 14443 Before NFC standards were established, various semiconductor giants in the 13.56 MHz high-frequency RFID space proposed their own low-level modulation schemes and proprietary data formats. When the NFC Forum was later founded, its brilliance lay not in inventing a brand-new RF technology, but in offering backward compatibility with these proprietary solutions while unifying them at the higher layer into the standardized NDEF (NFC Data Exchange Format) data format. Within this domain, NFC provides backward-compatible support for five major technical streams: - MIFARE: Led by NXP, this is currently the world's most widely adopted contactless smart card technology. Its physical layer is primarily based on the ISO/IEC 14443 Type A RF standard. It is incredibly ubiquitous, used in residential access control cards, hotel key cards, transit cards, and disposable paper tickets/stickers. - FeliCa: A proprietary standard developed by Sony, corresponding to the Japanese Industrial Standard JIS X 6319-4. It is the dominant standard in Japan's Suica (watermelon card) and Hong Kong's Octopus card systems. - ISO/IEC 14443 Type B: During the creation of the 14443 standard, NXP championed Type A, whereas STMicroelectronics (ST), Motorola, and others jointly backed Type B, which is better suited for high-density cryptographic operations. China's second-generation resident ID cards, various contact/contactless bank cards (EMV standard), and e-passports almost exclusively adopt the Type B standard. - ISO/IEC 15693: Compared to the aforementioned technologies, this standard sacrifices communication speed to achieve a longer read/write range (up to dozens of centimeters) and supports rapid, simultaneous anti-collision reading of multiple tags. Typical applications include library self-checkout systems, contactless ski passes, and batch inventory of medical reagent kits. !image.png Facing such a diverse array of underlying chips for contactless cards, if Linux application or app development teams were to directly parse their low-level sectors or blocks during scanning, they would run into highly challenging compatibility issues. To resolve this, the NFC Forum defined five standard "NFC Tag Types" (Type 1 through Type 5), mapping the aforementioned physical hardware standards into clean abstractions. As long as the physical chip complies with one of these Types, the host controller will retrieve structured, standardized rich text data. The development team can then parse the standard payload directly at the cloud or app layer. This decouples the business logic layer from the physical card, seamlessly resolving compatibility issues across different card standards: - Type 1: Based on the legacy Innovision Topaz. - Type 2: Perfectly maps to MIFARE Ultralight and NXP NTAG series. - Type 3: Perfectly maps to Sony FeliCa. - Type 4: Maps to ISO 14443 A/B (covering DESFire and CPU cards). - Type 5: Maps to ISO 15693. References - https://www.cnblogs.com/bluestorm/p/17705366.html - https://www.sony.co.jp/en/Products/felica/NFC/forum.html - [NFC Principles] Learn this and you can become an NFC expert too!
Summary of Operating Temperatures and Calculation Procedures for Electronic Products, Chip Thermal Resistance, and Junction Temperature
Focusing on common thermal design issues in electronic products, this article provides a detailed compilation of temperature, thermal resistance, and other parameters provided in component datasheets, as well as the calculation process for internal junction temperature using these parameters. It establishes a theoretical foundation for subsequent hardware system design, chip selection, and thermal design parameter testing and estimation in electronic products. Temperature Parameters in Component Datasheets Generally speaking, during the design of consumer electronic products, the temperature- and thermal-design-related parameters we encounter in chip datasheets are primarily the chip operating ambient temperature and junction temperature . Here, (Ambient Temperature) refers to the temperature of the air immediately surrounding the casing of the chip (or device) during normal power-on operation. It is important to note that the device ambient operating temperature defined in the product PRD is entirely different from the ambient temperature in the chip datasheet. In fact, the ambient operating temperature defined in product specifications is usually the air temperature outside the product enclosure. However, once heat-generating SoCs, power supplies, and sensors are enclosed in a sealed plastic shell, the temperature inside the enclosure directly adjacent to the chips can be a dozen degrees Celsius or even higher than the outside air temperature due to the temperature-rise effect caused by the heat dissipation of all components on the circuit board during operation. The figure below illustrates the huge difference between the external ambient temperature and the internal ambient temperature of a device. For the chip itself, it naturally cares more about the internal ambient temperature: !59932155-22a6-4ad0-9589-2937dbbb5cdf.png Meanwhile, (Junction Temperature) refers to the physical operating temperature of the PN junction (transistors; the junction temperature is actually the temperature of the PN junction) where heat is generated on the actual silicon die inside the semiconductor chip. Junction temperature is the fundamental standard for all thermal design in electronic products. Whether a chip can operate stably, its lifespan, and whether it will burn out are entirely determined by . As long as does not exceed the limit, how harsh the external environment is does not matter. Of course, because the PN junction is inside the chip, we cannot directly measure the internal junction temperature. In addition to the aforementioned ambient temperature and junction temperature , temperature-related parameters included in datasheets also comprise: - (Case Temperature): The temperature at the exact center of the surface of the chip package housing. Some chip datasheets explicitly specify the maximum case temperature () for the chip package. This simplifies thermal design, as we no longer need to back-calculate the junction temperature; we simply need to ensure that the temperature at the center surface of the chip package is lower than this parameter. However, the datasheets of the vast majority of chips do not provide this , supplying only a maximum junction temperature limit. - Storage Temperature: The temperature range within which a chip can be safely stored for long periods in a powered-off state. This temperature range is usually very wide, typically ranging from -65°C to +150°C for consumer-grade chips. This parameter is primarily intended for the supply chain and logistics sectors. During the logistics and transportation of chips and products, as long as the upper limit of the storage temperature is not exceeded, the chip packaging materials will not undergo irreversible physical expansion and cracking, and their internal bonding wires will not break. - Soldering/Reflow Temperature: The peak limit temperature and duration that a chip can withstand when passing through a reflow oven during SMT (Surface Mount Technology) processes. A typical parameter is usually 260°C for 10 seconds (compliant with the lead-free RoHS standard). This parameter is mainly for factory process engineers (PE), and the reflow oven temperature profile during production and soldering should be set according to this parameter. Several Easily Confused Thermal Resistance Parameters Apart from the general temperature parameters above, most thermal-design-sensitive chip datasheets often provide several thermal-resistance-related parameters to help developers accurately calculate power consumption and thermal data during design and testing. (Junction-to-Ambient Thermal Resistance): This parameter corresponds to the total thermal resistance from heat generated at the die PN junction area, passing through the package and PCB, and finally dissipating into the surrounding air. While it might seem that this parameter allows easy calculation of the junction temperature from the chip surface temperature, this value is measured by the manufacturer on a JEDEC standard test board with a huge area and no enclosure obstruction, placed in a 1-cubic-meter sealed, windless static pressure chamber. In contrast, our products typically have narrow internal spaces with mutual superposition from other heat sources, resulting in a completely different thermal environment. Therefore, if this value is directly applied in engineering calculations, the calculated junction temperature will have significant errors. (Junction-to-Case (top) Thermal Resistance): This parameter purely describes the physical resistance of heat traveling vertically upward from the junction area through the package lid to the topmost surface. Its calculation formula is: Here, is only the heat dissipated upward through the top package into the chip's interior. The problem is that we can only accurately calculate the total power consumption of the entire chip; it is impossible to estimate what proportion of the overall power consumption dissipates upward. Therefore, this parameter is not very practical in actual calculations. and (Junction-to-Board Thermal Resistance / Junction-to-Bottom Die Thermal Resistance): Complementary to , these parameters describe the physical resistance of heat conducting downward through the silicon substrate to the PCB or the bottom of the package. The same issue applies here: we cannot accurately estimate what proportion of the chip's power consumption dissipates downward. (Junction-to-Top Characterization Parameter): This parameter represents the ratio of the difference between the junction temperature and the package center surface temperature to the total input power of the chip in a standard natural convection test environment. Its calculation formula is: Compared to , refers to the complete power consumption of the entire chip, which can be measured very accurately using an oscilloscope or multimeter. Therefore, using the parameter along with the measured temperature at the center point of the chip surface to calculate the junction temperature provides a more accurate reflection of the actual internal junction temperature of the chip. !image.png (Junction-to-Board Characterization Parameter): Corresponding conceptually to , this is the ratio of the difference between the junction temperature and the temperature of the PCB copper trace 1 mm away from the edge of the chip to the total power consumption of the chip. This parameter can be used to calculate the internal junction temperature of the chip by measuring the temperature of the copper trace at the bottom edge of the chip (in certain scenarios, such as with sensor modules). In summary, parameters with the symbol (such as and ) are not very practical for actual junction temperature calculations. This is mainly because the total heat (total power consumption ) generated during chip operation splits into multiple paths: a portion of the heat conducts downward through the pins and solder balls to the PCB copper traces (), while the remaining heat travels upward through the plastic molding compound into the air or enclosure (). The problem is that we fundamentally cannot accurately measure what proportion of the power consumption goes upward. Therefore, even if the manufacturer provides a precise , we cannot accurately calculate the true junction temperature . Ideal Temperature Calculation Theory and Workflow So, in engineering practice, how do we verify through testing and calculation whether the current design meets the temperature requirements of the project and product? As mentioned above, the internal junction temperature of the chip is the fundamental standard for evaluating product thermal design. As long as the junction temperature obtained through testing and calculation complies with the junction temperature requirements in the chip datasheet, the product is considered acceptable from a design perspective. The calculation and evaluation of the chip's internal junction temperature generally fall into the following three scenarios. Scenario 1: The chip datasheet provides the temperature parameter at the exact center of the chip package surface. Because the dies inside the vast majority of chips are mounted in the center, the heat-generating core is located directly underneath the center of the package. Heat conducts upward in an inverted funnel shape, meaning the exact center of the package surface is the hottest spot on the entire accessible enclosure. In this scenario, there is no need to use complex thermal characterization parameters () or back-calculate the junction temperature (). We can directly measure the center temperature of the chip surface using a thermocouple and simply compare the test value against the threshold defined in the chip datasheet. Therefore, when the parameter is provided in the chip datasheet, this is the favorite and most efficient evaluation method for hardware and mechanical engineers in actual work. However, the industry reality is: for the vast majority of consumer-grade or security-grade SoCs and image sensors, their datasheets will almost certainly not provide , but will only provide or . Scenario 2: During the initial design phase of many complex, large-scale chips, a thermal diode is often etched directly into the heat-generating core area (such as beside the CPU/NPU cluster) for self-protection, enabling measurement of its internal junction temperature. For example, some master SoCs typically feature an internal TSADC (Temperature Sensor), allowing the core junction temperature to be obtained in real-time directly by software reading registers or sysfs nodes under Linux (e.g., /sys/class/thermal/thermal_zone*/temp). Junction temperatures read in this manner are also the most accurate. While this method is the most accurate, it is often unfeasible for most low-cost consumer electronics chips, as the vast majority of consumer-grade chips do not have built-in temperature sensors. When neither of the first two scenarios is achievable, measuring the temperature of the chip's external surface with a thermocouple and then back-calculating the internal junction temperature using thermal resistance parameters becomes the standard practice and workflow for hardware and thermal design engineers. The most critical calculation formula for this workflow is: Where: - (Junction Temperature): The target junction temperature we need to calculate. - (Case Temperature): The center temperature of the surface directly above the chip package. - (Power): The current actual operating power consumption of the chip (in Watts). - (Psi-JT, Junction-to-Top Characterization Parameter): The thermal characterization parameter from the junction to the top of the package (in °C/W). The laboratory operating steps for the above method are as follows: 1. First, measure (the center temperature of the chip surface): It is recommended to use a K-type thermocouple (36 AWG or finer is advised) with high-thermal-conductivity adhesive to securely attach the thermocouple to the exact center of the chip package surface. Next, place the complete device in a temperature and humidity chamber, set the maximum ambient temperature defined by the product PRD for a burn-in test, and once the temperature curve stabilizes, read via a data logger. 2. Measure the corresponding dynamic power consumption of the chip: Under high-temperature environments, semiconductor leakage current increases, leading to higher power consumption. Therefore, nominal power consumption from the datasheet cannot be used directly. Instead, an oscilloscope or high-precision multimeter must be used to measure the actual current and voltage of each sensor power rail (AVDD, DOVDD, DVDD) under high-temperature full-load operation to calculate the true total power consumption . 3. Calculate using the formula above: Substitute the measured , actual power consumption , and the manufacturer-provided into the formula to accurately derive the internal junction temperature under the current environment. Taking TI's 3D ToF Sensor OTP8241 as an example to illustrate the calculation process above, the sensor's parameter is 6.3 °C/W: !649c01a3-5675-44b4-91d3-e56c3e45ee5d.png Assuming an extreme burn-in test is conducted in a 70°C chamber, and a thermocouple measures that the temperature at the center of the sensor package surface reaches 85 °C, with an oscilloscope measuring the total power consumption of all power rails at the current frame rate under full load to be 1.2 W, then the true internal junction temperature undergoing stress is: The above outlines the calculation workflow under ideal conditions for relatively accurate testing, estimation, and final evaluation of the thermal design stability and rationality of a product. However, in real-world product design, for many consumer-grade or security-grade low-cost/low-price SoCs and image sensors, original manufacturers often perform only basic high- and low-temperature operating range tests during R&D finalization (such as calibrating the limit operating junction temperature between -30°C and 85°C) and do not strictly follow JEDEC standards to issue a complete 3D thermal resistance matrix (, , ). Therefore, in the datasheets of such low-cost consumer chips, the parameter cannot be found at all, making it impossible to precisely calculate the internal junction temperature using the workflow and formula above. In this case, we can only resort to estimation methods to roughly evaluate whether the design is reasonable and meets requirements. Estimation During Real-World Design As mentioned above, if the chip datasheet does not provide an accurate parameter, we fundamentally have no way to precisely calculate the junction temperature. In such cases, we can only use empirical estimations to roughly evaluate the rationality and risk factor of the entire product's thermal design. In actual product engineering design, the most commonly used method is to use the measurable chip surface temperature to roughly estimate the corresponding junction temperature . How to relatively accurately estimate using is closely related to the packaging type adopted by the chip. FCBGA / Bare Die: These packages are mainly created for high computing power and high heat generation. The silicon die is flip-chipped onto the substrate inside the package, so its heat-generating core directly faces the metal thermal packaging lid on top or is completely exposed. In this scenario, the heat from the chip's internal PN junction dissipates strictly upward. The empirical value of is 0.1 to 1.0 °C/W, meaning the chip's internal junction temperature is nearly equal to the surface temperature . QFN / DFN / ePAD-SOIC: These packages feature a bare copper metal pad at the bottom of the chip, which is soldered directly to the PCB ground plane. They are commonly found in Power Management Integrated Circuits (PMICs), motor drivers, and high-power audio amplifiers. Consequently, their heat dissipation direction is strictly downward. However, because the top plastic molding material of this type of package is usually very thin and the physical distance from the silicon die to the top is extremely short, its upward remains very small. The empirical value for is 0.5 to 4.0 °C/W. QFP / LQFP / TQFP: These packages have gull-wing leads on all four sides, and the black plastic body is relatively large and has a certain thickness. Most conventional MCUs (microcontrollers) and interface control chips (such as USB/Ethernet PHY) typically use this package. Heat dissipates in all directions: part goes downward through the leads, and part dissipates upward through the plastic casing. The empirical value for generally ranges between 2.0 and 8.0 °C/W. SOIC / TSSOP: These packages have leads on both sides, and the package volume appears relatively thick and heavy compared to the extremely tiny internal die. They are commonly found in conventional logic gate circuits, operational amplifiers, audio ADCs/DACs, or basic low-current analog chips. Heat dissipation occurs primarily through lead conduction. Therefore, for this type of package, the ultra-high thermal resistance of the plastic casing itself acts as an obstruction, causing the surface temperature to be much lower than the internal . The empirical value for is generally between 5.0 and 15.0 °C/W. Fortunately, such chips typically have extremely low power consumption (milliwatt level) and generally do not face severe thermal crises. References - Thermal Resistance Data: Definitions of Thermal Resistance, Thermal Characterization Parameters | About Thermal Design | TechWeb
How to Understand and Apply the AI-DLC Development Methodology?
When using AI development tools like Claude Code, Trae, or Cursor, many developers often fall into the trap of casual coding (so-called Vibe Coding): whatever comes to mind, write a simple prompt and let the AI write the code. While this approach is highly efficient for writing simple applications or script files, it quickly leads to codebase clutter, loss of context, and exorbitant maintenance costs when facing more complex, medium-to-large-scale projects. To address these challenges, AWS proposed and open-sourced a core methodology in early 2025: AI-DLC (AI-Driven Development Life Cycle). The Concept of AI-DLC In traditional software development workflows, the overall framework of the development process is primarily driven by humans. Product owners, developers, and architects spend a significant portion of their time on non-core activities such as planning, meetings, and other aspects of the SDLC (Software Development Life Cycle). With the rise of Generative AI technology, the technology and quality of AGI tools in understanding semantics, reading, and writing code have advanced by leaps and bounds. However, if AI is merely treated as a localized development tool to assist with auto-completion and code generation, it fails to unleash its powerful semantic understanding and generative capabilities. Furthermore, it easily falls into a localized dilemma, unable to meet the development demands of medium-to-large-scale projects. In response, AWS proposed a methodology to reconstruct the entire software development process and responsibilities for the AI era: AI-DLC. The core idea of this methodology is: In the software development lifecycle, redefine the cooperative relationship between humans and AI, where humans codify the judgment and make decisions, and AI orchestrates, executes, and self-verifies (Humans codify the judgement. AI orchestrates and self-verifies). You can intuitively understand the paradigm shift of software development workflows in the AI era through the comparison table below: !AI_DLC_Comparison_Table.png The overall logic of AI-DLC can be understood from the following two dimensions: - AI-driven execution workflow under human supervision: For specific development requirements, the AI systematically creates detailed work plans and processes, actively seeks clarification and guidance during collaboration with humans, and leaves critical decision-making steps to human judgment. This is crucial because only humans possess the contextual understanding and business requirement knowledge needed to make informed choices. AI tools must operate within a framework guided and judged by humans rather than acting arbitrarily. Once requirements are clarified and the execution plan is confirmed, the subsequent execution process is entirely completed by AI tools, with humans providing side supervision. - Dynamic teamwork: During the execution of tasks based on established plans, the team consisting of humans and AI unites within a collaborative space to solve problems in real-time, engage in creative thinking, and make rapid decisions. This shift from isolated work to high-energy teamwork accelerates innovation and delivery. The Workflow of AI-DLC Overall, the AI-DLC development philosophy operates according to the following workflow: The AI is responsible for formulating a work plan based on project requirements. During the planning process, it raises clear questions regarding ambiguities in requirements and technical solutions to seek further context and background information. The final technical execution plan and action plan are then implemented and executed after receiving human validation. !image.png Following the overall philosophy and workflow outlined above, AI-DLC does not let AI start writing code immediately after receiving requirements; instead, it forces AI Agents to follow a rigorous engineering stages framework. It divides the development process into the following three core phases. Phase 1: Inception This phase is responsible for clarifying requirements, formulating plans, and defining execution steps—addressing the questions of "what to build" and "why build it." Tasks to be performed in this phase include: - Workspace Detection & Reverse Engineering: The AI first scans the existing codebase to understand the current architecture, technology stack, and existing business logic code. - Requirements Analysis & User Stories: The AI clarifies ambiguous requirements by asking questions and receiving clear answers, breaking them down into standard User Stories. - Application Design & Workflow Planning: After determining the overall system design architecture, the AI is responsible for breaking down large tasks into independent "Units" that can be executed in parallel or sequentially. Phase 2: Construction In this phase, the AI begins processing the Units one by one according to the plan established in the Inception phase. For each unit, the AI cyclically executes the following steps: - Detailed Design: Includes functional design (code logic), non-functional design (security and performance considerations), and infrastructure design. - Code Generation & Test-Driven Development: AI-DLC strongly mandates that code and test cases must be generated synchronously. Adopting a test-driven development model can effectively enhance development quality control. - Self-Building & Verification: The AI attempts to run the build and execute test cases by itself. If errors occur, it self-heals based on the error logs. Phase 3: Operations This step involves post-development deployment, operations, monitoring, and maintenance. It primarily includes code deployment, continuous integration, and post-launch monitoring. The AI similarly assists in troubleshooting logs, generating operations reports, and performing continuous optimization within this workflow. In fact, each of the above phases provides richer background and context for the execution of the next phase, enabling the AI to provide increasingly wise suggestions and execution outcomes. !image.png Comparison Between the AI-DLC Philosophy and Latest AI Development Tools Based on studying the AWS AI-DLC development philosophy whitepaper and its related technical documents, the theoretical knowledge related to this development process and philosophy has been organized above. However, looking back from today's perspective (June 2026), you will find that the concept of AI-DLC is actually nothing extraordinary. This is because most mainstream AI development tools we use today (such as Antigravity 2.0, Claude Code, Codex, etc.) have naturally embedded and enforced the core development workflows and rules described above within their underlying architecture designs. For example, when using Google's Antigravity 2.0 for software development, if I propose a development requirement in a project, Antigravity 2.0 will first analyze my requirement before modifying any code, raise questions to confirm any ambiguities, and generate an implementation plan document. Once I confirm this execution plan, Antigravity 2.0 begins execution, requesting permissions and confirming intermediate steps when necessary during the execution process, and finally summarizes the complete execution process through a walk-through document after development is completed. Therefore, this automated process already perfectly covers the AI-DLC development philosophy—and this is merely an out-of-the-box feature of tools like Antigravity. However, back in March 2025, when mainstream AI development tools were still unable to handle medium-to-large-scale project development, the proposal of AI-DLC still held significant value and application prospects. The breakthroughs in the capabilities of AI software development tools to handle medium-to-large-scale projects in the second half of 2025 happened because the entire AI software engineering community, having learned lessons from 2023–2024 regarding unorganized prompts and blind coding leading to context collapse, collectively converged on using more standardized, process-oriented approaches to improve AI code quality. Below is a mapping and comparison between the AI-DLC development philosophy and current Antigravity 2.0 implementations: !AIDLC_Workflow_Mapping_20260612.png The Value of the AI-DLC Philosophy Looking at it today in 2026, as AI development tools have become increasingly advanced and standardized, does AI-DLC and its associated development rules and workflows still hold value? I believe that regardless of how development tools evolve, such development rules still deserve attention in at least the following two aspects. Unified Team Development Rules and Standards In team development, different developers have their own preferences for development tools—some are used to Trae, some use Claude Code, and others stick to Cursor. Differences in the underlying behaviors of various tools can lead to uneven quality in team-developed code. Therefore, we can define explicit rules common within the team, such as aidlc-workflows (like .cursorrules or global system prompts), to standardize AI behavior across tools within the team. No matter what tool a developer uses, as long as this unified set of development rules (Rules) is loaded, the AI will be forced to write design documents and unit tests first, thereby achieving standardization in engineering quality. !90409f5b-722a-4711-929e-c413f8e3f01e.png Rules Can Handle More Complex Multi-Agent Collaborative Scenarios Even today, development tools like Antigravity 2.0 still lean towards scenarios where a single powerful Agent solves a specific issue. However, when we face ultra-large-scale project development and refactoring, we often need Product Agents, Architecture Agents, Coding Agents, and Testing Agents to work collaboratively. The Adaptive Workflow Steering proposed by AWS is essentially a theoretical framework built for future Multi-Agent Orchestration, where different Agents correspond to their own Rules, aligning their workflows more closely with the requirements of their role definitions, thereby enhancing the development quality of each individual Agent. References - AI-Driven Development Life Cycle: Reimagining Software Engineering | AWS DevOps & Developer Productivity Blog
Summary of Learning Amazon AWS CloudFront Service
Workflow of CloudFront Amazon CloudFront Service is positioned as AWS's global Content Delivery Network (CDN) service (currently generally available/GA across all AWS Regions). Its core function is to cache static resources and accelerate the transmission and distribution of both static and dynamic content through AWS's globally deployed backbone network. The underlying network of CloudFront Service is based on hundreds of POPs (Edge Locations) deployed by AWS worldwide. In this scenario, when a user or device initiates a network request, traffic is routed by AWS Anycast to the physically closest node, significantly accelerating the transmission of static and dynamic content. The following flowchart illustrates the workflow of CloudFront Service by taking the example of downloading a file from an S3 Bucket in the AWS Tokyo Region via CloudFront Service. Every time an end-user initiates a request to the CloudFront URL, the request is first routed by AWS Anycast to the CloudFront network node closest to the request initiator. CloudFront then checks for a cache hit (i.e., whether CloudFront's own cache contains the static resource file required by the request): - On a cache hit—meaning the CloudFront cache contains the requested file—it jumps directly to step four to return the file to the end-user. - On a cache miss, CloudFront makes an origin request to the bucket deployed in the S3 Tokyo station via AWS's globally deployed backbone network, reads the file from the S3 Bucket into CloudFront's cache, returns the file to the end-user, and simultaneously stores it in the CloudFront cache. This ensures that subsequent visits will result in cache hits, returning the file directly to the end-user from the cache. !35808f53-88a2-425a-b6a0-4085d1b8d8ff.png As can be seen from the above workflow, the primary function of CloudFront as AWS's CDN service is to enable global network acceleration and distribution for static resource files (especially hot resources). Hot resources receive a high volume of requests in a short period. Using a CDN service leverages cache servers distributed across different geographical nodes to rapidly distribute resources to user terminals closest to them. This not only effectively improves the user experience but also avoids the stability issues and network routing inefficiencies caused by all user requests concentrating on a single node. Even for dynamic resources that result in cache misses, because the communication between the CDN cache servers (CloudFront) and the origin servers where dynamic resources are actually stored (such as the S3 Bucket in the Tokyo Region mentioned above) traverses AWS's internal backbone network, response speeds for user requests are still significantly improved compared to users accessing the origin server directly. How Does CloudFront Manage Caches? CloudFront does not limit the size of a single file (object) stored at its edge locations, meaning it can cache everything from a few KB of script files to tens of GB of software installation packages. AWS has multiple edge locations deployed worldwide, each with specific hardware storage capacity limits. Naturally, CloudFront cannot keep previously accessed cache files in its cache servers indefinitely. Generally speaking, CloudFront uses the Least Recently Used (LRU) algorithm to dynamically manage the files stored in its cache servers. If a file is stored at an edge location for a long time and is rarely accessed, it may be deleted when current storage space becomes insufficient to free up space. In this case, the next new request for this file will be forwarded back to the origin server to request the data. Of course, besides the LRU algorithm mentioned above, cache invalidation is also related to the file's own TTL (Time to Live) lifecycle duration. Cache Time Limit (TTL) The validity period of a file in the CloudFront cache can also be set via the origin station's TTL parameters. By default, CloudFront respects the HTTP caching header parameters returned by the origin station (such as S3, EC2, or API Gateway), namely Cache-Control: max-age= and Expires: , to set the file's validity period in the cache. Therefore, if we have specific requirements for the time validity of files, we can configure these headers in the origin server configuration or S3 object metadata to more precisely control the caching duration of each file. High TTL (Long Cache Time): - Pros: Increases the cache hit ratio. A longer retention time of files at edge locations means that when users request them, they are more likely to be served directly from the edge location, drastically reducing origin requests and cutting down data transfer costs from the origin to CloudFront. - Cons: Content updates more slowly, and users may request outdated files. Therefore, if there are high requirements for the lifecycle of the files themselves, a excessively high TTL should not be set. Low TTL (Short Cache Time) or 0 TTL (No Caching): - Pros: The content of the data files obtained with every request is always the most up-to-date. - Cons (More Expensive): Decreases the cache hit ratio, leading a large volume of user requests to hit the origin server for data, which increases request volume and costs. Therefore, whether to set a high or low TTL parameter depends on the design requirements of your files and application: if the timeliness requirements for data file contents are relatively high, a low TTL should be chosen, at the cost of higher expenses; otherwise, a high TTL setting should be used to minimize origin request counts as much as possible. CloudFront Pricing Model Below is a comparison of how adding CloudFront impacts cloud service usage costs, based on a typical application of downloading files from S3. Overall, for the workflow of downloading files from S3, the components related to cloud service usage costs primarily include: Storage, Data Transfer Out, and Requests (API/HTTP). - Storage: Refers to static object storage fees on S3, billed based on the amount of data stored in S3 (GB/month). Standard storage class first 50 TB: 0.09 / GB. - For the CloudFront download model, it is billed by region + tier. The cost in North America/Europe environments is 0.0004 / 1,000 requests. - Under the CloudFront model, on a cache miss, the API requests made from CloudFront to S3 incur the same fees as above. Therefore, this cost is correlated with the cache hit ratio. Under a high hit ratio, this cost approaches 0. - CF HTTP/HTTPS Request Fees: Billed based on the number of requests sent by users to CloudFront edge nodes. HTTPS requests in North America cost 0.0004 / 1,000 requests. - Downloads via CloudFront involve two parts: first, the CloudFront API request fees initiated by users at a rate of 15 as an example, the free allowances included in this package are: - Outbound Data Transfer: Up to 50 TB, which is valued at approximately $4,000+ under the traditional on-demand model. - Access Request Count: 10,000,000 requests (10 million). - Value-Added Security (Included for Free): AWS WAF (Web Application Firewall) is mandatory and included, featuring 25 built-in rules and DDoS protection. - S3 Storage Credit: An additional 50 GB of Amazon S3 Standard storage allowance is granted each month. !ae7f5972-7413-4337-8b34-9eb8adfd1f54.png Powered by this flat-rate pricing plan, the cost of using CloudFront will be substantially reduced. Below is a cost comparison among three scenarios—accessing S3 directly, accessing S3 via CloudFront (standard pricing model), and accessing S3 via CloudFront (flat-rate pricing model)—assuming an S3 storage capacity of 1 TB, monthly outbound traffic of 10 TB, 10 million requests, and a 90% cache hit ratio: !21d886b9-5247-41e0-b905-17fc1aed910a.png References - https://aws.amazon.com/cn/s3/pricing/ - Amazon CloudFront CDN — Plans and Pricing — Free Trial - CloudFront Flat-Rate Pricing Plan - Amazon CloudFront
Summary of Calculation Workflows for Model FP16 and INT8 Quantization
This article provides a comprehensive summary of the concepts and calculation workflows for half-precision floating-point conversion (FP16) and fixed-point quantization (INT8) applied to models trained in frameworks like PyTorch. PyTorch Model Training and Storage Format In mainstream deep learning frameworks such as PyTorch and TensorFlow, the default tensor data type used is FP32 (32-bit floating-point). Therefore, when we define a convolutional layer (nn.Conv2d) or a linear layer (nn.Linear) in PyTorch, the randomly initialized weights, biases, and the activations generated during the forward pass all occupy 32 bits (i.e., 4 bytes, FP32) of memory space by default. When model training is completed in PyTorch, we use torch.save() to save the model file to the local disk. Because the default tensor dtype during training is FP32, models saved through this standard workflow are also in FP32 format. However, why are the official YOLO pretrained model files downloaded from Ultralytics FP16 in size and internal parameters rather than FP32? This is because the official YOLO pretrained model files provided by Ultralytics (such as yolov8n.pt or yolov5s.pt) are forcibly converted to FP16 format before release. The core purpose of this is to significantly save transmission bandwidth and storage space. Once model training is complete, Ultralytics invokes a classic internal post-processing function: strip_optimizer(). This function calls the model's .half() method to convert all its weights into 16-bit half-precision floating-point (FP16) format. The general workflow is as follows: Calculation Process of FP16 Half-Precision Conversion Strictly speaking, converting the storage format of model parameters from FP32 to FP16 is called type casting / downcasting, rather than quantization in the strict sense. To understand this conversion process, one must first understand the true memory representation of the FP16 and FP32 data types. Both floating-point types conform to the IEEE 754 floating-point binary standard in memory. The IEEE 754 specification uses scientific notation (e.g., can be written as ) to represent floating-point data in memory. The specification divides floating-point representation into three regions: Sign, Exponent, and Mantissa/Fraction. The unified mathematical formula for final reconstruction is: Where: - Sign bit S: Always the most significant bit (1st bit), where 0 represents a positive number and 1 represents a negative number. - Exponent E: Immediately follows the sign bit, used to control the magnitude and dynamic range of the number. - Mantissa M: Used to control the precision of the number and the number of significant digits. In standard binary scientific notation, the digit before the binary point is always 1 (i.e., ). Since it is always 1, to squeeze memory to the absolute limit, IEEE 754 mandates that this 1 is not stored in memory. Instead, only the fractional part after the binary point is stored in memory (i.e., in the formula above), but during computation, the hardware automatically adds that 1 back. !ce6be79d-c521-45a1-b6d5-add7e59dbb69.png For FP32 and FP16: - FP32: Single precision, 32 bits, comprising 1 sign bit, 8 exponent bits, and 23 mantissa bits, with a representable data range of . - FP16: Half precision, 16 bits, comprising 1 sign bit, 5 exponent bits, and 10 mantissa bits, with a representable data range of . Next, when FP32 parameters saved after model training are converted to FP16 format, what is the specific conversion workflow? It can be mainly divided into the following three steps: Step 1: Exponent checking and overflow/underflow handling. - Overflow check: As mentioned above, the maximum absolute value FP16 can represent is 65504. If an FP32 weight value exceeds 65504, the converter typically performs a clamp operation, forcibly truncating the excess value to 65504. - Underflow check: The minimum normalized positive number FP16 can represent is approximately . If an FP32 parameter value is extremely small, the converter forces it to 0. Step 2: Forced truncation of the mantissa. FP32 has a 23-bit mantissa, while FP16 has only 10 bits. During conversion, the converter simply chops off the trailing 13 bits. In binary, this truncation operation is equivalent to erasing tiny significant digits from the 4th to the 7th decimal places. Naturally, this step is the primary source of precision loss in FP32-to-FP16 conversion. The final step is computation graph reconstruction. This involves replacing the execution logic of operators in the model's computation graph, swapping out FP32 operators (such as Conv2D_Float32) for FP16 operators (such as Conv2D_Float16). The complete conversion workflow of the above three steps is illustrated below: !FP32_to_FP16_Conversion_Flowchart_RK3588_%282%29.png Based on the operations in these three steps, the primary factors that may affect the model's inference results and precision when converting from FP32 to FP16 stem from two aspects: exponent overflow and forced mantissa truncation. However, in reality, for the vast majority of CV and audio models, the precision loss from FP32 to FP16 is almost negligible. Why is that? Regarding exponent overflow, whether in CNNs or Transformers, once a model undergoes initial training, the vast majority of its weight parameters strictly obey a normal distribution with a mean of 0 and an extremely small variance. Furthermore, current CV and audio models are generally equipped with BatchNorm (BN) or LayerNorm (LN) normalization layers. These normalization layers forcibly pull the feature map data distribution back to a standard state with a mean of 0 and a variance of 1 after each convolution or attention mechanism calculation. This means that 99.9% of the weight values in the network fall within the tiny interval . Given FP16's maximum value of 65504, the probability of exponent overflow on the weight side is practically zero. The precision loss caused by forced mantissa truncation is mitigated by the rounding strategy adopted during truncation. During the FP32-to-FP16 conversion, a Round-to-Nearest-Even (RNE) truncation strategy is applied to the mantissa bits (this strategy is somewhat similar to round-to-even in decimal systems). If simple direct truncation and discarding were used, the errors would always bias in one direction, causing errors to snowball into a disaster after tens of thousands of accumulations. However, RNE turns truncation error into a symmetrical random noise with a mean of 0. In this case, when the model sums up tens of thousands of product results with zero-mean, independent noise, the positive and negative errors statistically cancel each other out, greatly mitigating the precision loss and error issues caused by forced truncation. Calculation Process of INT8 Quantization Unlike FP16, which truncates bit widths based on the IEEE 754 standard, INT8 quantization is a sophisticated mathematical space mapping. It requires cramming the continuous, highly dynamic floating-point space of FP32 into a discrete integer space with only 256 scale levels (). For this mapping, the industry-standard approach is to use linear mapping transformation. This mapping transformation is determined by two key parameters: - Scaling factor S: An FP32 floating-point value representing the true range in the FP32 space that corresponds to a single scale unit in the INT8 space. - Zero-point offset Z: An INT8 integer representing which integer scale in the INT8 space corresponds to the absolute zero point in the FP32 space. Based on these two parameters, assuming the true value in the FP32 space is and its corresponding quantized value in the INT8 space is , the fundamental conversion equation between and is: The formula for calculating the quantized value from the true value is: Where: - represents the operation of rounding to the nearest integer. - represents the anti-overflow operation, strictly restricting the result within the legal range of INT8 (i.e., between and , such as ). The full workflow for calculating from FP32 to INT8 can also be broken down into the following three steps. In fact, INT8 quantization calculations execute the quantization formula shown above, but before executing this formula, the parameters and must first be calculated. Step 1: Calculate the scaling factor . Once the range of quantized values is determined (a total of 256 scales from -128 to 127 for INT8), the interval range ( and ) of the true values in the FP32 space must first be determined. Only then can the range of be accurately mapped into the range of . There are two scenarios here, depending on whether we look at parameter weights/biases or activations: - For parameter weights and biases: Because these values are constants determined after model training, model converters (such as Rockchip's RKNN-Toolkit2) can directly scan the convolution kernel matrices in the ONNX file during INT8 quantization to find and . - For activations: Activations dynamically change with the feature data of input images. This is why performing INT8 quantization requires providing a set of calibration datasets (dataset, typically containing 20-50 representative images) based on the training image set. During INT8 quantization, the model converter uses these images to perform a single forward pass, computes the probability histogram of the output feature maps for each layer, and then uses algorithms like KL-Divergence to find an optimal truncation threshold ( and ) that best preserves information. Naturally, the and found this way are derived from the data in our provided calibration dataset, so it is best if the images included in your dataset closely match the actual image formats used post-quantization. Step 2: With and calculated in Step 1, parameters and can now be computed. There are two methods for calculating these parameters: asymmetric quantization (for activations) and symmetric quantization (for weights). Symmetric quantization for weight parameters: The distribution of weight values produced by model training (i.e., and ) is usually centered around 0, being largely symmetrical on both sides. For maximum hardware computation speed, the quantization zero point is strictly required to be , with the target range of INT8 quantized values set to . For example, if and are , the calculated and are: Asymmetric quantization for activations: Asymmetric quantization can fully utilize all scales of INT8. Assuming and , the workflow for calculating and is: > 💡 Why do activations use asymmetric quantization while weights use symmetric quantization? This is because modern CV networks heavily use ReLU family activation functions. After passing through ReLU, all negative numbers in the feature maps are set to 0. If symmetric quantization were forcibly applied to such a single-sided distribution—meaning the center of the mapping range was forced to —then in order to represent a number like , the quantization scale would have to cover and map it to INT8's . As a result, the 127 states from in INT8 would never be used (since there are no negative activations), wasting half of the quantization values and effectively turning 8-bit quantization into 7-bit quantization. However, weight distributions are naturally centered around 0 (Gaussian distribution), so using symmetric quantization wastes virtually no space and enables more efficient hardware computation acceleration. Step 3: Physical conversion and persistence. Once and are calculated in Step 2, the model converter applies the following formula to convert all FP32 weights into INT8 values, packing them into the quantized model file: The complete workflow of the INT8 quantization calculation process described above is illustrated in the flowchart below: !FP32_to_INT8_Quantization_Flowchart_RK3588.png
Case Analysis: GitOps-Driven Development and Deployment Workflow for AWS Cloud-Native Applications
This article demonstrates the complete workflow of code development, testing, and automated deployment in production environments on AWS using GitOps principles, through a simple Python project. The general requirements of this case are: - The local client sends an HTTP request (containing a file name string in the request message) to AWS API Gateway; - AWS Gateway receives it and forwards it to Lambda; - Lambda creates a file in S3 based on the file name and returns a message to the client. 1. Introduction to GitOps-Driven Cloud-Native Application Development Workflow In traditional operations modes, we are accustomed to performing cloud environment operations and management using imperative operations (such as manually typing commands in the AWS web console to create an S3 bucket, or manually packaging and uploading code to S3). Under the increasingly popular GitOps philosophy, deeply integrating Infrastructure as Code (IaC) with CI/CD pipelines makes operations much more efficient and reliable. The core idea of GitOps is very simple: the Git repository of project code is the single source of truth for the system state, and cloud environment deployments automatically unfold based on the code committed in the Git repository. !image.png This standardized development and testing workflow goes as follows: 1. Coding & Testing Environment: Developers write business code (Python, Java, Node.js, etc.) and infrastructure architecture definition files (YAML) in their local IDE, and run basic unit tests locally using unit testing tools (such as Python's pytest). 2. Code Commit (Git Push): Developers push the code to the main branch of GitHub. 3. GitHub Pipeline & Automated Testing: The code push in the previous step automatically triggers the GitHub Actions pipeline. Upon receiving the code submission, Actions spins up an isolated container environment based on the latest code, and installs dependencies and runs unit tests according to the pipeline configuration file. If the tests executed in this automated process fail, the pipeline immediately blocks with a red error light, preventing erroneous code from polluting the cloud. 4. AWS Cloud Automated Orchestration (SAM & CloudFormation): Once the above testing process passes, Actions automatically invokes AWS's cloud infrastructure deployment APIs (CloudFormation) based on strict permission controls (OIDC). During this process, code compilation and packaging are executed, and the infrastructure is smoothly deployed to the AWS environment. Through this highly automated approach, environment discrepancies are completely eliminated. Developers can focus solely on writing code while leaving the rest of the work to the pipeline. 2. Local Environment and Code Structure Preparation Implementing the GitOps workflow described above requires upgrading the project from a local debugging mode to a production deployment mode. A standardized Python project directory tree corresponding to the above workflow should look like this: The template.yaml file is the AWS CloudFormation infrastructure template definition file, which can be thought of as the architectural blueprint submitted by the project to AWS. Its specific contents are detailed in the subsequent AWS CloudFormation execution workflow section. The .github/workflows/pipeline.yaml file defines the automated execution rules for the GitHub Actions CI/CD workflow, which will be detailed in the subsequent section covering GitHub Actions execution. src/app.py is the core business logic code executed in AWS Lambda for this demo; eventually, this code will be deployed to AWS Lambda. Note that in a production environment, Lambda must include robust error handling, CORS cross-origin support, and structured logging. The code for this part is as follows: the main workflow parses the request message sent from API Gateway, extracts the filename field, and creates a file in S3. To execute automated tests in the CI/CD workflow defined by GitHub Actions later, unit test code needs to be written in advance. The unit test code for this case is located at test/test_app.py: After code submission, and before the GitHub Actions pipeline executes the actual deployment in AWS CloudFormation, Actions will first run the test code above. If the tests fail (e.g., an assertion fails), the program will throw a non-zero exit code, and the pipeline will automatically trigger to block the release of code to the production environment. 3. AWS OIDC Role Setup OIDC (OpenID Connect) is an identity authentication protocol based on OAuth 2.0. When the GitHub pipeline runs, GitHub issues a temporary digital identity credential (JWT Token) with a digital signature to the current runner. The runner accesses AWS based on this credential. Upon verifying that the signature was indeed issued by GitHub and confirming that the visitor belongs to the main branch of the specified repository, AWS issues the runner a set of temporary access permissions with a very short lifespan (typically 1 hour), which are discarded after use. This completely eliminates the need for manually managed long-term credentials, achieving true zero-trust and automated security. To implement the mechanism described above, three steps must be completed: telling AWS to trust GitHub, creating a dedicated role in AWS, and configuring the GitHub pipeline to use OIDC login. First, register GitHub as a "Trusted Identity Provider" in AWS. Log in to the AWS console, go to the IAM service, select Identity providers in the left navigation bar, click Add provider, select OpenID Connect, fill in the following information, and click Add provider: - Provider URL: https://token.actions.githubusercontent.com - Audience: sts.amazonaws.com Second, create an IAM Role in AWS for GitHub to assume. Click Roles in the left navigation bar of IAM, then click Create role. Fill in and select according to the figure below: !dbefdaa7-e601-4a2a-866e-fb460c90437e.png Next, add permissions to this role: To allow SAM to smoothly deploy resources in the subsequent CI/CD workflow, grant the AdministratorAccess permission to this role. Finally, name the role GitHubActionsDeployRole and create it. Once the role is created, go to its detailed information page and record its ARN, which will need to be configured in the pipeline.yaml file required by GitHub Actions later: !11e67041-bc7c-4255-b8ce-8a21a9d8492c.png The configurations and modifications to be made in AWS are now complete. The next step is to configure the GitHub Actions pipeline configuration file. 4. GitHub Actions Execution Workflow How exactly does GitHub Actions start and execute the automated CI/CD workflow? The answer lies in the .github/workflows/pipeline.yaml file committed with the code. When a developer executes git push locally, the GitHub Webhook automatically triggers this file to run the complete CI/CD pipeline. The underlying logic behind GitHub Actions is: GitHub's backend engine only monitors YAML files located in the .github/workflows/ folder at the root directory of the project (as long as the suffix is .yml or .yaml), and multiple pipelines can work in parallel. The filenames of the YAML configuration files in this directory can be customized. Therefore, in real commercial projects, multiple files are usually placed in the .github/workflows/ directory, each with its own responsibilities. For example: - unit-test.yaml: Defines that Python unit tests will run whenever code is committed (regardless of the branch). - deploy-prod.yaml: Defines that the full suite of actions to deploy to the AWS cloud is executed only when code is pushed to the main branch. When parsing this YAML configuration file, GitHub automatically decides which pipeline to wake up based on the conditions defined by the on: keyword in the file. For this current demo project, its corresponding pipeline YAML configuration file is: 4.1 Actions Evaluating Unit Tests Question: Every time we push code to GitHub, how does Actions determine which unit test files to execute, and how does it determine whether the unit tests executed successfully? Addressing the first question above, the unit tests that Actions determines to execute are defined by its pipeline YAML file. For this demo, it is the following snippet: That is, the only unit test file to be run for the current demo is test_app.py under the test directory. If a directory is specified for pytest instead of a unit test file, pytest will recursively search down for all Python files in that directory, but it only recognizes files whose filenames start with test_ (such as test_app.py above) or end with _test.py, and will only run unit test functions within them whose names start with test_. Addressing the second question above, the criteria used by Actions to judge whether unit tests succeed are related to the assert statements in the unit test file. When the conditions specified in the assert statements hold true, it indicates that the unit tests ran normally, and execution continues downward until the complete unit test workflow finishes, returning an exit code 0 to the system to indicate successful completion. If any assert statement condition is not met, the program throws an AssertionError exception and returns an exit code 1. The operating system in GitHub Actions inspects the exit code of each execution step. An exit code of 0 indicates that the step completed smoothly; otherwise, it immediately determines that the current step execution failed, blocks the execution of all subsequent commands, and returns an error. 5. AWS CloudFormation Execution Workflow In the CI/CD pipeline, the core philosophy of Infrastructure as Code (IaC) is: all cloud resources should be defined and automatically created by code rather than manually clicked through the AWS console. This part of the work is defined by the template.yaml file. In the GitHub Actions pipeline configuration file .github/workflows/pipeline.yaml mentioned earlier, the final command executed—sam deploy --stack-name my-iot-edge-stack—is responsible for realizing the AWS cloud infrastructure defined in template.yaml within the cloud environment. - sam deploy reads the template.yaml configuration file, and sends this configuration file along with the complete deployment package via temporary permissions obtained through OIDC to a core underlying service of AWS—AWS CloudFormation. - Upon receiving the configuration file, CloudFormation automatically calculates which underlying APIs need to be executed to create the S3 Bucket, Lambda, and API Gateway in order. - If any step fails during this automated deployment process, CloudFormation automatically rolls back (deleting all half-built resources), ensuring that the cloud environment never enters a "half-broken" dirty state. The template.yaml corresponding to this demo is as follows: Question: If developers subsequently modify the current code and push it to GitHub after each modification, it will execute the automated deployment pipeline to create the S3 Bucket, Lambda Function, and API Gateway. What happens if a previous commit has already created these resources? The answer is: no matter how many times the above pipeline is executed, the final state in the cloud will always match the state declared in the cloud environment deployment code. When the Actions pipeline runs sam deploy --stack-name my-iot-edge-stack for the first time, AWS CloudFormation creates a "logical file folder" named my-iot-edge-stack in the cloud. !0ab67a79-aa9d-4eb7-a70b-e6549873cf97.png This file folder records all current states and unique IDs of the S3 Bucket, Lambda, and API Gateway created by the pipeline, and AWS firmly remembers the association between these resources and the pipeline. When code is modified and pushed again subsequently, the pipeline packages the new blueprints and code and sends them to AWS. Upon receiving them, AWS does not immediately overwrite them, but handles them differently based on specific conditions: - If only business code is modified (e.g.,app.py): That is, the content of template.yaml has not changed (meaning infrastructure does not need to be touched), and only the hash value of the underlying Lambda compression package has changed. At this point, AWS only deploys the new code package to the existing Lambda function, replacing the old code. The previous S3 Bucket and API Gateway are completely untouched, and historical files in S3 remain intact. - If infrastructure parameters are modified (template.yaml): For example, changing MemorySize: 128 in the Lambda Container configuration to MemorySize: 256. At this point, AWS determines that the configuration properties of Lambda have changed. It directly modifies the configuration of the existing Lambda function via underlying APIs, scaling its memory up to 256MB. Similarly, S3 and API remain as they are. - If nothing is changed and the pipeline is accidentally triggered again: That is, the new code is 100% identical to the state in the file folder. Then the GitHub Actions pipeline outputs No changes to deploy. Stack my-iot-edge-stack is up to date at the sam deploy step, and finishes in seconds with a green success status without performing any redundant operations. It should be noted in the above workflow that S3 Bucket is used to store core business data, and CloudFormation has special protection logic for storage resources. If a subsequent commit directly deletes the entire IoTDataBucket code block in template.yaml (or renames it) and pushes it to GitHub, AWS by default does not allow the direct deletion of a Bucket containing data when the pipeline attempts an update. This causes the deployment to throw an error directly (Update Rollback), protecting production data from being wiped out by an accidental commit. 6. Testing and Verification After completing all the preparations above, commit the code to the main branch on GitHub. The corresponding Actions will automatically start, execute the unit tests, and automatically deploy the cloud environment on AWS once the unit tests pass: !f7a8a8b2-6abb-43f9-b885-fa562efa483c.png Once the entire process is complete, you can check the specific deployment status and its corresponding API in AWS Lambda: !dab16dbf-a3de-4640-917d-fd704f430e06.png Next, you can test using the curl command in a terminal or similar interface (replace with your own API):
How PSRAM and LPDDR Reduce Power Consumption
Due to the inherent self-refresh characteristic of DRAM and the processing of high-frequency communication signals, DDR has always been a major power consumer in electronic system design. This article focuses on summarizing the targeted design strategies implemented by LPDDR and PSRAM to reduce power consumption. !image.png The Power Consumption Issue of DDR With soaring frequencies, modern DDR (especially DDR5) has long become a major power hog on motherboards. This is why high-end memory modules in our PCs today must wear thick metal heat spreaders, or even be equipped with dedicated Power Management Integrated Circuits (PMICs). !image.png Where does the high power consumption of DDR come from? Generally speaking, the causes of DDR's high power consumption can be attributed to the following three core parts. Dynamic Power Consumption There is a very classic formula for calculating the dynamic power consumption of digital circuits: In summary: The dynamic power consumption of a digital circuit is directly proportional to the operating frequency , the square of the voltage , and the parasitic capacitance . Modern DDR4 easily reaches 3200 MT/s, and DDR5 even surges to 5600 MT/s or higher, meaning its internal base frequency is as high as 2.8 GHz or more. At such high frequencies, hundreds of millions of transistors inside the chip and dozens of external data and clock lines must toggle their voltage levels (from 0 to 1 / from 1 to 0) billions of times per second. This high-frequency switching action generates huge instantaneous currents and is also the largest heat source for DDR in its active state. Similarly, PCB traces and connectors on the circuit board introduce a certain amount of parasitic capacitance (corresponding to in the dynamic power consumption formula above). Furthermore, to ensure that signals remain precise when routed and branched across the PCB, DDR4 must maintain a relatively high I/O driving voltage of ( for DDR5). According to the dynamic power consumption formula above, its power consumption is exponentially amplified. Static Analog Dissipation When frequencies enter the microwave level (such as the base frequency of DDR5600 mentioned above), DDR must attach power-hungry advanced analog circuits to its peripheral interface modules (i.e., the DDR PHY module) to prevent high-frequency communication signals from distorting: - DLL (Delay-Locked Loop): To ensure that external clocks and internal data are precisely aligned within a nanosecond or even picosecond window, the DLL module must run at high speed in the background, constantly detecting and forcibly compensating for tiny physical delays. As long as the clock keeps running, the power consumption of the DLL will not stop, which is one of the sources of static base current. - ODT (On-Die Termination): High-frequency signals generate severe electromagnetic reflections on long PCB traces. To absorb these reflected waves, DDR instantaneously turns on internal ODT resistors when receiving data. This is equivalent to laying a DC path in the circuit, where signals are directly dissipated as heat, turning into actual thermal loss. For the working principles related to DLL and ODT, you can refer to the article Can PSRAM Be a Solution to DDR Shortages?. DRAM Self-Refresh Power Consumption Fundamentally, the underlying layer of DDR is a DRAM storage array, where every single bit of data relies on the charge in a miniature capacitor to be maintained. In reality, capacitors inevitably leak charge. To prevent data loss, even when the system is completely idle (without any read/write operations), the SoC master controller must send a self-refresh command to the DDR every few milliseconds, forcing billions of capacitors inside the chip to be frequently charged and discharged. This large-scale charge and discharge working mechanism means that even during standby and sleep, DDR cannot achieve true zero power consumption like static logic circuits. For the specific working principles of DRAM, you can also refer to the article Can PSRAM Be a Solution to DDR Shortages?. How LPDDR Mitigates Power Consumption Issues? To address the high power consumption issues of DDR mentioned above, LPDDR prioritizes low-power design in its architecture. It has carried out targeted renovations on the underlying physical architecture of standard DDR. While maintaining a high data throughput rate, it drastically reduces power consumption, making it more suitable for mobile high-performance computing devices such as laptops and smartphones. !image.png Targeting Dynamic Power Consumption Still referring to the formula for digital circuit dynamic power consumption: . To reduce power consumption while maintaining high frequency (), the first step is to focus on the I/O interface voltage (). As mentioned above, the core and I/O voltages of standard DDR4 are typically both 1.2V. In contrast, LPDDR4X directly lowers the I/O voltage responsible for external communication (VDDQ) to 0.6V. is only one-quarter of . This means that simply in terms of high and low voltage level transitions on the data bus, LPDDR4X saves 75% of dynamic power consumption compared to DDR4. In addition, to ensure signal integrity at such low voltages, LPDDR adopts a dedicated Low-Voltage Swing Terminated Logic (LVSTL) and requires the physical distance between the master controller and the memory to be extremely short (usually using PoP stacked packaging or compact SiP), which also helps reduce the parasitic capacitance of the PCB traces. Targeting Static Power Consumption As mentioned above, to align clock signals in high-frequency communications, DDR adds a dedicated DLL module. This module runs continuously even when the system is under no load and consumes extreme amounts of power. Therefore, LPDDR completely abandons the internal DLL module in its chip design. Instead, to solve the clock signal alignment problem, it requires the memory controller of the master SoC to execute extremely complex Training algorithms during system boot, allowing the SoC's LPDDR controller to measure the delay of each data line and then perform active phase compensation inside the SoC. This transfers the burden of signal synchronization to the SoC master, allowing LPDDR to shed its biggest static power consumption burden. Introducing TCSR and PASR Mechanisms For the self-refresh actions performed on its internal DRAM array, standard DDR makes no distinctions. Regardless of whether the current temperature is high or low and whether the data is in use, it refreshes all bits across the entire array at the highest frequency, which actually results in a huge waste of power. Therefore, LPDDR integrates two intelligent refresh control mechanisms internally to optimize power consumption: - TCSR (Temperature Compensated Self Refresh): There is a temperature sensor inside the chip. When it senses that the device is in a cold state (where capacitor leakage is relatively slow in this state), it automatically lowers the self-refresh frequency. - PASR (Partial Array Self Refresh): For sleep scenarios, before the system enters sleep, the operating system uses special commands to tell LPDDR which banks are empty. This way, during sleep, LPDDR can directly power down the empty banks during self-refresh, only maintaining self-refresh for banks containing data. Through the targeted power consumption optimization design across these three dimensions, the power consumption of LPDDR is significantly reduced compared to DDR: !6cf5a78f-b0c9-4fac-a6d5-c712ac8c7627.png How PSRAM Solves Power Consumption Issues Although, as summarized in the article Can PSRAM Be a Solution to DDR Shortages?, PSRAM and DDR/LPDDR are actually products targeting completely different fields and applications, PSRAM's low-power performance is indeed prominent. Therefore, this section also summarizes the efforts made by PSRAM in reducing power consumption. If LPDDR achieves relatively low power consumption while guaranteeing performance through extremely expensive advanced manufacturing processes and extremely complex fine-grained management, then the logic behind PSRAM solving power consumption issues is essentially "letting go" (Zen style)—that is, trading extreme power savings for raw physical simplification and architectural reduction (of course, its performance is completely out of class compared to DDR/LPDDR). The figure below shows the power consumption profile of a Winbond PSRAM: !31a6bf33-c8c4-4a5f-8c66-813b1113aabe.png Targeting Dynamic Power Consumption Analysis is still based on the digital circuit dynamic power consumption formula: . For dynamic power optimization, LPDDR's approach is to lower the voltage () as much as possible, which also requires the distance between the SoC master and LPDDR to be minimized. In contrast, PSRAM's approach is to minimize the frequency () and pin capacitance (). - Serial Bus: DDR typically has 60 to 100 I/O pins, and the massive routing network on the motherboard leads to large parasitic capacitance (). In contrast, mainstream OSPI PSRAM has only 8 data lines and fewer than 12 pins in total. - Low Frequency Band: The physical clock of DDR is generally in the microwave band above 1200 MHz. PSRAM proactively avoids the complexity brought by microwave communication by capping the maximum clock well within 200 MHz. As a result, due to fewer pins and lower frequencies, the physical capacitance and number of toggles that the master SoC and PSRAM need to overcome during data communication are reduced by orders of magnitude. Therefore, even though PSRAM's I/O voltage still adopts the conventional 1.8V (without dropping to 0.6V like LPDDR, thus lowering PCB layout and routing requirements), its overall dynamic power consumption remains far lower than that of DDR. Targeting Static Analog Dissipation Since the clock frequency is below 200 MHz, there is no need to deal with high-frequency communication signal issues, no need for a DLL to forcibly align nanosecond-level phases, and no need for ODT to absorb electromagnetic reflections of high-frequency signals. Consequently, the DLL and ODT modules, which have high static power consumption in DDR, can be eliminated. When there are no read or write operations, the interface terminals of PSRAM can enter absolute silence, and static power consumption can be directly reduced to zero. Targeting Sleep Base Current Whether it is DDR or LPDDR, even when the system enters a sleep state, the SoC's DDR controller must remain operational to refresh the internal storage arrays of DDR/LPDDR (LPDDR can only turn off refresh for some idle banks). This causes the sleep base current of DDR/LPDDR to remain stubbornly high even during sleep. To address this pain point where DDR must be externally managed by the SoC, PSRAM uses a completely different self-refresh and sleep control logic, completely resolving the base current issue during sleep. This exact feature is why PSRAM is well-suited for applications that are extremely sensitive to sleep power consumption. PSRAM features an internal self-refresh module. Thus, when the device enters a sleep state, the master SoC can directly cut off the external clock and completely power down. The extremely power-efficient micro-RC oscillator inside PSRAM wakes up and recharges the capacitor array at a very slow pace to maintain data persistence. Through the targeted power consumption optimization above, there is a massive order-of-magnitude difference in power consumption between DDR and PSRAM: Under Full-Load Active State: - Standard DDR4: Consumes anywhere from 2 watts to 3 watts, with currents at the level of hundreds of milliamperes (mA), causing noticeable heat on the chip surface. - OSPI PSRAM: When streaming data at 200 MHz, the current is typically only around 20 mA to 35 mA. Under Deep Sleep State: - Standard DDR4: Even upon entering sleep, its base current typically remains as high as 10 mA to 20 mA, which is also the primary reason why AOV Camera power consumption stays high. - OSPI PSRAM: Standby current drops off a cliff, typically ranging between 20 µA and 50 µA. !7721f3d0-8063-4c86-abb5-0616b342f437.png
Can PSRAM Become the Solution to DDR Shortages?
With the current tight supply and drastic price fluctuations in the DDR memory market, some SoC vendors in the IPC field have started promoting Camera SoC platforms with built-in PSRAM. What are the differences between PSRAM and the DDR we commonly use, and what applications are they suitable for? This article attempts to clearly answer these questions. To understand what PSRAM actually is, we must first understand the difference between SRAM and DDR (DRAM). SRAM vs. DRAM SRAM can be considered the high-end, wealthy elite of the storage world, with the most common current use being the L1/L2 Cache inside CPUs. Storing 1 bit of data requires a full 6 transistors (the 6T architecture). These 6 transistors are cross-coupled to form a logical closed-loop (a flip-flop). With this storage structure, accessing bit information is extremely simple and reliable: - Writing data: A high external voltage is applied to forcefully set the state of the flip-flop to one side. - Reading data: The state across the two ends of the flip-flop is measured directly. This read operation is non-destructive to the original state of the flip-flop, and the speed is extremely fast (nanosecond or even picosecond level). Its advantages are that this storage structure is extremely stable, the state is locked forever as long as power is maintained (no refreshing required), and reading a memory bit is non-destructive with blazing speed. However, the disadvantages are certainly that the footprint is too large, it is difficult to scale up the capacity, and the cost is extremely high. The figure below shows the circuit structure of a single storage bit in SRAM: !image.png The initial birth and subsequent continuous evolution of DRAM were both aimed at solving the aforementioned issues of large capacity and low cost. In the design of a single-bit DRAM storage cell, only 1 transistor + 1 miniature capacitor are used. An analogy for this storage structure is: the transistor is a water faucet, and the capacitor is a small bucket. A full bucket represents 1, and an empty one represents 0. This bit storage structure has a fatal physical flaw: the capacitor leaks electricity. Therefore, within a few milliseconds, a full bucket leaks down to a half-full bucket, and eventually, 1 becomes 0. Thus, to maintain the stability of the bit state, the transistor must be periodically opened to check (determine whether it is 0 or 1), and if it is 1, the water (charge inside the capacitor) must be refilled. This is the physical essence of why DRAM requires dynamic refreshing. Worse yet, the read and write process for each bit in DRAM is extremely complex: - Writing data: First, open the transistor (faucet) and pump charge into the capacitor (bucket) to represent 1, or drain the charge to represent 0. - The DRAM read process is a complex, destructive read operation: First, you must detect whether there is water (charge) in the bucket. To detect this, you can only open the transistor and let the water flow out to the external bus (Bitline). An external Sense Amplifier senses the weak water flow and determines whether the previous state of the bit was 0 or 1. Because the water flows out during a read operation, the original data state is destroyed after reading. Therefore, at the end of every read operation, DDR must forcibly execute a write-back action to refill the bucket with the 1 that was just read. !image.png The above is a brief summary of the working principles of SRAM and DRAM. DDR, LPDDR, and PSRAM, which will be introduced later, are all based on DRAM; their internal bit storage array structures and read/write processes follow the DRAM conditions described above. > 💡 Note: PSRAM is not SRAM, but rather DRAM. The reason it carries a "P (Pseudo)" is because it is a misnomer. Its internal structure is still DRAM that leaks electricity, except that a micro-controller is integrated inside the silicon chip to automatically handle the refresh operation, masquerading to the external host controller as SRAM that requires no refreshing. To understand how PSRAM actually works, a good starting point is to understand how the most commonly used DDR works, and then examine the differences between it and DDR. What Exactly is the Technical Barrier of DDR? > Note that while the internal structures and workflows of different DDR specification versions—as well as their earlier predecessors like SDR—are extremely complex, the purpose of this article is primarily to clearly explain the differences in workflow and structure between DDR/LPDDR and PSRAM. Therefore, detailed minor points will not be summarized; only the parts with distinct differences from PSRAM will be covered. In product design, when using external DDR, we often face issues such as high DDR power consumption and complex circuit design. Because of this, mainstream Camera SoC manufacturers generally integrate DDR internally to reduce system design and debugging difficulty. The primary reason for this complexity in DDR is its pursuit of high throughputs reaching tens of GB/s. The figure below is a typical connection diagram between an SoC DDR controller and a DDR chip: !image.png To pursue extremely high throughput between the SoC and DDR, current mainstream DDR5 has achieved 5600 MT/s (Mega Transfers per second) or even higher. The basic principle of DDR (Double Data Rate) communication is: transmitting data on both the rising edge and the falling edge of the clock signal. Therefore, when a DDR5 data throughput reaches 5600 MT/s, its actual physical clock (i.e., the true square-wave oscillation frequency sent by the SoC to the DDR via the CLK pin) reaches 5600 / 2 = 2800 MHz (2.8 GHz)! A fundamental frequency of 2.8 GHz already falls into the typical microwave frequency band on a PCB. At this frequency, the copper traces on the motherboard are no longer simple wires, but rather microstrip antennas. Issues caused by these antennas, such as signal reflection, crosstalk, and attenuation, become extremely severe. This is the core problem that high-frequency DDR must solve. The high-speed analog and mixed-signal design capabilities required to solve this problem are what truly separate mid-to-low-end memory manufacturers from international giants (such as Samsung, SK Hynix, and Micron). To solve the aforementioned high-frequency signal issues, high-frequency DDR adopts DDL (Delay-Locked Loop) and ODT (On-Die Termination) solutions in its signal design. !0029a77a-d62b-4ee1-9a87-887fd73841b0.png The purpose of the DLL (Delay-Locked Loop) module is primarily to combat internal clock delay within the DDR chip. During communication when the external SoC accesses data in DDR, the clock signal travels through the PCB traces, arrives at the DDR pins, and must pass through a complex internal routing tree inside the DDR to reach the registers that finally output data. This physical path generates an internal propagation delay of about 0.1 to 0.2 nanoseconds. Without a DLL, by the time DDR data reaches the SoC pins, it might be delayed by half or even a full clock cycle. The external SoC expects to receive data precisely on the clock edge, and such access would result in reading completely garbled data. The role of the DLL module is like an extremely precise timing predictor. During operation, it continuously measures the inherent physical delay between the arrival of the external clock and the emission of internal data. Then, through an internal voltage-controlled delay line, it intentionally advances the clock used to trigger data inside the DDR, ensuring that the data returned by the DDR appears at its pins precisely aligned with the SoC's clock. The purpose of ODT (On-Die Termination) is mainly to eliminate signal echoes. As mentioned above, when the signal frequency of a transmission line reaches the GHz level, the copper wires on the PCB are no longer simple conductors, but rather transmission lines. When the SoC transmits data (electromagnetic waves) to the DDR at full speed, if the signal hits the end of the DDR pins and finds an impedance mismatch, the electromagnetic wave will bounce back along the same path, creating an echo signal. This echo signal will collide with the next new wave being sent by the SoC, causing the waveform across the entire bus to degrade (professionally termed ringing, overshoot, or undershoot), resulting in instantaneous, massive data corruption. To cope with echo issues caused by impedance mismatches in RF signals, the JEDEC specification dictates adding termination resistors on the silicon inside the DDR chip (On-Die) to absorb reflected waves—this is ODT. Structure and Internal Characteristics of PSRAM Compared to the complexity faced by high-speed DDR in high-frequency signal communication, the structure of PSRAM is much simpler. The external communication frequency of the vast majority of PSRAM is typically limited to within 200 MHz, avoiding severe electromagnetic reflections and nanosecond-level clock skew issues. Consequently, its physical interface becomes conventional CMOS/LVCMOS transceivers. Current mainstream PSRAM and master SoCs communicate via QSPI (4 data lines) and OSPI (8 data lines) interfaces. The SoC simply sends simple SPI serial commands, and PSRAM translates these simple commands internally into the complex instruction combinations required by the underlying DRAM array (such as splitting them into Active row activation -> Read/Write column access -> Precharge). As a result, the SoC no longer needs to integrate a complex DDR controller. !d4462f95-87b1-468b-a598-eef64d55edb3.png Compared to DDR, a major innovation of PSRAM is its built-in self-refresh counter. PSRAM uses this internal self-refresh counter to completely take over the self-refresh behavior of its internal DRAM array. In this case, when entering sleep mode, the master SoC can even truly shut down (as long as power to the PSRAM itself is maintained) without affecting the data inside the PSRAM. Thus, power consumption in sleep mode is drastically reduced. - In contrast, with DDR, even when the host goes to sleep, the SoC's memory controller cannot be powered off; it must continue to maintain specific voltage levels on the clock pin or CKE (Clock Enable) pin. This causes a portion of the power domain inside the SoC to remain unclosable, making it very difficult to reduce the overall baseline current of the system. Overall, therefore, the design philosophy of PSRAM is to sacrifice extreme throughput and capacity (since communication throughput is too low, high capacity is meaningless, which is why current mainstream PSRAM capacities typically range from 32 Mb to 256 Mb). By adding a large amount of logic circuitry inside the chip to solve the DRAM array leakage problem and presenting an extremely user-friendly interface to the master SoC, it ultimately trades for extreme power savings and minimalist hardware design. Conclusion Generally speaking, although the manufacturing of the internal storage core array (DRAM Cell) of DRAM still requires extremely advanced process nodes, this is not an insurmountable hurdle. The true technical barrier in the DDR domain lies in high-speed analog and mixed-signal design capabilities (namely peripheral circuits including the DLL, ODT, and high-speed PHY interfaces briefly outlined above). For many manufacturers producing PSRAM or older legacy DDR specifications (such as DDR2 or low-speed DDR3), their strengths lie in digital logic design and low-power control. In the 100 MHz to 200 MHz frequency band, digital signals remain relatively ideal square waves, eliminating the need for overly complex analog circuits to repair signals. However, once they want to advance toward high-speed DDR4 or even DDR5, manufacturers must assemble top-tier analog circuit design teams. What they must solve are no longer simple 0-and-1 logic problems, but microwave-level electromagnetic field problems. In addition to the aforementioned DLL and ODT, modern high-speed DDR must also integrate advanced analog anti-interference technologies such as VREF (Internal Reference Voltage Calibration) and even DFE (Decision Feedback Equalizer), which were previously found only in high-end communication chips (like PCIe and Ethernet PHYs). This is why there are countless manufacturers in the market capable of making PSRAM, while those capable of stably supplying high-speed LPDDR4X and DDR5 can be counted on one hand. The essence of the latter is an ultra-high-speed RF/analog chip disguised in memory clothing. Therefore, combining the internal architectural composition and working logic of DDR and PSRAM discussed above, it is clear that these two fundamentally target completely different application domains and are not comparable. - The core mission of the DDR series (including LPDDR commonly used in mobile devices) is to provide extreme memory bandwidth. As long as the system runs a massive operating system (such as standard Linux, Android, Windows) or needs to process intensive matrix operations and high-definition multimedia streams, it must be handled by DDR. - The purpose of PSRAM is to provide the host controller with a cache much larger than on-chip SRAM, all within limited PCB space and with extremely low standby power consumption. As long as the device is purely battery-powered (low-power), processes audio, acts as a low-resolution smart doorbell, or is a lightweight IoT device with a screen, using PSRAM is very appropriate—provided, of course, that the software architecture transitions from heavy Linux to an RTOS, or significantly optimizes application-layer memory footprints and bus overhead. References - Detailed Explanation of ODT Function in DDR and Waveform Comparison_Memory rdodt - CSDN Blog