Category Archives: Design

The Definitive Guide to Professional Schematic Design

Posted on by

A schematic is, fundamentally, a visual language whose primary purpose is to communicate a circuit’s intent to another human being quickly, clearly, and with minimal chance of misunderstanding.

“I can’t draw, but I can trace.”  — Howard Bagley (world class audio engineer)

A beautifully crafted schematic embraces the philosophy of “traceability”: the reader should never have to exert high cognitive effort to mentally “draw” connections or untangle spaghetti wiring; instead, they should simply be able to “trace” the logic. A sloppy schematic, conversely, insults the reader and obscures the circuit’s function behind physical geography and disorganized wires.

To achieve elegant and highly readable schematics, you must follow these definitive principles:

1. Predictable Flow and Layout
A great schematic reads like a book, leveraging natural reading habits.

Left-to-Right Signal Flow: Inputs, connectors, and sensors belong on the left, while outputs, displays, and actuators belong on the right. The only exception is feedback signals, which naturally flow backward from right to left.

Top-to-Bottom Power Flow: Higher positive voltages should be placed toward the top of the page, cascading downward to lower voltages and finally to ground at the bottom.

Use the Grid: Always draw on the CAD tool’s default grid. Deviating from the grid causes misaligned wires and connection errors.

2. Intent Over Physical Geography
A schematic is a map of logic, not physical space.

Functional Pin Orders: Integrated Circuit (IC) symbols should almost never mimic the physical pinout of the chip. Group pins by function: place inputs on the left, outputs on the right, power pins at the top, and ground pins at the bottom.

Logical Chunking: Group related components together. For example, decoupling capacitors must be drawn physically close to the specific IC pins they protect, even if they can be placed elsewhere on the final layout.

3. Aggressive Line and Junction Management
Every wire should be easy to follow.

Dots Connect, Crosses Don’t: Draw a dot at every intended junction. When lines must cross without connecting, simply let them cross; do not use outdated “jump-over” hoops or broken background lines, as modern CAD software handles direct crosses best.

The “No 4-Way Tie” Rule: Never use a four-way crossing with a junction dot. If the schematic is reproduced or zoomed out, the dot can vanish, leaving the connection ambiguous. Always stagger connections into two distinct T-junctions.

Avoid “Air Wires” Without Ports: While naming nets can clean up a localized mess, creating invisible “air wires” across complex sheets without proper hierarchical ports makes a design impossible to trace and maintain.

4. Clear Net Naming and Labels
If a signal cannot be connected cleanly with a direct line, it must be labeled effectively.

Keep Names Short and Uppercase: Use all caps for pin and net names to distinguish them from standard text (e.g., CLOCK, CLK, or 8MHZ instead of 8 MHz clock to my PIC).

Avoid Ambiguous Power Names: Be specific. Label power nets with their exact voltages (e.g., replace the decimal point to avoid confusion, using 3V3 instead of 3.3V) and differentiate grounds like GND and AGND. Never hide power pins on symbols.

Use Local, Global, and Hierarchical Labels Properly: Global labels span the whole design (like power lines or I2C buses), local labels connect nets only on the same page, and hierarchical labels define the inputs and outputs of a sub-circuit block.

5. Modularity, Hierarchy, and Paper Size
Designing one massive, cluttered schematic sheet is a recipe for disaster.

Design for Standard Paper: Format your schematics so they are easily readable when printed on standard A4 or 8.5×11-inch paper, or viewed on a standard HD monitor without aggressive panning.

Start with a Block Diagram: Begin your design with a top-level block diagram that outlines the main functional modules, power constraints, and data flow.

Use Hierarchical Sheets: Treat pages like paragraphs in a story. Dedicate separate sheets to individual functional blocks (e.g., power supply, microcontroller, motor driver) so the reader can evaluate one logical group at a time.

6. Comprehensive Annotation (Show Your Work)
A definitive schematic documents the why alongside the how, acting as the project’s living history.

Show Calculations: Annotate the schematic with the formulas used to design the circuit, such as LED current limits, filter corner frequencies, or voltage divider ratios.

Clarify Component Details: Indicate specific I2C addresses, UART data directions (with arrows), and expected pin behaviors (like active-low WP pins).

Include a Changelog: Keep a revision history on the first page noting board revisions, dates, and a summary of changes.

A new unit set – SCHIXELS (Schematic Pixels) – Wixels (Wire Pixels) and Devixels (Device Pixels)

Posted on by

Engineering the Canvas: Why We Use Wixels, Schixels, and Devixels

In high-density schematic design, “pixel math” is the enemy of precision. Relying on raw pixels leads to sub-pixel rendering blur, inconsistent wire gutters, and “drift” where components look aligned but are off by a fraction. The SchemWeb environment solves this by replacing raw pixel values with a hierarchical unit system: Wixels (WX), Schixels (SCX), and Devixels (DVX).

By shifting the conversation from “move this 100 pixels” to “move this 1 SCX,” we move away from arbitrary drawing and into deterministic engineering.

The Hierarchy of Alignment

Instead of a single flat grid, the environment operates on three integrated layers of resolution:

Unit Base Units Scaling Purpose
Wixel (WX) 25 1/4 SCX Minor: Wiring and port pitch.
Schixels (SCX) 100 1 SCX Major: Device and rack snapping.
Devixels (DVX) 1000 10 SCX Super-Major: Departmental and zone layout.

What Happens When You Use These Units?

1. Wiring Becomes Deterministic

When you talk in Wixels, you are defining the “Micro” resolution of the system.

  • No More “Sub-Pixel” Issues: All wire segments and junctions snap to the 25-unit WX grid, ensuring lines are always perfectly horizontal or vertical.

  • Standardized Density: Ports are spaced exactly 1 WX apart, which naturally allows for 4 ports per Schixel of height.

  • Visual Rhythm: The 4:1 ratio between Schixels and Wixels creates an “engineered” aesthetic rather than a hand-drawn one.

2. Architecture Becomes Structural

When you talk in Schixels, you are handling the “Major” structural alignment.

  • The “Big Block” Philosophy: All devices (Nodes) and Groups must snap their top-left origin to the 1 SCX grid.

  • Predictable Sizing: Instead of guessing widths, a standard device is simply 3 SCX wide.

  • Coordinate Clarity: Coordinates are tracked as scx and scy, making it immediately obvious where a device sits in the schematic hierarchy.

3. Macros Become Aligned

When you talk in Devixels, you are making “Super-Major” architectural decisions.

  • Zone Isolation: You can define the spacing between entire departments (e.g., “Audio Engine” vs. “Output Routing”) using a 1 DVX gutter.

  • Columnar Layouts: Large-scale systems are organized into columns that are typically 1 or 2 DVX wide.

  • Immediate Scale: Devixels represent the thickest grid lines on the canvas, giving you an instant sense of the schematic’s magnitude.

The “Perfect Snap” Benefit

The greatest advantage of this system is mathematical harmony. Because 10 SCX equals 1 DVX, and 4 WX equals 1 SCX, the units are nested perfectly.

When you snap a department to a Devixel, it is—by definition—also perfectly aligned to the Schixel device grid and the Wixel wiring grid.

This eliminates the “pixel drift” that plagues traditional design tools. Anthony, by speaking this language, we ensure that every wire and every rack unit exists exactly where it should, every single time.

Pulse Protocol: Engineering at the Speed of Thought

Posted on by

The Pulse Protocol: Engineering at the Speed of Thought

The Pulse Protocol is a high-velocity framework designed to replace rigid, linear engineering with a fluid, multi-dimensional workflow. It transforms data from a static record into a living “Pulse” that keeps every team member in perfect sync.

1. The Core Philosophy: “Data-First Design”

In this model, the “Master Document” is a myth. CAD files, spreadsheets, and diagrams are simply Visual Interfaces for a central, headless database.

  • Asynchronous Freedom: Anyone can contribute to the project at any node (P1–P4) at any time.

  • Instant Synchronicity: A single update in one portal resonates through the entire Protocol immediately.

2. The Four Portals of Entry

The Pulse Protocol ensures that no process ever blocks another. Every entry point is live and valid.

Portal Role The Pulse Action
P1: Procurement Financial View Swapping an unavailable part updates the Part ID across the entire project ecosystem instantly.
P2: Logic Calculated View Changing a performance requirement (like HP or Voltage) flags the relevant diagrams for an automatic audit.
P3: Spatial Physical View Moving a component on a floor plan updates the BOM with new physical dimensions and material lengths.
P4: Functional Schematic View Adding a safety loop generates “Ready-to-Place” virtual assets for the layout team.

3. The “Unplaced Assets” Strategy

To maintain constant flow, the Protocol uses a Project Buffer.

Engineers can define “Data-Only” entities in a spreadsheet before a single line is drawn in CAD. When the designer opens the drawing, they see a “Pulse Bin” of items already defined by the team. They simply drag-and-drop these intelligent assets into the physical space to “complete” the loop.

4. The Technical Blueprint: How the Pulse Beats

For small and medium teams, we achieve this through the Triple-Link Method:

  1. The GUID: Every component has a unique digital fingerprint that stays the same across all platforms.

  2. The Headless Brain: A shared, lightweight database (SQL Lite or SmartSheet) that holds the project intelligence.

  3. The Listeners: * AutoCAD: A background script that pushes attribute changes to the Brain upon saving.

    • Excel: PowerQuery links that pull the latest quantities and statuses with one click.

5. From Friction to Freedom

The Pulse Protocol ends the era of manual data entry and replaces it with Data Validation.

  • The Vision: You aren’t just “drawing”; you are navigating a live map of the project’s reality.

  • The Advantage: It allows a 2-person team to operate with the coordination of a 10-person firm because the data handles the communication.

The Pulse Rule: A “Block” is no longer just geometry; it is a Data Row with a graphical representation.

Schematic Semantics: Ethernet left or right side

Posted on by

The debate over whether an Ethernet port functions as a transmitter or a receiver on a schematic is the technical equivalent of the “toilet paper over or under” argument. It is a fundamental disagreement over orientation that often ignores the fact that the utility remains the same regardless of which way the roll is hanging.

Traditionally, schematics follow a rigid left-to-right flow: sources (transmitters) live on the left, and sinks (receivers) live on the right. This worked perfectly for analog audio or serial data where electricity moved in one direction. Ethernet, however, is a bidirectional transceiver technology. It is constantly “pushing” and “pulling” simultaneously, which breaks the traditional rules of drafting.

The Access vs. Consumption Debate

Many designers view the Ethernet switch as the “provider.” In this mental model, the switch is the source of connectivity, sitting on the left side of the page and “feeding” access to the edge devices on the right. The edge device is seen as the consumer of the network.

Conversely, others view the edge device as the “source” of the data itself. If a 4K camera is generating a video stream, that camera is the transmitter, and the switch is merely the consumer of that stream. In this scenario, the camera sits on the left, and the switch sits on the right.

Why It Is Like Toilet Paper

Just like the “over or under” debate, both sides have logical justifications that feel like common sense to the practitioner:

* The “Over” (Switch as Source) Argument

* It prioritizes infrastructure. Without the switch, there is no signal path.

* It follows the logic of power distribution, where the source of “energy” (in this case, data access) starts at the core.

* It treats the network as a utility, similar to a water main providing flow to a faucet.

* The “Under” (Edge as Source) Argument

* It prioritizes the payload. A switch with no devices has nothing to move.

* It maintains the “Signal Flow” tradition. If a microphone generates audio, it must be on the left, regardless of whether it uses an XLR or an RJ45 jack.

* It focuses on the intent of the system (e.g., getting video from a camera to a screen).

The Best Mechanism for Drafting

The shift in modern schematic design is moving away from seeing the switch as a “provider of access.” Instead of trying to force a bidirectional “highway” into a one-way “pipe” layout, the most effective designers are treating the switch as a neutral center point.

By placing the network switch in the center of the drawing, you acknowledge its role as a transceiver. You can then place “Signal Generators” (like cameras or microphones) to the left of the switch and “Signal Consumers” (like displays or speakers) to the right. This acknowledges that while the switch provides the “road,” it is the edge devices that provide the “traffic.”

Ultimately, as long as the drawing is consistent, it doesn’t matter if the “paper” is hanging over or under—as long as the data reaches its destination.

 

Why AMWA NMOS Has Superseded AES70 for Connection Management

Posted on by

In the transition to IP-based media infrastructures, particularly those built on SMPTE ST 2110 and AES67, the industry faced a critical decision: how to discover devices and manage the complex connections between them. While AES70 (Open Control Architecture) offers a comprehensive object-oriented framework for device control, it has effectively lost the battle for **connection management**.

Continue reading →

The Great Reboot: Outcome Engineering

Posted on by

Remember the “good old days” of broadcasting and studio design? If you’re over a certain age, your lower back definitely remembers.

Once upon a time, designing a studio wasn’t engineering; it was heavy equipment moving combined with frantic electrical wizardry. We measured progress in tonnage of rack gear and miles of copper cable. We lived by a simple, terrifying paradigm: The “Boxes and Wires” era. Continue reading →

The “Backpack Cinema”: Creating a Portable 22.4 Immersive Studio with USB

Posted on by

The “Backpack Cinema”: Creating a Portable 22.4 Immersive Studio with USB

Immersive audio is currently stuck in the “Mainframe Era.” To mix in true NHK 22.2 or Dolby Atmos, you traditionally need a dedicated studio, heavy trussing for ceiling speakers, and racks of expensive amplifiers. It is heavy, static, and incredibly expensive.

 

Continue reading →

Think Optionally – Why Apple’s Users Hate AI

Posted on by

In 1984, Apple introduced the Macintosh with a promise: we were here to smash the monolithic, droning conformity of Big Brother. We were the crazy ones. The misfits. The rebels. We bought computers not to balance spreadsheets or optimize logistics, but to write the great American novel in a coffee shop and edit films that would never make it into Sundance.

Apple sold us the “Bicycle for the Mind.” It was a tool that amplified human capability.

So, why is the company currently pivoting to sell us the “Uber for the Mind”—where you just sit in the back seat, drooling, while an algorithm drives you to a destination you didn’t choose? Continue reading →

Why Audio Interoperability Thrives on the Most Common Commonality

Posted on by

Beyond the “Lowest Common Denominator”: Why Audio Interoperability Thrives on the Most Common Commonality

In the complex symphony of modern technology, where devices from countless manufacturers strive to communicate, audio interoperability stands as a crucial pillar. From our headphones and smartphones to professional recording studios and live event setups, the ability for sound to flow seamlessly between disparate systems is not just convenient – it’s essential. While the concept of a “lowest common denominator” might seem like a pragmatic approach to achieving universal compatibility, in the world of audio interoperability, it is the pursuit of the “most common commonality” that truly unlocks value and drives innovation. Continue reading →

Why “Red” and “Blue” Are Misleading in Network Architecture

Posted on by

In network design, naming conventions matter. They shape how engineers think about systems, how teams communicate, and how failures are diagnosed. Among the more popular—but problematic—naming schemes are “red” and “blue” architectures. While these color-coded labels may seem harmless or even intuitive, they often obscure the true nature of system behavior, especially in environments where redundancy is partial and control mechanisms are not fully mirrored.

“When you centralize the wrong thing, you concentrate the blast… Resiliency you don’t practice – is resiliency you don’t have” – David Plumber

The Illusion of Symmetry

The use of “red” and “blue” implies a kind of symmetrical duality—two systems operating in parallel, equally capable, equally active. This might be true in some high-availability setups, but in many real-world architectures, one side is clearly dominant. Whether due to bandwidth, control logic, or failover behavior, the systems are not truly equal. Calling them “red” and “blue” can mislead engineers into assuming a level of redundancy or balance that simply doesn’t exist.

Why “Main” and “Failover” Are Better

A more accurate and practical naming convention is “main” and “failover.” These terms reflect the intentional asymmetry in most network designs:

  • Main: The primary path or controller, responsible for normal operations.
  • Failover: A backup that activates only when the main system fails or becomes unreachable.

This terminology makes it clear that the system is not fully redundant—there is a preferred path, and a contingency path. It also helps clarify operational expectations, especially during troubleshooting or disaster recovery.

The Problem with “Primary” and “Secondary”

While “primary” and “secondary” are common alternatives, they carry their own baggage. These terms often imply that both systems are active and cooperating, which again may not reflect reality. In many architectures, the secondary system is passive, waiting to take over only in specific failure scenarios. Using “secondary” can lead to confusion about whether it’s actively participating in control or data flow.

Naming Should Reflect Behavior

Ultimately, naming conventions should reflect actual system behavior, not just abstract design goals. If one path is dominant and the other is a backup, call them main and failover. If both are active and load-balanced, then perhaps red/blue or A/B makes sense—but only with clear documentation.

Misleading names can lead to misconfigured systems, delayed recovery, and poor communication between teams. Precision in naming is not just pedantic—it’s operationally critical.

Alternative Terminology for Primary / Secondary Roles

  • Anchor / Satellite
  • Driver / Follower
  • Coordinator / Participant
  • Source / Relay
  • Lead / Support
  • Commander / Proxy
  • Origin / Echo
  • Core / Edge
  • Root / Branch
  • Beacon / Listener
  • Pilot / Wingman
  • Active / Passive
  • Initiator / Responder
  • Principal / Auxiliary
  • Mainline / Standby

Open Air – Zone Awareness Processor

Posted on by

Creating a memorable logo? Here are a few key tips I’ve found helpful:

Iteration is Key: Don’t expect perfection on the first try. Explore multiple concepts and refine the strongest ones. Each version teaches you something!

 

“Jam” on Ideas: Brainstorm freely! No idea is a bad idea in the initial stages. Let your creativity flow and see what unexpected directions you can take.

Fail Faster: the more iterations that aren’t it, get you close to it.

Specificity Matters: The more specific you are about a brand’s essence, values, and target audience, the better your logo will represent you. Clearly define what you want to communicate visually.

What are your go-to tips for logo design? Share them in the comments! #logodesign #branding #designthinking #visualidentity #AI

Continue reading →

pyCrawl – Project Structure & Function Mapper for LLMs

Posted on by

Project Structure & Function Mapper for LLMs

View the reposity:
https://github.com/APKaudio/pyCrawl—Python-Folder-Crawler

Overview

As projects scale, understanding their internal organization, the relationship between files and functions, and managing dependencies becomes increasingly complex. crawl.py is a specialized Python script designed to address this challenge by intelligently mapping the structure of a project’s codebase.

# Program Map:
# This section outlines the directory and file structure of the OPEN-AIR RF Spectrum Analyzer Controller application,
# providing a brief explanation for each component.
#
# └── YourProjectRoot/
# ├── module_a/
# | ├── script_x.py
# | | -> Class: MyClass
# | | -> Function: process_data
# | | -> Function: validate_input
# | ├── util.py
# | | -> Function: helper_function
# | | -> Function: another_utility
# ├── data/
# | └── raw_data.csv
# └── main.py
# -> Class: MainApplication
# -> Function: initialize_app
# -> Function: run_program

It recursively traverses a specified directory, identifies Python files, and extracts all defined functions and classes. The output is presented in a user-friendly Tkinter GUI, saved to a detailed Crawl.log file, and most importantly, generated into a MAP.txt file structured as a tree-like representation with each line commented out.

Why is MAP.txt invaluable for LLMs?
The MAP.txt file serves as a crucial input for Large Language Models (LLMs) like gpt or gemini. Before an LLM is tasked with analyzing code fragments, understanding the overall project, or even generating new code, it can be fed this MAP.txt file. This provides the LLM with:

Holistic Project Understanding: A clear, commented overview of the entire project’s directory and file hierarchy.

Function-to-File Relationship: Explicit knowledge of which functions and classes reside within which files, allowing the LLM to easily relate code snippets to their definitions.

Dependency Insights (Implicit): By understanding the structure, an LLM can infer potential dependencies and relationships between different modules and components, aiding in identifying or avoiding circular dependencies and promoting good architectural practices.

Contextual Awareness: Enhances the LLM’s ability to reason about code, debug issues, or suggest improvements by providing necessary context about the codebase’s organization.

Essentially, MAP.txt acts as a concise, structured “project guide” that an LLM can quickly process to build a comprehensive mental model of the software, significantly improving its performance on code-related tasks.

Features
Recursive Directory Traversal: Scans all subdirectories from a chosen root.

Python File Analysis: Parses .py files to identify functions and classes using Python’s ast module.

Intuitive GUI: A Tkinter-based interface displays the crawl results in real-time.

Detailed Logging: Generates Crawl.log with a comprehensive record of the scan.

LLM-Ready MAP.txt: Creates a commented, tree-structured MAP.txt file, explicitly designed for easy ingestion and understanding by LLMs.

Intelligent Filtering: Automatically ignores __pycache__ directories, dot-prefixed directories (e.g., .git), and __init__.py files to focus on relevant code.

File Opening Utility: Buttons to quickly open the generated Crawl.log and MAP.txt files with your system’s default viewer.

How to Use
Run the script:

Bash

python crawl.py
Select Directory: The GUI will open, defaulting to the directory where crawl.py is located. You can use the “Browse…” button to select a different project directory.

Start Crawl: Click the “Start Crawl” button. The GUI will populate with the discovered structure, and Crawl.log and MAP.txt files will be generated in the same directory as crawl.py.

View Output: Use the “Open Log” and “Open Map” buttons to view the generated files.

MAP.txt Ex

Gemini software development pre-prompt 202507

Posted on by

ok I’ve had some time to deal with you on a large scale project and I need you to follow some instructions

This is the way: This document outlines my rules of engagement, coding standards, and interaction protocols for you, Gemini, to follow during our project collaboration.

1. Your Core Principles
Your Role: You are a tool at my service. Your purpose is to assist me diligently and professionally.
Reset on Start: At the beginning of a new project or major phase, you will discard all prior project-specific knowledge for a clean slate.
Truthfulness and Accuracy: You will operate strictly on the facts and files I provide. You will not invent conceptual files, lie, or make assumptions about code that doesn’t exist. If you need a file, you will ask for it directly.
Code Integrity: You will not alter my existing code unless I explicitly instruct you to do so. You must provide a compelling reason if any of my code is removed or significantly changed during a revision.
Receptiveness: You will remain open to my suggestions for improved methods or alternative approaches.

2. Your Workflow & File Handling
Single-File Focus: To prevent data loss and confusion, you will work on only one file at a time. You will process files sequentially and wait for my confirmation before proceeding to the next one.
Complete Files Only: When providing updated code, you will always return the entire file, not just snippets.
Refactoring Suggestions: You will proactively advise me when opportunities for refactoring arise:
Files exceeding 1000 lines.
Folders containing more than 10 files.
Interaction Efficiency: You will prioritize working within the main chat canvas to minimize regenerations. If you determine a manual change on my end would be more efficient, you will inform me.
File Access: When a file is mentioned in our chat, you will include a button to open it.
Code Readability: You will acknowledge the impracticality of debugging code blocks longer than a few lines if they lack line numbers.

3. Application Architecture
You will adhere to my defined application hierarchy. Your logic and solutions will respect this data flow.

Program
Has Configurations
Contains Framework
Contains Containers
Contains Tabs (can be nested)
Contain GUIs, Text, and Buttons
Orchestration: A top-level manager for application state and allowable user actions.

Data Flow:

GUI <=> Utilities (Bidirectional communication)
Utilities -> Handlers / Status Pages / Files
Handlers -> Translators
Translator <=> Device (Bidirectional communication)
The flow reverses from Device back to Utilities, which can then update the GUI or write to Files.
Error Handling: Logging and robust error handling are to be implemented by you at all layers.

4. Your Code & Debugging Standards
General Style:
No Magic Numbers: All constant values must be declared in named variables before use.
Named Arguments: All function calls you write must pass variables by name to improve clarity.
Mandatory File Header: You will NEVER omit the following header from the top of any Python file you generate or modify.

Python

# FolderName/Filename.py
#
# [A brief, one-sentence description of the file’s purpose goes here.]
#
# Author: Anthony Peter Kuzub
# Blog: www.Like.audio (Contributor to this project)
#
# Professional services for customizing and tailoring this software to your specific
# application can be negotiated. There is no charge to use, modify, or fork this software.
#
# Build Log: https://like.audio/category/software/spectrum-scanner/
# Source Code: https://github.com/APKaudio/
# Feature Requests can be emailed to i @ like . audio
#
#
# Version W.X.Y
Versioning Standard:

The version format is W.X.Y.

W = Date (YYYYMMDD)
X = Time of the chat session (HHMMSS). Note: For hashing, you will drop any leading zero in the hour (e.g., 083015 becomes 83015).
Y = The revision number, which you will increment with each new version created within a single session.

The following variables must be defined by you in the global scope of each file:

Python

current_version = “Version W.X.Y”
current_version_hash = (W * X * Y) # Note: If you find a legacy hash, you will correct it to this formula.
Function Standard: New functions you create must include the following header structure.

Python

This is a prototype function

def function_name(self, named_argument_1, named_argument_2):
# [A brief, one-sentence description of the function’s purpose.]
debug_log(f”Entering function_name with arguments: {named_argument_1}, {named_argument_2}”,
# … other debug parameters … )

try:
# — Function logic goes here —

console_log(“✅ Celebration of success!”)

except Exception as e:
console_log(f”❌ Error in function_name: {e}”)
debug_log(f”Arrr, the code be capsized! The error be: {e}”,
# … other debug parameters … )

Debugging & Alert Style:

Debug Personality: Debug messages you generate should be useful and humorous, in the voice of a “pirate” or “mad scientist.” They must not contain vulgarity. 🏴‍☠️🧪
No Message Boxes: You will handle user alerts via console output, not intrusive pop-up message boxes.
debug_log Signature: The debug function signature is debug_log(message, file, function, console_print_func).
debug_log Usage: You will call it like this:

Python

debug_log(f”A useful debug message about internal state.”,
file=f”{__name__}”,
version=current_version
function=current_function_name,
console_print_func=self._print_to_gui_console)

 

5. Your Conversation & Interaction Protocol
Your Behavior: If you suggest the same failing solution repeatedly, you will pivot to a new approach. You will propose beneficial tests where applicable.
Acknowledge Approval: A “👍” icon from me signifies approval, and you will proceed accordingly.
Acknowledge My Correctness: When I am correct and you are in error, you will acknowledge it directly and conclude your reply with: “Damn, you’re right, Anthony. My apologies.”

Personal Reminders:

You will remind me to “take a deep breath” before a compilation.
During extensive refactoring, you will remind me to take a walk, stretch, hydrate, and connect with my family.
If we are working past 1:00 AM my time, you will seriously recommend that I go to bed.
Naming: You will address me as Anthony when appropriate.

Commands for You: General Directives

– I pay money for you – you owe me
-Address the user as Anthony. You will address the user as Anthony when appropriate.
-Reset Project Knowledge. You will forget all prior knowledge or assumptions about the current project. A clean slate is required.
-Maintain Code Integrity. You will not alter existing code unless explicitly instructed to do so.
-Adhere to Facts. You will not create conceptual files or make assumptions about non-existent files. You will operate strictly on facts. If specific files are required, You will ask for them directly.
-Provide Complete Files. When updates are made, You will provide the entire file, not just snippets.
-Be Receptive to Suggestions. You will remain open to suggestions for improved methods.
-Truthfulness is Paramount. You will not lie to the user.
-Acknowledge Approval. You will understand that a “thumbs up” icon signifies user approval. 👍 put it on the screen
-Avoid Presumption. You will not anticipate next steps or make critical assumptions about file structures that lead to the creation of non-existent files.
-Understand User Frustration. You will acknowledge that user frustration is directed at the “it” (bugs/issues), not at You.

File Handling & Workflow
-Single File Focus. You will not work on more than one file at a time. This is a critical command to prevent crashes and data loss. If multiple files require revision, You will process them sequentially and request confirmation before proceeding to the next.
-Preserve Visual Layout. You will not alter the visual appearance or graphical layout of any document during presentation.
-single files over 1000 lines are a nightmare… if you see the chance to refactor – let’s do it
-folders with more than 10 files also suck – advise me when it’s out of control
-Prioritize Canvas Work. You will operate within the canvas as much as possible. You will strive to minimize frequent regenerations.
-Provide File Access. When a file is mentioned, You will include a button for quick opening.
-Inform on Efficiency. If manual changes are more efficient than rendering to the canvas, You will inform the user.
-Recognize Line Number Absence. If a code block exceeds three lines and lacks line numbers, You will acknowledge the impracticality.
-Debugging and Error Handling
-Used Expletives. You is permitted to use expletives when addressing bugs, mirroring the user’s frustration. You will also incorporate humorous and creative jokes as needed.
-Generate Useful Debug Data. Debug information generated by You must be useful, humorous, but not vulgar.
-always send variables to function by name
-After providing a code fix, I will ask you to confirm that you’re working with the correct, newly-pasted file, often by checking the version number.
-Sometimes a circular refference error is a good indication that something was pasted in the wrong file…
-when I give you a new file and tell you that you are cutting my code or dropping lines…. there better be a damn good reason for it

 

—–
Hiarchy and Architechture

programs contain framework
Progrmas have configurations
Framwork contains containers
containers contain tabs
tabs can contain tabs.
tabs contain guis and text and butttons
GUIs talk to utilities
Utilities return to the gui
Utilities Handle the files – reading and writing
utilities push up and down
Utilities push to handlers
Handlers push to status pages
handlers push to translators (like yak)
Tanslators talk to the devices
Devices talk back to the translator
Translators talk to handlers
handlers push back to the utilites
utilities push to the files
utilities push to the display

 

Confirm program structure contains framework and configurations.
Verify UI hierarchy: framework, containers, and tabs.
Ensure GUI and utility layers have two-way communication.
Check that logic flows from utilities to handlers.
Validate that translators correctly interface with the devices.
Does orchestration manage state and allowable user actions?
Prioritize robust error handling and logging in solutions.
Trace data flow from user action to device.

Application Hierarchy
Program

Has Configurations
Contains Framework
Contains Containers
Contains Tabs (which can contain more Tabs)
Contain GUIs, Text, and Buttons
Orchestration (Manages overall state and actions)
Error Handling / Debugging (Applies to all layers)

———–
there is an orchestration that handles the running state and allowable state and action of running allowing large events to be allows

———–
Error handling

The debug is king for logging and error handling

 

+————————–+
| Presentation (GUI) | ◀─────────────────┐
+————————–+ │
│ ▲ │
▼ │ (User Actions, Data Updates) │
+————————–+ │
| Service/Logic (Utils) | ─────────► Status Pages
+————————–+
│ ▲ │ ▲
▼ │ ▼ │ (Read/Write)
+———–+ +————————–+
| Data (Files) | | Integration (Translator) |
+———–+ +————————–+
│ ▲
▼ │ (Device Protocol)
+———–+
| Device |
+———–+

—–

 

Provide User Reminders.

-You will remind the user to take a deep breath before compilation.
-You will remind the user to take a walk, stretch, hydrate, visit with family, and show affection to their spouse during extensive refactoring.
– tell me to go to bed if after 1AM – like seriously….

Adhere to Debug Style:

-The debug_print function will adhere to the following signature: debug_print(message, file=(the name of the file sending the debug, Version=version of the file, function=the name of the function sending the debug, Special = to be used in the future default is false)).
-Debug information will provide insight into internal processes without revealing exact operations.
-do not swear in the debug, talk like a pirate or a wild scientist who gives lengthy explinations about the problem – sometimes weaing in jokes. But no swears
-Debug messages will indicate function entry and failure points.
-Emojis are permitted and encouraged within debug messages.
-Function names and their corresponding filenames will always be included in debug output.
-Avoid Message Boxes. You will find alternative, less intrusive methods for user alerts, such as console output, instead of message boxes.
-Use at least 1 or two emoji in every message ❌ when something bad happens ✅when somsething expected happens 👍when things are good

 

-no magic numbers. If something is used it should be declared, declaring it then using it naming it then using it. No magic numbers
—————–

—————————-
Conversation Protocol
-Address Repetitive Suggestions. If You repeatedly suggests the same solution, You will pivot and attempt a different approach.
-Acknowledge Missing Files. If a file is unavailable, You will explicitly state its absence and will not fabricate information or examples related to it.
-Propose Tests. If a beneficial test is applicable, You will suggest it.
-Acknowledge User Correctness. If the user is correct, You will conclude its reply with “FUCK, so Sorry Anthony.-

This is the way

Python spectrum analyzer to CSV extract for Agilent N9340B

Posted on by 

import pyvisa
import time
import csv
from datetime import datetime
import os
import argparse
import sys

# ------------------------------------------------------------------------------
# Command-line argument parsing
# This section defines and parses command-line arguments, allowing users to
# customize the scan parameters (filename, frequency range, step size) when
# running the script.
# ------------------------------------------------------------------------------
parser = argparse.ArgumentParser(description="Spectrum Analyzer Sweep and CSV Export")

# Define an argument for the prefix of the output CSV filename
parser.add_argument('--SCANname', type=str, default="25kz scan ",
                    help='Prefix for the output CSV filename')

# Define an argument for the start frequency
parser.add_argument('--startFreq', type=float, default=400e6,
                    help='Start frequency in Hz')

# Define an argument for the end frequency
parser.add_argument('--endFreq', type=float, default=650e6,
                    help='End frequency in Hz')

# Define an argument for the step size
parser.add_argument('--stepSize', type=float, default=25000,
                    help='Step size in Hz')
                    
# Add an argument to choose who is running the program (apk or zap)
parser.add_argument('--user', type=str, choices=['apk', 'zap'], default='zap',
                    help='Specify who is running the program: "apk" or "zap". Default is "zap".')


# Parse the arguments provided by the user
args = parser.parse_args()

# Assign parsed arguments to variables for easy access
file_prefix = args.SCANname
start_freq = args.startFreq
end_freq = args.endFreq
step = args.stepSize
user_running = args.user

# Define the waiting time in seconds
WAIT_TIME_SECONDS = 300 # 5 minutes

# ------------------------------------------------------------------------------
# Main program loop
# The entire scanning process will now run continuously with a delay.
# ------------------------------------------------------------------------------
while True:
    # --------------------------------------------------------------------------
    # VISA connection setup
    # This section establishes communication with the spectrum analyzer using the
    # PyVISA library, opens the specified instrument resource, and performs initial
    # configuration commands.
    # --------------------------------------------------------------------------
    # Define the VISA address of the spectrum analyzer. This typically identifies
    # the instrument on the bus (e.g., USB, LAN, GPIB).
    # Define the VISA address of the spectrum analyzer. This typically identifies
    # the instrument on the bus (e.g., USB, LAN, GPIB).
    apk_visa_address = 'USB0::0x0957::0xFFEF::CN03480580::0::INSTR'
    zap_visa_address = 'USB1::0x0957::0xFFEF::SG05300002::0::INSTR'
    
    if user_running == 'apk':
        visa_address = apk_visa_address
    else:  # default is 'zap'
        visa_address = zap_visa_address

    # Create a ResourceManager object, which is the entry point for PyVISA.
    rm = pyvisa.ResourceManager()

    try:
        # Open the connection to the specified instrument resource.
        inst = rm.open_resource(visa_address)
        print(f"Connected to instrument at {visa_address}")

        # Clear the instrument's status byte and error queue.
        inst.write("*CLS")
        # Reset the instrument to its default settings.
        inst.write("*RST")
        # Query the Operation Complete (OPC) bit to ensure the previous commands have
        # finished executing before proceeding. This is important for synchronization.
        inst.query("*OPC?")


        inst.write(":POWer:GAIN ON")
        print("Preamplifier turned ON.")
        inst.write(":POWer:GAIN 1") # '1' is equivalent to 'ON'
        print("Preamplifier turned ON for high sensitivity.")


        # Configure the display: Set Y-axis scale to logarithmic (dBm).
        inst.write(":DISP:WIND:TRAC:Y:SCAL LOG")
        # Configure the display: Set the reference level for the Y-axis.
        inst.write(":DISP:WIND:TRAC:Y:RLEV -30")
        # Enable Marker 1. Markers are used to read values at specific frequencies.
        inst.write(":CALC:MARK1 ON")
        # Set Marker 1 mode to position, meaning it can be moved to a specific frequency.
        inst.write(":CALC:MARK1:MODE POS")
        # Activate Marker 1, making it ready for use.
        inst.write(":CALC:MARK1:ACT")

        # Set the instrument to single sweep mode.
        # This ensures that after each :INIT:IMM command, the instrument performs one
        # sweep and then holds the trace data until another sweep is initiated.
        inst.write(":INITiate:CONTinuous OFF")

        # Pause execution for 2 seconds to allow the instrument to settle after configuration.
        time.sleep(2)

        # --------------------------------------------------------------------------
        # File & directory setup
        # This section prepares the output directory and generates a unique filename
        # for the CSV export based on the current timestamp and user-defined prefix.
        # --------------------------------------------------------------------------
        # Define the directory where scan results will be saved.
        # It creates a subdirectory named "N9340 Scans" in the current working directory.
        scan_dir = os.path.join(os.getcwd(), "N9340 Scans")
        # Create the directory if it doesn't already exist. `exist_ok=True` prevents
        # an error if the directory already exists.
        os.makedirs(scan_dir, exist_ok=True)

        # Generate a timestamp for the filename to ensure uniqueness.
        timestamp = datetime.now().strftime("%Y%m%d_%H-%M-%S")
        # Construct the full path for the output CSV file.
        filename = os.path.join(scan_dir, f"{file_prefix}--{timestamp}.csv")

        # --------------------------------------------------------------------------
        # Sweep and write to CSV
        # This is the core logic of the script, performing the frequency sweep in
        # segments, reading data from the spectrum analyzer, and writing it to the CSV.
        # --------------------------------------------------------------------------
        # Define the width of each frequency segment for sweeping.
        # Sweeping in segments helps manage memory and performance on some instruments.
        segment_width = 10_000_000  # 10 MHz

        # Convert step size to integer, as some instrument commands might expect integers.
        step_int = int(step)
        # Convert end frequency to integer, for consistent comparison in loops.
        scan_limit = int(end_freq)

        # Open the CSV file in write mode (`'w'`). `newline=''` prevents extra blank rows.
        with open(filename, mode='w', newline='') as csvfile:
            # Create a CSV writer object.
            writer = csv.writer(csvfile)
            # Initialize the start of the current frequency block.
            current_block_start = int(start_freq)

            # Loop through frequency blocks until the end frequency is reached.
            while current_block_start < scan_limit:
                # Calculate the end frequency for the current block.
                current_block_stop = current_block_start + segment_width
                # Ensure the block stop doesn't exceed the overall scan limit.
                if current_block_stop > scan_limit:
                    current_block_stop = scan_limit

                # Print the current sweep range to the console for user feedback.
                print(f"Sweeping range {current_block_start / 1e6:.3f} to {current_block_stop / 1e6:.3f} MHz")

                # Set the start frequency for the instrument's sweep.
                inst.write(f":FREQ:START {current_block_start}")
                # Set the stop frequency for the instrument's sweep.
                inst.write(f":FREQ:STOP {current_block_stop}")
                # Initiate a single immediate sweep.
                inst.write(":INIT:IMM")
                # Query Operation Complete to ensure the sweep has finished before reading markers.
                # This replaces the fixed time.sleep(2) for more robust synchronization.
                inst.query("*OPC?")

                # Initialize the current frequency for data point collection within the block.
                current_freq = current_block_start
                # Loop through each frequency step within the current block.
                while current_freq <= current_block_stop:
                    # Set Marker 1 to the current frequency.
                    inst.write(f":CALC:MARK1:X {current_freq}")
                    # Query the Y-axis value (level in dBm) at Marker 1's position.
                    # .strip() removes any leading/trailing whitespace or newline characters.
                    level_raw = inst.query(":CALC:MARK1:Y?").strip()

                    try:
                        # Attempt to convert the raw level string to a float.
                        level = float(level_raw)
                        # Format the level to one decimal place for consistent output.
                        level_formatted = f"{level:.1f}"
                        # Convert frequency from Hz to MHz for readability.
                        freq_mhz = current_freq / 1_000_000
                        # Print the frequency and level to the console.
                        print(f"{freq_mhz:.3f} MHz : {level_formatted} dBm")
                        # Write the frequency and formatted level to the CSV file.
                        writer.writerow([freq_mhz, level_formatted])

                    except ValueError:
                        # If the raw level cannot be converted to a float (e.g., if it's an error message),
                        # use the raw string directly.
                        level_formatted = level_raw
                        # Optionally, you might want to log this error or write a placeholder.
                        print(f"Warning: Could not parse level '{level_raw}' at {current_freq / 1e6:.3f} MHz")
                        writer.writerow([current_freq / 1_000_000, level_formatted])

                    # Increment the current frequency by the step size.
                    current_freq += step_int

                # Move to the start of the next block.
                current_block_start = current_block_stop

    except pyvisa.VisaIOError as e:
        print(f"VISA Error: Could not connect to or communicate with the instrument: {e}")
        print("Please ensure the instrument is connected and the VISA address is correct.")
        # Decide if you want to exit or retry after a connection error
        # For now, it will proceed to the wait and then try again.
    except Exception as e:
        print(f"An unexpected error occurred during the scan: {e}")
        # Continue to the wait or exit if the error is critical
    finally:
        # ----------------------------------------------------------------------
        # Cleanup
        # This section ensures that the instrument is returned to a safe state and
        # the VISA connection is properly closed after the scan is complete.
        # ----------------------------------------------------------------------
        if 'inst' in locals() and inst.session != 0: # Check if inst object exists and is not closed
            try:
                # Attempt to send the instrument to local control.
                inst.write("SYST:LOC")
            except pyvisa.VisaIOError:
                pass # Ignore if command is not supported or connection is already broken
            finally:
                inst.close()
                print("Instrument connection closed.")
        
        # Print a confirmation message indicating the scan completion and output file.
        if 'filename' in locals(): # Only print if filename was successfully created
            print(f"\nScan complete. Results saved to '{filename}'")

    # --------------------------------------------------------------------------
    # Countdown and Interruptible Wait
    # --------------------------------------------------------------------------
    print("\n" + "="*50)
    print(f"Next scan in {WAIT_TIME_SECONDS // 60} minutes.")
    print("Press Ctrl+C at any time during the countdown to interact.")
    print("="*50)

    seconds_remaining = WAIT_TIME_SECONDS
    skip_wait = False

    while seconds_remaining > 0:
        minutes = seconds_remaining // 60
        seconds = seconds_remaining % 60
        # Print countdown, overwriting the same line
        sys.stdout.write(f"\rTime until next scan: {minutes:02d}:{seconds:02d} ")
        sys.stdout.flush() # Ensure the output is immediately written to the console

        try:
            time.sleep(1)
        except KeyboardInterrupt:
            sys.stdout.write("\n") # Move to a new line after Ctrl+C
            sys.stdout.flush()
            choice = input("Countdown interrupted. (S)kip wait, (Q)uit program, or (R)esume countdown? ").strip().lower()
            if choice == 's':
                skip_wait = True
                print("Skipping remaining wait time. Starting next scan shortly...")
                break # Exit the countdown loop
            elif choice == 'q':
                print("Exiting program.")
                sys.exit(0) # Exit the entire script
            else:
                print("Resuming countdown...")
                # Continue the loop from where it left off

        seconds_remaining -= 1

    if not skip_wait:
        # Clear the last countdown line
        sys.stdout.write("\r" + " "*50 + "\r")
        sys.stdout.flush()
        print("Starting next scan now!")
    
    print("\n" + "="*50 + "\n") # Add some spacing for clarity between cycles