Neuron v0.4 has been fantastic; the platform more than meets my expectations. The board has not developed any electrical issues, and the hardware design does not seem to constrain progress. The steep learning curve of AVR-C (and embedded programming in general) has taken up most of my attention, with eight-board build-outs providing a much-needed break between coding sessions. With that said, I've tried to keep track of a few gripes, roughly outlined here.

1. The LED isn't great at being "RGB". Specifically, the red wavelength is about 20-30 nm or so too short; it's sort of an orange-red. During normal operation, the LED won't be seen with only its red element on, since (at least with the current firmware) that would occur very close to an action potential. However, the 70% level is a pretty common sight, since it's the point a single Exciter will hold; with a better RGB element, this might be more of a pure orange. If I can find something for <$0.25 each that fits this criteria, I think it's worth a shot.
2. Bigger pads. Everywhere. The current board design has enough room between components that I can at least stretch the standard footprints out a bit to improve reworkability. Pulling the dropping resistors away from the LED a bit might be necessary.
3. More on-board axon connections! Maybe a dedicated axon with a built-in terminal that ends in wired plugs rather than header--this would be fairly easy to construct with a bit of heat shrink to connect a bundle of standard axon halves. Or just 2-plug, 4-plug, and 6-plug axons, with the 4- and 6- units having one longer lead to connect to the upstream Neuron.
4. Cheaper. Always cheaper, if I can swing it. That means looking at the most expensive bits--the circuit board, then the microcontroller, then the LED, then a lot of space before the passives and connectors.
5. Improved programming interface. I think a commercially available PCB-based solution might serve me best--the cheapest option at scale since it just requires a bit of drilling and de-masking, and fast for programming lots of units in series.
6. More flexibility on the dendrite side. I've thought about this most of all, even though it's not the highest priority right now since I rarely, even with 30+ Neurons, fill all six Dendrite headers on a single board. Here's the thing--I think I'm mostly constrained by item (3) on this list right now. My Axon Terminal design isn't fantastic--broken perf board bits with heat shrink and a few headers, meaning each one requires three additional Axons to function completely. But if I fix this problem, I'll start using tons of 4-plug and 6-plug axons in my designs, and the Dendrite constraint is really tough--since I take up an entire I/O line for each Dendrite, I'll need to use a different (or multiple) chips to gain I/O. Or cascade branches of Neurons, adding potentially unwanted delays to a loop. Or building dedicated 'high volume' Neurons, which would double the firmware sets (even if they're only slightly different) I'd need to maintain, and increase the BOM length and the number of circuit board designs...

So I started mulling it over and think I could drastically change the electrical design of the Dendrite system. Rather than looking for incoming voltage pulses on an upstream Neuron, I could build some kind of a circuit that utilizes the onboard ADC to figure out how many simultaneous signals are getting to a big parallel bus.

More to come!