rnd:sketchpad [UWiki XXX]

This page is read only. You can view the source, but not change it. Ask your administrator if you think this is wrong.
====== Sketchpad ======
A home for project ideas that aren't yet fully formed (and which may never be). Those that do survive this gestation phase should receive their own pages, and rejects should probably be retained somewhere.

===== Teensy softcard for Apple II =====
Build an Apple II softcard based around the Teensy microcontroller. I'm not yet sure what we'll do with it yet, but we should try to keep as many special pins (the main I2C/SPI buses, maybe a UART bus) free for later use. Maybe one corner of the initial card could be a protoboard, or we could have some of the free pins broken out for jumpers to a breadboard. Sample projects for inspiration:

  * https://github.com/rallepalaveev/A2DVI/blob/main/v2.0/A2DVI.v2.0.sch.pdf
  * https://www.tindie.com/products/cvt/esp32-softcard-expansion-card-for-the-apple-ii/
  * https://www.v2retrocomputing.com/analog (can be used as a VGA output //or// a Z80 softcard!)
  * schematics and details in the MS SoftCard manual

We don't yet have a specific use case in mind. Some ideas:

  * I2C/SPI/UART interface
  * some kind of audio card/MIDI thing?
  * ProDOS disk emulation (via SD card)
  * Z80 softcard
  * ethernet?
  * USB bus sniffer

It may make sense to start with a very simple breakout card and a basic bus sniffer firmware. 

===== Dual Euclidean trigger/gate module with logic =====
Generate two independent channels (A and B) of Euclidean gate sequences and a third channel (A * B) which performs a selectable logic function on A and B. Attach LEDs to the output of each channel for visual indication. CV control over the parameters would be welcome but is not necessary for the first version. 

Note that this will need to able to follow an external clock!

===== Bluebox MIDI sync =====
The [[:sounds:Bluebox]] is a wonderful piece of gear, but synchronization can be a pain. The core problem is that it has no option to disregard STOP messages((At least as of firmware 1.2.21.)). All those delicious tails have to go to waste! We need a middleman device to filter out STOP messages headed into the Bluebox. All other gear should be placed upstream from said device. 

We have already unsuccessfully trialed the [[:sounds:Zoia]] for this purpose. There is no way to fully isolate the transport messages. 

The attached Python script will work in a pinch, but a more robust solution is desirable. Something Daisy-based? 

<file python midifilter.py>
#!/usr/bin/env python3

'''JACK client for filtering out stop (0xfc) messages'''

import jack

client = jack.Client('MIDI filter')
inport = client.midi_inports.register('input')
outport = client.midi_outports.register('output')

stop = bytes.fromhex('fc')

@client.set_process_callback
def process(frames):
    outport.clear_buffer()
    for offset, data in inport.incoming_midi_events():
        if data == stop:
            continue
        outport.write_midi_event(offset, data)


with client:
    print('#' * 80)
    print('press Return to quit')
    print('#' * 80)
    input()
</file>

The [[https://conductivelabs.com/mrcc/|Conductive Labs MRCC]] is fully capable of MIDI message filtering, and it can do so selectively --- in other words, I could feed the clock and transport from Pam's to all devices at once but block the STOP messages only to the Bluebox. 

===== MIDI "mixer" =====
Selectively mute and mix different components of a MIDI stream. 

**This already exists!** It's called the [[:sounds:MRCC]], and I have one. 
===== 8800 Lisp interpreter =====
Why not? I like the Altair, and I like Lisp. Some starting points:

  * [[https://web.archive.org/web/20240116154313/https://blog.nullspace.io/apple-2-lisp-part-1.html|Apple 2 Lisp, part 1]] (part 2 was never written)
  * [[https://github.com/hausdorff/turtles|source for the above]]
  * [[https://github.com/ghosthamlet/awesome-lisp-machine]]

===== Convert PC PSU to Eurorack =====
One of the first projects in //Microcontroller Projects for Amateur Radio// is a power supply converted from an old PC PSU. It occurred to me while reading it that the voltages supplied by a PC PSU are exactly those needed by Eurorack. It should be entirely possible to use one as a Eurorack PSU with minimal modifications. 

===== MIDI control surface =====
Like the 16n fader bank but with even more controls. Could also be fun to make a software version. 

===== Wireless USB link =====
Assemble a pair of devices --- host (which connects to the peripheral) and peripheral (which connects to the controlling computer). These pass USB packets back and forth over a wireless link. Data rate will obviously be fairly slow, but it could be an interesting experiment. 

===== Eurorack test harness =====
As I start designing and constructing Eurorack modules, it will be helpful to know how much current they draw. Construct a (skiff-friendly?) power supply and an integrated microcontroller-based ammeter and small LCD to provide a current draw readout. See [[https://adafruit.com/product/1164|this breakout board]] for inspiration on how to measure current from a microcontroller.

What if we took some cues from the [[https://www.amazingsynth.com/module-tester-pcb/|AmazingSynth.com module tester]] (which seems to be based on a one-time Mutable Instruments product) and added some extra bells and whistles? Maybe have an onboard VCO, DAC, ADC, and headphone amp with 3.5 mm patch points (patchable points are shown as ellipses in the diagram).

Could this be done with a Daisy (either a standalone Seed or a Patch module)?

<graphviz dot>
digraph G {
  psu [shape=box,label="+/-12 V, +5 V PSU"];
  ucu [shape=box,label="μCU"];
  vco [shape=ellipse];
  isense [shape=box,label="current sense"];
  hdr [shape=box,label="16-pin header"];
  dut [shape=box,label="DUT"];
  hpamp [shape=ellipse,label="headphone amp"];
  
  psu -> {isense,ucu,vco,hpamp};
  isense -> hdr -> dut;
  isense -> ucu;
  adc -> ucu -> dac;
}
</graphviz>

===== Audio mixer =====
I've always wanted to build my own mixer from scratch. In theory, it should be a series of channels connected by one or more summing amplifiers (depending on the number of outputs available for routing). A single channel would look something like the diagram below:

<graphviz dot>
digraph mixerchannel {
  input;
  gain;
  metering;
  eq;
  presends;
  fader;
  postsends;
  pan;
  dummy [label="",shape=point];
  outrouting;
  
  input -> {gain, metering}; 
  gain -> eq -> {presends,fader};
  fader -> {postsends, pan};
  pan -> dummy;
  dummy -> outrouting [label="L"];
  dummy -> outrouting [label="R"];
}
</graphviz>

===== R/C lawnmower =====
This would be worthy of the name "grassolator". Essentially an R/C car with mower blades attached. The goal is for it to be as operable as possible without leaving the house, though the user will probably at least need to step outside to power it on. Use a bidirectional RF data stream for control to keep the base station as flexible as possible. With control commands like ''THROTTLE 50'', ''STEER -10'', ''BLADES 1'', ''HALT'', etc. (and a computer-transmitter interface) we can possibly script its operation. We consider this preferable to a more typical R/C controller. If desired, the control program can map inputs from a game controller to vehicle commands.

It would be awesome to enable fully autonomous operation, though that's probably very infeasible (and definitely unsafe) at this time. A more realistic option is GPS-based operation. It may be possible to couple this with a route learn feature; think auto routing in Satisfactory --- as the player drives the desired route, the vehicle periodically samples its position and interpolates a path between them. Another option is to define coordinate regions that must be avoided and have the vehicle path its way around them.

Safety must be an essential consideration at all times. We need to identify a set of conditions under which the vehicle must absolutely stop and constantly monitor those conditions (how? Short-range radar? Ultrasound?). This is where the bidirectional connection comes in: if a stop condition is encountered, the system can notify the operator and prompt for further steps. At a minimum, the vehicle needs a front-facing wireless camera for the operator to view. If (semi-)autonomous operation is enabled, there must also be a command to immediately switch to manual control. 

It is very tempting to find a way to integrate Lisp into this system.

===== Eurorack counter =====
See [[.:projects:overunder]]

A Eurorack module that outputs a trigger once it has received a certain number of triggers. The proposed I/O is something like the following:

<graphviz dot>
digraph module {
  rankdir=LR;
  // inputs
  trig_inc;
  trig_dec;
  cvknob_max;
  clk_in;
  
  // outputs
  trig_wrap;
  cv_percentage;
  
  //
  module;
  
  trig_inc -> module;
  trig_dec -> module;
  cvknob_max -> module;
  clk_in -> module;
  
  module -> trig_wrap;
  module -> cv_percentage;
}
</graphviz>

The user selects a number of maximum steps via a combination of CV and panel knob. Upon receiving a trigger on the increment or decrement input, the module counts up or down, respectively. Once the max is reached, the counter wraps back to zero, and the module outputs a trigger on its wrap output. The module also outputs a stepped CV proportional to how far along it is in the count (e.g., with a max of 16 and current count at 8, the output is 2.5V). This output can be used to build a progression into the patch. Finally, the module has a clock/sync/enable input which, unless high, prevents the count from changing. 

It could also have separate trigger outputs for underflow and overflow (either in place of or in addition to the wrap output), as well as a reset trigger to return the count to zero. We could also include front panel buttons for manual increment/decrement. 

The state indicator could be made up of either a series of bicolor LEDs or an LCD display similar to Pam's Euclidean trig interface. 

Maybe call it something like "IncDec" or "Over/Under"?

===== Microcontroller-based LLDP sniffer =====
//See [[.:projects:tnt]]//

This would be a great combination with [[.:projects:aft]]. I've discovered that most switches at work source LLDP packets, which can be helpful to identify where a given cable ends up. Having a device that could capture these packets and decode fields of interest would be extremely handy.

I'm inclined to begin with the [[:Teensy]], as it has a built-in Ethernet PHY and fairly fast processor, but its networking libraries are designed for fairly simple client-server applications. I have yet to find one that grants low-level access to raw packet data. I may need to talk directly to the PHY chip, which will require some doc digging. 

===== GreatFET as keyboard =====
//See [[.:projects:gfkb]]//

Use the [[:GreatFET]] to accept keypresses (and maybe mouse input somehow) from one machine and pass them on to another as a USB HID. To capture special keys like ''C-M-del'' and the like, maybe open [[:ncurses]] in raw mode as the input window. 

Will I have to translate the keys into keycodes?

===== Teensy-based GB(A) rom dumper =====
Just one of those "what-ifs" after being asked to help restore some GBA carts. [[https://douevenknow.us/post/68126856498/arduino-based-gba-rom-dumper-part-1|This page]] has some good info to get started, though I'm not interested in copying all of their code. Since the Teensy has a microSD card slot, I can dump the resulting files onto it (with filenames derived from the cart header). How many models can I support? 

===== The ultimate bootable flash drive =====
See [[.projects:ultiboot]]

===== Wiring diagram generator =====
Create a schema for specifying network connections in JSON format that can be parsed and converted into, say, Graphviz diagrams or spreadsheets. Since the primary inspiration was [[:work:]], I'm not yet sure how general I want to make the format. 

===== Automatic work planner =====
This might fit under the AIMEM 864 heading below. In the blue-sky dream version, it would scan Jira for open issues, generate possible schedules, and (once I accepted one) state my intent in issue comments. Aside from the obvious challenges (designing automated planners is a capital-letter Hard Problem), such a system might be hampered by my own general efficiency: tickets often arrive in a trickle, so the system may not have enough options to generate balanced schedules.

A different idea could be to use the Jira data for some kind of machine learning project. Perhaps some kind of anomaly detection ("Part X has been replaced more times than usual lately") or outage prediction ("Area Y is likely to need a replacement soon")?

===== Electrosmith Eurorack module use cases =====
These are Daisy development boards (fun fact: a few of Qu-Bit Electronix's products are based on the Daisy platform) in Eurorack format. The modules would be fun to play with and would grant me some experience programming for the platform. 

There are two models: the Patch.Init(), based around the Patch Submodule, and the Patch, based around the Seed. I/O components vary, but each has at least four pots, a pushbutton, four CV inputs, two gate inputs, a gate output, two audio inputs, two audio outputs, and a CV output. 

  * VCA
  * Bernoulli gate
  * Boolean logic
  * Euclidean sequencer
  * oscillator
  * envelope generator
  * MIDI-CV converter (or CV-MIDI converter)
  * pitch quantizer?
  * Turing Machine clone

===== Build a loft bed =====
Base it around the following designs: 

  * https://www.pbteen.com/products/girls-sleep-and-study-loft/
  * https://plankandbeam.com/products/classic-full-size-high-loft-bed-with-bookcase-and-desk-white?variant=42697095839906&currency=USD&gclid=EAIaIQobChMIwLefo62W_gIVxAp9Ch1kHQPZEAQYDSABEgJ6VfD_BwE
  * https://www.wayfair.com/Harriet-Bee--Full-Loft-With-BuiltIn-Desk-And-Bookshelf-X121324304-L1074-K~W010213293.html?refid=GX637589397739-W010213293_1656989078&device=m&ptid=1883495602939&network=g&targetid=pla-1883495602939&channel=GooglePLA&ireid=226293025&fdid=1817&PiID%5B%5D=1656989078&gclid=EAIaIQobChMIwLefo62W_gIVxAp9Ch1kHQPZEAQYDyABEgKU5_D_BwE

In particular, I want it to be full sized with an L-shaped desk and a number of shelves. The goal is to be able to set up my audio gear, electronics tools, and a computer all at once. A tray level with the mattress (for storing a laptop, my glasses and meds, and maybe a book) would be ideal as well. Bonus points if the tray can optionally fold down. 

Note that the bed will need to be able to separate easily into pieces so I can fit it into my room for assembly. 

===== Build a bookshelf =====
I would like it to have 6 shelves of at least 12" each. I have no goals of design or finish otherwise.   

===== Matrix bot use cases =====
//See [[.:projects:matrix]]//

I've been playing with Matrix here on sinensis. I figure it could be fun to build a bot to perform various tasks. This is a better vehicle for some other ideas I've had than a general key-value store would be. [[https://docs.opsdroid.dev/en/stable/|Opsdroid]] is simple enough to use.

  * send timed reminders
  * report telemetry data
  * keep small notes
  * interact with Jira
  * track packages with Easypost

===== MIDI-text converter =====
Take in MIDI notes and convert them into alphanumeric key presses (in Python, of course). Maybe Mido to pynput? Not sure how to handle the mapping of notes to keys. And what about CCs? Ooh, we could use the mod wheel to select different keyboard modes (e.g., single key, whole word, special key macros).
===== Hack the label maker =====
Now that I know a tiny bit about USB programming, I might try my hand at making a Linux driver for it. See [[https://github.com/TomasHubelbauer/brother-p-touch-d600|this page]] to get started.

===== Airflow use cases =====
Allow me a moment to describe how I was led to Airflow. I wanted to write a script to monitor the [[https://shop.flipperzero.one|Flipper Zero shop page]] and notify me when it opened again. Naturally, my brain began taking the next step and envisioning a tool for executing graph-based workflows. This sounded like what I remembered of Airflow from a previous cursory inspection, so I looked into that before <del>wasting a whole bunch of time</del> reinventing the wheel. I then proceeded to spend the evening toying with a test instance, including writing an Airflow operator to send messages via Gotify. And that's the story of how I scrapped my graph-cron idea((It wasn't //exactly// identical in design to Airflow, despite their significant similarities. Airflow is strictly DAG-based, whereas mine would have allowed any digraph. All edges could be assigned conditions or probabilities to help the executor decide which path to take. In the case of multiple eligible transitions, the system would either select one at random (weighted by edge probability) or execute each in parallel. It also would have permitted direct nesting of digraphs, which I'm not yet sure Airflow can do easily.)).

Once you figure out the basic semantics, directing Airflow is fairly simple, owing to its Python implementation. In my early experimentation, I was able to easily compose my Flipper shop monitor. Working on that set me to thinking about other ways I could use it. Airflow was designed with data pipelines in mind (i.e., ingest a dataset, train several models, and select the best), so that might guide possible uses

  * rewrite existing monitoring/notification scripts (the work Jira one comes to mind)
  * read in a CSV of EasyPost packages, spin off a separate task to get the status of those not yet delivered, notify of updates, aggregate the results, and overwrite the CSV with updated values
  * give it a list of sites and conditions (e.g. CSS selector) to check; notify about any sites that meet the specified condition

===== Jira CLI script =====
To allow me to operate my Jira account programmatically, including closing tickets, adding comments, and retrieving data. 

A recurring sticking point is that an all-in-one Jira CLI is in most circumstances less convenient than the mobile app I already use. 

===== Portable RPi all-in-one =====

===== CAN/OBD sniffer =====
See [[.:projects:CANOBDicon]]

Read values from a CAN bus. [[https://www.seeedstudio.com/OBD-II-CAN-BUS-Development-Kit-p-2993.html|This kit]] seems like a good starting platform. The [[:Teensy]] platform also apparently features 3 whole CAN buses all to itself---however, it requires a transceiver chip. Also check [[gh>iDoka/awesome-canbus]] for further information on CAN.

Could call it the CANOBDicon.

===== Electronics work mat =====
Covered in references, actual-size device footprints, etc. 

===== Modular radio transceiver =====
"Modular" is hands-down my favorite word. I've always wanted to build my own radio transceiver, so why not make it modular while I'm at it? I'd like the signal path to be all-analog, but something like the [[https://www.pjrc.com/teensy/|Teensy]] could make for a nice digital brain. That could also be a great chance to experiment with [[https://www.analog.com/en/analog-dialogue/articles/all-about-direct-digital-synthesis.html|DDS]].

One key task will be to ensure that the inputs and outputs for each module type are well-defined (signal levels, signal types, connectors, etc.) so they can be easily interchanged. 

A basic block diagram appears below. The control module also contains the I/O and AF gain stages, as these form the core components of the radio. I am undecided on whether to integrate the mixer into another module (consider: when would I want to swap it out?). Were I to do so, it would probably also go into the control module. Moving it to the modem or PA modules would mean that every such module would include its own mixer, which is just wasteful. 

<graphviz>
digraph G {
  rankdir=TB;
  
  {rank=min; modem; mixer; pa; }
  {rank=max; control;}  
  
  control -> modem [label="AF/input signal"];
  modem -> control [label="AF"];
  control -> pa [label="T/R switching,\nLO tuning"];
  pa -> control [label="metering"];
  
  modem -> mixer [label="IF"];
  mixer -> modem;
  mixer -> pa [label="RF"];
  pa -> mixer;
}
</graphviz>

Also take a look at the [[https://www.hfsignals.com/index.php/ubitx-v6/|uBITX]] and [[https://www.vu2ese.com/index.php/2022/07/20/the-sbitx-the-sdr-for-the-homebrewer/|sBITX]]. These are homebrew multi-band superheterodyne transceivers built around an Arduino/Teensy and a Raspberry Pi, respectively. Each project includes detailed schematics, block-by-block circuit descriptions, and firmware/UI explanations. Both also use the Si5351 clock generator to produce the local oscillator(s). 
===== Email pingback =====
Sometimes it's handy to know when someone opens an email. 

The current idea is to use a simple REST API to manage //trackers//. Each has an associated ID (included in the URL) and some associated metadata (recipient/purpose?). Each URL returns a 1x1 transparent image that can be embedded into the email body. When the recipient loads the message and downloads the image, the app can log the access for later viewing or notify me immediately. 

===== Applications of AI Memo 864 =====
The paper, properly titled "[[https://people.csail.mit.edu/brooks/papers/AIM-864.pdf|A Robust Layered Control System for a Mobile Robot]]", describes a control system architecture based on //layers of competency//. Each layer consists of a series of //modules//, interconnected finite state machines that together achieve a high-level goal. Each higher competency is stacked upon the those below it and can override their inputs and outputs. In this design, adding a higher layer does not require modifications to the lower ones. 

I am interested in exploring applications of this idea to other autonomous systems (not necessarily robotic in nature).