Staff Assign: Automating Nurse Assignments

Background

This project automates nurse staffing assignments in an ICU by integrating patient acuity, pod constraints, device rotation, and leadership roles into a unified system. Built using Google Apps Script (JavaScript), the solution processes data from a Google Sheets setup comprising a “Manifest” of patient data and a “Staff” roster to create a fair distribution of patients to nurses for each shift. For scalability, the project was initially tested on a "playground" unit consisting of two leadership roles—a charge nurse and a resource nurse—and a maximum of eight bedside nurses caring for approximately 16 patients.

The formation of this program was heavily inspired by the way football and soccer teams create their lineups to take the field. Just as coaches strategically assign players to positions based on their strengths, roles, and the dynamics of the game, this system seeks to do the same with nurse staffing assignments. Each nurse, like a player, brings unique skills and experience to the team, and the goal is to position them where they can perform at their best while maintaining balance across the unit. This approach mirrors the careful planning required to create a lineup that not only meets immediate demands but also adapts to the fluidity and unpredictability of the game—or, in this case, the ICU shift.

The “challenge” to make this program was presented to me by my coworker. The code was initially written in Python, inspired by Automate the Boring Stuff with Python by Al Sweigart and heavily informed by Chapter 15 and 16 from Henry Petroski’s To Engineer Is Human: The Role of Failure in Successful Design, and utilized Microsoft Excel for data handling. However, due to implementation challenges and compatibility issues, transitioning to a Google Sheets script proved to be the most practical solution. I leveraged Claude and Bard/Gemini to assist in converting my Python code into JavaScript, ensuring a smooth adaptation to the Google Apps Script environment.

These are the Rules

Patient rooms are numbered 301 to 316 and divided into two pods: Pod A (rooms 301–308) and Pod B (rooms 309–316). Nurses must be assigned to a single pod, meaning a nurse caring for a patient in Pod A cannot also care for a patient in Pod B. The standard nurse-to-patient ratio is 1:2 but becomes 1:1 for high-acuity patients. These high-acuity cases include patients with devices such as IABP, Impella, CRRT, TTM, LVAD, or Rotoprone. They also encompass patients requiring constant care for reasons such as psych/behavioral issues, stroke with thrombolytic treatment, or “imminent death.” For this model, Psych 1:1 and other high-acuity assignments are treated synonymously. Patients requiring these "Needs" are only assigned one nurse, prohibiting dual assignments. COVID patients are not given special considerations in this version of the system.

There is also the concept of a "Suboptimally Utilized Nurse," or SUN. In the context of this automated staff assignment system, a SUN refers to a nurse assigned to only one patient, not due to the patient's high acuity, but simply because no other patients are available within their assigned pod. The current iteration of the script does not address SUNs and is touched upon later in this blog under Bugs. 

Some patients may have multiple devices (e.g., Impella with CRRT), though certain combinations, such as IABP with Impella, are prohibited. To ensure fairness, the system maintains a "device dates" log to track the last time each nurse cared for patients with specific devices or high-acuity needs, rotating assignments equitably among staff. Each patient is assigned an acuity score, which the script uses to distribute workload evenly across nurses within each pod. Leadership roles, such as charge or resource nurses, cannot simultaneously serve as preceptors to avoid conflicts in responsibility.

Demo video.

The Set Up

The Google Sheets implementation includes two key tabs: “Staff” and “Manifest.” The “Staff” tab lists nurse-specific data, including names, qualifications (e.g., eligibility to serve as charge or resource), and "device dates" for tracking prior assignments. While all nurses qualified to serve as charge (C) can also serve as resource (R), the reverse is not always true. Ancillary roles like Code Nurse are noted but do not directly influence patient assignments. Device-specific headers start in Row 1 (Cell D1), with subsequent rows logging the dates of each assignment.

Info contained on the staff tab. All names are completely fictional.

The “Manifest” tab functions as a bed roster, detailing room numbers, acuity scores, and specific care needs. High-acuity patients are flagged as requiring single-nurse assignments. Designations such as "NO" indicate unoccupied beds, while "OTA" marks beds open for admission, allowing nurses to be assigned to these rooms.

Manifest that indicates patient acuity and “Needs.”

The script processes this data to generate nurse-patient assignments that adhere to patient-specific needs, workload balancing, pod constraints, and device rotation. The output is presented in a clear, table-based format, with one column for room numbers and another for assigned nurse names. Each row corresponds to a specific room, providing a structured and efficient overview of nurse assignments for the shift.

Output showing the staff assignment. Note how the rooms that are not open, 308 and 316, do not have a nurse assigned to them.

The Script

The following section is background behind the code that I used. You can skip over if you have no interest in learning about the machinations behind the script.

1. Create or Clear the Output Sheet

The script checks for the presence of an "Assignments" sheet. If it doesn’t exist, it creates one; if it does, it clears its contents to prepare for new data.

let outputSheet = ss.getSheetByName("Assignments");

if (!outputSheet) {

  outputSheet = ss.insertSheet("Assignments");

}

outputSheet.clearContents();

2. Read Staff Data

This chunk reads the "Staff" sheet, captures headers, and identifies columns corresponding to various devices (e.g., IABP, Impella) for tracking nurse assignments.

const staffData = staffSheet.getDataRange().getValues();

const staffHeaders = staffData[0];

let deviceColIndex = {};

for (let col = 3; col < staffHeaders.length; col++) {

  const deviceName = staffHeaders[col];

  if (deviceName) {

    deviceColIndex[deviceName] = col;

  }

}

3. Build Nurse Objects

Each nurse is represented as an object with details like their qualifications, assigned rooms, acuity total, and device dates. This prepares the data for assignment logic.

let nurseList = [];

for (let r = 1; r < staffData.length; r++) {

  const row = staffData[r];

  if (!row[0]) continue;

  let nurseObj = {

    name: row[0],

    canCharge: (row[1] === "C"),

    canResource: (row[1] === "C" || row[1] === "R"),

    codesPreceptor: row[2],

    deviceDates: {},

    assignedRooms: [],

    assignedAcuityTotal: 0,

    hasHighAcuity: false,

    isChargeOrResource: false

  };

  for (let device in deviceColIndex) {

    let dateVal = row[deviceColIndex[device]];

    nurseObj.deviceDates[device] = dateVal ? new Date(dateVal) : null;

  }

  nurseList.push(nurseObj);

}

4. Identify Charge and Resource Nurses

This identifies and designates one charge nurse and one resource nurse based on qualifications, marking them as ineligible for bedside assignments.

let chargeNurse = null;

let resourceNurse = null;

for (let n of nurseList) {

  if (!chargeNurse && n.canCharge) {

    chargeNurse = n;

    n.isChargeOrResource = true;

    continue;

  }

  if (!resourceNurse && n.canResource && !n.isChargeOrResource) {

    resourceNurse = n;

    n.isChargeOrResource = true;

    break;

  }

}

let bedsideNurses = nurseList.filter(n => !n.isChargeOrResource);

5. Read Manifest Data

This section processes the "Manifest" sheet to extract patient room numbers, acuity scores, and specific needs. High-acuity patients are flagged.

const manifestData = manifestSheet.getDataRange().getValues();

let patients = [];

for (let r = 1; r < manifestData.length; r++) {

  const row = manifestData[r];

  let roomNumber = row[0];

  let acuity = row[1];

  let needs = row[2];

  if (!roomNumber || !needs || needs === "NO") continue;

  const highAcuityTags = ["IABP", "Impella", "CRRT", "TTM", "LVAD", "Rotoprone", "HIGH ACUITY", "Psych 1:1"];

  let isHighAcuity = highAcuityTags.includes(needs);

  patients.push({

    room: roomNumber,

    acuity: acuity || 0,

    needs: needs,

    isHighAcuity: isHighAcuity,

    isIABP: (needs === "IABP"),

    isImpella: (needs === "Impella")

  });

}

patients.sort((a, b) => b.acuity - a.acuity);

6. Pod Logic

Helper functions determine if a room belongs to Pod A or Pod B, enforcing the rule that nurses must stay within a single pod.

function roomIsPodA(rm) {

  return rm >= 301 && rm <= 308;

}

function roomIsPodB(rm) {

  return rm >= 309 && rm <= 316;

}

7. Check Room Eligibility for Nurses

This function verifies if a nurse can be assigned a specific room based on pod constraints, number of current assignments, and high-acuity limitations.

function canAssignRoom(nurse, roomNumber) {

  if (nurse.hasHighAcuity || nurse.assignedRooms.length >= 2) return false;

  if (nurse.assignedRooms.length === 0) return true;

  let firstRoom = nurse.assignedRooms[0];

  let firstIsPodA = roomIsPodA(firstRoom);

  let newIsPodA = roomIsPodA(roomNumber);

  let firstIsPodB = roomIsPodB(firstRoom);

  let newIsPodB = roomIsPodB(roomNumber);

  if (firstIsPodA && newIsPodA) return true;

  if (firstIsPodB && newIsPodB) return true;

  return false;

}

8. Assign Nurses to Patients

Patients are assigned nurses based on their needs, starting with high-acuity cases. Nurses are selected using device rotation or workload balancing logic.

for (let p of patients) {

  let chosenNurse = null;

  if (p.isHighAcuity) {

    if (p.isIABP) {

      chosenNurse = findBestNurseForDevice(bedsideNurses, "IABP", p.room);

    } else if (p.isImpella) {

      chosenNurse = findBestNurseForDevice(bedsideNurses, "Impella", p.room);

    } else if (["CRRT", "TTM", "LVAD", "Rotoprone"].includes(p.needs)) {

      chosenNurse = findBestNurseForDevice(bedsideNurses, p.needs, p.room);

    } else {

      chosenNurse = findBestNurseNormal(bedsideNurses, p.room);

    }

  } else {

    chosenNurse = findBestNurseNormal(bedsideNurses, p.room);

  }

  if (chosenNurse) {

    chosenNurse.assignedRooms.push(p.room);

    chosenNurse.assignedAcuityTotal += p.acuity;

    if (p.isHighAcuity) {

      chosenNurse.hasHighAcuity = true;

    }

    if (deviceColIndex[p.needs] !== undefined) {

      chosenNurse.deviceDates[p.needs] = new Date();

    }

  }

}

9. Prepare Final Output

This aggregates all assignments, including leadership roles, and writes them to the "Assignments" sheet in a clear, tabular format.

let allAssigned = [];

for (let n of bedsideNurses) {

  for (let rm of n.assignedRooms) {

    allAssigned.push({ room: rm, nurse: n.name });

  }

}

allAssigned.sort((a, b) => parseInt(a.room) - parseInt(b.room));

let rowIndex = 1;

outputSheet.getRange(rowIndex, 1).setValue("Leadership Role");

outputSheet.getRange(rowIndex, 2).setValue("Assigned Nurse");

if (chargeNurse) {

  rowIndex++;

  outputSheet.getRange(rowIndex, 1).setValue("Charge Nurse");

  outputSheet.getRange(rowIndex, 2).setValue(chargeNurse.name);

}

if (resourceNurse) {

  rowIndex++;

  outputSheet.getRange(rowIndex, 1).setValue("Resource Nurse");

  outputSheet.getRange(rowIndex, 2).setValue(resourceNurse.name);

}

rowIndex += 2;

outputSheet.getRange(rowIndex, 1).setValue("Room");

outputSheet.getRange(rowIndex, 2).setValue("Assigned Nurse");

for (let i = 0; i < allAssigned.length; i++) {

  rowIndex++;

  outputSheet.getRange(rowIndex, 1).setValue(allAssigned[i].room);

  outputSheet.getRange(rowIndex, 2).setValue(allAssigned[i].nurse);

}

Shortcomings

Even with sophisticated algorithms designed to align staff competency with patient needs, automated staff assignment programs have inherent limitations. One major shortcoming is their inability to account for human factors. These systems often overlook individual preferences, personal circumstances, and interpersonal dynamics within teams. For example, a nurse dealing with personal stress, such as a sick child at home, might need a less demanding shift, or two colleagues with a history of conflict might be assigned to collaborate, reducing efficiency and morale. These subtleties, while critical to a positive work environment, are challenging to capture in an algorithm, potentially leading to dissatisfaction, decreased morale, and even staff turnover.

Another limitation is the system’s difficulty in adapting to real-time changes and unexpected events. A sudden surge in patients, emergency situations, or unforeseen staff absences can disrupt a meticulously pre-planned schedule. While programming for flexibility is possible, automated systems are inherently rigid, which may hinder the rapid adjustments required in dynamic healthcare settings. This rigidity can result in delays in care, uneven workloads, and potential risks to patient safety.

Over-reliance on such automation may undervalue the role of human judgment and intuition. Nurse leaders (charge nurses), with their deep understanding of team dynamics and individual capabilities, bring critical insight that cannot always be replicated by automated systems.

Lastly, resistance from staff can pose significant challenges to implementation. Concerns about job security, loss of control over schedules, and skepticism toward the technology may create apprehension. Successful adoption requires clear communication, comprehensive training, and iterative feedback to address these concerns and ensure that the system benefits both staff and patients.

In many ways, I approached this project as a combination of a Hail Mary, a nuclear option, and a lark. The primary motivation was not necessarily to create staff assignments but to validate them—a way to ensure that assignments were fair, balanced, and aligned with patient needs and nurse competencies. It was born out of necessity during challenging times when the pressure to make quick decisions in high-stakes situations often left little room for reflection or verification.

This program serves as a practical, three-minute solution for moments when the shift is so intense that there’s no time to second-guess or analyze every detail of the assignments. By automating the process, it eliminates the guesswork, providing a structured and reliable framework that can guide decision-making under pressure. While the goal was to bring efficiency and clarity to an often chaotic process, it also carried the weight of being a bold attempt to tackle deeply ingrained inefficiencies in staffing practices.

At the same time, there was an element of curiosity driving this project—an interest in seeing how far automation and algorithms could go in solving such a human-centered problem. This combination of practicality, urgency, and exploration reflects the essence of the program: a tool designed to enhance decision-making, save time, and validate the complex choices nurse leaders make every day in a fast-paced and unpredictable environment.

Bugs

When attempting to display un-assignable rooms—such as beds with no eligible nurses available—issues arose in the program’s execution. Specifically, rooms flagged as “NNA” (No Nurse Available) did not always display properly, disrupting the clarity of the final output. This bug highlights the challenge of incorporating nuanced exceptions into the assignment algorithm while maintaining a coherent and accurate representation of the staffing situation. Addressing this requires refining how the system processes and outputs unassignable cases to ensure transparency and usability.

Previously, I mentioned the concept of a "Suboptimally Utilized Nurse." When attempting to address this situation, the script would end up "skipping" a room, leaving it unassigned. The bug likely arises from the program's strict pod constraints, the distribution of patient acuity within pods, and the algorithm's lack of explicit awareness of "Suboptimally Utilized Nurse" situations. To address this, the algorithm needs to prioritize 1:2 assignments whenever possible, potentially consider pod flexibility in unavoidable "Suboptimally Utilized Nurse" scenarios, and at least identify and flag these situations in its output for human oversight and adjustment.

Future Considerations

A potential enhancement to the automated staff assignment system is the Strength Score. The Strength Score would be calculated based on a nurse's experience, training, proficiency with medical devices, and ability to serve as a charge, resource, or preceptor. This score would ensure that high-acuity patients are assigned to highly experienced nurses, while lower-acuity patients are assigned to less experienced nurses who can benefit from mentorship opportunities.

Another consideration is how to identify float assignments on the roster. The suggestion is to use "NL" followed by a number to designate float nurses, with "NL" standing for "Non-Local." Finally, the Continuity of Care Feature aims to assign the same nurse to a patient on consecutive shifts when possible. This feature would prioritize continuity while also balancing other factors like patient acuity, nurse workload, and device-heavy patient rotation. If no nurse is available for a given assignment, "NNA" (No Nurse Available) would be displayed.

Conclusion

This project represents a bold step toward leveraging technology to address the complexities of ICU nurse staffing. While the program is not without its challenges, including the inherent limitations of algorithms and the bugs encountered during implementation, it reflects an innovative approach to improving efficiency, fairness, and patient care in a demanding healthcare environment. By combining data-driven automation with future considerations like Strength Scores and Continuity of Care, the system has the potential to evolve into a valuable tool for nurse managers and staff alike. Ultimately, this project is a testament to the importance of innovation, experimentation, and the ongoing pursuit of solutions that balance technical rigor with the human element in healthcare.

Balance and Flow: Gauging Success in Renal Replacement Therapy Fluid Removal via a Data-Driven, Gamified Approach

Summary

In this post, I share my data-driven, gamified approach to gauging success in fluid removal during renal replacement therapy (RRT). I dive into the importance of precision in achieving net fluid balance goals, while tackling real-world challenges like inherited deviations, partial treatments, and unexpected interruptions. By introducing success tiers—Optimal, Acceptable, Marginal, and Failure—and adjusting goals proportionally for special circumstances, I’ve created a system that ensures fair and meaningful evaluations. My motivation for this approach stems from a desire to track data and identify areas for improvement in managing renal replacement therapy. By analyzing performance metrics and success tiers, I can pinpoint where adjustments are needed to enhance precision and outcomes.

Introduction

The idea to “gamify” my performance in achieving Continuous Renal Replacement Therapy (CRRT) net fluid balance goals was initially suggested by my coworker. At first glance, the concept seemed straightforward: Hit the goal and I “win”; miss it and I “lose.” However, as I explored the idea further, I realized that achieving the net fluid removal goal in CRRT isn't always straightforward. Fluid removal targets often span a wide range to account for patient-specific factors, and simply falling within that range doesn’t always reflect how well I’m meeting the clinical intent.

Disclaimer: Before diving into the tiered framework for evaluating net fluid removal success, it’s important to clarify how I’m speaking about these values. When I refer to fluid balance targets, I am using integers in the context of negative values, not absolute numbers. For instance, if the goal is to achieve a net fluid balance less than -2 L, this refers to values such as -3 L, -4 L, or lower, not values like -1 L, 0 L, or 1 L.

This distinction is critical because the terminology can easily be misunderstood without this context. In this discussion, a “less than” relationship is always relative to increasingly negative numbers (e.g., moving further into the negatives). Conversely, if a fluid balance is greater than -2 L, it refers to values like -1 L, 0 L, or higher, meaning the fluid removal is less aggressive or even positive. The maximum prescribed range is the most negative number while the minimum prescribed range is generally zero. 

This framing ensures that the numerical references are consistent and avoids confusion about the directionality of the target values.

Also, the net fluid removal goal refers to the volume removed by the dialysis machine, while the net fluid balance goal reflects the patient’s overall fluid status, accounting for all inputs and outputs. The removal goal focuses on machine performance, whereas the balance goal provides a broader measure of the patient’s clinical fluid management. Distinguishing these terms ensures clarity in evaluating outcomes.

That being said, let’s talk about what defines success.

Tiers of Success

Categorizing success into tiers rather than relying on a simple met/not met framework was the best approach because it captures the nuances of fluid management in renal replacement therapy. A binary evaluation doesn’t account for degrees of precision or the context behind achieving—or falling short of—the goal. For instance, achieving the lower end of a range might technically “meet” the target but fail to align with the clinical intent, while a slight deviation from the range due to unavoidable circumstances may still reflect a well-executed effort. By using tiers such as Optimal, Acceptable, Marginal, and Failure, I can better assess not just whether the goal was reached but how closely performance aligned with the intended outcomes, providing a more actionable and realistic evaluation. This stratification fosters accountability, highlights areas for improvement, and ensures that patient care remains the central focus.

For example, a net fluid balance of 0 L in a 0 to -2 L range is technically a “win,” but it might fall short of the clinical intent if the goal was aggressive fluid removal closer to -2 L. This led me to stratify success into four tiers—optimal, acceptable, marginal, and failure—to better account for precision, intent, and context. 

For a net fluid balance goal ranging from 0 to -2 L, success is classified into four tiers—Optimal, Acceptable, Marginal, and Failure. Optimal success is achieved when the actual net fluid balance is within ±10% of the maximum prescribed range, or between -1.8 L and -2.2 L. Acceptable success occurs when the balance falls outside the Optimal range but remains within the prescribed range, specifically from 0 to -1.8 L. Marginal success includes balances that are either 11–20% below the maximum range, or slightly above the minimum range (up to 10%). For this example, this means a balance between -2.2 L and -2.4 L, or from 0 to 200 mL. Finally, Failure is defined as any balance that falls outside the Marginal limits, such as greater than 200 mL or less than -2.4 L. This tiered system ensures a structured and clinically relevant assessment of success in achieving fluid removal goals.

The variance percentages I use for categorizing performance are similar to the benchmarks we used in my Chem51 lab (UC Irvine) to evaluate reaction yields. Just like in the lab, these thresholds are somewhat arbitrary but serve a practical purpose: providing clear, measurable benchmarks to guide performance and determine success. In the lab, we often needed to set acceptable ranges for reaction yields to account for variability in methods, equipment, and conditions, even though the specific thresholds didn’t always have a scientific basis. They were there to ensure consistency and fairness in evaluation.

The Four Goals

As I developed this framework, I realized there were two key areas that required assessment to truly evaluate performance. The first is the overarching 24-hour net fluid balance goal, which must be achieved collaboratively across shifts. For instance, if the 24-hour goal is 0 to -2 L, seamless coordination between day and night shifts is essential to keep the patient within that range. The second area is my 12-hour shift, which carries a proportional responsibility for the 24-hour goal—typically half. For example, if I start my shift with the patient already at -300 mL, my adjusted target would be -1700 mL to stay on track for the 24-hour goal. Addressing this dual responsibility also requires considering the previous shift’s impact, which I refer to as “Inherited Deviations” or “Inherited Conditions.” These represent the starting net fluid balance handed over to me, which may align with or deviate from the expected trajectory of the 24-hour goal. Balancing my 12-hour responsibility with these inherited deviations often requires flexibility and critical thinking to adjust for any over- or under-removal by the previous shift. To guide this process, I also incorporate a theoretical 12-hour goal, which assumes an even distribution of the 24-hour target across shifts. By comparing this idealized goal to the realities of my shift, I can better balance expectations with practical adjustments.

It’s important to keep in mind both the theoretical 12-hour goal and the actual net fluid balance goal during my shift because they serve complementary purposes. The theoretical goal provides a baseline for what I should aim to achieve under ideal conditions, ensuring I contribute my share toward the 24-hour target. The actual goal, however, reflects the reality of what I inherit from the prior shift, including any deviations from their target and adjustments needed to compensate. By balancing these two perspectives, I can stay on track for the 24-hour goal while adapting appropriately to patient-specific needs and the performance of the prior shift. Ignoring either one risks overcompensating or falling short, which could impact patient outcomes or complicate care for the following shift.

For clarity, I will include a fourth, overarching goal: Met/Not met. This goal evaluates whether the patient achieves the 24-hour fluid balance goal by the end of my shift. This overarching goal provides a straightforward assessment of whether the treatment is aligned with the intended outcomes, regardless of inherited deviations, interruptions, or proportional adjustments.

Information related to tier success will help track Shift Success Rate, which measures the percentage of shifts classified as optimal, acceptable, or marginal success based on the defined tiers. This metric will help me gauge how consistently I meet goals, offering insights into my overall performance.

Special Circumstances 

Special circumstances may arise involving PIRRT (Prolonged Intermittent Renal Replacement Therapy) or situations where CRRT runs only for a portion of the shift because the treatment was just initiated. In these cases, adjustments to the net fluid balance goals are necessary to ensure accurate assessment.

For PIRRT, the goal will be proportional to the time I was managing the machine and will include any inherited deviations, calculated as:

(number of hours managing machine / total number proposed hours machine is intended to run) x net fluid balance goal minus the previous shift’s fluid balance

For example, if a patient is to be on RRT between the hours of 2000 to 0800 with a net fluid balance goal of -2L, the fluid balance at the start of the shit was -700 mL, and I am only managing the treatment  for 12-hours (1900-0700), the adjusted net fluid balance goal is (11 hours / 12 hours) x -2 L minus -700 mL, or -1.13 L. 

For CRRT scenarios where the treatment is initiated shortly before or during my shift, the net fluid balance goal will account for both the hours it is running under my care and the inherited fluid balance from the previous shift. This is calculated as:

(hours machine ran / 24 hours) x net fluid balance goal minus the previous shift’s fluid balance

For example, treatment first started at 1400. I am on shift for 12-hours. Net fluid balance goal is -2 L; however, the patient is approximately 500 mL positive. The adjusted net fluid balance goal is (12 hours / 24 hours) x -2 L minus 500 mL, or -1.5 L. 

This adjustment applies exclusively to new starts or initiations of CRRT. In contrast, for treatments that have already been running for at least 24 hours but were interrupted due to issues like circuit clotting or procedures, the net fluid balance goal will not be proportioned. Instead, inherited deviations resulting from these interruptions will be documented and factored into the overall assessment.

Additionally, in special circumstances where treatment abruptly ends and therapy cannot be restarted, such as when HD access becomes unusable or care is withdrawn, success will transition from the conventional audit to the Dynamic criteria. 

Under the Dynamic criteria:

• The net fluid balance goal will still include inherited deviations and be proportional to the time the machine was active during my shift.

• Success will be evaluated solely for the time the machine was running, ensuring fairness and accountability.

By including inherited deviations in these calculations, the system ensures that every shift’s contribution is accurately assessed within the context of collaborative patient care.

In special circumstances, two goals are evaluated to ensure fairness and simplicity. The first is the proportional goal, which adjusts the net fluid balance target based on the time the machine was under my care. The second is the simple met/not met goal, which determines whether the 24-hour net fluid balance goal was achieved by the end of my shift. 

Conclusion 

By combining all these metrics and gamifying my goals, I’ve created a process that is both engaging and motivating. Treating net fluid balance targets as a challenge not only keeps me focused but also transforms a routine task into an opportunity for growth and improvement. At the end of next year, this project will give me a detailed view of my performance—highlighting strengths and pinpointing areas of improvement.

Simple Fick/Thermodilution CO/CI Calculator

Disclaimer: This Fick/Thermodilution cardiac output/index calculator is intended for educational purposes only and should not be used as a diagnostic tool or a substitute for professional medical advice, diagnosis, or treatment. Use of this calculator is at your own discretion and risk.

Body Surface Area (BSA, m²):

Oxygen Saturation of Arterial Blood or Oxygen Saturation as Detected by the Pulse Oximeter (SaO2 or SpO2, %):

Mixed Venous Oxygen Saturation (SvO2, %):

Hemoglobin (Hgb, g/dL):

Calculate
Clear

Results

Cardiac Output (L/min):

Cardiac Index (L/min/m²):

If you have taken the time to utilize this calculator, I kindly ask that you consider filling out a brief survey.

Your input is incredibly valuable to me and will significantly contribute to the development and enhancement of future projects. Thank you for your participation and support.

A Tale of Two Procedures: Analyzing IV Insertion and Feeding Tube Placement Outcomes

Introduction

This post presents an analysis of IV insertion and feeding tube placement success rates from January 1, 2024 to October 8, 2024.

Peripheral IV insertion and small bowel feeding tube placement are common procedures in the critical care setting. Peripheral IVs provide essential access for fluids, medications, and other treatments, while small bowel feeding tubes ensure proper nutrition delivery in patients with compromised gastrointestinal function. Tracking performance metrics for each procedure is crucial for ensuring patient safety and optimizing outcomes. Monitoring success rates in reference to techniques used can help identify areas for improvement, guide professional development.

By keeping a close eye on these metrics, I can improve in these essential procedures.

IV Insertion Success Rates: A Proven Track Record

This table presents an analysis of IV insertion success rates, comparing different insertion methods (US, Conventional, Transillumination, and IO) across different time periods (First Part of Year, Second Part of Year).

• Overall: Ultrasound (US) and Transillumination show the highest success rates, with IO having no insertions. The overall success rate across all methods is 44.77%.

• First Part of Year: Conventional insertions, or those done based on palpation and anatomical landmarks, were attempted alongside US, with a combined success rate of 44.94%. Note: Transillumination wasn't recorded during this period as I had not differentiated between the Conventional and Transillumination until later in the year.

• Second Part of Year: Conventional insertions were not performed, but a significant increase in the overall success rate (74%) is observed, driven by improved US and Transillumination success. By this time, I had differentiated between the Transillumination and Conventional insertions.

The data showcases a strong track record of successful IV insertions, particularly when utilizing Ultrasound (US) and Transillumination techniques. On average, I placed 1.232 IV catheters per shift. Overall, these methods demonstrate high success rates, contributing to an overall success rate of 44.77%. Notably, performance has improved over time, with the second part of the year showing a remarkable 74% success rate. This upward trend highlights a commitment to continuous improvement and the adoption of the most effective technique: Ultrasound.

Note that Conventional insertions were only recorded in the first part of the year, and I didn’t differentiate between Conventional and Transillumination until the second part of the year. While some methods have shown lower success rates, the data indicates a clear focus on utilizing the most effective technique (US), leading to more successful insertions.

Small Bowel Feeding Tube: An Area in Need of Improvement

This table tracks the success and failure rates of small bowel feeding tube insertions and the location of successful insertions.

• Overall: The overall success rate is 60.71%, with a higher percentage of successful insertions terminating in the stomach (76.47%) compared to the small bowel (23.53%).

• First Part of Year: Success rate was lower (56.52%) with a similar distribution of termination locations as the overall data.

• Second Part of Year: A significantly higher success rate (80%) was achieved, with all successful insertions terminating in the stomach.

The data reflects a strong overall success rate of 60.71% in feeding tube insertions, with a notable improvement in performance observed in the latter part of the year, reaching an impressive 80% success rate. This demonstrates a clear upward trajectory in skill and proficiency. However, the majority of successful insertions consistently terminate in the stomach, indicating a low degree of accuracy and precision in the procedure. While there is room for continued growth and refinement, the data supports a narrative of consistent competence.

Also while the data suggests an improvement in the procedure's success rate over time and a potential association between insertion technique and termination location, more detailed information and larger sample sizes would be needed to draw definitive conclusions.

Conclusion

In conclusion, this analysis of IV insertion and feeding tube placement success rates highlights a commitment to providing high-quality patient care. The data demonstrates a strong overall track record in both procedures, with notable improvements observed over time.

In the realm of IV insertion, the adoption of Ultrasound significantly boosted success rates. The upward trajectory in success rates, particularly in the latter part of the year, further underscores this commitment to continuous improvement.

While feeding tube insertions have also seen a commendable overall success rate and a marked improvement in recent months, the data indicates an opportunity for enhanced precision and accuracy in achieving the desired placement location. This presents a clear area for targeted focus and future development.

Overall, this analysis paints a positive picture of proficiency and progress in both IV insertion and feeding tube placement.

Kintsugi, revisited: a JFET overdrive based on the SSBS Mini with a dynamic sag circuit based on the SSBS F-k overdrive.

A year ago I became really determined to figure out the dynamic sag portion of the SSBS Fk Overdrive. At the time, no readily available schematic of the dynamic sag circuit existed other than a rudimentary diagram The Tone God had shared. Therefore, I had to deduce what I believed was the circuit based on numerous blog posts by Brian from SSBS in conjunction with tracing photos of the PCBs from the various pedal forums and Instagram. As Dino from DeadEndFX would later inform me, my final result was off by 2-3 parts and one incorrect signal path. Not bad for surmising a circuit with the limited resources available to me.

I stuck that dynamic sag circuit into a SSBS Mini, which is in turn a derivative of the SSBS Fk Overdrive. The final product sat on my pedal board in an unmarked, hammer-finished enclosure for over a year. I never had any intention of releasing this as a commercial product, but I wanted to make something more “official.” I spent a few months figuring out how to do artwork - as in, have the labels align with the knobs, sent the design to AmplifyFun, and reboxed my work.

I don’t have a schematic right now, but I do offer this free project for the Mini, and if you look up the Fk Overdrive schematic on PedalPCB or DeadEndFX, you can finagle the circuit together. Furthermore, my version adds a sensitivity control and a control that determines the magnitude of the voltage drop in the sag, the Threshold knob. I did remove the Heavy/Light control from the Fk OD because the Kintsugi knob made it sonically redundant.

Anyways, I had not written on this pedal in a while, and I just want to share. The past few years building have been great, and it’s always crazy to think I went from literally melting my first pedal kit to being able to create a viable pedal that I put together from an idea to a PCB CAD file to artwork.

Bean and Cheese Burrito Rankings

Last month I started a journey looking for the best bean and cheese burritos in San Diego County.

I started reviewing burritos as a way to expand my writing skills and scratch that creative itch. It’s a challenge to take something as simple as a bean and cheese burrito—just four components—and try to orate about it in a meaningful way. I wanted to see if I could break down the nuances of something seemingly straightforward without coming across as overly pretentious. The goal was never to be critical for the sake of it, but to explore how much depth you can find in something so basic. It’s an exercise in finding the art in simplicity.

These are the current rankings, from best to least best, as of October 21, 2024.

List will be updated regularly.

1. Kotija Jr. 

2. JV’s Mexican Food

3. Antonio’s

4. Sombrero’s

5. El Nuevo Milenio

6. Lolita’s 

7. Jalapeños

8. Sayulita’s

9. California Burritos

10. Taco Bell

Kintsugi, a JFET drive with dynamic sag circuit.

Last year I built my first Smallsound/Bigsound Mini based on a PCB of my own creation. Over the course of the months that followed, I started becoming more curious about the F- Overdrive, which is a JFET based overdrive/fuzz/distortion that features a dynamically modulated starve circuit that is said to mimic the sound of a dying tube amp. To me, the effect is akin to a compressor and tremolo working in tandem. On the most subtle level, the dynamic sag circuit can make a drive pedal sound like Neil Young’s “exploding small amp” from Weld, and on the most extreme level, the pedal will struggle and strive to illicit a sound. For reference, the demo at the bottom of this page is set to about 75% of the dynamic sag’s full capabilities.

What I believed would be a simple project derived from researching a series of Google searches exploded into a full fledged R&D project. As I would later find, the information needed to construct the dynamic sag circuit was either non-functioning and/or incomplete. I solicited advice from the usual forums (FSB, DIYStompBoxes, Reddit), and ultimately rebuilt the dynamic sag circuit from scratch. While I am still not completely sure my dynamic sag circuit is 100% a part for part remake of what’s in the SSBS model, I believe I have come very close and am approximating similar sounds (effects). Furthermore, up until now, the only person I have seen publicly claim to get the dynamic sag circuit to work is Brian from SSBS. Even Andrew/The Tone God who first shared the dynamic sag circuit which later made its way into the SSBS drive has never made a claim to producing a functioning unit.

This project started back in April and it wasn’t until now that I’ve completed the product I set out to create: A JFET drive with a dynamic starve circuit. The primary circuit is the SSBS Mini, but I did make some changes along the way like implementing some snippets from the Fairfield Circuitry Barbershop and Benson Preamp. I also added an additional control to the dynamic sag circuit: “Brokenness” that acts sort of like an attack/decay knob. Just like the SSBS F- Overdrive, the dynamic sag unit is footswitch bypass-able, meaning the pedal can either be run with the normal power supply or be run with the sag unit activated. I opted against making it momentary activated because (1) it would require an additional SPDT toggle switch that I had difficulty fitting on to the PCB layout and (2) for my style of music/playing, I found myself preferring it to be a “latching” effect versus momentary.

Controls

• Volume - Controls audio level output.

• Gain - Controls two gain stages simultaneously and increases distortion levels.

• Bass - Passive EQ control for bass frequencies.

• Treble - Passive EQ control for treble frequencies.

• Threshold - Determines aggressiveness of dynamic sag.

• Sensitivity - Adjust for audio input. Hotter signals and pick-ups may require less sensitivity.

• Range - Determines how much voltage (although technically, current) gets starved but also acts like an attack/decay knob.

• If you would like to play around with the dynamic sag and see its effect on voltage, see this model: https://everycircuit.com/circuit/4638353567514624.

Demo

Updates

• August 5, 2023: Added a “full band” demo. Made changes to some of the wording regarding the controls. Updated with dynamic sag model.

A deep dive into deciphering the elusive dynamic sag circuit in the Smallsound/Bigsound Overdrive.

I originally posted two similar versions of this blog on Reddit and the PedalPCB forum. This version includes changes based on feedback from those posts.

Summary

I spent the past few months figuring out the dynamic sag portion of the Smallsound/Bigsound (SSBS) F- Overdrive, had a breakthrough, and then stuck it into a Fairfield Circuitry Barbershop + SSBS Mini-hybrid drive.

The companion effect, an envelope-controlled voltage starve circuit, mimics a dying tube amp and responds to an individual's playing: As described by Brian/SSBS, the dynamic sag circuit is “dynamically modulated (envelope controlled)…turn up the threshold and the harder you play, the more the overdrive crackles, tries to keep up… and fails miserably.” I call it a practice in kintsugi - or discovering and embracing the musicality in the “brokenness” of the pedal.

In this post I have included video demos, a schematic of the dynamic sag circuit, background information, a schematic of the dynamic sag circuit in practice, and final notes on shortcomings and future things to explore.

The post is quite lengthy, so I implemented headers in case you want to jump ahead to a specific section. Also, instead of posting ongoing updates or progress reports, I will just update this post.

(Last updated: 7-4-2023)

Video Demos

• Diagram of the signal path.

• Rhythm guitar demo.

• Lead guitar demo.

Background

A few months ago, after having built a SSBS Mini clone, I came across a video demo of the F Overdrive. The video detailed a feature within the pedal that was described as an envelope follower that starved a single gain stage. I thought the process would be as simple as a Google search, but whenever I did, I found threads suggesting people just Google the answer which leads to more threads suggesting people just Google the answer which leads to more threads…so on and so forth. In all my hours of Googling and perusing forums like FreeStompBoxes and DIYStompBoxes, I had only found one person who figured out the circuit and produced a functional dynamic sag circuit: Brian from SSBS.

Eventually I happened across a thread on Reddit in which someone used the phrase “dynamic sag,” which lead me to the Tone God Punisher circuit.

The Tone God Punisher circuit is not so much a pedal as a companion piece for a pedal. Utilizing an envelope filter, a NPN BJT, and a JFET, the circuit starves current and mimics a dying tube amp. The core concept of the circuit (envelope follower and voltage controlled resistors) can be used for a myriad of applications in which an input signal dynamically controls another part of the pedal - be it, gain, volume, delay time (like the Retroflect), clipping, etc.

The circuit itself is derived from the Nurse Quacky, which in turn is derived from the Dr. Quack, which in turn is based on the EHX Doctor Q.

The dynamic sag feature is a hallmark of the SSBS F Overdrive. More recently The Shields Blender sported a similar feature. Fender ostensibly claims the dynamic sag - or “reactive sag” is “the first of its kind,” but clearly it isn’t, lending credence to the fact that Brian/SSBS is (was?) quite ahead of his time. To clarify, I don’t know if the sag circuitry in the Shields Blender is the same as the SSBS, but I do take issue that the reactive sag is being purported as being revolutionary when another pedal had the same function years prior.

Research

To say it took me a couple of months to figure out how to get the dynamic sag circuit to work would be an understatement. The original Tone God Punisher schematic was not functional. Through a series of trial, error, soliciting advice, multiple breadboards layouts, meticulously looking at internal of the SSBS OD and unpopulated SSBS OD PCBs, and a random late night epiphany, I managed to get the circuit working.

The big changes I had to implement were (1) the biasing of the op amp and (2) the removal of the JFET. The latter was a last minute decision brought about by a FreeStompBoxes.Com post in which a user felt the JFET and BJT interaction would be too unpredictable and warrant careful (laborious) selection of components. Alas, I got the circuit working and stuck it into a Fairfield Circuitry Barbershop/SSBS Mini hybrid.

Because of the alterations I have made and lack of the heavy/light control in my circuit, I have to state that this is not 100% a replication of the dynamic sag circuit in the SSBS OD; however, it is very similar in topology and produces the same effect.

Schematic of the Dynamic Sag

Note: Since originally sharing this schematic, I have made some changes based on feedback I received. The above schematic also includes a few proposed changes that I have learned about since my initial postings on the forums.

Practical Application in a Pedal Schematic

Based on my analysis of the SSBS Overdrive PCB, my circuit is probably only 80% similar to what's in the SSBS Overdrive - but I do believe it is a fair approximation.Above is a schematic of the Fairfield Circuitry Barbershop with the implementation of the dynamic sag unit. Note this is not the same schematic as the demo videos. I just wanted to share how the schematic would look once all the pieces are put together.

Explanation

(Note that parts referred to in this section is referring to the primary Dynamic Sag Circuit schematic.)

The input of the guitar signal splits off into the actual audio circuit and into the dynamic sag circuit. The signal goes through a buffer into the Sensitivity control. Thereafter, the signal goes to an envelope follower, which is a oddly-biased op amp. The envelope follower triggers an LED. LED charges up a capacitor, which in turn discharges to the BJT and allows current/power to flow to ground. The current/power that flows to ground is current/power that’s meant for the gain stage, effectively starving the stage in the process. LEDs’ forward voltage must be matched. Vout goes to the power source of the gain stage and R10 is whatever the bias resistor is.

The two knobs, Sensitivity and Threshold, control circuit. Sensitivity should be adjusted based on playing style - eg. Picking/strumming strength and Threshold determines how much starve should occur. Mark Hammer proposed that the RC network could be changed in order to increase/decrease the decay or even make the effect less aggressive overall. I postulate that the SSBS Fuck’s compression switch (heavy/low) goes between two different RC networks (R8, C4). In my own personal builds, I usually make C4 10uF. I find that values greater than 22uF drain too much power and take longer for the circuit to recover. Another proposal is to replace R8 with a potentiometer in series with a 50-100 ohm resistor in order to make an Attack control. The two foot switches are Bypass and Dynamic Sag. Bypass activates the drive and Dynamic Sag activates the Dynamic Sag.

The schematic for the dynamic sag footswitch bypass wiring is shared in the schematic under "Pedal Schematic or Practical Application." This will enable you to toggle the dynamic sag on or off. You can also opt for a monetary DPDT switch so that pressing/holding activates the sag and releasing immediately turns it off.

Shortcomings and Proposed Changes

Based on my analysis of the SSBS Overdrive PCB, my circuit is probably only 80% similar to what's in the SSBS Overdrive - but I do believe it is a fair approximation. In the future I would like to find a better way to control the rate of voltage change. I think a slew rate limiter is a plausible solution.

Updates

July 4, 2023

When my Skeptical Buffer schematic came under criticism - which I invite for the sake of correcting my work, I decided to proceed with using Simulation Program with Integrated Circuit Emphasis (SPICE). The program I chose was EveryCircuit. I plugged in the Dynamic Sag circuit and experimented with the different suggestions I posted in my original schematic. To my surprise, none of what I proposed did much. The one change that produced the most change - a more subdued voltage starve - was increasing R9, the resistor from Threshold to the base of the BJT.

Furthermore, as a result of this change, I am inclined to believe that the Compression switch on the SSBS overdrive toggles between two different resistors. The larger the value of R9, the higher the minimum voltage will be when the gain stage starves, and the smaller the value of R9, the lower the minimum voltage will be. Also in future builds, I have considered either omitting the Sensitivity control or making it an internal trimmer because I find that if you can fine tune R9, the circuit may not need a sensitivity knob and the Threshold control will offer more usability.

September 22, 2023

Dino from DEAD END FX has stated that their company plans to release a SSBS F*ck PCB. He has offered the following insight as to my research/development:

Theoretically, there is nothing wrong with the TG (Tone God) schemo. It really depends on the application, as well as the gain structure of what you want to influence with it. Where the F*ck is concerned, there is no Vref scheme in the power structure at all, meaning that the opamp input is not biased, and it works fine. Even with a guitar signal. The sag structure is more or less verbatim to the TG schemo, EXCEPT... there is one resistor to ground added at the back end of the envelope. You're not influencing the main rail voltage here, but rather, the bias voltage of one JFET within the audio gain structure. As such, minor (and I mean MINOR) tweaking might be required to get it to work with the destined application. From my breadboarding, I find that the resistor acts as a bleed control of the sag function (biasing the base of the NPN transistor). My experimenting led me to replace the resistor with a pot, which enhances the sag depending on the gain structure of the circuit being influenced, which is important. I found the F*ck that I had to lack sufficient "fade, crackle, pop" when the gain was turned up high, which using a pot instead of a fixed resistor value (as previously mentioned), helps compensate for.

As for the F*ck, I can tell you from experimentation that even the type of JFET's used as the VCR is important. The 2N5457's gave the smoothest voltage transitions, while others (ex.PF5102) were much more abrupt. At the initial attack, the bias voltage of the JFET used in the audio gain side of the circuit can drop from it's normal 4.5v to less than 1v when being "sagged", adequately providing the "edge of tube disaster" effect that is sought after.

Building a Smallsound/Bigsound Mini.

This was first published in two different places: PedalPCB forum and Reddit.

Disclaimer

Please exercise safety when building pedals. While the voltages being worked with are small, be mindful of electrocution. Wear proper safety gear, take breaks, and solder in a well-ventilated room. I don’t offer any sort of technical assistance and these build logs are meant for educational purposes only. Proceed with caution.

Also, I am not associated with any of the companies or groups/people mentioned in this post. I patronized their businesses and entities so I would like to share/promote them.

Build Log

I used this schematic that I redid from FSB. Gray Bench Electronics also did a teardown of the pedal that showed a few variances like the Bass potentiometer (C500K -> C1M), the Gain potentiometer (B100K dual gang -> A100K dual gang), and JFET selection.

PCB was designed in Eagle. I did do a version to allow for SMT JFETs; however, the SMT versions of the JFETs are not available at this time. I opted for a J201 for the first JFET sourced from PedalPCB and 2N5457 for the other JFETs sourced from StompBoxParts. I also changed all the trimmers to 50K because the 10K on the Bias control didn't allow me to adjust the voltage appropriately. I put some "empty pads" on the PCB so I could easily adjust the voltages with my multimeter probe. Chuck's insight about biasing JFETs and this runoffgrove article helped with the biasing of the JFETs. One of the challenges was making the Bias control (not to be confused with the bias trimmers) to work, and I did need to change the source resistor (R8) of Q3 to 100R from 1K. Furthermore, some of the JFET transistors from my pile did require 100R for R10 on Q4 as well in order for the JFET to bias correctly.

I built this in a 125B Pro from StompBoxParts. I highly recommend it; it's legitimately one of the best looking plain aluminum enclosures I have ever seen. My drilling was a bit off and I had to drill bigger potentiometer holes to allow for more "play" to allow better positioning, but I think it turned out fine. Graphic art is from Daiso, a Japanese dollar store in my area. The overall schematic reminds me of a Big Muff but upon closer inspection, the topology is more like the Fairfield Circuitry Barbershop with passive EQ controls and a dual gain stage.

Updates

• 7-17-2023: Corrected schematic with updated values. Uploaded relevant files to GitHub. Shared PCB on OshPark.

Building a germanium fuzz face.

Disclaimer

Please exercise safety when building pedals. While the voltages being worked with are small, be mindful of electrocution. Wear proper safety gear, take breaks, and solder in a well-ventilated room. I don’t offer any sort of technical assistance and these build logs are meant for educational purposes only. Proceed with caution.

Also, I am not associated with any of the companies or groups/people mentioned in this post. I patronized their businesses and entities so I would like to share/promote them.

Background

For a while, I avoided making any sort of germanium transistor-based pedals because of a series of errors while building some Hudson Broadcast clones. However, I became enamored with revisiting the idea after hearing demos of a fuzz by a local builder, LST Gnome Electronics. Germanium fuzzes consisting of 1-2 transistors may seem simple, but they are like making cacio e pepe: Small quantity of ingredients but require the right execution to get working.

Looking to bypass the steps of germanium transistor selection, I opted for matched transistors from Amplified Parts. From there, I wanted to really mimic the look of vintage fuzzes from the UK, and purchased a slanted fuzz case, large potentiometers, and axial capacitors to mimic that old school look. Also, having forgotten to source 22uF radial capacitors from Amplified Parts, I defaulted to using eBay. (Although during a chance trip to LA, I did come across an electronics store that sold “mojo parts” including radial 22uF capacitors.)

I implemented a couple ideas like the Incandeza Bypass by Demedash Effects relay bypass, SMD components, and a voltage inverter to provide a -9V power supply. I did have plans to insert a pick-up simulator and temperature controls as adapted from the Benson Germanium Fuzz, but the idea proved to be overly ambitious. Furthermore, the slanted structure of the fuzz case I was working with was difficult to design a PCB around.

Making a Stripboard Version

This version features stripboard. The insides are not pretty, and I did have to heavily pad the enclosure because the components/joints kept making contact with the case.

As you’ll read in the following section, I did have plans to make a PCB. While waiting for the PCBs to be delivered, I did make a stripboard version of the pedal. Because the transistor set includes specific values for the resistors, I did have to copy those resistor values by soldering together resistors of differing values. This worked but did not lead to pretty results, and because of the compact stripboard layout for the fuzz portion of the circuit (the charge pump is on a different piece of stripbroad), the resistors had a tendency to touch the germanium transistors, short circuiting the pedal in the process.

Creating a PCB

I used the provided Fuzz Face schematic from Amplified Parts in combination with the Sun Face schematic from PedalPCB. I wanted to go with something that was mountable to the footswitch, and I was going be using lugged potentiometers. Later I would find that the pre-drilled holes on the fuzz case were more fitting for the smaller Alpha potentiometers. Using the larger potentiometers did require me to expand the holes in the case. The metal used for the case is incredibly strong - almost to a fault, and I found that expanding these holes as well as adding an additional hole for a DC jack was quite difficult.

The PCB design as done on EagleCAD. Note the wavy traces - they are meant to mimic vintage fuzz circuit boards. To be clear, this is NOT an optimal way to do traces and only serve an aesthetic purpose.

I did make some changes to the original fuzz face schematic by implementing the popular Bias knob mod. I also put in the original resistor (R9 in the schematic below), which can be used if a person opts against the Bias knob. Furthermore, I implemented jumper pads into the PCB to allow for a silicon version, based on the Analog Man Silicon Sun Face, to be built. Also, the board size allows this pedal to be build into a 1590B enclosure; however, this will require smaller solder-lug potentiometers. If anyone wants to bias their transistors, I recommend substituting R7 and R9 with these boards.

Gutshots

Axial capacitors are used for the actual fuzz circuit. The footprints allow for a full 18mm long component with 5-8mm width. They offer no sonic advantage. They just look cool.

Completed board sans germanium transistors. The footswitch holds the PCB against the enclosure. There is a piece of cardboard between the PCB and the enclosure to prevent the joints of the circuit from shorting against the enclosure. I lifted this idea from Effects Layouts’ Incandenza Bypass layout.

Socketed transistors. There is a LED inside the enclosure. I was going to omit it all together but I needed it while testing to ensure power is going to the circuit.

Completed pedal. The PCB version had way less squealing than the stripboard version.

Schematic

Schematic of the final design. The Test pad is a suggestion by Demedash to check for any power spikes. Note the jumpers. Pad 1 and Pad 2 are an error when I thought I could sub in a LT1054. C3, C4, and C5 appear as resistors in the schematic because I couldn’t find axial capacitor footprints for the PCB.

Parts

If you wish to build a similar pedal, here are the parts I sourced from Amplified Parts:

• Germanium transistor set. I used a T7-H, which is somewhat questionable for testing germanium transistors. I got an hfe of 50-60 and 70-80 for Q1 and Q2 respectively. I did not test for leakage.

• Fuzz case.

• Potentiometer (audio).

• Potentiometers (linear).

• Axial capacitors: Non-polarized, polarized.

• Additional parts like the relay, footswitch, DC jack, audio jacks, and radial capacitors, ICs were sourced from Electronics Warehouse in Riverside County (CA), Jameco, and Love My Switches.

Preliminary thoughts on the Empress Effects Zoia.

I am a huge fan of multi effects units. I sport a HX Stomp and a Zoom MS-70CDR on my board. I enjoy how they offer tons of variety for a plethora of sounds, ability to reroute the pedals (series, parallel), and constant updates that the companies have provided - especially Line6.

Admittedly, I do not believe multi effects are for everyone: Their pitfalls tend to be (1) “menu diving”; (2) decision fatigue leading to creative exhaustion due to the sheer amount of options, (3) and uninspiring drive sections. I am also skeptical about their longevity especially those companies that have been cited requiring DRM-esque requirements for continued usage between owners.

What drew me to the Zoia was the ability to piece together effects. Having spent the past couple of months dissecting the Smallsound/Bigsound F-ck Overdrive, I went down a rabbit hole of voltage-controlled anything and envelope followers. The notion that you can alter the behavior and parameters of effects using analog circuits has become a new cause I’ve become engrossed in. In my search for the basic circuitry of the dynamic sag portion of the F-ck Overdrive, the Zoia has always popped up. This is because the Zoia allows a user to connect and patch together effects using a number of tools that I have barely scraped the surface of understanding.

Approaching this unit as a multi-effects would be a disservice to its full capabilities. It’s part multi-effects unit, part LTSpice, part “sandbox,” and part instrument. If you are a tinkerer, this is one of the most powerful tools you could add to your rig. As a designer of circuits and builder of pedals, the Zoia plays towards my more experimental inclinations.

Buy here from Pitbull Audio. That isn’t a sponsored link either - I just want to support my local music shop.

Suggested Reading:

• ZOIA for Guitarists - Official Tutorial

• Digital Generation of LFO's for Modulating Effects

"Closure", a short film treatment and script.

I recently took a class on script writing at San Diego City College. The following are from my fiction script titled Closure. The storyline was inspired by Ubiq by Philip K. Dick and written as if I was doing a project for Wong Fu Productions.

Hook

In the future, hospice patients are given the opportunity to wear a cybernetic device (Reminiscence) that allows them to traverse their memories and explore their pasts. Many use it to revel in a moment that brought them great joy and others use it to rectify an error from ages ago. Unfortunately, the technology is still limited and users are only allotted the ability to travel to a single event.

Isiah, an elderly man dying from pancreatic cancer, has a final wish of revisiting an incident prior to his wife’s (Grace) death. Present at his side is his estranged daughter, Anna. However, things go awry when the machine malfunctions, and Anna must go into the fading mind of her father to help him confront the greatest mistake he ever made and prevent a Compartmentalization Event from occurring.

Files

• Treatment

• Script

Failed Builds: RAT+Muff+HM2.

I first came across the idea of combining a RAT and a Big Muff upon learning of the Drunk Beaver Pedals Disambiguation: The body consists of a mish-mash of a RAT and a Big Muff. Playing off that idea, I designed a pedal with the input stage of the RAT followed by the clipping section of the Big Muff. The initial design was heavy. In many ways “doomy,” and in many other ways, compressed and gated. However, I found the tone to be far too niche for any commercial application. I let the idea gestate for a few months before happening upon various online discussions about using the HM2’s EQ section as the tone stack in various drives. As luck would have it, Drunk Beaver has implemented a similar idea before.

I wish I could say that I invested time and calculation to put together this design, but in the end, I just copy and pasted schematics that I found online and used ElectroSmash to identify the key parts of the RAT and Big Muff. I have managed to get this pedal to work…but I have never managed to make it sound viable.

Additional Sources:

• ElectroSmash Big Muff Pi Analysis

• ElectroSmash Pro Co Rat Analysis

Progress Report: Envelope Follower, Voltage Controlled FETS, and the Elusive "Dynamic Power Supply Sag"

“...the highlight of this pedal is a unique blown amp feature which provides crackles, compression, gating and eq changes similar to that of a tube amp pushed past it’s (sic) limits...”

— Smallsound/Bigsound F- Ovedrive Manual

The Smallsound/Bigsound F- Overdrive has been on the market for some time, and alongside its amazing overdrive pedal, is a highly unique feature: A Crackle/Burst/Threshold system that is an enveloper follower circuit based on the Dr. Quack schematic. The Dr. Quack is an off-shoot of the Dr. Q by Electro-Harmonix. The Dr. Quack was used by The Tone God to create The Punisher, and the Punisher is widely said to be the schematic behind the F- Overdrive’s Crackle/Burst/Threshold (CBT) feature.

Go to 3:35 for demonstration.

“The Punisher is a dynamic power supply sag simulator. The Punisher is not an audio effect but a companion effect that is to be used to control another effect to provide new sounds. You plug your audio signal and power supply into Punisher in series and connect the output audio signal and power supply into the effect to be controlled.”

— The Tone God, "Punisher"

The envelope follower feeds a control voltage to a JFET, which in turn alters its resistance, producing a voltage-controlled resistor in the process. The JFET is run in series with the power supply to a JFET stage, thus mis-biasing the JFET stage in the process. The resulting sounds is said to emulate that of an amp on the verge of explosion whose tubes wax and wane.

For further reading, I suggest visiting this page and scrolling down to “Driving Effects Circuits with the LFO Waveforms.”

Having built the Smallsound/Bigsound (SSBS) Mini, I started to set my eyes on the SSBS F- Oveddrive. However, I had little clue as to the underworkings of the CBT. Initially I thought the circuit was some sort of phaser/tremolo circuit that altered the volume/output of a specific stage of the SSBS Mini. But I wasn't too sure. Also, pictures of the F- Overdrive PCB did not look anything like a tremolo/phaser circuit. Although, oddly enough, the concepts of JFETs as voltage-controlled resistors (VCRs) is closely associated with phasers.

I began researching the most readily available information out there: It's a voltage-controlled envelope follower circuit. I pulled up schematics for the Glowfly Retroflect and Frantone Vibutron, which features envelope followers affecting FETs. I shot off a few Google searches, which immediately turned up the Dr. Q schematic. Unfortunately, there was very little information about how that particular circuit fit in the CBT. I wish I could say that the subsequent research was streamlined once I aligned the CBT circuit with the Dr. Q schematic, but in reality, I spent quite a few days perusing various forums to no avail. A culmination of 2-3 days of digging deep into forums helped me learn that the envelope follower controlled a "resistor," the resistor was associated with the second stage of the SSBS Mini, and the overall result was the JFET being mis-biased.

Simple enough, right?

A few more hours of Google searching lead me to Reddit where someone used the keywords, "dynamic sag." (Coincidently, I had just completed a LM317-based sag unit.) A few more Google searches lead me to the Pusnisher circuit. Furthermore, if you Google the Punisher circuit, the CBT pops-up alongside it!

I breadboarded the circuit, but I could not get it to function. Furthermore, I found several posts of individuals identifying the Punisher as being a key part of the CBT, but only a handful of people who successfully implemented the circuit: The Tone God, author of the circuit; some random guy on DIYStompboxes; and the mind behind SSBS. After a day of troubleshooting the circuit, I crowdsourced Reddit and DIYStompboxes for assistance.

The key piece missing from the original schematic was just a pair of resistors: The op-amp was not biased! The addition of the transistors allowed the circuit to work. I also experimented/ with and implemented some other changes from forum suggestions and the Dr. Q, which allowed the envelope signal to be much stronger. However, one change that helped was found on accident: I was trying out different biasing resistors and left one resistor in. This made the circuit work much better for reasons I am unsure of.

Schematic with many changes.

And like that, I figured it all out...sort of.

See, I call this "Progress Report" because there are still a few of issues to solve:

• How to calculate the resistance that is bestowed upon by the VCR/JFET.

• How to make the circuit smoother as the attack/release is really fast.

• How to elicit more crackling. I actually did manage to do this when I was using two 1M ohm resistors for biasing, but the envelope signal was not as strong.

• What the “Heavy/Light” function changes. I think it either changes the electrolytic capacitor attached to red LED or it may be the Attack function seen in the Nurse Quacky.

As for now, this is it.

Left side is the Crackle/Burst/Threshold function. On the right is a dummy unit to test the circuit. The dummy unit based on the Fairfield Circuitry Barbershop, which is like a minimalist SSBS Mini.

Updates:

• May 8, 2023: Grammar and spelling errors corrected.

Variable Voltage Regulator Pedal, or the Dying Battery Simulator Pedal

A dying battery simulator allows the voltage of an analog pedal to be reduced to a suboptimal level in order to mimic a dying battery effect. At lower voltages, distortion/overdrive/fuzz pedals are said to produce different sonic textures. For example, fuzz pedals may become gated, and high gain distortion pedals may take on a more subtle overdriven sound.

While the design is presented in pedal form, the schematic can be minimized to fit into another pedal in order to allow a user the ability to vary voltage within a pedal. Furthermore, pedal builders can also place the design into their test boxes in order to provide a wide range of voltages. In the lattermost case, building a 35V charge pump with a LM317 would allow a builder to have a wide breadth of voltages from ~32V to 1.25V - although I personally believe, 25V, 18V, 9V, and 4.5V would be satisfactory for many pedal designs.

The LM317 is a 3-terminal adjustable regulator that is capable of outputting a voltage range of 1.25 V to 37 V depending on input voltage. The regulator has three terminals: Input, Output, and Adjust.

Source: Wikipedia

When the JHS Volture first came out, I immediately knew it wasn't simply a potentiometer in series with a power supply. As soon as gut shots for the Volture became available, it was pretty clear the circuit was based on RG Keen's original concept, which in turn is probably from the actual datasheet for the LM317.

For my version, I utilized a video from Volos Projects to corroborate/refine the design. I then added in a LED voltmeter from Amazon and an internal Age control. New batteries differ from old batteries in that, “while new batteries can put out a lot of current, old ones can't - they develop a high internal resistance.” The Age knobs acts a rheostat. Putting “a resistor on the output of our regulator…will fake the internal resistance of the battery" (source). Voltmeter addition was inspired by MAS Effects’ UV Meter Drive and Silktone Fuzz. I did attempt to have a rotary switch for a Battery Simulator (carbon zinc, alkaline, “wall wort”) to play off the JHS April Fool’s joke, but the idea was too ambitious and overly complicated to implement. I also would've loved the Age control to be an actual potentiometer, but I could not find a reasonably priced and appropriately sized 100 ohm potentiometer.

This circuit allows you to go from ~7.5VDC to 1.25VDC which is similar to the Voluture specs on the JHS website ("...adjustable voltage from 7.5VDC down to 1.25VDC..."). The basic circuit is 5-6 different components and takes a matter of minutes to piece together.

Schematic.

Two changes I would've liked to implement were:

• Reverse polarity protection.

• 100uF to 1000uF electrolytic output capacitor for stability.

Demonstration. Note that the LED I used was very cheap and requires calibration. The read-out is not as smooth or accurate as I would like, but I am sure if a better, well-calibrated LED was used, the result would be better.

Files:

• (Pending)