VU meter iterations

Ever wonder why VU meters are always rectangular or circular?

It’s usually a matter of mechanical necessity. In the analog world, the physical sweep of a needle and the housing required to protect it dictated the design. We’ve become so accustomed to these “skeuomorphic” constraints that anything else feels almost alien—mechanically impossible, and therefore, aesthetically foreign.

But when you move from physical hardware to dynamic variables, hooks, and handles, those walls disappear.

The Danger & Joy of “Outside the Box”

Iterating without boundaries is a double-edged sword:
-The Danger: You can lose the user. If a shape is too “unseen,” it loses its familiarity and function.
-The Joy: You unlock unlimited potential. By manipulating the geometry through code, I’ve been riffing on the classic VU meter to see where the math takes me.

I’ve had to invent a new vocabulary just to keep track of these iterations. Say hello to the Squircle, the Squectangle, and the Hex-Dome.

Breaking the Skewmorphic Ceiling:
By leaning into the “mechanically impossible,” we create something that couldn’t exist in a world of gears and glass. It challenges the eye and redefines what an interface can look like.

Personally, the Parking Meter style is my favorite—there’s something inherently authoritative and nostalgic about that heavy arc.

Which of these shapes do you think works best? Or have we pushed “outside the box” too far?

#DesignSystems #UIUX #IterativeDesign #CreativeCoding #VUMeters #ProductDesign

Schematic Semantics: Ethernet left or right side

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

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

The Access vs. Consumption Debate

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

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

Why It Is Like Toilet Paper

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

* The “Over” (Switch as Source) Argument

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

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

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

* The “Under” (Edge as Source) Argument

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

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

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

The Best Mechanism for Drafting

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

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

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

 

Rotary Selector Switch (SelectorSwitch)

Rotary Selector Switch (SelectorSwitch)

The `SelectorSwitch` is a high-fidelity Tkinter Canvas-based widget designed to model discrete multi-position controls. It mimics the behavior of physical rotary switches found on industrial equipment, laboratory instruments, and high-end audio gear.

Continue reading

Rust Headless 96kHz Audio Console

Architecting a Scalable, Headless Audio Console in Rust

In the world of professional audio—spanning broadcast, cinema, and large-scale live events—the mixing console is the heart of the operation. Traditionally, these have been massive hardware monoliths. Today, however, the industry is shifting toward headless, scalable audio engines that run on standard server hardware, controlled remotely by software endpoints.

This article proposes the architecture for Titan-96k, a scalable, 32-bit floating-point audio mixing engine written in Rust. It is designed to handle everything from a simple podcast setup to complex 7.1.4 immersive audio workflows, controlled entirely via MQTT.

Continue reading

Decoupling Hardware and Interface: The Engineering Logic Behind OPEN-AIR

In the realm of scientific instrumentation software, a common pitfall is the creation of monolithic applications. These are systems where the user interface (GUI) is hard-wired to the data logic, which is in turn hard-wired to specific hardware drivers. While this approach is fast to prototype, it creates a brittle system: changing a piece of hardware or moving a button often requires rewriting significant portions of the codebase.

The OPEN-AIR architecture takes a strictly modular approach. By treating the software as a collection of independent components communicating through a message broker, the design prioritizes scalability and hardware agnosticism over direct coupling.

Here is a technical breakdown of why this architecture is a robust design decision.

Continue reading

The Clocking Crisis: Why the Cloud is Breaking Broadcast IP

The Clocking Crisis: Why the Cloud is Breaking Broadcast IP

The move from SDI to IP was supposed to grant the broadcast industry ultimate flexibility. However, while ST 2110 and AES67 work flawlessly on localized, “bare metal” ground networks, they hit a wall when crossing into the cloud.

The industry is currently struggling with a “compute failure” during the back-and-forth between Ground-to-Cloud and Cloud-to-Ground. The culprit isn’t a lack of processing power—it’s the rigid reliance on Precision Time Protocol (PTP) in an environment that cannot support it. Continue reading

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

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

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

 

Continue reading

SDP meta data and channel information

The Protocol-Driven Stage: Why SDP Changes Everything for Live Sound

For decades, the foundation of a successful live show has been the patch master—a highly skilled human who translates a band’s technical needs (their stage plot and input list) into physical cables. The Festival Patch formalized this by making the mixing console channels static, minimizing changeover time by relying on human speed and organizational charts.

But what happens when the patch list becomes part of the digital DNA of the audio system?

The demonstration of embedding specific equipment metadata—like the microphone model ($\text{SM57}$), phantom power ($\text{P48}$), and gain settings—directly into the same protocol (SDP) that defines the stream count and routing, paves the way for the Automated Stage. Continue reading

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.

Putting the Mechanics into Quantum Mechanics

As we explore the frontier of quantum computing, we’re not just grappling with abstract concepts like superposition and entanglement—we’re engineering systems that manipulate light, matter, and energy at their most fundamental levels. In many ways, this feels like a return to analog principles, where computation is continuous rather than discrete.

A Return to Analog Thinking

Continue reading

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

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

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

The Illusion of Symmetry

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

Why “Main” and “Failover” Are Better

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

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

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

The Problem with “Primary” and “Secondary”

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

Naming Should Reflect Behavior

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

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

Alternative Terminology for Primary / Secondary Roles

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

using GPI pins on an arduino to run a keyboard

 

#include <Keyboard.h>

// Define the GPIO pins for CTRL+A, CTRL+B, CTRL+C, and CTRL+D keys
#define A_PIN 2
#define B_PIN 3
#define C_PIN 4
#define D_PIN 5

void setup() {
// Set up the GPIO pins as inputs with pull-up resistors
pinMode(A_PIN, INPUT_PULLUP);
pinMode(B_PIN, INPUT_PULLUP);
pinMode(C_PIN, INPUT_PULLUP);
pinMode(D_PIN, INPUT_PULLUP);

// Initialize the keyboard library
Keyboard.begin();
}

void loop() {
// Check if the CTRL+A pin is pressed
if (digitalRead(A_PIN) == LOW) {
// Press and release the CTRL+A key combination
Keyboard.press(KEY_LEFT_CTRL);
Keyboard.press(‘a’);
delay(50);
Keyboard.releaseAll();
}

// Check if the CTRL+B pin is pressed
if (digitalRead(B_PIN) == LOW) {
// Press and release the CTRL+B key combination
Keyboard.press(KEY_LEFT_CTRL);
Keyboard.press(‘b’);
delay(50);
Keyboard.releaseAll();
}

// Check if the CTRL+C pin is pressed
if (digitalRead(C_PIN) == LOW) {
// Press and release the CTRL+C key combination
Keyboard.press(KEY_LEFT_CTRL);
Keyboard.press(‘c’);
delay(50);
Keyboard.releaseAll();
}

// Check if the CTRL+D pin is pressed
if (digitalRead(D_PIN) == LOW) {
// Press and release the CTRL+D key combination
Keyboard.press(KEY_LEFT_CTRL);
Keyboard.press(‘d’);
delay(50);
Keyboard.releaseAll();
}

// Wait for a short period of time before checking the pins again
delay(10);
}

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);
}
}

Python OSC device – Motarized fader for volume + mute switch and solo switch

import reapy
import OSC

# Create an OSC client to send messages to Reaper
client = OSC.OSCClient()
client.connect(("127.0.0.1", 8000))

# Create an OSC server to receive messages from the fader and switches
server = OSC.OSCServer(("127.0.0.1", 9000))

def handle_volume(path, tags, args, source):
volume = args[0]
# Set the volume of the track using the Reaper API
reapy.connect()
track = reapy.Track(1)
track.volume = volume
reapy.disconnect()

# Add a callback for the volume fader
server.addMsgHandler("/volume", handle_volume)

def handle_mute(path, tags, args, source):
mute = args[0]
# Set the mute of the track using the Reaper API
reapy.connect()
track = reapy.Track(1)
track.mute = mute
reapy.disconnect()

# Add a callback for the mute switch
server.addMsgHandler("/mute", handle_mute)

def handle_solo(path, tags, args, source):
solo = args[0]
# Set the solo of the track using the Reaper API
reapy.connect()
track = reapy.Track(1)
track.solo = solo
reapy.disconnect()

# Add a callback for the solo switch
server.addMsgHandler("/solo", handle_solo)

# Run the OSC server
st = threading.Thread(target=server.serve_forever)
st.start()

BESKAR2D2 – test board with RJ45

#include <ReefwingSBUS.h>
#define MIN_LEFT_ROLL    -255
#define MAX_LEFT_ROLL     255
#define MIN_LEFT_PITCH    -255
#define MAX_LEFT_PITCH     255
#define MIN_RIGHT_ROLL   -255
#define MAX_RIGHT_ROLL    255
#define MIN_RIGHT_PITCH   -255
#define MAX_LEFT_PITCH    255
#define MIN_SBUS          200
#define MAX_SBUS          1800
//#define SWITCH_ON         991
SBUS RX_from_RADIOLINK(Serial3);
uint16_t channels[16];
uint16_t lostFrameCtr = 0;
uint16_t sbusChannel6 = 0, sbusChannel7 = 0, sbusChannel8 = 0, sbusChannel5 = 0, rxMode = 0;
int16_t sbusChannel1 = 0, sbusChannel2 = 0, sbusChannel3 = 0, sbusChannel4 = 0;
bool failSafe;
bool lostFrame;
bool armed = false;
void setup() {
  //  Start Serial and wait for connection from computer
  Serial.begin(115200);
  while (!Serial);
  RX_from_RADIOLINK.begin();
//BLUE RJ45 WIRE A
  pinMode(26, OUTPUT);
  pinMode(27, OUTPUT);
  pinMode(28, OUTPUT);
  pinMode(29, OUTPUT);
//wHITE WIRE  RJ45 WIRE b
  pinMode(30, OUTPUT);
  pinMode(31, OUTPUT);
  pinMode(32, OUTPUT);
  pinMode(33, OUTPUT);
//BLUE RJ45 WIRE B
  pinMode(34, OUTPUT);
  pinMode(35, OUTPUT);
  pinMode(36, OUTPUT);
  pinMode(37, OUTPUT);
//WHITE RJ45 WIRE B
  pinMode(38, OUTPUT);
  pinMode(39, OUTPUT);
  pinMode(40, OUTPUT);
  pinMode(41, OUTPUT);
//GREY RJ45 WIRE A
  pinMode(45, OUTPUT);//this is capable of PWM//speed
  pinMode(49, OUTPUT);//direction
  pinMode(50, OUTPUT);//BRAKE
  pinMode(51, OUTPUT);//STOP
//GREY RJ45 WIRE B
  pinMode(44, OUTPUT);//this is capable of PWM  //SPEED
  pinMode(48, OUTPUT);//DIRECTION
  pinMode(46, OUTPUT);//BRAKE
  pinMode(47, OUTPUT);//STOP
}
void loop() {
  // Check for a valid SBUS packet from the RX_from_RADIOLINK receiver
  if (RX_from_RADIOLINK.read(&channels[0], &failSafe, &lostFrame)) {
   //Scale the joysticks to the min and max
    sbusChannel1 = map(channels[0], MIN_SBUS, MAX_SBUS, MIN_LEFT_ROLL, MAX_LEFT_ROLL);
    sbusChannel2  = map(channels[1], MIN_SBUS, MAX_SBUS,  MAX_LEFT_PITCH,MIN_LEFT_PITCH);
    sbusChannel4 = map(channels[3], MIN_SBUS, MAX_SBUS, MIN_RIGHT_PITCH, MAX_LEFT_PITCH);
    sbusChannel3 = map(channels[2], MIN_SBUS, MAX_SBUS, MIN_RIGHT_ROLL, MAX_RIGHT_ROLL);
    //  AUX Channels
    sbusChannel5 = channels[4];
    sbusChannel6     = channels[5];
    sbusChannel7    = channels[6];
    sbusChannel8    = channels[7];
    rxMode   = channels[8];
    if (lostFrame) { lostFrameCtr++; }
  //LEFT SWITCH
  switch (sbusChannel7) {
    case 200:
      Serial.print(“LS”);Serial.print(“A”);Serial.print(“\t”);
                digitalWrite(31, HIGH);
                  digitalWrite(32, LOW);
                  digitalWrite(33, LOW);
            break;
    case 1000:
      Serial.print(“LS”);Serial.print(“B”);Serial.print(“\t”);
                   digitalWrite(31, LOW);
                  digitalWrite(32,HIGH);
                  digitalWrite(33, LOW);
      break;
    case 1800:
      Serial.print(“LS”);Serial.print(“C”);Serial.print(“\t”);
      digitalWrite(31, LOW);
                  digitalWrite(32, LOW);
                  digitalWrite(33, HIGH);
      break;
    default:
     Serial.println(“Invalid value”);
  }
/////////////////////////////// LEFT VOLUME
      Serial.print(“LV”);Serial.print(sbusChannel8); Serial.print(“\t”);
////LEFT X
        Serial.print(“LX”);Serial.print(sbusChannel4); Serial.print(“\t”);
      if (sbusChannel4 >= -255 && sbusChannel4 < -50) {
    // sbusChannel is within the range from -100 to -50
                  digitalWrite(38, HIGH);
                  digitalWrite(39, HIGH);
                  digitalWrite(40, LOW);
                  digitalWrite(41, LOW);
} else if (sbusChannel4 >= -50 && sbusChannel4 < -10) {
    // sbusChannel is within the range from -50 to -10
                   digitalWrite(38, HIGH);
                  digitalWrite(39, LOW);
                  digitalWrite(40, LOW);
                  digitalWrite(41, LOW);
} else if (sbusChannel4 >= -10 && sbusChannel4 < 10) {
    // sbusChannel is within the range from -10 to 10
                  digitalWrite(38, LOW);
                  digitalWrite(39, LOW);
                  digitalWrite(40, LOW);
                  digitalWrite(41, LOW);
} else if (sbusChannel4 >= 10 && sbusChannel4 < 50) {
    // sbusChannel is within the range from 10 to 50
                  digitalWrite(38, LOW);
                  digitalWrite(39, LOW);
                  digitalWrite(40, LOW);
                  digitalWrite(41, HIGH);
} else if (sbusChannel4 >= 50 && sbusChannel4 <= 255) {
    // sbusChannel is within the range from 50 to 100
                  digitalWrite(38, LOW);
                  digitalWrite(39, LOW);
                  digitalWrite(40, HIGH);
                  digitalWrite(41, HIGH);
} else {
    // sbusChannel is outside of all of the specified ranges
}
//////////////////////LEFT Y AXIS
    Serial.print(“LY”);Serial.print(sbusChannel3); Serial.print(“\t”);
      if (sbusChannel3 >= -255 && sbusChannel3 < -50) {
    // sbusChannel is within the range from -100 to -50
                  analogWrite(45,fabs(sbusChannel3) );//speed
                  digitalWrite(49, LOW);//direction
                  digitalWrite(50, LOW);//BRAKE
                  digitalWrite(51, LOW);//STOP//
Serial.print(“RF”);
} else if (sbusChannel3 >= -50 && sbusChannel3 < -10) {
    // sbusChannel is within the range from -50 to -10
                  analogWrite(45,fabs(sbusChannel1) );//speed
                  digitalWrite(49, LOW);//direction
                  digitalWrite(50, HIGH);//BRAKE
                  digitalWrite(51, LOW);//STOP//
Serial.print(“RS”);
} else if (sbusChannel3 >= -10 && sbusChannel3 < 10) {
    // sbusChannel is within the range from -10 to 10
                   analogWrite(45,fabs(sbusChannel3) );//speed
                  digitalWrite(49, LOW);//direction
                  digitalWrite(50, HIGH);//BRAKE
                  digitalWrite(51, HIGH);//STOP//
Serial.print(“SS”);
} else if (sbusChannel3 >= 10 && sbusChannel3 < 50) {
    // sbusChannel is within the range from 10 to 50
                  analogWrite(45,fabs(sbusChannel3) );//speed
                  digitalWrite(49, HIGH);//direction
                  digitalWrite(50, HIGH);//BRAKE
                  digitalWrite(51, LOW);//STOP//
Serial.print(“FS”);
} else if (sbusChannel3 >= 50 && sbusChannel3 <= 255) {
    // sbusChannel is within the range from 50 to 100
                  analogWrite(45,fabs(sbusChannel3) );//speed
                  digitalWrite(49, HIGH);//direction
                  digitalWrite(50, LOW);//BRAKE
                  digitalWrite(51, LOW);//STOP//
Serial.print(“FF”);
} else {
    // sbusChannel is outside of all of the specified ranges
}
 Serial.print(“\t”);
 Serial.print(“\t”);
 Serial.print(“\t”);
//////////////////////////////
//RIGHT SIDE OF CONTROLLER
/////////////////////////////
////////////////////////////////
    Serial.print(“RX”);Serial.print(sbusChannel1); Serial.print(“\t”);
      if (sbusChannel1 >= -255 && sbusChannel1 < -50) {
    // sbusChannel is within the range from -100 to -50
                  digitalWrite(34, HIGH);
                  digitalWrite(35, HIGH);
                  digitalWrite(36, LOW);
                  digitalWrite(37, LOW);
} else if (sbusChannel1 >= -50 && sbusChannel1 < -10) {
    // sbusChannel is within the range from -50 to -10
                   digitalWrite(34, HIGH);
                  digitalWrite(35, LOW);
                  digitalWrite(36, LOW);
                  digitalWrite(37, LOW);
} else if (sbusChannel1 >= -10 && sbusChannel1 < 10) {
    // sbusChannel is within the range from -10 to 10
digitalWrite(34, LOW);
                  digitalWrite(35, LOW);
                  digitalWrite(36, LOW);
                  digitalWrite(37, LOW);
} else if (sbusChannel1 >= 10 && sbusChannel1 < 50) {
    // sbusChannel is within the range from 10 to 50
    digitalWrite(34, LOW);
                  digitalWrite(35, LOW);
                  digitalWrite(36, LOW);
                  digitalWrite(37, HIGH);
} else if (sbusChannel1 >= 50 && sbusChannel1 <= 255) {
    // sbusChannel is within the range from 50 to 100
    digitalWrite(34, LOW);
                  digitalWrite(35, LOW);
                  digitalWrite(36, HIGH);
                  digitalWrite(37, HIGH);
} else {
    // sbusChannel is outside of all of the specified ranges
}
///////////////////////////////////////RIGHT Y
    Serial.print(“RY”);Serial.print(sbusChannel2); Serial.print(“\t”);
      if (sbusChannel2 >= -255 && sbusChannel2 < -50) {
    // sbusChannel is within the range from -100 to -50
                  analogWrite(44,fabs(sbusChannel2) );//speed
                  digitalWrite(48, LOW);//direction
                  digitalWrite(46, LOW);//BRAKE
                  digitalWrite(47, LOW);//STOP
Serial.print(“RF”);
} else if (sbusChannel2 >= -50 && sbusChannel2 < -10) {
    // sbusChannel is within the range from -50 to -10
                   analogWrite(44,fabs(sbusChannel2) );//speed
                  digitalWrite(48, LOW);//direction
                  digitalWrite(46, HIGH);//BRAKE
                  digitalWrite(47, LOW);//STOP
Serial.print(“RS”);
} else if (sbusChannel2 >= -10 && sbusChannel2 < 10) {
    // sbusChannel is within the range from -10 to 10
                  analogWrite(44,fabs(sbusChannel2) );//speed
                  digitalWrite(48, LOW);//direction
                  digitalWrite(46, HIGH);//BRAKE
                  digitalWrite(47, HIGH);//STOP
Serial.print(“ST”);
} else if (sbusChannel2 >= 10 && sbusChannel2 < 50) {
    // sbusChannel is within the range from 10 to 50
                  analogWrite(44,fabs(sbusChannel2) );//speed
                  digitalWrite(48, HIGH);//direction
                  digitalWrite(46, LOW);//BRAKE
                  digitalWrite(47, LOW);//STOP
                Serial.print(“FS”);
} else if (sbusChannel2 >= 50 && sbusChannel2 <= 255) {
    // sbusChannel is within the range from 50 to 100
                  analogWrite(44,fabs(sbusChannel2) );//speed
                  digitalWrite(48, HIGH);//direction
                  digitalWrite(46, LOW);//BRAKE
                  digitalWrite(47, LOW);//STOP
                  Serial.print(“FF”);
} else {
    // sbusChannel is outside of all of the specified ranges
}
Serial.print(“\t”);
     //Serial.print(“RB”);Serial.print(sbusChannel6); Serial.print(“\t”);
switch (sbusChannel6) {
    case 200:
      Serial.print(“RB”);Serial.print(“O”);Serial.print(“\t”);
                  digitalWrite(26, LOW);
                  digitalWrite(30, LOW);
            break;
    case 1800:
    Serial.print(“RB”);  Serial.print(“P”);Serial.print(“\t”);
                  digitalWrite(26, HIGH);
                      digitalWrite(30, HIGH);
      break;
    default:
      Serial.print(“RB”);Serial.print(“Invalid value”);Serial.print(“\t”);
      digitalWrite(26, LOW);
      digitalWrite(30, LOW);
      break;
  }
;
  switch (sbusChannel5) {
    case 200:
      Serial.print(“RS”);Serial.print(“A”);Serial.print(“\t”);
                  digitalWrite(27, HIGH);
                  digitalWrite(28, LOW);
                  digitalWrite(29, LOW);
                  break;
    case 1000:
      Serial.print(“RS”);Serial.print(“B”);Serial.print(“\t”);
                  digitalWrite(27, LOW);
                  digitalWrite(28,HIGH);
                  digitalWrite(29, LOW);
                  break;
    case 1800:
    Serial.print(“RS”);  Serial.print(“C”);Serial.print(“\t”);
                  digitalWrite(27, LOW);
                  digitalWrite(28, LOW);
                  digitalWrite(29, HIGH);
      break;
    default:
      Serial.print(“RS”);Serial.print(“Invalid value”);Serial.print(“\t”);
                        digitalWrite(27, LOW);
                  digitalWrite(28, LOW);
                  digitalWrite(29, LOW);
  }
;
Serial.print(“\t”);
       Serial.println(rxMode);
  }
  delay(10);
}