Empowering the user

Empowering the User: The Boeing vs. Airbus Philosophy in Software and Control System Design

In the world of aviation, the stark philosophical differences between Boeing and Airbus control systems offer a profound case study for user experience (UX) design in software and control systems. It’s a debate between tools that empower the user with ultimate control and intelligent assistance versus those that abstract away complexity and enforce protective boundaries. This fundamental tension – enabling vs. doing – is critical for any designer aiming to create intuitive, effective, and ultimately trusted systems.

The Core Dichotomy: Enablement vs. Automation

At the heart of the aviation analogy is the distinction between systems designed to enable a highly skilled user to perform their task with enhanced precision and safety, and systems designed to automate tasks, protecting the user from potential errors even if it means ceding some control.

Airbus: The “Doing It For You” Approach

Imagine a powerful, intelligent assistant that anticipates your needs and proactively prevents you from making mistakes. This is the essence of the Airbus philosophy, particularly in its “Normal Law” flight controls.

The Experience: The pilot provides high-level commands via a side-stick, and the computer translates these into safe, optimized control surface movements, continuously auto-trimming the aircraft.

The UX Takeaway:

Pros: Reduces workload, enforces safety limits, creates a consistent and predictable experience across the fleet, and can be highly efficient in routine operations. For novice users or high-stress environments, this can significantly lower the barrier to entry and reduce the cognitive load.

Cons: Can lead to a feeling of disconnect from the underlying mechanics. When something unexpected happens, the user might struggle to understand why the system is behaving a certain way or how to override its protective actions. The “unlinked” side-sticks can also create ambiguity in multi-user scenarios.

Software Analogy: Think of an advanced AI writing assistant that not only corrects grammar but also rewrites sentences for clarity, ensures brand voice consistency, and prevents you from using problematic phrases – even if you intended to use them for a specific effect. It’s safe, but less expressive. Or a “smart home” system that overrides your thermostat settings based on learned patterns, even when you want something different.

Boeing: The “Enabling You to Do It” Approach

Now, consider a sophisticated set of tools that amplify your skills, provide real-time feedback, and error-check your inputs, but always leave the final decision and physical control in your hands. This mirrors the Boeing philosophy.

The Experience: Pilots manipulate a traditional, linked yoke. While fly-by-wire technology filters and optimizes inputs, the system generally expects the pilot to manage trim and provides “soft limits” that can be overridden with sufficient force. The system assists, but the pilot remains the ultimate authority.

The UX Takeaway:

Pros: Fosters a sense of control and mastery, provides direct feedback through linked controls, allows for intuitive overrides in emergencies, and maintains the mental model of direct interaction. For expert users, this can lead to greater flexibility and a deeper understanding of the system’s behavior.

Cons: Can have a steeper learning curve, requires more active pilot management (e.g., trimming), and places a greater burden of responsibility on the user to stay within safe operating limits.

Software Analogy: This is like a professional photo editing suite where you have granular control over every aspect of an image. The software offers powerful filters and intelligent adjustments, but you’re always the one making the brush strokes, adjusting sliders, and approving changes. Or a sophisticated IDE (Integrated Development Environment) for a programmer: it offers powerful auto-completion, syntax highlighting, and debugging tools, but doesn’t write the code for you or prevent you from making a logical error, allowing you to innovate.

Designing for Trust: Error Checking Without Taking Over

The crucial design principle emerging from this comparison is the need for systems that provide robust error checking and intelligent assistance while preserving the user’s ultimate agency. The goal should be to create “smart tools,” not “autonomous overlords.”

Key Design Principles for Empowerment:

Transparency and Feedback: Users need to understand what the system is doing and why. Linked yokes provide immediate physical feedback. In software, this translates to clear status indicators, activity logs, and explanations for automated actions. If an AI suggests a change, explain its reasoning.

Soft Limits, Not Hard Gates: While safety is paramount, consider whether a protective measure should be an absolute barrier or a strong suggestion that can be bypassed in exceptional circumstances. Boeing’s “soft limits” allow pilots to exert authority when necessary. In software, this might mean warning messages instead of outright prevention, or giving the user an “override” option with appropriate warnings.

Configurability and Customization: Allow users to adjust the level of automation and assistance. Some users prefer more guidance, others more control. Provide options to switch between different “control laws” or modes that align with their skill level and current task.

Preserve Mental Models: Whenever possible, build upon existing mental models. Boeing’s yoke retains a traditional feel. In software, this means using familiar metaphors, consistent UI patterns, and avoiding overly abstract interfaces that require relearning fundamental interactions.

Enable, Don’t Replace: The most powerful tools don’t do the job for the user; they enable the user to do the job better, faster, and more safely. They act as extensions of the user’s capabilities, not substitutes.

The Future of UX: A Hybrid Approach

Ultimately, neither pure “Airbus” nor pure “Boeing” is universally superior. The ideal UX often lies in a hybrid approach, intelligently blending the strengths of both philosophies. For routine tasks, automation and protective limits are incredibly valuable. But when the unexpected happens, or when creativity and nuanced judgment are required, the system must gracefully step back and empower the human creator.

Designers must constantly ask: “Is this tool serving the user’s intent, or is it dictating it?” By prioritizing transparency, configurable assistance, and the user’s ultimate authority, we can build software and control systems that earn trust, foster mastery, and truly empower those who use them.

pyCrawl – Project Structure & Function Mapper for LLMs

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

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

🚫🐛 Why This Tiny Debug Statement Changed Everything for Me

Want to level up your debugging with LLM copilots?
Give your logs structure. Give them context. Make them readable.
And yes — make them beautiful too.
🚫🐛 04.31 [engine.py:start_motor] Voltage too low

That one line might save you hours.

I learned a very valuable lesson working with large language models (LLMs) like Gemini (and honestly, ChatGPT too): clear, consistent, and machine-readable debug messages can massively speed up troubleshooting — especially on complex, multi-file projects.

It’s something I used to do occasionally… but when I leaned into it fully while building a large system, the speed and accuracy of LLM-assisted debugging improved tenfold. Here’s the trick:

python
print(f"🚫🐛 {timestamp} [{filename}:{function}] {message}")

This tiny statement prints:

  • A visual marker (🚫🐛) so debug logs stand out,

  • A timestamp (MM.SS) to see how things flow in time,

  • The file name and function name where the debug is triggered,

  • And finally, the actual message.

All this context gives the LLM words it can understand. It’s no longer guessing what went wrong — it can “see” the chain of events in your logs like a human would.


Why It Works So Well with LLMs

LLMs thrive on language. When you embed precise context in your debug prints, the model can:

  • Track logic across files,

  • Understand where and when things fail,

  • Spot async/flow issues you missed,

  • Suggest exact fixes — not guesses.


Python spectrum analyzer to CSV extract for Agilent N9340B

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

TWiRT 712 – Fun with AI Inspires Broadcast Engineers – Matt Aaron & Anthony Kuzub

The rise of AI-generated lyrics and music is giving engineers something to chuckle about. But could this “easy creativity” inspire other engineering solutions? Kirk drew a comparison with photographer Jeremy Cowart and his use of an LED wall to produce 60 different portraits in 60 seconds. Anthony Kuzub, an engineer at CBC in Canada, pointed out the AI that’s involved with lighting a new studio, matching accent lights to the video monitor feeds. Matt Aaron is programming a fully-AI streaming station that’s playing “Broadcast Engineers Gangster Rap”. Are these just passing curiosities? Or are they signals of technologies and techniques to come for broadcasting and content creation?

Show notes: “The Legend of Chris Tarr” from suno.com https://suno.com/song/ecb43422-a9a0-4…

And another version of “The Legend of Chris Tarr” https://suno.com/song/9f924c42-c5b7-4… Matt Aaron’s AI-music streaming station https://broadcastengineeringgangsters…

And if Kirk had a radio station, KIRK, this could be the theme song https://suno.com/song/7e61f354-34e0-4…

Anthony mentioned ElevenLabs for text-to-speech and AI voice generation https://elevenlabs.io/

Anthony noted the Roland VC-1-DMX video lighting converter https://proav.roland.com/global/produ…

 

Arduino sketch – keyboard keys pressed with gpi

#include KEYBOARD.h

const int F9_PIN = 2;
const int F10_PIN = 3;
const int F9_LED_PIN = 4;
const int F10_LED_PIN = 5;

void setup() {
Keyboard.begin();
pinMode(F9_PIN, INPUT_PULLUP);
pinMode(F10_PIN, INPUT_PULLUP);
pinMode(F9_LED_PIN, OUTPUT);
pinMode(F10_LED_PIN, OUTPUT);
}

void loop() {
if (digitalRead(F9_PIN) == LOW) {
Keyboard.press(KEY_F9);
digitalWrite(F9_LED_PIN, HIGH);
delay(100);
Keyboard.release(KEY_F9);
digitalWrite(F9_LED_PIN, LOW);
}

if (digitalRead(F10_PIN) == LOW) {
Keyboard.press(KEY_F10);
digitalWrite(F10_LED_PIN, HIGH);
delay(100);
Keyboard.release(KEY_F10);
digitalWrite(F10_LED_PIN, LOW);
}
}

Arduino Project – Digitally Controlled Analog Surround Sound Panning – Open Source

For your enjoyment:

Digitally Controlled Analog Surround Sound Panning

 

Presentation:

 

Circuit Explination:

 

Presentation documents:

0 – TPJ – Technical Presentation

0 – TPJ556-FINAL report DCASSP-COMPLETE

0 – TPJ556-FINAL report DCASSP-SCHEMATICS V1

 

 

Project Source Code:

Continue reading

Generating Code with spreadsheet for Keyboard Assignments of CADSOFT Eagle

I needed a way of Generating Code, lots of code.   In cadsoft eagle, the Keyboard Assignments are completely user customizable.  They have a script language that allows you to modify the software.  I’ve used hundreds of the ULP and SCRs and decided to write my own Generator.

Necessity is the mother of all innovation.  Screen Shot 2015-09-14 at 12.56.34 AM Screen Shot 2015-09-14 at 12.56.45 AM Screen Shot 2015-09-14 at 12.56.52 AM Screen Shot 2015-09-14 at 12.56.59 AM Screen Shot 2015-09-14 at 12.57.04 AM Screen Shot 2015-09-14 at 12.58.37 AM Screen Shot 2015-09-14 at 12.58.44 AM Screen Shot 2015-09-14 at 12.58.50 AM

 

On Compressing the English Language

Someone picked my brain the other day looking for a technique to compress language files.

After walking away to think about it… my method was to re-order the ASCII code to the letters by their frequency and the most common words by their frequency.

Where lowercase e is stored as an ASCII value using 1 byte
ASCII  e = 0x61 = 0b1100001 = 7 bits
vs
APK e = 0x1 = 1 bit

… this method stores an E in 1 bit.  This is similar to the Huffman Code with the addition of whole words being included in the code.

For example:

because” is the 94th most used word in the english language and in this method is stored in 7 bits.

I don’t know if this has been done before… but I would imagine it could compress Language files substantially.

I have thought about a third addition of using the most used 2 or three letter combinations commonly used.

APK ORDER APK LET FREQ WORD FEQ APK BIN APK HEX APK BITS USED
0 space 0 0 1
1 e 12.70% 1 1 1
2 t 9.06% 10 2 2
3 a 8.17% 11 3 2
4 o 7.51% 100 4 3
5 i 6.97% 101 5 3
6 n 6.75% 110 6 3
7 s 6.33% 111 7 3
8 h 6.09% 1000 8 4
9 r 5.99% 1001 9 4
10 d 4.25% 1010 A 4
11 l 4.03% 1011 B 4
12 c 2.78% 1100 C 4
13 u 2.76% 1101 D 4
14 m 2.41% 1110 E 4
15 w 2.36% 1111 F 4
16 f 2.23% 10000 10 5
17 g 2.02% 10001 11 5
18 y 1.97% 10010 12 5
19 p 1.93% 10011 13 5
20 b 1.49% 10100 14 5
21 v 0.98% 10101 15 5
22 k 0.77% 10110 16 5
23 j 0.15% 10111 17 5
24 x 0.15% 11000 18 5
25 q 0.10% 11001 19 5
26 z 0.07% 11010 1A 5
27 the 1 11011 1B 5
28 be 2 11100 1C 5
29 to 3 11101 1D 5
30 of 4 11110 1E 5
31 and 5 11111 1F 5
32 a 6 100000 20 6
33 in 7 100001 21 6
34 that 8 100010 22 6
35 have 9 100011 23 6
36 I 10 100100 24 6
37 it 11 100101 25 6
38 for 12 100110 26 6
39 not 13 100111 27 6
40 on 14 101000 28 6
41 with 15 101001 29 6
42 he 16 101010 2A 6
43 as 17 101011 2B 6
44 you 18 101100 2C 6
45 do 19 101101 2D 6
46 at 20 101110 2E 6
47 this 21 101111 2F 6
48 but 22 110000 30 6
49 his 23 110001 31 6
50 by 24 110010 32 6
51 from 25 110011 33 6
52 they 26 110100 34 6
53 we 27 110101 35 6
54 say 28 110110 36 6
55 her 29 110111 37 6
56 she 30 111000 38 6
57 or 31 111001 39 6
58 an 32 111010 3A 6
59 will 33 111011 3B 6
60 my 34 111100 3C 6
61 one 35 111101 3D 6
62 all 36 111110 3E 6
63 would 37 111111 3F 6
64 there 38 1000000 40 7
65 their 39 1000001 41 7
66 what 40 1000010 42 7
67 so 41 1000011 43 7
68 up 42 1000100 44 7
69 out 43 1000101 45 7
70 if 44 1000110 46 7
71 about 45 1000111 47 7
72 who 46 1001000 48 7
73 get 47 1001001 49 7
74 which 48 1001010 4A 7
75 go 49 1001011 4B 7
76 me 50 1001100 4C 7
77 when 51 1001101 4D 7
78 make 52 1001110 4E 7
79 can 53 1001111 4F 7
80 like 54 1010000 50 7
81 time 55 1010001 51 7
82 no 56 1010010 52 7
83 just 57 1010011 53 7
84 him 58 1010100 54 7
85 know 59 1010101 55 7
86 take 60 1010110 56 7
87 people 61 1010111 57 7
88 into 62 1011000 58 7
89 year 63 1011001 59 7
90 your 64 1011010 5A 7
91 good 65 1011011 5B 7
92 some 66 1011100 5C 7
93 could 67 1011101 5D 7
94 them 68 1011110 5E 7
95 see 69 1011111 5F 7
96 other 70 1100000 60 7
97 than 71 1100001 61 7
98 then 72 1100010 62 7
99 now 73 1100011 63 7
100 look 74 1100100 64 7
101 only 75 1100101 65 7
102 come 76 1100110 66 7
103 its 77 1100111 67 7
104 over 78 1101000 68 7
105 think 79 1101001 69 7
106 also 80 1101010 6A 7
107 back 81 1101011 6B 7
108 after 82 1101100 6C 7
109 use 83 1101101 6D 7
110 two 84 1101110 6E 7
111 how 85 1101111 6F 7
112 our 86 1110000 70 7
113 work 87 1110001 71 7
114 first 88 1110010 72 7
115 well 89 1110011 73 7
116 way 90 1110100 74 7
117 even 91 1110101 75 7
118 new 92 1110110 76 7
119 want 93 1110111 77 7
120 because 94 1111000 78 7
121 any 95 1111001 79 7
122 these 96 1111010 7A 7
123 give 97 1111011 7B 7
124 day 98 1111100 7C 7
125 most 99 1111101 7D 7
126 use 100 1111110 7E 7

GREEN HOME MONITORING SYSTEM

Title: GREEN HOME MONITORING SYSTEM – TRANSMITTER
Author: ANTHONY P KUZUB
DATE: 2015 04 01
Description:

REMOTE MONITORING TRANSMITTER

The GREEN HOME MONITORING SYSTEM controls, monitors then transmits the
status of three room lights to a remote monitoring station.

The code below is the local control and transmitter

Three light switches along with motion sensors control the functionality
of the rooms lights.

When the system is enabled:
The light turns on When motion is detected.
Once motion is detected a five second counter Starts.
If motion is not detected within the five seconds The light shut
off saving power.

When the system is disabled:
The light switch controls The light Directly.

A Peak Power cost value is captured based on the time of day.
To Test this feature: apply a slowly 10mHz Sine wave 1.25
Vpp with offset of 0.625V offset to TP7

This moving sine wave is converted to digital by means of A/D convertor

This power cost value is displayed on the segment display
Indicating the value of power throughout the day.

The Status of The System state, switch position, motion detection, Light
status, and Energy cost, are transmitted to a remote monitoring station
via serial port 1.

 

0 - main 1- ZeroVariables 2 - DefineHardware 3 - SystemEnableCheck 4 - Power Sample 5 - Room 1 Check 6 - Room 2 Check 7 - Room 3 Check 8 - EncodeTransmissionData 9 - Transmit 10 - Diagnostics

 

 

TRANSMIT TRUTH TABLE

 

Title: GREEN HOME MONITORING SYSTEM – RECEIVER
Author: ANTHONY P KUZUB
DATE: 2015 04 01
Description:

The GREEN HOME MONITORING SYSTEM controls, monitors then transmits the
status of three room lights to a remote monitoring station.

The code below is the remote monitoring station

This program receives 2 bytes of data from the transmitter through
Serial port 1. The data is decoded and displayed on a screen by access
of serial port 2 of the controller.

A workstations TERMINAL session connects a a com port to the hardware receiver.

SESSION CONFIGURATION:
BAUD RATE: 9600
DATA BITS: 8
PARITY: NONE
FLOW CONTROL: NONE
EMULATION: ANSI

The Status of the system, switch positions, motion detection, Light status,
and Energy PEAK VALUE displayed on the terminal screen.

Screen Layout

A Changing Peak Power cost is applied proportionaly to room cost acumulators.

By Pressing the respective key on the terminal keyboard, the rooms cost will
reset to zero.

Please note that with the exception of the push buttons all states are
ACTIVE HIGH

 

0 - main 1 - ZeroVariable 2 - Initialize Devices 3 - Paint Screen 4 - Receive 5 - DecodeReceivedData 6 - KeyboardCheck 7 - ScreenUpdateStatus 8 - ScreenUpdateLight 9 - ScreenUpdateCost 10 - scr_writech 11 - KeyPress 12 - Diagnostics