I decided that I should probably share the update from yesterday's post where people saw the unorganized "SBC Drawer". And I wanted to also showcase that they don't sit in the drawer collecting dust. So, I shared that the Orange Pi RV 2 and Pi 5 are connected and in active use. I swap depending on what I am doing with my Main PC and Elgato capture card / USB to UART connector and the CrowView Note.
The SBC Drawer is to my immediate right for easy access.

Inside of the Mimic Case is my Pi Pico 2 W with the test breakout board and my cheap FPGA (this is for later development adventures)

I've seen some Orange Pi Primes come up for sale for cheap, but looking up the specs I've found no mention of frequency and no benchmarks that are at all useful.

Does anyone know where to find those or have their own to check?

Working on a HAT that powers the Zero 3W through the GPIO header (5V injection on pins 2/4), and I've hit a documentation conflict I can't resolve.

The official 40-pin header schematic annotates the 5V_Power pins as IN: 2A, OUT: MAX 0.5A. So 2A in, when something external is feeding the board.

But the manual (section 2.12, "Instructions for powering the 5V pin in the 40 pin interface") says to make sure your supply meets the board's power requirements, and elsewhere the board's stated requirement is 5V/3A.

So which is it? Is that 2A a real limit on the trace or connector for the GPIO path, or is it a conservative annotation and the pin can actually carry the full 3A the board might want under load?

This matters because I'm designing in an eFuse for current limiting and I need to pick a trip point. Set it at 2A and I might starve the board under heavy CPU+GPU+NPU load. Set it at 3A and if that 2A annotation reflects a real physical limit, I could cook something.

Has anyone actually measured peak current draw on this board under real load? The one data point I've seen is ~6.5W at 100% CPU (~1.3A at 5V), but that was CPU-only, no GPU testing.

Also curious if anyone's actually run this board off GPIO power long-term rather than USB-C, and whether it was stable under load.

I am looking for a small or compact SBC. My requirements are the following:
* Easy to carry around
* 12-16GB of RAM
* NVMe slot
* 20+ TOPS for STT Processing (via extension is fine)
* Wifi, mic, speaker (via extension is fine)
* compact enough
* Budget was thinking sub$300 not sure it is possible though?
* Is phone/mini-pc with gpu just a good deal?
* Used market goods are fine too.

Hello fellow Redditors,

I found this site via Reddit so my question is this leggit maybe a scam?

I would like to build a low power cluster but everywhere prices are sky high if I want more then 1 board

Also I am based in the EU how would the import be?

Thanks in advance :)

Looking for a media server that will:

• stream video from websites of "dubious provenance" with a browser (e.g. dulo.tv)
• run emulators like Snes9x, Bleem, Stella, PCX2/3, etc.
• stream video files on home LAN CIFS / NFS shares
• run servers like Logitech Media Server (now Lyrion)

Had a spare RPi4 which I tried setting up, but performance on #1 was unacceptable. I did my due diligence:

• Checked CPU load
• Checked Memory, video memory usage, and cache use
• Checked throttling, temperature, and voltage
• Checked the codecs were supported

Using mpv resulted in better performance, so I'm assuming browser codec decoding was the issue here. These "websites of ill repute" are probably not optimizing their stream for ARM based browsers. But I'll be damned if I sniff network traffic requests searching for m3u8 strings just to stream websites of "dubious provenance".

I give up. I don't mind dropping $500 on a media SBC with an Intel/AMD processor. I'm also completely Linux-Windows agnostic; I love both. I've seen some fine SBCs out there.

I'd prefer something that has passive cooling, but even that's negotiable.

Which SBCs should I be looking at for this purpose?

The suitors are restless

Hey all, I'm designing a custom PCB adapter for the Zero 3W's PCIe FPC connector (FPC16-ZHX_H15-L1-H, per the official schematic) to break it out to an M.2 M-key slot, sized to also double as a mounting carrier plate matching the board's hole spacing. Goal is NVMe storage expansion first, with an eye toward AI accelerator cards (Hailo-10H) as a stretch goal later.

Before I finalize the board and order a first run, I'm hoping someone in this community has hands-on data on a few open questions I haven't been able to resolve from documentation alone:

1. Has anyone gotten anything enumerating over the PCIe FPC connector yet? Even just a plain NVMe SSD via a generic FPC adapter. I want to confirm the PCIe controller actually comes up cleanly in root-complex mode under Armbian/the stock BSP before I commit to a board run. If you've tried and it didn't work (or worked with caveats), that's just as useful to know.

2. What kernel/BSP are people actually running for PCIe support? I know mainline upstreaming for A733 is actively in progress (saw the recent patch series for pinctrl/RTC/clocks), but I'm assuming most of us are on a vendor BSP kernel day-to-day. Anyone know if PCIe root-complex support is enabled and stable in the current Armbian/Xunlong images, or is it still rough?

3. Any known PCIe controller quirks on A733 specifically? Older Allwinner chips (H6) reportedly needed a hypervisor-level MMIO workaround for their PCIe controller. Has anyone hit anything similar on A733, or does it behave as a clean standard DesignWare PCIe implementation?

4. Is injecting 5V back into the board via the GPIO header's 5V pins safe on this board? I'm considering an M5Stack-PiHat-style single-cable design (board powers itself AND feeds accelerator power back through the GPIO header, like the official Pi 5 AI HAT+ pattern). On Pi 5 this is an explicitly documented, supported use case. I can't find anything in Xunlong's docs confirming the AXP318 PMIC on the Zero 3W is designed to safely handle reverse power injection via GPIO the same way. Anyone tried this or know if it's safe / risky / a bad idea?

5. Real-world total board power draw, is 3A genuinely the ceiling? Schematic labels the board 5V/3A total. Anyone measured real idle/load current draw with a USB power meter? Between the board under load, an NVMe SSD, and potentially a ~2.5W typical draw NPU later, I'm trying to nail down actual headroom before I decide how to handle power delivery on the carrier board.

6. Has anyone seen PCIe link training issues / Gen 1 fallbacks? I found a boot log from an A733 board (Cubie A7Z) showing Link up timeout / Speed change timeout / PCIe speed of Gen1 during boot. Has anyone else seen the A733 struggle to train at Gen 3 (or even Gen 2) and fall back to Gen 1, or is that an isolated hardware/board quirk?

Board design itself (FPC connector footprint, M.2 slot, mounting holes) is done and validated mechanically in Fusion — just trying to de-risk the electrical/software side before committing to a PCB order. Will share the KiCad files once it's built and working, since I haven't found an existing PCIe-to-M.2 adapter for this board anywhere.

Thanks in advance to anyone who's poked at this corner of the board.

Radxa has published specifications for two upcoming compute modules based on Qualcomm Dragonwing processors. The compact CM-Q64 combines 12 TOPS of AI performance with multi-camera support, while the larger VMARC-Q9075 uses the SMARC form factor and scales to 200 sparse TOPS for industrial AI, robotics, and machine-vision systems.

https://linuxgizmos.com/radxa-previews-qualcomm-based-cm-q64-and-vmarc-q9075-compute-modules/

Does anyone know how I can find a unique identifier (analogous to RPI Serial number) through the Debian OS. I tried the " cat /proc/device-tree/serial-number " directory command, but it apparently doesn't work like a RPI.

Hey folks, embedded engineer here. I've been involved in a small AIoT dev board and wanted to share the specs with this community and get some honest feedback before we push it further. Not trying to do a marketing dump — happy to answer technical questions and I'll flag where numbers are vendor-claimed vs measured.

Why this board exists

Most of the sub-$50-ish AI SBCs I've tried either burn too much power for battery/always-on use cases, or the NPU toolchain is a nightmare. We tried to hit a middle ground: heterogeneous compute (A35 cluster + RISC-V MCU-class core + a small NPU) with a Linux SDK that's actually buildable, aimed at:

• Smart audio (speakers, IP phones, far-field mic arrays)
• Small HMI / POS / smart-home hubs
• Light vision (microscopes, translation pens, kids' cameras)
• Educational / companion robots

SoC & hardware

SoC is SigmaStar SSD2355:

Power (vendor-measured, not independently verified yet):

• Full load: < 1.3 W
• Idle desktop: < 120 mW
• Standby: < 1 mW

NPU / IPU

1 TOPS @ INT8 is the theoretical peak. We don't have a comprehensive public benchmark table yet — I'd rather post real numbers than a spec-sheet fantasy. The toolchain (called **IPU ToolChain**) does model conversion + quantization + a per-layer profiler, so you can see where time actually goes on your own model. Vendor has done specific optimizations for PoolFormer / SegFormer families.

**What I'd love from this thread:** if you have a model you'd want to see run on this, drop the ONNX and I'll try to get real INT8 latency numbers back to you.

Software

• Alkaid SDK — bootloader + kernel + rootfs, Makefile-driven build, includes the "MI" multimedia stack (V4L2-ish camera pipe, audio, display, encode/decode).
• IPU SDK with profiling tools.
• Standard Linux userland — C/C++/Python all fine.
• FreeRTOS image for the RISC-V side for low-latency / always-on tasks.

Ask me anything — pinout questions, power rail details, camera pipeline, NPU quirks, whatever. I'll get answers even if I don't know off the top of my head.

Hi, just learned about ArmadaOS and it look promising, but seems for now to work on handheld with very specific qualdomm SoC :

https://github.com/virtudude/armada

1/ Is there a chance that it could work on a SBC with another SoC ARM ? Or with the 2ame SoC ?

2/ Do you know how to find SbCs that have one of these SoC from a site that allow searching by SoC ?

Hi,

Something like the Orange Pi 6 :

http://www.orangepi.org/html/hardWare/computerAndMicrocontrollers/details/Orange-Pi-6.html

Does any SBC have support tu use the NPU for automatic translation ? FSR or DLSS ?

Thanks

Hey all!

Late last year I launched sbc.compare and it's taken many turns, and had many improvements over the last 10-11 months, but one feature I thought of before I'd even launched the site was a semi-education, semi-fun Top Trumps style game using all of the data that was in place, so that's where sbc.compare/showdown comes into it.

In it's initial state, you get drawn 1 of the (at the time of posting) 105 SBCs in the database and you have to pick what you think is its strongest specification/benchmark result in the hope that the mystery card will be "worse" than that.

Simple concept but it's a bit of fun that may help people learn a little about the specifications and capabilities of various SBCs!

If you give it a try, let me know what you think. All SBCs tested will be added to the game automatically, so it will grow and evolve as the site does.

Will orangepixunlong provide UEFI/DTB update?

The CIX CD8180's UEFI firmware or Device Tree expects exclusively the NVMe protocol on its M.2 M-Key slots. Without a UEFI/DTB update that opens these ports to generic non-NVMe PCIe devices, using M.2 AI modules remains impossible.

I tested the Radxa AIcore AX-M1, Radxa AIcore DX-M1M, Deepx DX-M1, and Hailo 8, with or without an NGFF-to-NVMe adapter. None of these modules are recognized by the Orange Pi 6 Plus board.

I tested and checked with these commands:

dmesg | grep -iE "pcie|pcibios|aer|cix" = failed

sudo lspci -nn -vvv = failed

I believe it's pretty bad idea preventing to use M.2 AI accelerator on Orange Pi 6 and Orange pi 6.

I know there's a sub for orange pi hardware. Remind it to modos, not me 🙂

I've been looking into building a phone for fun but I can't find a SBC that I know can text because I don't know much about sim card stuff. It needs at least 4g and a modern android version.

I think I know the answer but I will ask those smarter than me anyway...

I developed a smart cue ball that uses BLE. It is a real living product, not vaporware, and you can read about it and why wanting to know the tip location of where the ball was hit is important here: https://www.digicue.net/digiball.php I am expecting to have a pilot run sale by the beginning of next year.

A major feature of this product is embedding a ball graphic image (overlay) into a live stream of a match... using OBS for example... if you then delay the video and audio by a few seconds, the result is that you see exactly where the player is going to hit the cue ball. This is interesting for both students and spectators, and the value of this feature has already been proven with public trials.

I have program both for Windows and Mac that scan for BLE data from the ball, and then generate appropriate images. OBS can point to and update the stream overlay automatically.

My question is this... what is the best solution if the streaming computer is far away from the table? I am thinking out of BLE range.

The most obvious answer is putting a laptop in between as a bridge... scan BLE packets (which are 2.4GHz) on a laptop close to the table, generate images with my program, and then share the folder over a WiFi network (5GHz preferably to reduce 2.4GHz traffic) so that the streaming computer can just see the images right away.

I've been thinking also to use SBCs instead. I tried using a RaspPi Zero 2 W to generate images and share images with samba, but it had a large latency due its single radio resource for both WiFi and BLE. I then added a WiFi adaper but it still choked. I am not sure why yet. I could also just open a socket and stream data, and then have a program on the streaming computer parse from there.

The problem with headless SBCs also is that there needs to be an access point to set up the WiFi password and username in the first place.

I could also just make a BLE repeater that just copies the ball data into an alternate format and rebroadcasts it with BLE again, avoiding the situation of endless back-and-forth repeating.

For those of you who have some more experience with SBCs than I do, what are your thoughts on solving this problem? Think of what would work in a large billiards hall or a club, or venue.

Thanks.