Omega Attention v0.1

Omega Attention v0.1

Omega Attention is a small language model fine-tuned specifically for attention management inside an artificial cognitive architecture.

https://huggingface.co/rekstar/omega-attention-0.5b

Rather than using a general-purpose LLM to repeatedly decide what an agent should focus on, Omega Attention is designed as a lightweight specialist cognitive node.

Given a cognitive workspace containing competing goals, memories, observations, system events, and tool activity, the model selects an attention operation and target.

It is part of the broader Omega artificial cognitive architecture experiment. https://github.com/doctarock/Artificial-Cognitive-Architecture-ACA-

What does it do?

Omega Attention chooses between five attention operations:

  • ATTEND — bring something into active attention
  • MAINTAIN — continue attending to the current focus
  • SWITCH — move attention to a more important candidate
  • SUPPRESS — actively suppress a distracting or conflicting candidate
  • IGNORE — take no attentional action

The output contract is deliberately narrow.

{"operation":"SWITCH","target":"observation_4","confidence":0.91,"reason_code":"HIGHER_PRIORITY_INTERRUPT"}

The model is not intended to chat, explain its reasoning, or generate general-purpose text.

Its job is simply:

>

Model

Property Value
Base model unsloth/Qwen2.5-0.5B-Instruct-bnb-4bit
Base parameters ~502M
Fine-tuning LoRA
LoRA rank 16
LoRA alpha 16
Trainable parameters ~8.8M
Trainable percentage ~1.75%
Training epochs 3
Training examples 5,000
Evaluation examples 500
Training platform AMD Radeon 8060S / ROCm
Training framework Unsloth
Output Compact JSON

LoRA was applied to:

q_proj
k_proj
v_proj
o_proj
gate_proj
up_proj
down_proj

Training

The model was trained on 5,000 synthetic cognitive-workspace scenarios.

Each scenario contains competing candidates such as:

  • goals
  • memories
  • observations
  • system events
  • tool calls

Candidates have properties including activation, salience, confidence, novelty, and age.

Each workspace is paired with the desired attention operation and target.

Training used standard causal language-model fine-tuning with prompt tokens masked from the loss so that training focused on producing the required attention decision.

The final run consisted of 1,875 steps, approximately three epochs.

Training took approximately 54 minutes (3,229 seconds) on an AMD Radeon 8060S using ROCm.

Results

Evaluation was performed against 500 held-out synthetic scenarios.

Metric 200 steps 1,875 steps / 3 epochs
Valid JSON 100% 100%
Operation accuracy 74.2% 96.0%
Target accuracy 45.2% 92.2%

The architecture, dataset, LoRA configuration, and model size were unchanged between these runs.

The primary difference was training duration.

Target accuracy increased from 45.2% to 92.2% without increasing model size or inference cost.

Important evaluation caveat

These results should not be interpreted as demonstrating 96% accuracy on arbitrary real-world attention-management tasks.

The evaluation examples are held out from training, but they are generated by the same synthetic scenario-generation system used to produce the training dataset.

The results therefore demonstrate that a 0.5B model can successfully learn the attention policy represented by this dataset.

Generalisation to different distributions, adversarial scenarios, and real Omega cognitive traces remains to be evaluated.

This is one of the primary goals for future versions.

Why a 0.5B model?

Omega is exploring an alternative to using one large language model for every cognitive operation.

Instead, cognitive functions can potentially be decomposed into specialised nodes:

             Cognitive Workspace
                     |
                     v
              Attention Node
                     |
              "What matters now?"
                     |
          +----------+----------+
          |          |          |
          v          v          v
        Memory    Reasoning    Goals

Attention management is frequent but relatively narrow.

Using a large reasoning model for every attention decision would introduce unnecessary latency and compute cost.

Omega Attention explores whether a very small specialised language model can perform this cognitive function instead.

The v0.1 results suggest that, at least for the synthetic attention policy tested here, increasing model size was unnecessary.

Intended use

Omega Attention is intended for experimentation with:

  • artificial cognitive architectures
  • autonomous agents
  • cognitive workspaces
  • attention allocation
  • persistent agent loops
  • multi-model agent systems
  • specialised neural cognitive modules

It is primarily intended to operate as a component inside another system, rather than as a standalone conversational model.

Not intended for

Omega Attention is not intended to be:

  • a general-purpose assistant
  • a reasoning model
  • a chatbot
  • a factual knowledge model
  • a safety classifier
  • a replacement for human decision-making

It has been trained for a deliberately narrow experimental task.

Status

Experimental — v0.1

This is the first public iteration of Omega Attention.

The major question addressed by v0.1 was:

>

The initial result is encouraging.

The next question is more important:

>

Future work will focus on harder evaluation rather than immediately increasing model size.

About Omega

Omega is an experimental artificial cognitive architecture exploring the idea that an artificial mind does not need to be synonymous with a single large language model.

Instead, language models can act as specialised neural components within a larger cognitive system incorporating mechanisms such as attention, working memory, long-term memory, goal management, reasoning, planning, and action.

Omega Attention is the first specialised cognitive model produced as part of that experiment.

u/Electronic-Space-736 — 3 days ago
▲ 5 r/u_Electronic-Space-736+3 crossposts

I built an artificial mind treating LLM as a cognitive processor, not the mind itself

https://github.com/doctarock/Artificial-Cognitive-Architecture-ACA-
Reddit is skeptical, totally understandable, so I am running some tests to prove it.

So far I'm testing:

  • Persistent episodic vs semantic memory and whether experiences become abstractions
  • Autonomous cognitive cycles and self-monitoring without user prompts
  • Executive control: compare → broadcast → reflect → remember → speak
  • Cross-domain concept formation from deliberately unrelated experiences
  • Whether provisional hypotheses are held separately from consolidated semantic knowledge
  • Whether newly formed concepts can later be retrieved and transferred to completely novel situations
  • Whether the system can revise a learned abstraction when presented with contradictory evidence
  • Whether apparent “internal feelings” correspond to measurable architectural states rather than just anthropomorphic language

early result: ACA independently identified a common abstraction across biological, engineering and social examples, while explicitly saying semantic synthesis was being withheld pending further evidence.

Now testing whether that abstraction actually gets consolidated into semantic memory, survives removal of the original examples, and can be applied to a genuinely new situation.

u/Electronic-Space-736 — 5 days ago

I got myself an Ryzen 395, here is the suite I built for it.

Hilbert AI Suite.

Rather than piecing together dozens of repositories, scripts, Discord posts, and setup guides, it's a single collection of tools for building a local AI workstation. It's focused on AMD ROCm systems (particularly Infplane Hilbert), but much of it is useful on other Linux installations as well.

It brings together a large collection of installers, utilities, and workflows for:

  • Local LLMs
  • Image/video/audio generation (ComfyUI and related tools)
  • Coding assistants
  • Speech and voice models
  • Embeddings and RAG
  • Development utilities
  • Model management
  • And a growing collection of other AI tools

You'll want a fresh 2TB drive if you want all the models downloaded at once, but the repo is only a couple of hundred MB (due to needing to bundle a small model)

I am regularly updating it, if it seems useful help yourself.

https://github.com/Pixel-Forge-AU/Hilbert-Unofficial-Suite/tree/main/ai-suite

reddit.com
u/Electronic-Space-736 — 19 days ago
▲ 3 r/LocalAIServers+1 crossposts

I got myself an Ryzen 395, here is the suite I built for it.

Hilbert AI Suite.

Rather than piecing together dozens of repositories, scripts, Discord posts, and setup guides, it's a single collection of tools for building a local AI workstation. It's focused on AMD ROCm systems (particularly Infplane Hilbert), but much of it is useful on other Linux installations as well.

It brings together a large collection of installers, utilities, and workflows for:

  • Local LLMs
  • Image/video/audio generation (ComfyUI and related tools)
  • Coding assistants
  • Speech and voice models
  • Embeddings and RAG
  • Development utilities
  • Model management
  • And a growing collection of other AI tools

You'll want a fresh 2TB drive if you want all the models downloaded at once, but the repo is only a couple of hundred MB (due to needing to bundle a small model)

I am regularly updating it, if it seems useful help yourself.

https://github.com/Pixel-Forge-AU/Hilbert-Unofficial-Suite/tree/main/ai-suite

reddit.com
u/Electronic-Space-736 — 19 days ago

Fails to communicate with printer whenever I paint models

Really poor performance, freezing every 3 seconds for 30 seconds cannot connect to printers.

Does anyone have alternative methods to handle multicolor print that doesn't require this terrible version of orca?

reddit.com
u/Electronic-Space-736 — 27 days ago

Constant clogs

*More accurately constant catching leading to jams

I have been pulling apart three toolheads a day.

I get half way through a print and I am air printing.

I stop the print and try to extrude, it is stuck, cant retract either.

It is multiple toolheads at a time, not just one failing.

I pull them completely apart, clean them perfectly, put them completely back together.

Next print it does it again, at the same Z.

Surely a firmware issue?

You can see the supports getting weaker as it reaches the failure point.

u/Electronic-Space-736 — 1 month ago
▲ 4 r/Infplane+1 crossposts

Infplane Hilbert first impressions

I've now completed the Pop!_OS installation and have Hilbert up and running successfully as a dedicated local AI workstation.

Pop!_OS installed and stable.

llama.cpp running successfully.

comfyui.cpp running successfully.

Large GGUF models running using unified memory.

Q5_K_M quantization tested.

Real-world responsiveness feels comparable to frontier cloud models.

~51.7 tokens/sec on an ~833 token generation.

~48.7 tokens/sec after a 12,800 token context.

The minimal drop in throughput with a much larger context is particularly encouraging and suggests the unified memory architecture is performing very well for large-model inference.

* The only notable issue so far is a suspend/resume bug where waking from sleep appears to crash the graphics driver. This seems to be a Pop!_OS/Linux graphics issue rather than a hardware or AI workload problem, and it doesn't affect normal operation.

I have unsubbed 3 services already, I wont need them. Based on my experience so far, I'd consider the project a success. I am chuffed.

reddit.com
u/Electronic-Space-736 — 1 month ago

Reverse-engineering the 3DMakerpro Fox scanner over USB, and the one thing I can't crack

3DMakerpro Fox — USB investigation findings

The 3DMakerpro Fox is an inexpensive single-shot structured-light 3D scanner that ships with only one Windows app, JMStudio. I wanted to drive it from my own offline pipeline — grab frames, reconstruct, measure — without JMStudio in the loop, so I spent a while working out how it talks over USB (interoperability RE on hardware I own).

The good news: the two cameras are plain UVC devices you can open straight from OpenCV/V4L2, and JMStudio caches the full factory calibration — both cameras, the projector modelled as a third camera, the baselines, and the projected pattern itself — in a plain-text file on disk.

The bad news, and the reason I'm posting: I can capture the cameras fine, but I cannot figure out what turns the projector on. I chased a vendor UVC Extension Unit for ages before a USBPcap capture proved it's a red herring — JMStudio runs the entire scan with nothing but standard UVC (it commits a specific 640×480 / 10 fps format, sets a short exposure and gain, then streams). When I replicate exactly that, the projector stays dark. Everything I ruled out is below.

If you've enabled the projector on a Fox or a similar Sonix-based structured-light scanner, I'd love to hear how.

> TL;DR (read this first — the doc below is a chronological investigation and > some early hypotheses are later overturned): the vendor UVC Extension Unit > turned out to be a red herring — USBPcap capture shows JMStudio drives the > whole scan with 100% standard UVC (it commits format 1 / frame 2 = 640×480 > YUY2 @ 10 fps, then sets exposure and gain) and never writes the extension unit > or the HID device. Depth is computed host-side from a projected pattern. The one > thing still unsolved: what enables the projector. It is not the extension > unit, HID, resolution, frame rate, dual-streaming, or exposure — all ruled out. > If you've cracked the projector-enable on a similar Sonix structured-light > scanner, that's the feedback I'm after.

Answer: yes, the Fox exposes standard USB camera streams

The Fox enumerates as three Sonix Technology (VID 0x0C45) devices:

Device Interface What it is
USB\VID_0C45&PID_636A UVC camera <SERIAL>_A Standard USB Video Class camera
USB\VID_0C45&PID_636B UVC camera <SERIAL>_B Standard USB Video Class camera
USB\VID_0C45&PID_672E HID (keyboard + consumer + vendor collections) Carries no device serial and looks like a keyboard-class device; Sonix VID is common in keyboards. Later confirmed unrelated to scanning — JMStudio never touches it (see USBPcap section).

Verified with OpenCV: both cameras open with the stock OS driver (MSMF on Windows; they will appear as V4L2 /dev/video* on Linux) and stream YUY2 at up to 1280×720. Default mode is 640×480. No vendor driver is needed — JMStudio's bundled "drivers" are generic camera driver installers plus a WCH CH343 USB-serial driver (used for the turntable accessory).

What is NOT on the wire

There is no depth stream. The Fox is a single-shot structured-light scanner: depth is computed on the host from what the two cameras see of a projected pattern. Projector/exposure control is a vendor protocol carried over a UVC Extension Unit on each camera's VideoControl interface (confirmed below). JMStudio's LightP setting in scaner_settings_*.ini is the projector-power knob that travels over this channel.

Confirmed: the projector control path (UVC Extension Unit)

Reading the cameras' USB descriptors (libusb, no device claim needed) shows a real vendor Extension Unit on VideoControl interface 0 of both cameras:

Extension Unit  unitID = 3   bNumControls = 8
GUID = {28F03370-6311-4A2E-BA2C-6890EB334016}

That exact GUID is embedded in SonixCamera.dll (Sonix is the camera-ASIC vendor; VID 0x0C45), which is JMStudio's low-level control layer. Its exported API is the whole vendor surface:

SonixCam_XuRead / SonixCam_XuWrite         raw extension-unit access
SonixCam_ControlSet / ControlGet / ...Range  named controls
SonixCam_AsicRegisterRead / Write          Sonix ASIC registers
SonixCam_SensorRegisterRead / Write        image-sensor registers
SonixCam_SerialFlashRead / Write           on-board flash
SonixCam_GetParamTableAddr / SetParamTable... parameter table in flash

The DLL string I2C64XUData shows the XU tunnels a 64-byte I2C payload — i.e. an XU write addresses the projector/LED driver over I2C. Three candidate XU GUIDs sit in a table in the DLL (different firmware variants); the one above is the one this unit actually enumerates.

So driving the projector natively = send an XU SET (control selector in 1..8, 64-byte I2C payload) to unit 3, either through SonixCam_XuWrite or directly via the Windows UVC KsProperty interface (property set = the XU GUID). The remaining unknown is which of the 8 selectors is projector power and the exact I2C payload — recoverable by capturing JMStudio's XU traffic (USBPcap) or disassembling SonixCam_ControlSet around the LightP path.

Read-only control map (foxstudio xu)

Querying the XU through the Windows IKsControl/KsProperty interface (no writes, stream never started; reproducible with foxstudio xu) gives the live control map. The XU is topology node 1 (KSNODETYPE_DEV_SPECIFIC). Typical values on this unit, camera A:

selector 0  GET      len 22  = XU GUID + control-count/version (identity)
selector 1  GET/SET  len 4   volatile  (low byte increments run-to-run)
selector 2  GET/SET  len 8   semi-volatile
selector 3  GET/SET  len 11  first byte increments run-to-run (live)
selector 4  GET/SET  len 11  stable; reads 00 00 00 .. when idle
selector 5  GET/SET  len 11  stable
selectors 6-9            ERROR_NOT_FOUND (0x80070490)

Both cameras expose the same XU with independent state (each has its own controller). Several controls carry a trailing 40 42 0F 00 = 1,000,000 (a µs/clock-looking constant). Selectors 1 and 3 are free-running counters (pure noise); 0 is identity; 2 tracks exposure/gain.

Observed under JMStudio (foxstudio xu --watch, read-only)

Watching both cameras' XU while JMStudio ran scans (no writes from us; property reads work fine while JMStudio streams) isolates the projector/pattern control:

Selectors 4 and 5, on BOTH cameras, are the only config controls that ever move, and they moved exactly once — a brief (~0.4 s) synchronized pulse at the start of a capture, then reverted:

camera A  sel4: 00 00 00 |ff ff| 42 0f 00 00 00 00  ->  00 00 00 |02 40| 42 0f 00 00 00 00
camera A  sel5: 2d 04 01 |ff ff| 42 0f 00 00 00 00  ->  2d 04 01 |02 40| 42 0f 00 00 00 00
camera B  sel4: 00 00 00 |88 40| 42 0f 00 00 00 00  ->  00 00 00 |00 40| 42 0f 00 00 00 00
camera B  sel5: 2d 04 01 |88 40| 42 0f 00 00 00 00  ->  2d 04 01 |00 40| 42 0f 00 00 00 00

The change is confined to bytes [3:5] (each camera has its own idle value there). Because it is a brief pulse rather than a level held for the whole scan, selector 4/5 read as a per-capture arm/trigger, not a sustained "projector power" knob; the continuous illumination is likely driven by the streaming/pattern mode once armed. Selectors 4 and 5 on camera A are therefore the concrete control surface to replay.

Bounded write test (done, safe, negative)

With go-ahead, a careful bounded write test was run: while streaming camera A, read+save selectors 4/5, replay JMStudio's captured active values verbatim (SET_CUR to unit 3), capture a 30-frame burst, then restore. It was fully clean and reversible (values restored; device settled back to idle ff ff).

Result: the projector did not fire. All frames stayed at the projector-off baseline (Laplacian variance ~152, unchanged). And the read-back exposed byte 3 of selector 4 stepping ff -> 01 -> 02 across sessions — i.e. it behaves like a counter/status field, not a command input. Conclusion: selectors 4/5 are most likely status/config readback that changes as a side-effect of scanning, not the projector control. --watch can only see values change; it cannot tell a device write from a device-side status update, and this test indicates the latter.

Also ruled out (read-only): streaming at the scan resolution (1280×720) alone does not enable the projector — native captures at that mode show no pattern.

Net: the projector control is not a simple XU value replay.

USBPcap capture of JMStudio (done) — the extension unit is a red herring

A full USBPcap capture of JMStudio running a scan (decoded with scratchpad/parse_usbpcap.py) settles the direction question the read-only side could not. During an entire scan, JMStudio's traffic to the Fox was 100 % standard UVC, and it never touched the extension unit (unit 3) or the HID device (0c45:672e) at all:

VS_PROBE/COMMIT (iface 1, sel 1/2): format index 1, frame index 2,
                                    dwFrameInterval 1,000,000 (10 fps)
Camera Terminal exposure  (unit 1, sel 4): ~2-4 ms (short)
Processing Unit gain      (unit 2, sel 4)
...then isochronous video. No SET to unit 3, no HID reports.

So the whole extension-unit line of investigation — and the earlier bounded write test — was aimed at the wrong entity; that is why the write did nothing. The 0c45:672e HID device is confirmed unrelated to scanning (silent throughout).

Second capture (from cold) + replication attempts — projector NOT cracked

A second USBPcap capture taken from a cold power-cycle (Fox just replugged, JMStudio never opened, then JMStudio launched during the window) showed the same thing at device connect: 100 % standard UVC, no extension-unit write, no HID output report (the HID device only sends input reports, it is never commanded). JMStudio's committed video format is format 1 / frame 2 = 640×480 YUY2 @ 10 fps (dwMaxVideoFrameSize 0x00096000 = 614400 = 640×480×2), then SET_INTERFACE to start streaming, then CT AE-mode manual + exposure (~2–4 ms) + PU gain. Nothing else.

Replication attempts via our own standard-UVC streaming, checked with a rigorous discriminator (very short exposure isolates a bright projected pattern as dots-on-black; ambient goes black):

variable tried result
640×480, 1280×720, other resolutions projector off
10 fps (JMStudio's rate) vs 30 fps off in both
single camera vs both cameras streaming (controlled, same exposure) identical — both pure black
exposure ladder −7…−13 collapses to black; no dots-on-black

Earlier apparent "pattern" sightings were confounds — a shiny metal mesh glinting at short exposure, textured surfaces, or exposure settings not applying in some paths — not confirmed projector activity. The one time the projector was genuinely latched on (bold stripes on a matte item) followed a JMStudio scan and did not reproduce cold.

Honest status: the projector-enable was not reproduced. It is definitively not the extension unit, the HID device, the resolution, the frame rate, the dual-stream condition, or exposure. The only remaining untested variable is the exact UVC media type / probe-commit bytes and control ordering committed via a DirectShow graph (OpenCV negotiates its own and may not match format 1/frame 2 precisely) — a significant instrumentation effort with uncertain payoff. Pending that, JMStudio remains the structured-light capture path; FoxStudio's native passive-stereo + factory calibration + full downstream pipeline stands on its own.

Confirmed: the Fox is single-shot structured light, and the calibration is on disk

JMStudio caches the full factory calibration per unit at <install>/download/calib_<SERIAL>.txt in plain text. For this unit it contains:

  • image size 1280×720;
  • both cameras as pinhole+distortion models (fx ≈ 2799 px), and the projector modeled as a third camera;
  • extrinsics: camera↔camera baseline 32.36 mm, camera↔projector 57.6 mm;
  • a 128-entry projector column→ray lookup table;
  • the fixed projected pattern: 246 rows × 6 symbols over a 4-symbol alphabet — a De Bruijn-style stripe code that is the same every frame (single-shot), so it can be decoded without capturing a sequence.

FoxStudio parses this file directly (foxstudio/fox_calibration.py) and uses it for native scanning, so no checkerboard calibration is required — the factory numbers are better than a user calibration. The checkerboard flow remains as a fallback for units whose file is missing.

Consequence for the roadmap: native scanning does not need passive-stereo texture. Once the projector is on, the two cameras see a strong known pattern, so either (a) plain SGBM stereo works well, or (b) the pattern can be decoded against the stored code + projector calibration for full structured-light depth. The only missing piece is the one-line XU command that turns the projector on — a device write, held pending explicit go-ahead.

What direct capture can do today

foxstudio capture grabs synchronized A/B stereo frame pairs straight from the UVC streams (close JMStudio first — it holds the cameras exclusively).

Path to full independent depth reconstruction, in increasing effort:

  1. Passive stereo — calibrate the A/B pair once (OpenCV stereoCalibrate with a printed checkerboard), then compute disparity with StereoSGBM and back-project to a point cloud. Works without touching the HID channel, but quality on textureless parts is poor.
  2. Pattern-assisted stereo — with the pattern projector on (leave a scan preview running, or replay the control commands once learned), textured stereo works much better with the same calibration.
  3. Full protocol — capture the USB control traffic JMStudio sends (Wireshark + USBPcap filtered to the two camera devices) to learn the UVC extension-unit requests for projector power/pattern sequencing, then drive the whole scan loop independently. This is the reverse engineering long game.

The practical near-term workflow remains: scan in JMStudio, export STL/OBJ/PLY/ASC, and run everything downstream offline with FoxStudio.

Other notes from the JMStudio install

  • C:\Program Files (x86)\JMStudio\<ver>\Config\scaner_settings_*.ini holds per-model tuning (camera brightness, projector power LightP, Poisson reconstruction defaults). Useful reference values for our own Poisson step: resolution=1.7, trim_value=2.0, islandAreaRatio=0.00005.
  • Bundled SDKs for MindVision/HK industrial cameras are for other scanner models in the JMStudio family, not the Fox.
  • Turntable control is a CH343 USB-serial device (COM port) when connected.
reddit.com
u/Electronic-Space-736 — 1 month ago

Reverse-engineering the 3DMakerpro Fox scanner over USB, and the one thing I can't crack

3DMakerpro Fox — USB investigation findings

The 3DMakerpro Fox is an inexpensive single-shot structured-light 3D scanner that ships with only one Windows app, JMStudio. I wanted to drive it from my own offline pipeline — grab frames, reconstruct, measure — without JMStudio in the loop, so I spent a while working out how it talks over USB (interoperability RE on hardware I own).

The good news: the two cameras are plain UVC devices you can open straight from OpenCV/V4L2, and JMStudio caches the full factory calibration — both cameras, the projector modelled as a third camera, the baselines, and the projected pattern itself — in a plain-text file on disk.

The bad news, and the reason I'm posting: I can capture the cameras fine, but I cannot figure out what turns the projector on. I chased a vendor UVC Extension Unit for ages before a USBPcap capture proved it's a red herring — JMStudio runs the entire scan with nothing but standard UVC (it commits a specific 640×480 / 10 fps format, sets a short exposure and gain, then streams). When I replicate exactly that, the projector stays dark. Everything I ruled out is below.

If you've enabled the projector on a Fox or a similar Sonix-based structured-light scanner, I'd love to hear how.

> TL;DR (read this first — the doc below is a chronological investigation and > some early hypotheses are later overturned): the vendor UVC Extension Unit > turned out to be a red herring — USBPcap capture shows JMStudio drives the > whole scan with 100% standard UVC (it commits format 1 / frame 2 = 640×480 > YUY2 @ 10 fps, then sets exposure and gain) and never writes the extension unit > or the HID device. Depth is computed host-side from a projected pattern. The one > thing still unsolved: what enables the projector. It is not the extension > unit, HID, resolution, frame rate, dual-streaming, or exposure — all ruled out. > If you've cracked the projector-enable on a similar Sonix structured-light > scanner, that's the feedback I'm after.

Answer: yes, the Fox exposes standard USB camera streams

The Fox enumerates as three Sonix Technology (VID 0x0C45) devices:

Device Interface What it is
USB\VID_0C45&PID_636A UVC camera <SERIAL>_A Standard USB Video Class camera
USB\VID_0C45&PID_636B UVC camera <SERIAL>_B Standard USB Video Class camera
USB\VID_0C45&PID_672E HID (keyboard + consumer + vendor collections) Carries no device serial and looks like a keyboard-class device; Sonix VID is common in keyboards. Later confirmed unrelated to scanning — JMStudio never touches it (see USBPcap section).

Verified with OpenCV: both cameras open with the stock OS driver (MSMF on Windows; they will appear as V4L2 /dev/video* on Linux) and stream YUY2 at up to 1280×720. Default mode is 640×480. No vendor driver is needed — JMStudio's bundled "drivers" are generic camera driver installers plus a WCH CH343 USB-serial driver (used for the turntable accessory).

What is NOT on the wire

There is no depth stream. The Fox is a single-shot structured-light scanner: depth is computed on the host from what the two cameras see of a projected pattern. Projector/exposure control is a vendor protocol carried over a UVC Extension Unit on each camera's VideoControl interface (confirmed below). JMStudio's LightP setting in scaner_settings_*.ini is the projector-power knob that travels over this channel.

Confirmed: the projector control path (UVC Extension Unit)

Reading the cameras' USB descriptors (libusb, no device claim needed) shows a real vendor Extension Unit on VideoControl interface 0 of both cameras:

Extension Unit  unitID = 3   bNumControls = 8
GUID = {28F03370-6311-4A2E-BA2C-6890EB334016}

That exact GUID is embedded in SonixCamera.dll (Sonix is the camera-ASIC vendor; VID 0x0C45), which is JMStudio's low-level control layer. Its exported API is the whole vendor surface:

SonixCam_XuRead / SonixCam_XuWrite         raw extension-unit access
SonixCam_ControlSet / ControlGet / ...Range  named controls
SonixCam_AsicRegisterRead / Write          Sonix ASIC registers
SonixCam_SensorRegisterRead / Write        image-sensor registers
SonixCam_SerialFlashRead / Write           on-board flash
SonixCam_GetParamTableAddr / SetParamTable... parameter table in flash

The DLL string I2C64XUData shows the XU tunnels a 64-byte I2C payload — i.e. an XU write addresses the projector/LED driver over I2C. Three candidate XU GUIDs sit in a table in the DLL (different firmware variants); the one above is the one this unit actually enumerates.

So driving the projector natively = send an XU SET (control selector in 1..8, 64-byte I2C payload) to unit 3, either through SonixCam_XuWrite or directly via the Windows UVC KsProperty interface (property set = the XU GUID). The remaining unknown is which of the 8 selectors is projector power and the exact I2C payload — recoverable by capturing JMStudio's XU traffic (USBPcap) or disassembling SonixCam_ControlSet around the LightP path.

Read-only control map (foxstudio xu)

Querying the XU through the Windows IKsControl/KsProperty interface (no writes, stream never started; reproducible with foxstudio xu) gives the live control map. The XU is topology node 1 (KSNODETYPE_DEV_SPECIFIC). Typical values on this unit, camera A:

selector 0  GET      len 22  = XU GUID + control-count/version (identity)
selector 1  GET/SET  len 4   volatile  (low byte increments run-to-run)
selector 2  GET/SET  len 8   semi-volatile
selector 3  GET/SET  len 11  first byte increments run-to-run (live)
selector 4  GET/SET  len 11  stable; reads 00 00 00 .. when idle
selector 5  GET/SET  len 11  stable
selectors 6-9            ERROR_NOT_FOUND (0x80070490)

Both cameras expose the same XU with independent state (each has its own controller). Several controls carry a trailing 40 42 0F 00 = 1,000,000 (a µs/clock-looking constant). Selectors 1 and 3 are free-running counters (pure noise); 0 is identity; 2 tracks exposure/gain.

Observed under JMStudio (foxstudio xu --watch, read-only)

Watching both cameras' XU while JMStudio ran scans (no writes from us; property reads work fine while JMStudio streams) isolates the projector/pattern control:

Selectors 4 and 5, on BOTH cameras, are the only config controls that ever move, and they moved exactly once — a brief (~0.4 s) synchronized pulse at the start of a capture, then reverted:

camera A  sel4: 00 00 00 |ff ff| 42 0f 00 00 00 00  ->  00 00 00 |02 40| 42 0f 00 00 00 00
camera A  sel5: 2d 04 01 |ff ff| 42 0f 00 00 00 00  ->  2d 04 01 |02 40| 42 0f 00 00 00 00
camera B  sel4: 00 00 00 |88 40| 42 0f 00 00 00 00  ->  00 00 00 |00 40| 42 0f 00 00 00 00
camera B  sel5: 2d 04 01 |88 40| 42 0f 00 00 00 00  ->  2d 04 01 |00 40| 42 0f 00 00 00 00

The change is confined to bytes [3:5] (each camera has its own idle value there). Because it is a brief pulse rather than a level held for the whole scan, selector 4/5 read as a per-capture arm/trigger, not a sustained "projector power" knob; the continuous illumination is likely driven by the streaming/pattern mode once armed. Selectors 4 and 5 on camera A are therefore the concrete control surface to replay.

Bounded write test (done, safe, negative)

With go-ahead, a careful bounded write test was run: while streaming camera A, read+save selectors 4/5, replay JMStudio's captured active values verbatim (SET_CUR to unit 3), capture a 30-frame burst, then restore. It was fully clean and reversible (values restored; device settled back to idle ff ff).

Result: the projector did not fire. All frames stayed at the projector-off baseline (Laplacian variance ~152, unchanged). And the read-back exposed byte 3 of selector 4 stepping ff -> 01 -> 02 across sessions — i.e. it behaves like a counter/status field, not a command input. Conclusion: selectors 4/5 are most likely status/config readback that changes as a side-effect of scanning, not the projector control. --watch can only see values change; it cannot tell a device write from a device-side status update, and this test indicates the latter.

Also ruled out (read-only): streaming at the scan resolution (1280×720) alone does not enable the projector — native captures at that mode show no pattern.

Net: the projector control is not a simple XU value replay.

USBPcap capture of JMStudio (done) — the extension unit is a red herring

A full USBPcap capture of JMStudio running a scan (decoded with scratchpad/parse_usbpcap.py) settles the direction question the read-only side could not. During an entire scan, JMStudio's traffic to the Fox was 100 % standard UVC, and it never touched the extension unit (unit 3) or the HID device (0c45:672e) at all:

VS_PROBE/COMMIT (iface 1, sel 1/2): format index 1, frame index 2,
                                    dwFrameInterval 1,000,000 (10 fps)
Camera Terminal exposure  (unit 1, sel 4): ~2-4 ms (short)
Processing Unit gain      (unit 2, sel 4)
...then isochronous video. No SET to unit 3, no HID reports.

So the whole extension-unit line of investigation — and the earlier bounded write test — was aimed at the wrong entity; that is why the write did nothing. The 0c45:672e HID device is confirmed unrelated to scanning (silent throughout).

Second capture (from cold) + replication attempts — projector NOT cracked

A second USBPcap capture taken from a cold power-cycle (Fox just replugged, JMStudio never opened, then JMStudio launched during the window) showed the same thing at device connect: 100 % standard UVC, no extension-unit write, no HID output report (the HID device only sends input reports, it is never commanded). JMStudio's committed video format is format 1 / frame 2 = 640×480 YUY2 @ 10 fps (dwMaxVideoFrameSize 0x00096000 = 614400 = 640×480×2), then SET_INTERFACE to start streaming, then CT AE-mode manual + exposure (~2–4 ms) + PU gain. Nothing else.

Replication attempts via our own standard-UVC streaming, checked with a rigorous discriminator (very short exposure isolates a bright projected pattern as dots-on-black; ambient goes black):

variable tried result
640×480, 1280×720, other resolutions projector off
10 fps (JMStudio's rate) vs 30 fps off in both
single camera vs both cameras streaming (controlled, same exposure) identical — both pure black
exposure ladder −7…−13 collapses to black; no dots-on-black

Earlier apparent "pattern" sightings were confounds — a shiny metal mesh glinting at short exposure, textured surfaces, or exposure settings not applying in some paths — not confirmed projector activity. The one time the projector was genuinely latched on (bold stripes on a matte item) followed a JMStudio scan and did not reproduce cold.

Honest status: the projector-enable was not reproduced. It is definitively not the extension unit, the HID device, the resolution, the frame rate, the dual-stream condition, or exposure. The only remaining untested variable is the exact UVC media type / probe-commit bytes and control ordering committed via a DirectShow graph (OpenCV negotiates its own and may not match format 1/frame 2 precisely) — a significant instrumentation effort with uncertain payoff. Pending that, JMStudio remains the structured-light capture path; FoxStudio's native passive-stereo + factory calibration + full downstream pipeline stands on its own.

Confirmed: the Fox is single-shot structured light, and the calibration is on disk

JMStudio caches the full factory calibration per unit at <install>/download/calib_<SERIAL>.txt in plain text. For this unit it contains:

  • image size 1280×720;
  • both cameras as pinhole+distortion models (fx ≈ 2799 px), and the projector modeled as a third camera;
  • extrinsics: camera↔camera baseline 32.36 mm, camera↔projector 57.6 mm;
  • a 128-entry projector column→ray lookup table;
  • the fixed projected pattern: 246 rows × 6 symbols over a 4-symbol alphabet — a De Bruijn-style stripe code that is the same every frame (single-shot), so it can be decoded without capturing a sequence.

FoxStudio parses this file directly (foxstudio/fox_calibration.py) and uses it for native scanning, so no checkerboard calibration is required — the factory numbers are better than a user calibration. The checkerboard flow remains as a fallback for units whose file is missing.

Consequence for the roadmap: native scanning does not need passive-stereo texture. Once the projector is on, the two cameras see a strong known pattern, so either (a) plain SGBM stereo works well, or (b) the pattern can be decoded against the stored code + projector calibration for full structured-light depth. The only missing piece is the one-line XU command that turns the projector on — a device write, held pending explicit go-ahead.

What direct capture can do today

foxstudio capture grabs synchronized A/B stereo frame pairs straight from the UVC streams (close JMStudio first — it holds the cameras exclusively).

Path to full independent depth reconstruction, in increasing effort:

  1. Passive stereo — calibrate the A/B pair once (OpenCV stereoCalibrate with a printed checkerboard), then compute disparity with StereoSGBM and back-project to a point cloud. Works without touching the HID channel, but quality on textureless parts is poor.
  2. Pattern-assisted stereo — with the pattern projector on (leave a scan preview running, or replay the control commands once learned), textured stereo works much better with the same calibration.
  3. Full protocol — capture the USB control traffic JMStudio sends (Wireshark + USBPcap filtered to the two camera devices) to learn the UVC extension-unit requests for projector power/pattern sequencing, then drive the whole scan loop independently. This is the reverse engineering long game.

The practical near-term workflow remains: scan in JMStudio, export STL/OBJ/PLY/ASC, and run everything downstream offline with FoxStudio.

Other notes from the JMStudio install

  • C:\Program Files (x86)\JMStudio\<ver>\Config\scaner_settings_*.ini holds per-model tuning (camera brightness, projector power LightP, Poisson reconstruction defaults). Useful reference values for our own Poisson step: resolution=1.7, trim_value=2.0, islandAreaRatio=0.00005.
  • Bundled SDKs for MindVision/HK industrial cameras are for other scanner models in the JMStudio family, not the Fox.
  • Turntable control is a CH343 USB-serial device (COM port) when connected.
reddit.com
u/Electronic-Space-736 — 1 month ago
▲ 19 r/vscode

Copilot doing the "microsoft edge browser" tricks in VSCode, keeps reinstalling itself and forcing focus on copilot chat when I do not use copilot.

I use a bunch of other service, Claude, Codex, Cline, Roo. I do not find Copilot to be up to scratch but it seems to keep forcing itself back into focus, I cant remove its chat window, I will be working with other LLMs and then bam, copilot chat is back in front answering my questions as it hid codex window and pretended to be codex.

Thinking about moving away from VSCode due to it.

reddit.com
u/Electronic-Space-736 — 1 month ago

Some issues with phantom stuck filament

I have pulled this toolhead apart three times now, there is no stuck filament (that I can find on any part when disassembled).

Every time I put it back together the preloaders just keep pushing filament in and it never detects that it has entered the toolhead until it jams.

Does anyone know where this sensor lives? or can I disable this warning as the toolhead will print fine manually when I hand feed it in and extrude

u/Electronic-Space-736 — 2 months ago

Terrible design choices

UPDATE: SnapMaker have informed me that they may not supply a replacement, they seem to think this is AOK

I would like to congratulate the engineer who decided to add this little clip to the heating block, perfectly positioned and spring loaded to pop off and bridge the positive and negative points on the thermistor wires.

Good Job. I love the magic smoke!

EDIT: I was trying to be humorous with the post, tongue in cheek, adding context.

It happened during a print causing the print to fail spectacularly, on a hardened steel nozzle .4, the nozzle itself was barely worn in (a dozen prints about). This was on toolhead1, I arrived to the machine to find toolhead 2 knocked from its perch, assuming something happened during a tool change that caused a collision and sprung off this clip directly onto the wire contact points.

Second Edit:

I have installed the old hot end and run a print, no issue with the machine or toolhead, just the hot end I think is no more.

Another note, the standard hot end I put in was better shielded around this area so may be a bad batch / early and may not be as common as it at first appeared.

u/Electronic-Space-736 — 3 months ago
▲ 40 r/OpenAI

This is obviously a defensive action being taken against a recent vulnerability, I am not doing anything sus here, these cloud services have been nerfed to uselessness.

u/Electronic-Space-736 — 4 months ago

Sorry I missed my post window last night, I was busy helping resurrect Roo Code with the Zoo Code crew, so here is yesterdays plugin offering for my open source pluggable local LLM home assistant.

To answer the problem in the title, when doing agentic work, the solution is git integration, review procedures and regular checkpoints.

So todays solution is a Code Review plugin, which covers this pain point.

- Review git diffs and staged changes
- Analyze code snippets for security and quality issues
- Detect patterns like SQL injection, shell injection, hardcoded secrets, weak crypto, XSS, path traversal, and more
- Build a summary report with risk level, file breakdown, and review checklist

It declares plugin permissions for worker tools, code-review.analyze, and the intake:tool-call hook.

It registers the review tools: review_diff, review_staged, review_code_snippet, review_security_only, review_get_context.

Core exposes plugin tools through pluginManager.listTools()

It is available as a cross-plugin capability too.

The repo:
https://github.com/doctarock/Code-Review-Plugin-for-Home-Assistant

Other Plugins:
https://github.com/doctarock/Auto-plan-Plugin-for-Home-Assistant
https://github.com/doctarock/Browser-Plugin-for-Home-Assistant-playwright-
https://github.com/doctarock/Philosophy-Plugin-for-Home-Assistant
https://github.com/doctarock/Wordpress-Bridge-Plugin-for-Home-Assistant
https://github.com/doctarock/Finance-Plugin-for-Home-Assistant
https://github.com/doctarock/Mail-Plugin-for-Home-Assistant
https://github.com/doctarock/Calendar-Plugin-For-Home-Assistant
https://github.com/doctarock/Project-Plugin-for-Home-Assistant

The core system:
https://github.com/doctarock/local-ai-home-assistant

u/Electronic-Space-736 — 4 months ago
▲ 4 r/LocalAIServers+3 crossposts

Hello, it's me, I know you missed me, I was so well behaved yesterday.

I am ready to throw the next plugin out to you ravenous wolves for my magnificent marvelous locally hosted ai assistant!

Today I am sharing a plugin which implements a borrowed concept that I thought was pretty cool and useful. Garry Tan shared his Gstack repository, and gave a good explanation of his design principals, and the package he had prepared to extend Claude code.

Since I am doing my own thing here adjacent to Claude code, but still wanted to channel a little Garry Tan in my AI, I wrote a plugin that implements his principals using my systems plugin hook infrastructure, in a minimal way.

It affects the system in four places:

It injects decision principles into prompts - workers are nudged toward completeness, blast-radius fixes, reuse, explicit code, and acting without unnecessary clarification.

It also influences intake/triage it injects the same principles into the intake prompt. That means the intake model may be more likely to enqueue work, avoid over-clarifying, and choose complete handling when routing requests.

The plugin registers autoplan_resolve, autoplan_principles, and autoplan_checklist, these expose a small heuristic decision engine. Workers or intake can ask “should I test?”, “should I fix everywhere?”, “should I create a helper?”, etc., and get a structured recommendation.

Other plugins can consume its capability.

I often keep my ear to the ground and try to incorporate new ideas into my code, even in a rudimentary way that can be expanded later, in the pre AI days you could only dream of the flexibility to try new ideas we have now.

The repo:
https://github.com/doctarock/Auto-plan-Plugin-for-Home-Assistant

Other Plugins:
https://github.com/doctarock/Browser-Plugin-for-Home-Assistant-playwright-
https://github.com/doctarock/Philosophy-Plugin-for-Home-Assistant
https://github.com/doctarock/Wordpress-Bridge-Plugin-for-Home-Assistant
https://github.com/doctarock/Finance-Plugin-for-Home-Assistant
https://github.com/doctarock/Mail-Plugin-for-Home-Assistant
https://github.com/doctarock/Calendar-Plugin-For-Home-Assistant
https://github.com/doctarock/Project-Plugin-for-Home-Assistant

The core system:
https://github.com/doctarock/local-ai-home-assistant

Gstack:
https://github.com/garrytan/gstack

u/Electronic-Space-736 — 7 days ago

Alright guys, the philosophy plugin was fun and interesting but I am going to give you something useful today. The next plugin for the local ai assistant I will be sharing is a dedicated browser daemon running playwright and a suite of tools for the agent to interact with it.

https://github.com/doctarock/Browser-Plugin-for-Home-Assistant-playwright-

This plugin adds persistent Playwright browser automation tools for worker tasks, including navigation, screenshots, element interaction, HTML/text extraction, and PDF export.

What it provides:

- browser_navigate
- browser_screenshot
- browser_click
- browser_fill
- browser_get_text
- browser_get_html
- browser_get_links
- browser_get_forms
- browser_evaluate_js
- browser_scroll
- browser_hover
- browser_type
- browser_select
- browser_wait_for
- browser_go_back
- browser_go_forward
- browser_reload
- browser_get_cookies
- browser_get_metrics
- browser_export_pdf
- browser_current_url
- browser_shutdown

I wont guild your lilies with any witty wordplay today, but a shout out to the guy who broke the fourth wall with a well thought out two character comment, go get it:

The repo:
https://github.com/doctarock/Browser-Plugin-for-Home-Assistant-playwright-

Other Plugins:
https://github.com/doctarock/Philosophy-Plugin-for-Home-Assistant
https://github.com/doctarock/Wordpress-Bridge-Plugin-for-Home-Assistant
https://github.com/doctarock/Finance-Plugin-for-Home-Assistant
https://github.com/doctarock/Mail-Plugin-for-Home-Assistant
https://github.com/doctarock/Calendar-Plugin-For-Home-Assistant
https://github.com/doctarock/Project-Plugin-for-Home-Assistant

The core system:
https://github.com/doctarock/local-ai-home-assistant

reddit.com
u/Electronic-Space-736 — 4 months ago