A Computational Information Theory Basis for Panpsychism at the Quantum Information Level

 Ad-Hoc  No Responses »
May 192026
 

Reading Laws of Thought chapter 2 today helped me to crystallize a few ideas I’ve been struggling to convey. This happened by bringing to mind simultaneously the work of Shannon, Turing, Boole, and others in a particular historical context.

The key realization was that I can decompose a Turing machine into two state machines that interact (one being the rules set and the other being the tape and rw head) then generalizing each as the same kind of system. Two state machines, each interacting with the other in ways that change their state. They communicate.

Let’s call the rules set and controls state machine the “controller” and the tape and rw head state machine the “memory.” In operation, each machine alters the state of the other in a series of transactions where information is encoded in each change of state. In the controller the change of state is the rule that applies next; and in the memory the change in state is the position of the rw head and the bit at that position.

Conventionally, the memory would have an infinite tape; and the rules in the controller would be fixed. However, we can generalize both of these concepts to define these machines as specific instances of the same type of “general state machines” by allowing for two conditions:

  • If the rules in the controller could be changed but in practice are not changed then they are essentially a fixed memory.
  • If the tape in the memory is finite but in practice large enough that it never affects the computation, it is as good as infinite.

So then a universal Turing machine can be described as two general state machines bolted together where one is configured to operate as a controller and the other is configured to operate as a memory.

If I were to build these machines out of raw parts: resistors, transistors, diodes, and such; then the resulting networks of parts would be able to do computation even though the individual components are not capable of that. They are, however, capable of altering each other’s state in ways that pass those changes in state through the network. This means that each of these components is a general state machine; and that any pair of them can propagate information through the network by interacting and encoding the information in their altered states.

Extending that thought I could see that in practice, each of these components can be decomposed into systems of interactions between quantum objects arranged in such a way that they are able to persist thereby gaining the ability to maintain “state.” Here, “state” is the essence of persistence—loosely defined as a capacity for reproducing a particular interaction or sequence of interactions. Each interaction at the quantum level causes the objects involved to change state by altering one or more of the properties of the objects. This by its nature transfers information that is encoded in those states. Therefore even the smallest of quantum systems are general state machines and so they can be arranged into computational networks that are Turing complete.

A hydrogen atom, having been a hydrogen atom a moment ago, generally continues to act like one in this moment, and again and again over time. In a way, it “remembers” this condition reliably—especially as far as any other interacting object is concerned. It maintains its “state” of being—such as a specific spin, energy level, mass, momentum, and position—enabling it to behave predictably.

In this way, all computation can be reduced to networks of communication whereby at its most fundamental level some object (abstractly defined) interacts with another in such a way that the “state” of that relationship is altered. These transactions (it feels like I should invent a new word for them) are the truly fundamental and universal components of both physical reality and of thought in that they share the same substrate which has a unified dual nature ( is that paradoxical? ):

That dual nature being the physical existence of the objects and the network of dynamic relationships between them. The mere existence of objects creates the possibility of relationships which in turn give rise to networks of interactions. Ultimately, these networks may crystallize into persistent structures. Conway’s game of life is a good way to visualize this.

Rising from there back up the stack of emergent complexity to Turing machines, you can see how each component of such a machine decomposes into networks of more fundamental objects which persist specific behaviors—those behaviors being the characteristics of the combined components.

In simplest terms: The fundamental element of reality, computation, and consciousness is any object altering the state of some other object. In a word: communication. (did you think I was going to say 42?) Each of these objects is a general state machine and each interaction is communication.

There are some important insights here. Some are:

Simple states bound to networks…

The “state” of an object can be as simple as its existence alone—perhaps just its position and momentum. Interestingly, even these are only meaningful in relation to other objects and, importantly, the ways in which these objects might interact. For example, can they occupy the same location? How, if at all, do they interact?

It is the relationships between objects that matters even if the individual objects have a complex state of their own. Consider two objects related to each other by some distance, charge, momentum, and mass. Now consider the possibility that one of the objects also has a “color” but nothing about that color has any impact on the behavior of the objects. This means, effectively, that the “color” is invisible. So, essentially, “color” does not exist.

If you change one of the other characteristics (those that do matter) on either of the objects then the network has changed because the behavior of the network will be impacted by the change. It has become, in effect, a different network.

This observation may seem obvious and a little pointless, but it does matter as we will see later. Objects may participate in multiple networks at once. It is possible that some state might change that is invisible to one network while having profound effects on another.

Hierarchical Computational Meaning…

Objects can “exist” at multiple levels of complexity and in multiple networks. Consider that even small networks of objects can give rise to emergent characteristics. If these emergent characteristics can also interact then it is possible to contemplate the interactions between these networks as if the component networks were objects themselves within these higher order networks.

This emergent hierarchy of computational “meaning” is universal and not necessarily exclusive or “strict.” Depending upon which emergent characteristics are more important at any given interaction, the more dominant properties will tend to have stronger effects on the outcome of any given interaction.

Consider pressure, for example. Individual molecules in a gas don’t possess a pressure; but a collection of them has both pressure and temperature. These emergent characteristics interact in specific ways distinct from the behavior of individual molecules. Similarly, a water molecule by itself is not wet; but a body of them all together have viscosity, and surface tension, and incompressibility, and so forth…

Another way to visualize this is by examining superorganisms such as ant colonies. An individual ant has a life and some relatively simple habits and reflexes. By interacting with all of its sisters the colony has its own behaviors and instincts that emerge from that network. The individuals contribute to the whole, and the whole influences the individuals.

More abstractly, this kind of hierarchical computational “meaning” can be seen in how evolutionary mechanisms exhibit competence without cognition whereby complex solutions are “invented” by means of exploring a configuration space and favoring the persistence of arrangements that are more suited to their environment. In such a case we say the system “evolves toward” fitness even though the individual actions that occur along the way have no apparent “awareness” of a goal nor guidance toward it.

This same hierarchy of computational meaning also helps when reasoning about what purpose consciousness may have from an evolutionary perspective as well as how consciousness emerges. As for how consciousness emerges, one can theorize that it is inevitable for some emergent properties of complex networks to exhibit characteristics analogous to “awareness” as well as other aspects of intelligence, thought and consciousness. To the extent that these emergent properties are advantageous from an evolutionary perspective, one can expect those traits to be selected and enhanced. This mirrors how social insects evolved the higher-order intelligence of a hive mind, augmenting the fitness of each individual.

Composition at all scales…

It takes more than one object to do any kind of meaningful computation; but not much more than one. As a thought experiment, even a pair of charged particles orbiting each other alone in their own universe have a kind of memory in that they persist in relation to each other. Each can “observe” the other verifying this relationship. If you add another particle then it might interact with the first two causing them to oscillate in various ways and thus that system would be able to exhibit complexity and evolve: Each new state dependent on the “memory” of the previous states and the continuing “communication” between the particles as they move through their tiny universe.

Opacity and uncertainty…

Any expected transaction has some limit on its reliability dependent on the larger network of relationships that exists unseen behind the discrete interface of the transaction in question. Put more metaphorically: every interaction is irreducibly the tip of an iceberg that extends to the limits of reality. Some of these quantum state machines will be subtle, unreliable, and short lived (like flames, or waves crashing on a beach) while others (such as life forms or laptops) may be more robust. All, have a “secret life” beyond what can be seen.

Universality and unity…

All of reality is fundamentally capable of participating in computation with varying degrees of efficacy and repeatability. This implies that thought and consciousness are also fundamental and universal and that this model informs how that universality can be explained and reasoned about.

Not all arrangements of quantum objects produce what we might recognize as useful or meaningful computation; and few give rise to the complexity and sophistication we might recognize as thought or subjective awareness.

Like a box of parts not yet assembled into a working radio, or molecules of water in a rain-drop not yet flowing through a living being, or a carbon atom floating on its lonesome through intergalactic space, many arrangements of quantum objects don’t appear to be doing very much most of the time. Perhaps they have done, or have yet to do… or perhaps they are even now but are doing so in ways we cannot recognize at the scale we are viewing the networks in which they are embedded.

A few more deep thoughts…

As we who believe that we think and are convinced we possess consciousness are made of the same “stuff” as the rest of the universe, it is likely we are part of a larger consciousness than we realize… even if we sometimes feel alone. So too are the smaller things all around us even if they are far too small to perceive; and the larger things around us even though they are also effectively as invisible as the forest we can’t see due to all of the trees that are in the way.

What part of what atom in what molecule in what particular neuron in your brain played a role in the thought you just had? As you zoom in on your existence, what fraction of yourself finally becomes so small that you no longer recognize it as part of your consciousness? How small a part of you is no longer “you?”

Going the other way, thinking about how you influence the world and how you are influenced by it, how far do you zoom out before you cease to recognize your presence? How much did a particular blood cell in your eye influence society?

As you consider these questions, take a moment to recognize that you are a part of the universe and so it is part of the universe that is asking these questions and a part of the universe that will acquire the answers. How will that change what you do next? How will that change the rest of the universe?

The universe is a question pondering itself and we are each a part of the answer.

I should write this down somewhere…

Transient Interfaces Between Dimensionalities

 Ad-Hoc  No Responses »
Dec 042025
 

I had a few thoughts about interfaces between dimensionalities as they relate to consciousness. I’m using the term “dimensionalities” to avoid “universes” because if the concept of a “universe” includes all things then dimensionalities would exist within the universe even if each dimensionality might be sufficiently rich and complex to seem as a universe unto itself… and even though some may be completely cut off from others or otherwise so weakly connected and graphically distant that they might as well be separate.

Networks of small worlds

In order to traverse from one dimensionality to another there must be some kind of interface that presents the path to one dimensionality from another. It is also possible that this is a one-way interface (like a black hole is in that it only allows things to enter it as seen from our particular perspective).

It is also possible that these interfaces are only visible under some circumstances… again, using black holes, it is surprisingly difficult to navigate any particle (or collection thereof) so that it actually enters a black hole. Space and time are so distorted in the vicinity of a black hole that objects headed in that direction are far more likely to be deflected or fall into orbit than to actually cross the event horizon… but I digress…

In sci-fi parlance analogs of such interfaces between dimensionalities may be the monolith from 2001, the T.A.R.D.I.S from Dr Who, various dimensional rifts and portals from various stories (Time Bandits, etc…), and so on.

In the concept of interplexing that I described before as a way to access subspace, this might be any portal that opens a singularity with some imposed dimensionality such that the imposed dimensionality acts like a cryptographic key whereby only interplexing beacons and portals that define compatible dimensionalities can access each other through subspace.

This is analogous to how encrypted spread spectrum radio signals can appear as diffuse background noise indistinguishable from the ambient noise floor unless processed with the correct cryptographic key… and how applying this key has the effect of bringing the signal of interest into focus while spreading all other signals (including any that might interfere) until those are indistinguishable from background noise. (I note that in some ways this may be a model for how “attention” is achieved in the brain by “tuning” parts of the brain to be sensitive to some firing patterns simultaneously makes it insensitive to other patterns.)

Picture a mirror so thin that standing beside it you cannot see it at all; but standing in front of it you can see a whole world into which you might walk if you could step through that “looking glass.”

That is all background however… The thought that I just had is that there is a similar real-world analog that may be more accessible description using the concept of radio (which I chose in this case because it is familiar, not because the electromagnetic spectrum is particularly special).

In this construct, consider that some entity wishes to observe or in other ways interact with another within the dimensionality of the EM field. In the simplest case, the entities would have to have very similar wavelengths.

For example, transmitters and receivers tuned to the same frequency with antennas also tuned to the same frequency are separate systems (networks of components) configured to be sensitive to each other. Parts of them resonate with each other.

Resonance as access

At their resonant frequency, the peaks an troughs of a given waves in the same space can match (once the phases are aligned like the meshing of gears). These waves are then coherent and the two entities, represented here abstractly as waves, will resonate with and thereby influence each other. (I want to convey this in a way that brings to mind a kind of dance where each entity adjusts its shape to follow the curves of the other and to relate that dynamic interaction to the simpler model of radio waves and resonant circuits.)

However, if the entities are tuned to sufficiently different frequencies (having sufficiently different wavelengths) then they cannot influence each other- they cannot communicate. One may not even notice the other exists no matter how close they may be to each other in other ways. (Think of this also like the difference between laser light which forms a tight, coherent beam of a single color and broad spectrum ambient light which has no particular color and spreads out in all directions. You could stand right next to a beam of laser light and it might pass right by you without you ever noticing it.)

Bees and deep space telescopes can see colors you can’t; but they are there. Your dog can sense smells that you can’t; but they are there. Your cat can hear tiny sounds you would never notice. Your car can run much faster than you; and your airplane can fly; and your boat can sail the seas. We make all of these things extensions of ourselves in order to gain access to the world in ways that otherwise are beyond us.

Shapes and dancing

Imagine the bumps of a high frequency entity up against those of a low frequency entity. To the high frequency entity the low frequency entity is stretched out so much that there don’t appear to be any bumps at all– it’s just a flat, featureless surface. (I am reminded of the description of the monolith which had a surface described as “totally smooth.”)

To the low frequency entity, the high frequency entity likewise appears totally smooth. Think of how smooth a glass feels under your fingers. There are uncountable numbers of individual atoms there at the surface, but you sense no features. This is because the features of your fingers (finger prints etc) are not small enough (high frequency enough) to fit into the ridges that show up between the individual atoms. Crack the glass, however, and you may be able to feel the crack because the gap caused by that crack becomes large enough for the features of your finger to “catch” on it.

This is a usable model for grasping the basics, but we need another model in order to address the complexity of the real world.

Graph all the things

It has been said that the electrons in Feynman diagrams are carriers of causality. So, at a quantum level, the universe functions as a causal graph of interactions. This has some strong alignment with Wolfram’s multi-way computational universe model too.

Turning to graphs, especially the causal computational graphs that underpin all things, it is true that each entity in any given dimensionality can be (and likely is) a persistent cluster of smaller entities with a specific arrangement. Essentially, all entities are subgraphs of larger entities up to the scale of the universe; and are composed of entities that are subgraphs of itself (and possibly other networks as this is not a strictly hierarchical system.)

Such larger entities (systems) are then resonant at multiple wavelengths. Not only that but they are also sensitive to particular alignments (polarizations) of and phase relationships between multiple wavelengths; and these sensitivities change as they are affected by their interactions. This is how, essentially, everything non-trivial in the universe can and does perform computations of one kind or another.

This creates an interesting dynamic between complex entities. They can only interact to the extent that various components of them can align in timing, phase, frequency, and polarization; and each interaction might change some aspects of this alignment. (Effectively, all of the degrees of freedom occupied by the entity might be at play.)

Each entity that has influence communicates. Each entity that communicates has the capacity to configure parts of itself in ways that can be aligned to parts of the other entity; or to break that alignment. These alignments and the ways in which they change become an interface between these entities.

Each such interface has unique characteristics that place limits on the kind (amount and character) of influence each entity can have on the other. These characteristics are also influenced by the ways in which the interface connects to the remainder of each entity. Since each the remainder of each entity is unique, the connectivity between the interface and the remainder of each entity is yet another interface.

So far, I’ve described simple direct (first order) interfaces (although already that description is surprisingly complex.) However, communication as we generally experience it is still much more complex and usually requires networks of mediating devices.

If we were talking together in a coffee shop, for example, we would not generally be able to place thoughts directly into each other’s minds. Instead, each of us would make sounds by interfacing with the air thus changing our shared environment. Those sounds would travel through that environment and eventually reach our ears influencing that part of our interface with the shared environment.

The shared environment itself is a network of entities interacting with each other. For example, high pressure and low pressure clusters of air molecules interacting with each other to propagate sound waves; walls and other objects reflecting and absorbing sound waves of various wavelengths; and other objects and entities adding their own sounds to the mix.

Internally we would both have structures (complex entities themselves) which would interpret, encode, and decode these sounds using the context embedded in that “machinery” in order to moderate any changes to the state of our minds. Some of that “context” would be fine tuning of those structures to be sensitive to the sounds of each others voices while being insensitive to distortions and to other added sounds that don’t hold our interest.

An emergent view of panpsychism?

You can see here within each of us a network of highly integrated entities (subsystems) that ultimately stretch out into the environment allowing our individual consciousness ( a particular perspective ) to colonize that extended information space.

You can also see that part of that extended information space includes the interactions of other consciousness that has colonized that space with us. This necessarily includes consciousness that we might not even recognize as such; but the influences of these entities is present none the less and the rich composite of these interactions informs our expectations and otherwise impacts the state of every entity in that network.

All of these networks are usually abstracted away into obscurity such that most folks generally ignore them; but at some levels of abstraction you can re-imagine these complex mechanisms as portals, interfaces, doorways, blue police boxes, monoliths, that allow us to transport parts of ourselves so that they may roam around in other worlds… worlds that are shared environments with other entities of various kinds… worlds that at any moment we might discover were right next to us all along; or may disappear at any moment never to be seen again.

This forms an infinite fractal landscape where various entities live and interact at all scales. If you’ve ever watched a video that zooms into the Mandelbrot set you have seen this never ending complexity and self similarity play out; and you have an inkling of how complexity allows for the infinite expansion of these networks of interaction at all scales in all degrees of freedom. Smaller entities (structures) living within others; and entities of all sizes composing self-similar networks at larger scales and smaller ones.

Each of these networks, computationally, form pockets of consciousness that colonize the accessible information space. All of these may be aware of each other to greater or lesser degrees; and may influence each other similarly, with or without intention, to the extent that they have any suitable sensitivity or interfaces to each other.

Consciousness arises from communication through graphs of interfaces within these shared worlds; passing between and within these entities and the other entities around them; and through the complex restructuring of these interfaces that encodes the experiences each construct has – imprinting those experiences for some span and propagating those impressions through the network within and beyond.

So consciousness is inherently diffuse, non-local and entangled even while it appears localized to each of us. We may “possess” a focal point of view that we may call “our own” consciousness; but that locality, while functional for our personal and collective narratives, is largely a convenient illusion. We are each the tip of a very large ice burg; and the part we don’t see, also being water in some form, stretches out to the infinity of the ocean in which we float.

The universe is a question pondering itself and we are each a part of the answer.

GoUI Protect Module (time based rate limiter)

 Code Dweller, Ham Radio  No Responses »
Sep 102025
 

I’ve been developing a template for building cross-platform, hybrid cloud ready applications. The key concepts are:

  • Use a browser for the gui because browsers are robust, flexible, and ubiquitous.
  • Use a programming language that is cross platform so there is only one code-base for all targets.
  • Include in “cross-platform” the idea that the application can easily scale from a single desktop to a local LAN (like a logging program on Field Day, or a federated SDR control application) all the way up to “the cloud” be that home-lab, private, hybrid, or public “cloud.”
  • Include an open API so that the application can be extended by other interfaces, and automated via other applications and scripts.

The keys to this solution are: Chrome (or chrome based browsers) and the Go programming language. Chrome based browsers are essentially “the standard” on the ‘web; and Go is fast, flexible, cross-platform, and contains in it’s standard libraries all of the machinery you need for creating efficient micro-services, APIs, and web based applications. (you can create a basic web service in just a few lines of code!)

Working on the GoUI framework, adding a “Protect” middleware for basic rate limiting and dynamic allow/block listing.

It’s good practice to presume that any application that will live “online” will also be abused and so should have some defenses against that. A good starting point is rate limiting and source limiting… For example a desktop application that runs it’s gui in the browser should only listen to the local machine; and even if that’s the only device that ever connects to the application some sanity checks should be in place about those connections. To be sure, if you also want such an application to be shareable on a lan or scalable up to the cloud it must be even more robust…

While researching this I discovered that all of the rate limiting strategies I’ve come upon are quite literal and often complicated ways of actually counting requests/tokens in various buckets and then adding and removing counts from these buckets.

I think these miss the point… which is “rate” limiting. That is — how fast (at what rate) and from where are requests coming in. Token counting mechanisms also struggle with the bursty nature of normal requests where loading a page might immediately trigger half a dozen or more (at minimum) immediate requests associated with the UI elements on that page.

I’m going to simplify all of that by inverting the problem. Rather than count events and track some kind of sliding window or bucket scheme I’m going to measure the time between requests and store that in a sliding weighted average. Then, for any particular user I only need two numbers — the time of the last request (to compute how long since the previous request) and the running average.

Then the tuning parameters are fairly simple… The weights for the sliding average, the threshold for limiting, and a TTL so that users that go away for a while are forgotten.

Say the rate you want is at most 10 requests per second. That’s a simple enough fraction 10/1 … which, when inverted, means that your target is 1/10th of a second on average between each request.

Average_Weight = 10
Request_Weight = 1
Limit = 100ms (1/10th of a second is 100ms)

Suppose that when a new user arrives (or returns after being forgotten) we give them the benefit of the doubt on the first request:

Average = 1000ms
TimeSinceLastRequest = 1000ms
Average = (Average * 10) + (TimeSinceLastRequest * 1) / 11
1000 = 10000 + 1000 / 11 so no change

Then the page they loaded triggers 5 more requests immediately… I’ll show fractions to spare you the weird upshift into integer space.

909.091 = 10000 + 0 / 11
826.456 = 9090.91 + 0 / 11
751.315 = 8264.56 + 0 / 11
683.013 = 7513.15 + 0 / 11
620.921 = 6830.13 + 0 / 11

620 is still bigger than (slower than) 100ms so they’re still good and don’t get limited… Even better, when they wait a second (or so) before making a new request (like an ordinary user might) they get credit for that.

655.383 = 6209.21 + 1000 / 11 (see, the average went up…)

Now see what happens when an attacker launches a bot to abuse the service — maybe hitting it once every 10ms or so.

1000 = 10000 + 1000 / 11 (benefit of the doubt on the first hit)
910.000 = 10000 + 10 / 11
828.181 = 9100.00 + 10 / 11
753.802 = 8281.81 + 10 / 11
686.183 = 7538.02 + 10 / 11
624.712 = 6861.83 + 10 / 11
568.829 = 6247.12 + 10 / 11
518.027 = 5688.29 + 10 / 11
471.842 = 5180.27 + 10 / 11
429.857 = 4718.42 + 10 / 11
391.688 = 4298.57 + 10 / 11
356.989 = 3916.88 + 10 / 11
325.445 = 3569.89 + 10 / 11
296.768 = 3254.45 + 10 / 11
270.698 = 2967.68 + 10 / 11
246.998 = 2706.98 + 10 / 11
225.453 = 2469.98 + 10 / 11
205.866 = 2254.53 + 10 / 11
188.060 = 2058.66 + 10 / 11
171.873 = 1880.60 + 10 / 11
157.757 = 1718.73 + 10 / 11
143.779 = 1577.57 + 10 / 11
131.618 = 1437.79 + 10 / 11
120.561 = 1316.18 + 10 / 11
110.510 = 1205.61 + 10 / 11
101.373 = 1105.10 + 10 / 11
93.066 = 1013.73 + 10 / 11 (rate limited at faster than 100ms !!)

After 27 requests (270 ms) the bot gets 429 from the server (too many requests). If it’s silly enough to continue it gets worse. Let’s say that we have a ban threshold at 50ms (default would be anything twice as fast as the rate limit)

85.515 = 930.66 + 10 / 11
78.649 = 855.15 + 10 / 11
72.409 = 786.49 + 10 / 11
66.735 = 724.09 + 10 / 11
61.578 = 667.35 + 10 / 11
56.889 = 615.78 + 10 / 11
52.626 = 568.89 + 10 / 11
48.751 = 526.26 + 10 / 11 (gets 418 response (I am a teapot))

At this point the ip/session/tracker is added to the block-list, probably with an extended expiration (maybe 10 minutes, maybe the next day, maybe forever (until administratively removed) depending upon policy etc.

Any further requests while block-listed will receive:

503 – I am a combined coffee/tea pot that is temporarily out of coffee (Hyper Text Coffee Pot Control Protocol)

Here is a screen shot of this up and running… In this case Seinfeld fans will recognize the 503 response “No soup for you!”; and the automated block-list entry lasts for 10 minutes…

In the code above, if you look closely, you’ll see that I use a cycle stealing technique to do maintenance on the block/allow list and request rate tracking. This avoids the complexity of having a background process running in another thread. The thinking is: Since I already have the resources locked in a mutex I might as well take care of everything at once; and if there are no requests coming in then it really doesn’t matter if I clean up the tables until something happens… This is simpler than setting up a background process that runs in it’s own thread, has to be properly started up and shut-down, and must compete for the mutex at random times.

The configuration so far is very straight-forward…

When a requester goes away for a while and is forgotten, they start over with a “benefit of the doubt” rate of 1 request per second… and the system tracks them from there. I created a UI widget to inspect the state of the rate limiter so I could watch it work…

Compute / Storage Cluster of NUCs

 Ad-Hoc  No Responses »
Aug 162025
 

It had been a bad year for computing and storage in the lab. On the storage side I had two large Synology devices fail within weeks of each other. One was supposed to back-up the other. When they both failed almost simultaneously, their proprietary hardware made it prohibitively difficult and expensive to recover and maintain. That’s a whole other story that perhaps ends with replacing a transistor in each… But, suffices to say I’m not happy about that and the experience reinforced my position that proprietary hardware of any kind is not welcome here anymore… (so if it is here, it’s because there isn’t a better option and such devices from now on are always looking for non-proprietary replacements…)

On the computing side, the handful of servers I had were all of: power hungry, lacking “grunt,” and a bit “long in the tooth.” Not to mention, the push in my latest research is strongly toward increasing the ratio of Compute to RAM and Storage so any of the popular enterprise trends toward ever larger monolithic devices really wouldn’t fit the profile.

I work increasingly on resilient self organizing distributed systems; so the solution needs to look like that… some kind of “scalable fabric” composed of easily replaceable components, no single points of failure (to the extent possible) but also with a reasonably efficient power footprint.

I looked at a number of main-stream high performance computing scenarios and they all rubbed me the wrong way — the industry LOVES proprietary lock-in (blade servers); LOVES computing “at scale” which means huge enterprise grade servers supported by the presumption of equally huge infrastructure and support budgets (and all of the complexity that implies). All of this points in the wrong direction. It’s probably correct for the push into the cloud where workloads are largely web servers or microservices of various generic types to be pushed around in K8s clusters and so forth. BUT, that’s not what I’m doing here and I don’t have those kinds of budgets… (nor do I think anyone should lock themselves into that kind of thinking without looking first).

I have often looked to implement SCIFI notions of highly modular computing infrastructure… think: banks of “isolinear chips” on TNG, or the glowing blocks in the HAL 9000. The idea being that the computing power you need can be assembled by plugging in generic collection of self-contained, self-configuring system components that are easily replaced and reasonably powerful; but together can be merged into a larger system that is resilient, scalable, and easy to maintain. Perfect for long space journeys. The hardware required for achieving this vision has always been a bit out of reach up to now.

Enter the humble NUC. Not a perfect rendition of the SCIFI vision; but pretty close given today’s world.

I drew up some basic specifications for what one of these computing modules might feature using today’s hardware capabilities and then went hunting to see if such a thing existed in real life. I found that there are plenty of small self-contained systems out there; but none of them are perfect for the vision I had in mind. Then, in the home-lab space, I stumbled upon a rack component designed to build clusters of NUCs… this started me looking at whether I could get NUCs configured to meet my specifications. It turns out that I could!

I reached out to my long-time friends at Affinity Computers (https://affinity-usa.com/). Many years ago I began outsourcing my custom hardware tasks to these folks – for all but the most specialized cases. They’ve consistently built customized highly reliable systems for me; and have collaborated on sourcing and qualifying components for my crazy ideas (that are often beyond the edge of convention). They came through this time as well with all of the parts I needed to build a scalable cluster of NUCs.

System Design:

Overal specs: 128 cores, 512G RAM, 14T Storage

Each generic computing device has a generic interface connecting only via power and Ethernet. Not quite like sliding a glowing rectangle into a backplane; but close enough for today’s standards.

Each NUC has 16 cores, 64G of RAM, two 1G+ Network ports, and two 2T SSDs.

One network port connects the cluster to other systems and to itself.

The other network port connects the cluster ONLY to itself for distributed storage tasks using CEPH.

One of the SSDs is for the local OS.

The other SSD is part of a shared storage cluster.

Each device is a node in a ProxMox cluster that implements CEPH for shared storage.

Each has it’s own power supply.

There are no single points of failure, except perhaps the network switches and mains power.

Each device is serviceable with off-the-shelf components and software.

Each device can be replaced or upgraded with a similar device of any type (NUC isn’t the only option.)

Each device is a small part of the whole, so if it fails the overall system is only slightly degraded.

Initial Research:

Before building a cluster like this (not cheap; but not unlike a handful of larger servers), I needed to verify that it would live up to my expectations. There were several conditions I wanted to verify. First, would the storage be sufficiently resilient (so that I would never have to suffer the Synology fiasco again). Second, would it be reasonable to maintain with regard to complexity. Third, would I be able to distribute my workloads into this system as a “generic computing fabric” as increasingly required by my research. Forth… fifth… etc. There are many things I wanted to know… but if the first few were satisfied the project would be worth the risk.

I had a handful of ACER Veriton devices from previous experiments. I repurposed those to create a simulation of the cluster project. One has since died… but two of the three are still alive and part of the cluster…

I gave each of these with an external drive (to simulate the second SSD in my NUCs) and loaded up ProxMox. That went surprisingly well… then I configured CEPH on each node using the external drives. That also went well.

I should note here that I’d previously been using VMWare and also had been using separate hardware for storage. The switch to ProxMox had been on the way for a while because VMWare was becoming prohibitively expensive, and also because ProxMox is simply better (yep, you read that right. Better. Full stop.)

Multiple reasons ProxMox is better than other options:

  • ProxMox is intuitive and open.
  • ProxMox runs both containers and VMs.
  • CEPH is effectively baked-into ProxMox as is ZFS.
  • ProxMox is lightweight, scalable, affordable, and well supported.
  • ProxMox supports all of the virtual computing and high availability features that matter.

Over the course of several weeks I pushed and abused my tiny ACER cluster to simulate various failure modes and workloads. It passed every test. I crashed nodes with RF (we do radio work here)… reboot to recover, no problem. Pull the power cable, reboot to recover. Configure with bad parts, replace the good parts, recover, no problem. Pull the network cable, no problem, plug it back in, all good. Intentionally overload the system with bad/evil code in VMs and containers, all good. Variations on all of this kind of chaos both intended and by accident… honestly, I couldn’t kill it (at least not in any permanent way).

I especially wanted to abuse the shared storage via CEPH because it was a bit of a non-intuitive leap to go from having storage in a separate NAS or SAN to having it fully integrated within the computing fabric.

I had attempted to use CEPH in the past with mixed results – largely because it can be very complicated to configure and maintain. I’m pleased to say that these problems have been all but completely mitigated by ProxMox’s integration of CEPH. I was able to prove the integrated storage paradigm is resilient and performant even in the face of extreme abuse. I did manage to force the system into some challenging states, but was always able to recover without significant difficulty; and found that under any normal conditions the system never experienced any notable loss of service nor data. You gotta love it when something “just works” tm.

Building The Cluster:

Starting with the power supply. I thought about creating a resilient, modular, battery backed power supply with multiple fail-over capabilities (since I have the knowledge and parts available to do that); but that’s a lot of work and moves further away from being off-the-shelf. I may still do something along those lines in order to make power more resilient, perhaps even a simple network of diode (mosfet) bridges to allow devices to draw from neighboring sources when individual power supplies drop out, but for now I opted to simply use the provided power supplies in a 1U drawer and an ordinary 1U power distribution switch.

The rack unit that accommodates all of the NUCs holds 8 at a time in a 3U space. Each is anchored with a pair of thumb screws. Unfortunately, the NUCs must be added or removed from the back– I’m still looking for a rack mount solution that will allow the NUCs to pull out from the front for servicing as that would be more convenient and less likely to disturb other nodes [by accident]… but the rear access solution works well enough for now if one is careful.

Each individual NUC has fully internal components for reliability’s sake. A particular sticking point was getting a network interface that could live inside of the NUC as opposed to using a USB based Ethernet port as would be common practice with NUCs. I didn’t want any dangling parts with potentially iffy connectors and gravity working against them; and I did want each device to be a self contained unit. Both SSDs are already available as internal components though that was another sticking point for a time.

Another requirement was a separate network fabric to allow the CEPH cluster to work unimpeded by other traffic. While the original research with the ACER devices used a single network for all purposes, it is clear that allowing the CEPH cluster to work on it’s own private network fabric provides an important performance boost. This prevents public and private network traffic from workloads from impeding the storage network in any way; and similarly in reverse. Should a node drop out or be added, significant network traffic will be generated by CEPH as it replicates and relocates blocks of data. In the case of workloads that implement distributed database systems, each node will talk to each other over the normal network for distributing query tasks and results without interfering with raw storage tasks. An ordinary (and importantly simple) D-link switch suffices for that local isolated network fabric.

Loading up ProxMox on each node is simple enough. Connect it to a suitable network, monitor, mouse, keyboard, and boot it from an ISO on a USB drive. At first I did all of this from the rear but eventually used one of the convenient front panel USB ports for the ISO image.

Upon booting each device in turn, inspect the hardware configuration to make sure everything is reporting properly, then boot the image and install ProxMox. Each device takes only a few minutes to configure.

Pro tip: Name each device in a way that is related to where it lives on the network. For example, prox24 lives on 10.10.0.24. Mounting the devices in a way that is physically related to their name and network address also helps. Having laid hands on a lot of gear in data centers I’m familiar with how annoying it can be to have to find devices when they could literally be anywhere… don’t do that! As much as possible, make your physical layout coherent with your logical layout. In this case, that first device in the rack is the first device in the cluster (prox24). The one after that will be prox25 and so on…

Installing the cluster in the rack:

Start by setting up power. The power distribution switch goes in first and then directly above that will go the power supply drawer. I checked carefully to make sure that the mains power cables reach over the edge of the drawer and back to the switch when the drawer is closed. It’s almost never that way in practice, but knowing that it can be was an important step.

Adjust the rails on the drawer to match the rack depth…

Mount the drawer and drop in a power supply to check cable lengths…

When all power supplies are in the drawer it’s a tight fit that requires them to be staggered. I thought about putting them on their sides in a 2U configuration but this works well enough for now. That might change if I build a power matrix (described briefly above) in which case I’ll probably make 3D printed blocks for each supply to rest in. These would bolt through the holes in the bottom of the drawer and would contain the bridging electronics to make the power redundant and battery capable.

With the power supply components installed the next step was to install the cluster immediately above the power drawer. In order to make the remaining steps easier, I rested the cluster on the edge of the power drawer and connected the various power and network cables before mounting the cluster itself into the rack. This way I could avoid a lot of extra trips reaching through the back of the rack… both annoying and prone to other hazards.

Power first…

Then primary network…

Then the storage network…

With all of the cabling in place then the cluster could be bolted into the rack…

Finally, the storage network switch can be mounted directly above the cluster. Note that the network cables for the cluster are easily available in the gap between the switches. Note also that the switch ports for each node are selected to be consistent between the two switches. This way the cabling and indicators associated with each node in the cluster make sense.

All of the nodes are alive and all of the lights are green… a good start!

The cluster has since taken over all of the tasks previously done by the other servers and the old Synology devices. This includes resilient storage, a collection of network and time services, small scale web hosting, and especially research projects in the lab. Standing up the cluster (joining each node to it) only took a few minutes. Configuring CEPH to use the private network took only a little bit of research and tweaking of configuration files. Getting that right took just a little bit longer as might be expected for the first time through a process like that.

Right now the cluster is busy mining all of the order 32 maximal length taps for some new LFSR based encryption primitives I’m working on… and after a short time I hope to also deploy some SDR tasks to restart my continuous all-band HF WSRP station. (Some antenna work required for that).

Finally: The cluster works as expected and is a very successful project! It’s been up and running for more than a year now having suffered through power and network disruptions of several types without skipping a beat. I look forward to making good use of this cluster, extending it, and building similar clusters for production work loads in other settings. It’s a winning solution worth expanding!

The pockyclypse will be illustrated…

 Ad-Hoc  No Responses »
Feb 132025
 

I observed at one of my haunts that after a series of forced platform and tooling migrations with unreasonable deadlines the dev teams found themselves buried in tech debt… for example, the need to migrate from labrats to gitlab build pipelines and so forth;

Personally, I don’t run things this way… so it’s extremely painful to watch and creates a toxic environment.

While working with the team to try an wrangle the situation an image occurred to me of the team fighting a desperate battle against tech debt (and not necessarily winning). I described what flashed in my mind to gemini and it made a pretty good rendition of it. If nothing else, generative AI is a good way to rapidly express ideas…

Sketchy – Integration

 Ham Radio  No Responses »
Mar 022024
 

Sense Wire Loop

The first step to prepping for installation is to clip the sense wire used for testing and convert it into a loop – to act as a terminal on the board. The plan is to clip the existing sense wire in the controller and insert “sketchy” into that line. In order to make that work we need to have an easy way to connect both ends of the clipped sense wire. A loop on each end of the board will do nicely.

Find Power

The next step will be to identify the cleanest way to get power to our board. As it turns out the controller has regulated 5V rails in the middle of it’s board AND (lucky for us) there are two adjacent holes on those rails exactly in the right place for our ribbon wire. Here you can see the red and black ribbon wire matched up with the rails… carefully inspecting the circuit to make sure the polarity is correct and precisely where these wires will come through the controller board.

Not visible in this shot, on the top side of the board near the top of this picture I identified the 5V regulator and it’s pins to make sure which of the two rails in the middle are positive and negative.

Power Leads Inserted Top Side

Here I’ve inserted the power leads from the amplifier into the controller. They fit correctly flush up against the board and it’s clear that the colors for + (red) and – (black) match up with other connections on the board. This is another good sign that I have the polarity right.

Power Leads Inserted Bottom Side

Viewed from the bottom side we can see the wires coming through the holes in the power rails on the controller. It all looks correct (again checking carefully) so we can solder it in.

Power Leads Soldered

Here is a close up inspection of the new connections soldered into the rails. No unwanted solder bridges. Nice smooth, shiny solder joints. Some of the other nearby joints leave holes uncovered but otherwise they look fine… so I resist the urge to reheat them.

No Melted Insulation Top Side

One of the reasons I resisted the urge to re-heat those other joints is because I don’t want to begin melting insulation or causing other trouble. The connections themselves are electrically just fine – -it doesn’t matter at all (except maybe aesthetically) if the holes aren’t completely filled in. But, it DOES matter if the insulation melts potentially causing a shorting hazard.

Here we can see that the newly installed wires to power “sketchy” are not melted at all. That means there was just enough heat for just long enough to make a good solder joint.

Clip Existing Sense Wire

Now that power is available to the amplifier board we need to put it in line with the sense wire. The existing sense wire is the white wire in the maw of the clippers. I have dry-fit the board into that location in the box and so I know I can clip the sense lead right in the middle of that location. One side of it will bend back to the input of the amplifier and the other side will bend back to the output. This will leave just enough extra lead to safely solder the connections and move the new board around to the right position in the box.

Carefully Calibrate Stripper

A tricky part of the installation will be trimming the insulation off of the freshly clipped sense wire. It’s important to get this right the first time… because if this step goes wrong then there will be a lot more work to do replacing that wire and it’s other connections.

The wire strippers have a small bolt and nut that can be slid into the correct position to calibrate the strippers and then tightened down. So, with the calibration bolt loosened, I take a similar wire that I can use as a gauge and carefully close the strippers on it until they just barely cut all of the insulation without nicking the conductor. Then I carefully tighten the bolt and re-check that the calibration didn’t move during that process. It seems like a lot of work – but sometimes there is no substitute and I “really” don’t want to have to replace those wires if I can avoid it so it’s worth the effort.

To make sure I have it right, I strip a few more bits of insulation off of the test wire and inspect the conductor to ensure it’s not nicked; all the while making note of the pressure required to squeeze and pull the insulation so I know what will feel right when I do the real thing.

Sense Lead Cut, Stripped, and Tinned

Once I’ve stripped off about half a centimeter of insulation from both halves of the sense wire I tin the ends so that it will be easy to get these soldered into place. With tinned wires, one can push them through the connector loops and give them a quick hit with the soldering iron to get them connected. Then when both are done it’s easy to go back and re-heat them and fill them in a bit without having to worry much about the board or connections moving around during the process.

Sense Leads Inserted Into Loops

Here is a shot of the board in place, top-side up, with both ends of the sense wires “tacked” in place.

Sense Leads Soldered

With that done, we can go back and re-heat the connections and fill them in a bit to make things good and solid. Here is a shot of that from the top at about the angle I saw soldering them.

Side View

Here is a shot more from the side.

Sense Lead Output Close Insepection

Just to make sure the connections are solid I used the camera to take close-up inspection shots — here is the output lead close up.

Sense Lead Input Close Inspection

Here is the input lead close up. This shot is a bit motion-blurred, but it’s clear that the connection is solid and shiny.

Installed

With all of the wires connected it’s time to flip the board over into it’s permanent location. Part side down, directly over the input connections. This protects the parts by keeping them (as much as possible) in free space away from the top, and makes the circuit easily accessible for any probing I might want to do later.

Smoke Test – Green Light!

A quick look around to make sure everything still seems correct and then we turn on the power. Hurray! No magic smoke has escaped and as expected the green light is on! The tuner is virtually always in a tuned state so this is what we expect. It looks like the project is a complete success.

Hrmmm, That’s Not Right

… except, after letting WSPR tune up on a few bands I notice that the green light never seems to go out. Occasionally, as I recall, the amber light should come on while the tuner is working it’s magic… and that doesn’t seem to be happening.

So, I hook up the meter to the input side of the amplifier via some clips and I see it’s barely a diode drop below the 5V rail… or should I say a BE (base, emitter) drop.?

It seems that my sketchy open collector signal amplifier works too well. It’s clear that the signal line from the tuner is not open, and it’s also not shorted, nor is it being pulled to ground as expected. In previous tests I noted that the voltage did vary quite a bit as if some signal were making it through that line and into the controller… so I expected that I could amplify that signal and get the desired result.

As it turns out, that was not a good assumption… and I will have to go back to head-scratching, and perhaps go and investigate connections out near the antenna to see what’s actually happening there.

In any case, this was a fun little project and it does do what it’s designed to do… it’s just that this sketchy idea has turned out not to be the right solution. I guess that makes it a successful failure.

Sketchy – Build

 Ham Radio  No Responses »
Feb 142024
 

There are a lot of ways to build quick prototypes. These days it’s even arguable that you should have a PCB made since you can get them so cheaply and quickly… and then also, if you go on to make a production grade project you’re further along.

However, I decided to do something really old school and just put the parts into a perf board. This is actually a pretty rare way of doing things these days since I won’t be using any kind of purpose built prototyping PCB, nor manhattan style construction, nor any of the other popular methods. I’m not even going to use perf board pins (that’s another old-school method… can you even buy those anymore??)

Instead, I’ll plan it out so that only the component leads and a bit of wire are required. With a bit of practice this method is perfectly fine for anything that’s not going to be using RF (because there is no ground plane of any kind with this method). This method is just shy of being sculpture… but working this way is quick because it doesn’t require anything more than what you have on hand, and therapeutic because getting it all together is a bit of an art form: working with your hands, bending wires just right, growing the circuit somewhat organically one part at a time… limited only by the parts themselves, your patience, and your imagination.

Plan the layout.

Lay a piece of perf board on a piece of graph paper, and imagine that each crossing point is a hole in the perf board. I like to work from the top side with an “x-ray” view of the wiring. Actually, the wiring might be on either side so “x-ray” means you can see it no matter where it is.

This approach will limit you to making circuits that don’t require jumpers (mostly)… and that tends to keep things simple. It’s not that you can’t use a jumper if you wish; but it’s easier if you avoid them… and that will make you think a little more carefully as you proceed.

You’ll also want to be very careful about the pin-outs of any components you’re using. Check everything more than twice as you lay out the circuit. It sometimes helps to actually pick up the part, find the correct pins, and put it in the perf board somewhere just so you can see and feel how that goes together. Not everyone can do all of that in their head (I can, but I have had a lot of practice). Seeing your drawing right next to an actual part in a board can be a very powerful way of making it all “real” so that you can reason about it without too much effort. The more time you spend relating the two physically the easier it will be (eventually) for you to see that process in your mind’s eye.

Generally proceed from input to output; complete the nets for any given component before moving on to the next (but have in mind where the next connected parts will fit into the layout); and try to keep the rails on the outside edges of the board. By working this way, eventually you will complete all of the work for one section of your design before moving on to the next section. As you complete each section it’s a good time to check that it’s really complete and everything is properly connected before moving on to the next.

Don’t be afraid to start over if you run into a dead-end of some kind… like painting yourself into a corner in a room, it’s possible to go through this process and eventually find out that you don’t have room for something; or maybe you might discover a better layout along the way. At this point it’s only paper! Toss it out and start again… this time starting from experience… it will go faster and be better each time you iterate through this process (if you need to).

After having done this for a while, I can usually get through a complete design in a single pass with almost no re-work… mostly because at this point I can see forward several steps at each stage and because I can have a rough block-diagram kind of model in mind even before I begin. All of that comes with experience and it’s the kind of thing that can save you huge amounts of time and trouble if and when you do start designing PCBs… starting with a “rats nest” and dragging parts into place, of course (you don’t use auto-routing do you!!!).

In this case, I started with the input (one resistor, yeah, not much of a section), then since it’s next connection is to the input amplifier I completed that next: first by placing the input transistor so that it’s base is right next to it’s side of the input resistor, then by adding the filter capacitor from that net to the emitter side of the transistor and the positive rail, then I cheated just a little by adding in the pull down resistor that’s at the gate of the output stage… I say I cheated but I didn’t really, it was a natural progression to the next stage and (depending on how you look at it) the collector resistor of the input amplifier IS the pull-down resistor for the gate of the output switch… either way, that part completes the input section and makes for a good time to look it over and check that all of the circuit up to that point is complete and will work as expected. A pause, then on to adding in the FET, and so forth…

I like to imagine actually mounting the parts as I draw them on the page so that when it comes time for physically mounting the parts and soldering them together I’ve already had a dry-run through that process.

This includes considering how the parts will hold each other in place through that process and when the project is completed. Some combination of bent wires against the circuit board, little loops, and other mechanical tricks will be combined to make this process work. Working out those details while laying out the design drawing is a powerful way to avoid problems during assembly and after things are complete.

By the time you’ve finished the drawing you should have complete confidence that all of the nets have been accounted for and that the physical rendering of the circuit will not only work, but might even have some aesthetic value 😉

Cut out some perf board.

Once you’ve finished your drawing you will know precisely how many “holes” of your perf board are required by counting the squares on the graph paper that are taken up by the completed design. Use a marker (sharpie) to sketch out the boundaries on your perf board and then score over those with an exacto knife. After that, you should be able to fairly easily use needle nose pliers to cleanly break the perf board along those lines.

I like to use the long edge of the pliers along a scored line and start bending the board at one end of it… that usually leads to a nice clean break as the needle nose pliers will tend to protect the part of the board that they cover.

Mount the input resistor.

Right away I start with some of those little physical tricks I mentioned. One end of the input resistor must also create a terminal for connecting the input. Here, I’ve used that to physically hold the resistor in place when it’s first mounted.

Using the end-on style of mounting this resistor (as was popular in old transistor radios) I chose to put the body of the resistor close to the input transistor. This way, the other lead of the resistor makes a handy test point and also is easier to work with while weaving the end of it through the perf board and back to make an input terminal (loop). Down through one hole, up around the edge of the board and back down through an adjacent hole bent into a loop. This lead holds the input resistor into the board early and acts as a strain relief for any wire(s) that might be soldered to the terminal later.

Mount the input transistor.

Next up I added the input transistor. This being a PNP transistor, I know I want the emitter toward the positive rail (eventually), and the collector toward the negative (ground) rail. Luckily the pin out has the base in the middle so it’s really easy to get precisely what I want just by making sure the flat side is away from the input resistor and the input resistor is “in the middle.”

To hold the transistor in place I can start by slightly splaying the leads out on the underside of the board, or perhaps even bending some of them into their final direction prior to soldering.

If you look closely you’ll see another physical trick similar to what was done with the input resistor. In this case, the emitter lead is weaved through the perf board to stick up through the top side eventually to connect to the positive rail and the filter capacitor. This required a little thinking ahead and was only one of several options; but I decided it was a good way to hold the transistor in place and provide options for binding the positive rail later.

Input connections underside.

Looking at the underside you can see that the input resistor lead is bent flat against the perf board and runs right next to the base lead of the input transistor. This way, the base lead can be laid flat right next to it in the other direction making for a tidy connection and a strong physical mount for both.

You can also see off to the right of that where the emitter lead has been fed back up through the perf board to connect to the positive rail and the filter capacitor (coming up next).

Add the filter capacitor.

Back on the topside of the board you can see how the filter capacitor fits perfectly (skipping a hole) between the extended emitter lead and the base lead. Here again was an opportunity during the planning stage to put a part through the perf board and understand exactly what size it is.

With the filter capacitor in place the emitter lead is bent down to meet it at the hole on that side. I actually tried to get the lead to go down through the same hole– but it was a bit too short and thick for that. No matter, I planned ahead so there will be plenty of ways to sure up this connection electrically.

Solder in place on the top side.

To start with, I just soldered the emitter lead to the filter cap lead on the top of the board. That works fine for these first steps and holds the filter capacitor in place while working on it’s other lead.

Connect filter capacitor to input, underside.

Back on the underside of the board the filter capacitor lead gets bent flat across the base lead and the input resistor lead. Having all three of these laying in parallel to each other will make for a good electrical connection.

Solder in place, underside.

Once soldered, the net for the base of the input amplifier is complete; and the net for the emitter side of the input amplifier is well prepped. Assembly of the circuit is progressing essentially in the same order as it’s planning was done.

The output section is highly dependent on the power rails being in place so I decided to get that work done before installing the FET and other components. This kind-of breaks the rule of progressing from input to output… but not really since in this case best way to install the next section would be to have the power rails (the ground rail especially) in place first.

Wire for rails and output.

I happened to know I had some color coded ribbon wire when I started this so I planned to use it from the beginning. It normally has 4 conductors, but at this point I’d stripped off the green wire leaving a convenient red, black, and white. In other parts of the project the input is generally white so that works out perfectly.

The imperfect part is that the white is not in the middle– but it will be on the perf board… and as it turns out, with a little planning, even that won’t matter for long because I’ll be removing the white wire to create a terminal instead during integration. For now, however, having these all together in a ribbon will help hold things in place.

Wire for rails and output fed into board.

After stripping off sufficient insulation to reach back to the existing circuitry I put the wires through the perf board and bent their leads flat along the required straight lines on the underside.

Route the positive rail into place, underside.

The most useful next step is to complete the positive rail. Note that the wire ends up parallel to the lead from the filter capacitor; but it runs past that so that it can be fed into the hole where the emitter lead was previously woven back up through the board.

Positive rail soldered into place, underside.

Having soldered the positive rail to the filter capacitor lead, which was laid down parallel to it, and having extended that further to the emitter lead, the positive rail net is now complete and quite solid.

Reheat the emitter at the positive rail.

For good measure I reheated the emitter, filter capacitor, and positive rail on the topside of the board.

Add pull-down resistor to collector.

The next best connection to complete the input section and begin the output section is the pull-down resistor. Here you can see it mounted with it’s body at the collector of the input transistor and it’s tail going through the board in line with the negative rail.

In this case I opted to have the tail connect to ground since that is a safer thing to expose and also because it keeps the lead connected to the signal in the circuit as short as possible.

Bend pull-down resistor leads for ground rail and collector net.

Back on the underside, the tail of the pull-down resistor is extended along the path of the negative rail; and the body side lead is folded flat in parallel with the collector lead of the input transistor. The transistor lead is then extended along that path to eventually meet up with the gate of the output FET.

Solder collector lead.

With the collector lead soldered to the pull-down resistor the resistor is held solidly in place and it’s time to mount the output switch (FET).

Mount FET.

The pin-out of the FET is also convenient. In this case we can put the source in line with the ground rail, put the gate in the next hole in line with the collector of the input transistor, and end up with the open drain perfectly in line with the output wire. To do this, the flat side of the FET must face the flat side of the PNP transistor… but that conveniently makes for a nice space where the pull-down resistor can live comfortably.

Bend FET leads for ground rail, collector net, and output.

Back on the underside of the board the FET leads can be bent flat against the perf board in parallel with the ground rail, the collector output of the input stage, and along the path of the output lead.

Solder the gate to finish off the collector net; prep ground rail.

At this point all of the parallel leads have been pressed and bent together. Some of them (the ground rail especially, and the output lead) are “a little squirrely” so I save them for the next step where I plan to use some clips as helping hands to get them soldered up cleanly.

Also, in keeping with the input-to-output flow of work, I soldered the gate to the collector net finally completing the input section.

Solder ground rail first pass; prep open drain output.

With a bit of patience and a strategic placement of the alligator clip I made a first pass at soldering up the ground rail. That’s enough to hold it in place and keep it tidy while working on the output line.

Open drain output and ground rail done.

Finally, I soldered and trimmed the output line and reheated the ground rail. That completed all of the nets! Now is a good time to inspect the work and do any final clean up that’s required.

Finished view from the top, ground rail side.

Finished view from top, positive rail side.

Smoke test; input open.

Satisfied that the circuit was correct and anxious to move forward I hooked it up in place of the original prototype on the bread board, turned on the power and the meter, and made a quick test. With the input open the output is also open.

I notice that the numbers are a little different, but not by much, and I expect that having scavenged the parts for this build from those that were used in the breadboard, and that breadboards are notorious for acting differently than soldered circuits, I paid it no mind.

Open for open is GOOD!
No escaping magic smoke!
next test…

Smoke test; input weakly grounded.

Next I put the weak ground lead through the input terminal and I expect the circuit to close.

It works! The circuit closes, the LED comes on, and still no magic smoke!!
…but did you spot the measurement error?

Just now I realize why the numbers are slightly off.

It turns out that in my excitement I put the meter in ACV mode instead of DCV. At first I was very puzzled that I got a stable reading at all… let alone one that was so close to what I expected.

I did some digging. Many (most) meters (this Fluke is one of them) don’t actually block DC when measuring ACV and so will tend to show something close to the DCV measurement when a DC input is present and an AC input is not.

Three takeaways then:

  • Hurray! It’s works, and it doesn’t look half bad.
  • Be more careful when setting up your measurements. For example, don’t ASSUME that having left your test rig set up it’s all ready to go if you just turn it on; and don’t assume that getting a measurement that’s close to what you expect is a sure sign everything is correct!
  • A DVM on ACV will probably (almost) measure a DCV that’s close to what you expect. Who knew?!

Sketchy – Prototype

 Ham Radio  No Responses »
Nov 112023
 

I thought “Ok, so let’s throw some parts at this thing and see if it works like the simulation…” and so I did:

As it turns out, I had a few different parts laying around the bench and using those would be easier than hunting down the specific values I had in my original simulation… those values aren’t critical really, so I just used what was already lying on the bench and updated the schematic in EveryCircuit to match:

Built up on the breadboard it looked like this:

I find that with a little effort and creative thought it’s not difficult to get breadboard layouts to closely resemble schematic diagrams… and from there it’s not too much of a leap to get to what the prototype(s) and final build(s) will resemble.

A clockwise tour of the circuit on the breadboard…

Here you can see from top to bottom on the breadboard matching roughly from left to right on the schematic: There is a 47K input resistor that I’ve connected to a white wire that will act as the switch.

I describe that as a “wire” so that I can reserve the word “jumper” for the short color coded jumpers I use to make patches between segments of the breadboard. These are fantastic, by the way, because they are color coded for the number of points they span. This saves a lot of time when building up more complex circuitry or trying to trace where one or more of these jumpers go…

See the red jumper connecting 2 points away, and the orange 3, and so forth… very nice. I bought a bunch of boxes of these and I use them all the time. They’re so cheerful and perky. Full of potential – like a fresh box of colored pens and a new graph pad. I love that… but I digress.

You can see the input resistor go directly to the base of the PNP transistor, and on the back side of that transistor you can see the filter capacitor between base and emitter; an orange jumper connecting that to the positive rail 3 points away.

Moving down from there we come to the MOSFET acting as a switch. A red jumper connecting the collector of the input transistor to the gate of the switching MOSTFET and then from there you can see another 47K resistor pulling that down to the negative rail on the right.

In parallel with that a yellow jumper connects the source of the MOSFET to the negative rail (which will be common ground)… so that the other side of the switch is a typical “open drain” version of the “open collector” type of switch. The key idea being that it’s either open, or connected to ground.

Speaking of the “open drain” you can find an orange jumper crossing the centerline gap to the left and acting as the “output” of the circuit. Over on the left side you see couple of header pins stuck in the breadboard as a test point connector of sorts and then a panel mount LED connected on it’s other side to the positive rail through a 470 ohm resistor. (It was laying right there, and I didn’t care about the LED being a little bit dimmer, so I just went with it!)

You may have a little trouble spotting the header pins because there is a white alligator clip chomping on them… and if you look over to the right you’ll see a black alligator clip chomping on another set of pins plugged into the negative rail. These two clip leads make it easy to keep the DVM in circuit to measure the voltage across the output of the circuit… that way we can see just a bit more detail than whether the LED is on or off.

Testing Sketchy with a floating input

The guess is that the tuner controls the status line as an open-collector type of output. This means that the long wire running from the shack out to the tuner would see a very high impedance and would be essentially “floating” whenever the open collector is “off” at the tuner.

In this test you can see that the white input wire is hanging in the air on the left. The voltage at the output of our circuit is about an LED drop down from the positive rail… I guess because the DVM pulls just enough current to see that drop. 1.256v = 5 – 3.743

The LED is off… so all is well.

Testing Sketchy with a “human antenna” input

A long “floating” wire seems a lot like an antenna that might pick up all kinds of noise or even some stray RF (this is going to an antenna tuner after all). We want to make sure the circuit isn’t sensitive to that so we put in a filter capacitor across the BE junction of the input transistor. The idea is that the input resistor and the capacitor make a low pass filter that will reject almost anything that isn’t close to DC.

Connecting myself to the input wire to give it some “extra length” we can see that I do inject some noise; but not enough to cause the circuit to really switch. The LED stays off, and the voltage across the output only goes down by a couple hundred millivolts. That’s enough to see on a DVM, but not enough to matter when switching LEDs on and off. (Nor even enough for any logic circuit that might come later to care about it either.) 201mv = 3.743 – 3.542

Testing Sketchy with the input pulled high

Another design spec is that the circuit should be happy with a TTL input. So, connecting the input to the positive rail (+5V) we get the same result as the floating input: The output is off as expected!!

Testing Sketchy with the input pulled low

Testing the other side of the TTL input spec as well as the open collector input spec, we pull the input low by connecting it to the negative (ground / common) rail. As expected, the output goes to ground and the LED comes on!! Not only on, but VERY on… 11mv measured across the output.

This is a benefit of using a good switching MOSFET vs a bipolar transistor for this kind of output (open drain/collector). The “closed circuit” or “on” condition of the output with the MOSFET will have a much lower voltage than you can get from a bipolar transistor. Definitely closer to ground.

Testing Sketchy with the input pulled low weakly

Finally, since our theory about the status line problem is that it may be oxidized at the connector near the tuner, we tested again with a high resistance in place. In this case, a 220K resistor to simulate whatever that unwelcome resistance might be out there. Again success! The LED is fully on just as if the input had been pulled hard to ground.

Qapla’ !!

Sketchy Long-Run “open collector” cleanup

 Ham Radio  No Responses »
Oct 102023
 

A while back we replaced the SGC-237 at the feed point of the big loop. Since then, the controller has been a bit sketchy. The indicator for a good tuning solution is intended to light either the yellow panel LED or the green panel LED; but since the upgrade the best it seems to manage is a bright or dim yellow.

I’m not sure what’s going on there, but I have a few theories. One is that the junction for the control indicator line in the box under the tree might be a bit oxidised causing extra resistance in the line. Another is that the design of the SGC-237 might have changed with the unit I have now, or that perhaps it never really was an open collector on the tuner end (that was a guess afterall). Another is that I just got lucky with the first design and that the long lead length might have something to do with my indicator not-quite getting the clear signal it needs.

I did measure the voltage across the input while the system was up doing it’s WSPR thing (where it must tune with each band change)… and I observed that the voltage from the indicator to ground seemed to get no higher than about 4V and no lower than about 3.2V… that’s weird, and suspiciously close to a silicon junction drop (about 0.8V)… almost as suspicious as frog’s breath… but of course, nothing is as suspicious as frog’s breath. Whatever is going on there has to do with how the indicator circuitry in my controller is interacting with the tuner through the controller cable and the junction box in the middle.

Anyway– at some point I will go out there and lie on the ground and “improve” the connections in the box. In the meantime, since the tuner seems to otherwise work just fine, I’m looking for a quick fix to get my indicator working properly again and generally make it more robust.

So, based on the idea that it’s probably some thing that looks reasonably like an open collector at the tuner end, or that even if it’s a TTL signal I might be able to interpret it like an open collector… I designed a circuit to clean up the indicator signal and make it FIRMLY on or off in an open collector manner.

Here is a snapshot of the schematic from Every Circuit (which was handier and a bit cleaner than my usual graph pad + phone camera… even if the N-Channel Mosfet symbol is a bit odd):

The diagram presumes I’ll be using the 5V supply from my existing controller. There is an SPST switch representing the input of the circuit which is the indicator line from the tuner. The output is the drain of the N Channel MOSFET that I’ve shown here connected to an LED via a 330 ohm resistor… but essentially that output will either be open if the input is “open” or “high”, or closed (shorted to ground) if the input is drawing current down from the 5V supply … as if it were “closed” (or trying to be) or “low” if it’s acting like a TTL signal.

Either way, the circuit should clean up the input by slamming the output fully open or closed. Here is the theory:

The input is tied to the base of a PNP transistor through a 47K resistor to limit the base current. The emitter of that transistor is tied to +5V (the positive rail).

If the input represents a high impedance between the positive rail and ground then effectively no current will flow through the base of the PNP transistor and it will be off. This will happen if either the input is something close to +5V like a TTL signal, or if the input is high impedance in general like an open collector would be.

The collector of the PNP transistor drives the gate of an N Channel MOSFET which is otherwise pulled to ground through another 47K resistor. So, if there is no current on the input then there is no current through the PNP transistor and the gate of the MOSFET will be at 0V. This will turn the MOSFET off and so it’s output will be “open” to ground.

On the other hand, if any current (even a fairly small one) flows to ground on the input, then the PNP transistor will switch on and pull up the gate on the MOSFET thus turning it on. The voltage gain of the PNP transistor given a 47K load (the MOSFET gate being essentially invisible to it) will be very high so that even a tiny current through the input will be enough to pull the MOSFET gate well above it’s “ON” voltage.

The choice of a 47K resistor on the input and also on the collector/gate is the same in both cases… it’s a high impedance (but not too high) and a handy value (I have a pretty good inventory of standard values like this). On the collector side of the PNP transistor this means a lot of gain. On the base side of the PNP transistor it means that not much current can flow through the transistor no matter what the input voltage is (within reason). That said, the beta of the PNP transistor is likely on the order of 100 so whatever the input current is at the base the output current will try to be about 100 times that amount.

I measured a 0.8v change between on and off in the existing circuit. The new circuit will amplify that by about the beta of the PNP transistor since the same resistance is on the base and on the collector, so any gain as big as 6 or so will be enough to swing the collector side between the 5V rails. With a beta of 100 I’ll be more concerned about instability than missing a weak signal. (I’ll address that if it shows up; but for now, simpler is better.)

Since I have these parts around I chose a 2N2907 (the complement of the 2N2222) as the PNP transistor; and a 2N7000 (a very common switching part) for the MOSFET.

Terrible Tiny Antenna Idea

 Ham Radio  No Responses »
Oct 052023
 

It was a dark and dismal November, a few years back; and there had been a lot of sudden, unwelcome changes that year. The house was empty, it didn’t feel very festive at all; but I had decided to treat myself to a new IC-705 and some other toys to try and break the gloom.

I sat in my living room pondering all the things, and wondering what to do for an antenna so I could light up the new rig and lighten the mood. I’d had a few discussions with folks who were trapped in apartments or even in tall buildings where there were essentially no good antenna options… so that was fresh in my mind.

I could have used the big loop outside — but it was busy with the robots, and not where I was. I looked out the window into the damp, cold, darkness… sinking slowly into madness.

Then, I thought, I could maybe string some wire around that window and make an antenna… surely I could at least receive with such a thing… and there’s nobody here to stop me or complain about it… My mood got a little brighter… but I knew the math and it wasn’t promising… and strictly receiving didn’t sound like quite as much fun as I hoped for.

I pondered some more, and the outside got darker; but eventually I dragged a few random bits of wire and odds and ends up from the lab along with a few other new toys I had… the random wire and bits and pieces reminded me of what the Grinch had left on the walls when he stole Christmas… it seemed fitting enough.

I figured if I was going to have “staring into the abyss” on my schedule I might as well tinker while I was at it… so I also grabbed my new Nano-VNA and my new LCR meter… additional toys I would be acquiring from Santa soon (or well, I could pretend anyway).

I’m normally the sort that draws a zillion pictures and diagrams and does all the math to figure out my designs before I set about building anything. This time, that seemed like a lot of work, and I wasn’t up for it… and since I had new toys that gave me the ability to “see” what the various parts and circuits “looked like” electrically, I decided to go the other route and just try stuff and see what happened. I figured I’d eventually end up with “something”, or I’d keep playing with it to see what I could learn. Besides, I’ve got plenty of theory in my head to give me some direction… it would keep me busy anyway.

The first idea I had was to take some shielded, multi-core cable I had and cross wire it so that it would be a 7 turn loop the size of my front window. I figured that with a large diameter and 7 turns it would be a pretty good inductor. I also thought that with the shielding in place it would be purely magnetic and so probably less noisy. But, in my temporary excitement I forgot about the inter-electrode capacitance. Each of those wires were all right next to each other inside the loop shield so that would defeat the multiple turns. I figured this out after trying it and being disappointed with the results.

The multi-turn loop idea had a few fairly narrow resonant points, but it didn’t really act like I wanted it to and was going to be really fiddly with the tuning. In fact, I had a devil of a time getting it to be sufficient at any of the frequencies I wanted to use.

Once I realized that the multi-core idea wasn’t going to work I grabbed some electrical ground wire I had laying around and decided to try a single loop with a loading coil to make up the difference in electrical length. That was less chaotic, but also didn’t quite work.

I knew I didn’t want to use a coupling loop because that would be impossible to hide as an inside antenna around a window… and well, also because I just didn’t like the idea! But that did make me think about the fact that that’s really a kind of transformer… So, I wrapped a couple of turns around the loading coil I’d made and that seemed to work much better.

I tried a handful of variations on that theme and got similar but varying results. I could see what was happening using the Nano-Vna, and I could measure the inductance and capacitance of the parts I was using with my LCR meter. This gave me a few ways to turn the wheels in my head… and so I kept tinkering… and it became morning, and then evening again…

2 turns on the primary of the transformer and 14 on the secondary with the tuning capacitor in series seemed to get an interesting result; so I played with that for a while… but I realized that the capacitor wasn’t really helping that much, and I also couldn’t get that second resonant point to be where I could really make use of it.

I started experimenting again… and essentially replaced the capacitor with an inductor… a loading coil, just to see how that would change things…

Tiger was supervising all of this work… Truth be told, it was Tiger who suggested replacing the cap with a coil and I told him it was a crazy idea and that it would never work because that’s not how you tune loops and … well, he’s a cat and … just … oh FINE, FINE! I’ll put in a coil and show you how it doesn’t work like that … you’ll see right!?

Nope, the crazy idea actually worked… the second resonant peek disappeared and the first one expanded… not quite as much as I had wanted, but quite a bit. Tiger, just looked at me as if to say “I told you so…”, but being a very cool cat, he refrained and just let me soak in the moment… then went back to doing cat things and occasionally supervising my continued tinkering.

After stumbling upon this solution I thought about it and realized I’d created a match that draws on several techniques.

The loading coil is borrowed from short whip antennas where it makes them electrically longer and therefore (typically) a higher impedance that’s easier to match to the feed line.

The high ratio transformer is borrowed from end-fed dipoles and similar kinds of antennas where it converts the high impedance at the end of the wire into a lower impedance that matches the feed line.

The loop antenna fed this way is completely balanced so it doesn’t need any kind of counterpoise nor does it have any free ends of it’s own which might expose high voltages.

I decided to take this to an extreme of sorts and scale it up. I basically doubled the number of turns on the loading coil and ramped up both sides of the transformer as well. The primary now had 3 turns, and the secondary had 30. The loading coil has 16 turns symmetrically split and bound to the secondary of the transformer so that there are no cuts in those wires… that is, the secondary of the transformer becomes the loading coil on a second core.

I have since called this contraption a Swamped Impedance Match because conceptually, the antenna and loading coil virtually guarantee a high impedance that “swamps out” the vagaries of the radiating element; and then that high impedance is divided by 100 using the high ratio transformer so that any of those “vagaries” are also divided by 100 thus making a reasonable match to the feed line across a wide range of frequencies.

The results were pretty good as far as matching goes. The antenna with the match manages to have a very wide frequency response covering most of the HF bands I wanted to play with and offering a usable SWR from about 4 MHz up to about 20 MHz. The antenna wire itself is a square about 80 inches on a side… but the actual loop isn’t critical. I picked that just because it would perfectly fit my window all the way down to the floor… the idea being that with any kind of drapes on the window the antenna could be completely hidden from view!

BUT, I hear you say; and I said it too; just because the thing has a reasonable 50 ohm match doesn’t mean it makes a good antenna… even if you can receive with it that doesn’t mean it’s actually a “good” antenna. It could be just a mediocre, and somewhat frequency specific, dummy load!

Tiger scoffed, and gave me a look, and an up-nod, and said (via kitty mind control) “You’re the Mad Scientist … do some science and prove it to yourself.”

So, I turned off the big rig temporarily and fired up WSPR on my Spectre laptop running Linux, and my new IC-705; connected it to the Terrible Tiny Antenna; and let it run for a couple of days to see what the rest of the world could tell me about the antenna’s performance.

It worked! No, really!! WSPR data from this setup shows fairly respectable results even when compared to my big loop in the back yard!

Here you can download the raw data (a text file) from that experiment. The top part of the data is for the Terrible Tiny Loop with the Swamped Impedance Match; and the bottom of the file is data from the big loop (with an SG-237 tuner at it’s feed point) for comparison. Both were running 5 watts. The small rig in my living room with the IC-705, and (at separate times) the big loop running from my lab with the Flex 6300.

Stealth-Antenna-WSPRDownload

Just to be extra sure about the results I asked some friends of mine in AMRAD to build the antenna themselves … and they also found it worked pretty well (though, their build quality was a bit better than my initial experiments.)

Here are some pictures of one of those builds:

Here is a schematic I hastily drew up for my friends to use as a guide… it’s simple enough as is the construction of the antenna and match.

The toroids are typical of what you might use for an HF balun (FT-240-43). Begin with about 4 meters of wire folded in half and wind the secondary on the first core from that mid-point. Half of the windings on each side of the core spaced so that they finish just opposite of the starting point.

Then, use a zip tie to attach the second core where the secondary wires are free and wind each of those wires through the second core about 8 turns on each side as if they are one winding split in the middle at the transformer.

This completes the secondary of the transformer and the loading coil with a single piece of wire. There should be just a bit left so that you can make some kind of connections for your antenna loop. Banana jacks are a good choice here.

Then complete the primary of the transformer by winding 3 interleaved turns of wire at the point where you began the secondary. Attach the free ends of the primary to some kind of coax connector of your choice. (it might be helpful to put a small value capacitor across the primary, but it’s not strictly necessary.)

The Swamped Impedance Match can be left loose like this for experiments, or it can be put in a box if you want it to look better and hide under your window behind your curtains 😉

The antenna loop itself as originally designed is approximately 80 inches on a side, but given the nature of the antenna the length is not critical and as long as you don’t have a lot of metal in your walls you can probably mount the antenna anywhere that works for your needs. I have taken this antenna out for demonstrations and simply stood it up in the air on a pair of lighting tripods with good results… it’s appears to be very tolerant of variations on installation and environment.

While the large toroids I used might imply that you can use some significant power with this — I don’t recommend it… certainly not if you’re using it inside where radiation and interference with other devices might be a concern. I simply used those toroids because they were what I had on hand. I suspect you could easily reduce the size and cost of your toroids and still get good results. Let me know if you try this and how it goes with any of your experiments.

 Older Entries