<?xml version="1.0" encoding="utf-8" standalone="yes"?><rss version="2.0" xmlns:atom="http://www.w3.org/2005/Atom"><channel><title>regulatory on toorun.dev</title><link>https://toorun.dev/tags/regulatory/</link><description>Recent content in regulatory on toorun.dev</description><generator>Hugo -- gohugo.io</generator><language>en-us</language><lastBuildDate>Sat, 29 Nov 2025 12:30:00 +0000</lastBuildDate><atom:link href="https://toorun.dev/tags/regulatory/index.xml" rel="self" type="application/rss+xml"/><item><title>Linux WiFi TX Power Configuration and Regulatory Constraints</title><link>https://toorun.dev/posts/linux-wifi-tx-power-regulatory-configuration/</link><pubDate>Sat, 29 Nov 2025 12:30:00 +0000</pubDate><guid>https://toorun.dev/posts/linux-wifi-tx-power-regulatory-configuration/</guid><description>WiFi TX Power Configuration Overview WiFi configuration typically allows runtime control of parameters such as channel selection.
However, TX power is not always dynamically configurable and may require configuration during driver initialization.
This is done by providing a TX power configuration binary to the driver.
TX Power Configuration Flow The general workflow:
Generate TX power configuration binary\ Place it in firmware path\ Load driver with configuration\ Verify applied limits Generating TX Power Configuration A configuration file is used to generate a binary representation of TX power limits.</description></item><item><title>Embedded RED Cybersecurity Compliance (EN 18031): Requirements and Implementation</title><link>https://toorun.dev/posts/embedded-red-cybersecurity-en18031/</link><pubDate>Sat, 29 Mar 2025 12:30:00 +0000</pubDate><guid>https://toorun.dev/posts/embedded-red-cybersecurity-en18031/</guid><description>RED Cybersecurity (EN 18031) Overview The RED cybersecurity standard (EN 18031) defines requirements to ensure that radio equipment is secure and does not negatively impact networks, users, or services.
It is structured around three main articles:
3.3.d: Protection of networks and prevention of service degradation 3.3.e: Protection of personal data and privacy 3.3.f: Protection against fraud Applicability Depending on the system design, not all articles may apply.
Typical example:
Systems without user data → privacy requirements may not apply Systems without financial interaction → fraud-related requirements may not apply Network interaction → usually relevant and must be addressed Requirements Structure Each article is divided into:</description></item></channel></rss>