rnd:sketchpad

Differences

This shows you the differences between two versions of the page.

Link to this comparison view

Both sides previous revision Previous revision
Next revision		 Previous revision
rnd:sketchpad [2023-07-15 22:04] – asdfrnd:sketchpad [2024-10-01 05:10] (current) – asdf
Line 1: Line 1:
 ====== Sketchpad ====== ====== 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. +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 ===== ===== Eurorack counter =====
Line 42: Line 182:
  
 ===== Microcontroller-based LLDP sniffer ===== ===== 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. 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.
  
Line 47: Line 189:
  
 ===== GreatFET as keyboard ===== ===== 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.  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. 
  
Line 95: Line 239:
  
 ===== Matrix bot use cases ===== ===== 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. 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.
  
Line 125: Line 271:
  
 ===== CAN/OBD sniffer ===== ===== 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. 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.
  
Line 157: Line 305:
 } }
 </graphviz> </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 ===== ===== Email pingback =====
 Sometimes it's handy to know when someone opens an email.  Sometimes it's handy to know when someone opens an email. 
  • rnd/sketchpad.1689458689.txt.gz
  • Last modified: 2023-07-15 22:04
  • by asdf