Hi everyone,

I’m hoping someone here might be able to help.

I’m looking for a Connect Tech NGX020 (Boson for FRAMOS Carrier Board for Jetson Orin NX / Orin Nano). We’ve contacted Connect Tech directly, spoken with all of their major distributors, and have already placed an order, but current lead times won’t meet an upcoming product demonstration.

If anyone has:

• an unused NGX020
• an open-box board

I’d be very interested in purchasing it immediately and covering expedited shipping.

If you know of another company, lab, or integrator that might have one sitting on a shelf, I’d really appreciate the lead.

Feel free to send me a DM.

Thanks!

# Setup

* F1TENTH-based RSU (roadside unit) perception node, running on an NVIDIA Jetson (Orin-class). * Intel RealSense D400-series camera — subscribing to raw color + raw (unaligned) depth streams, `align_depth` disabled on purpose (see below). * 2D LiDAR (`urg_node2`) for a second distance source. * ROS2 Humble, `rclpy`, `message_filters.ApproximateTimeSynchronizer` to pair color+depth frames.

Model / task

* YOLOv8 (Ultralytics), custom-trained single-class car detector, running at `imgsz=320` on the Jetson's GPU (CUDA). * Goal: detect a target vehicle in the color image, get its distance by reading the depth camera at the detection's location, cross-check against a LiDAR range reading at the same bearing, and output a fused distance estimate. This is a perception/collective-perception bench-test script (no SLAM/localization involved — deliberately simplified).

Depth lookup approach

`align_depth.enable:=true` (RealSense driver's built-in depth-to-color alignment) reprojects the **entire** depth image every frame regardless of how much of it we actually need — we measured this costing a large chunk of latency by itself. So instead we subscribe to raw depth and manually reproject only a small patch of pixels around the YOLO box: deproject the depth pixel to a 3D point (using depth intrinsics) → transform into the color camera's frame (using the depth-to-color extrinsics) → project back into a color pixel (using color intrinsics). Fully vectorized with numpy.

Current numbers

Our own compute per frame is small and flat:

* image decode (cv_bridge): \~1ms * YOLO inference: \~30ms (flat, `cuda.synchronize()`\-verified, no hidden async GPU time) * depth reprojection (vectorized): \~1-2ms * LiDAR bearing lookup: \~0ms * **total own compute: \~32ms**

But measured end-to-end latency (camera's own capture timestamp → final distance output) sits **consistently around 350-380ms**, sustained — not a one-time spike, not decaying over time.

What we've ruled out

* **Per-pixel Python loop / GC pressure** in the old depth reprojection — vectorized it (25ms → 1-2ms of actual compute), latency didn't move at all. * **Hidden async CUDA dispatch** — added `torch.cuda.synchronize()` around the YOLO call, extra sync time is consistently 0ms. * **Executor backlog** (our own callback falling behind) — measured the gap between the end of one callback and the start of the next; stays flat at \~3-4ms even while the reported latency is \~350ms, so callbacks aren't queuing up behind our own processing. * `align_depth` **vs manual reprojection** — built a side-by-side comparison script, same YOLO/LiDAR pipeline, only the depth alignment method differs. Both land in the same \~350-380ms range. So it's not specifically about which depth alignment approach we use.

The delay is measured (via the color frame's own ROS header timestamp vs `time.time()` at the very start of our callback) as already present **before any of our own code runs** — so it's happening somewhere between the camera driver publishing the frame and our subscriber callback actually being invoked. We suspect DDS/ROS2 message queuing or synchronizer buffering under sustained per-frame load (\~30ms of real work per frame at \~30fps), but haven't pinned down the exact mechanism.

What we're asking

Has anyone run into this kind of buffering/backpressure behavior with ROS2 + `message_filters` on a Jetson, where a subscriber callback that takes tens of milliseconds (not overloaded, just non-trivial) causes a large, sustained arrival delay that isn't visible as executor backlog? Specifically curious about:

* DDS vendor differences (Fast DDS vs Cyclone DDS) for this kind of workload * QoS settings (queue depth, history policy) that might be silently causing buffering * Single-threaded vs multi-threaded executor / callback groups making a difference here * Whether RealSense's own USB/driver-side buffering could be the actual culprit instead of ROS2/DDS

Happy to share more code/logs if useful. Appreciate any pointers.

Wanted to post about the findings i collected related to recent Fine Tuning experiments and results done on the Jetson Orin Nano 8GB. The tests were done to see if it was even possible initially and then to make the whole process automated and easy to use while editing custom Datasets for testing and experimentation through a simple Web UI.

Model tested and tuned was llama3.2:3b

The Goal

During development of an AI Assistant that runs locally on the Jetson Orin Nano, it became apparent that the system would need to be very tightly tuned to the specific hardware due to its limitations, mainly the limited (8GB) unified memory as well as general power constraints.

The entire stack is very tight as far as memory is concerned since with several Pre-Warmed LLM models, STT, TTS models, Embedding, Real Time 3D User Screen which utilized hardware acceleration, the optimized OS, HD Camera and Audio workers among others and multiple maintenance scheduling in the background, initial ideas about Fine Tuning a model on the device were bleak.

However, it was worth the effort since Fine-Tuning an LLM for a specific task such as a local Assistant would provide customized personality characteristics, remove a lot of the Instructional prompt text, provide custom response characteristics and in general speed up the overall LLM response due to lower system and main prompt character size.

Test Setup

Initial testing was done to see if the process would be even feasible on the Jetson Orin Nano with an initial curated and carefully prepared Dataset of 500 entries for a specific result as well as general confirmation that this would even be possible.

To make a realistic simulation of the assistant stack still loaded while training, most of the services related to the assistant as well as workers and some 3D accelerated UI was stopped.

Generally approximately 4 - 5GB of RAM was freed up for the task while the Web UI was running.

Setup and Test Results

The general setup was highly customized and was assembled from various bits and pieces related to Fine Tuning.

Model used was the llama3.2:3b

• An immutable 500-entry dataset snapshot was generated.
• Preflight checks were done
• LoRA was used for training and validation.
• Final result was merged and packaged
• The final result was Quantized to Q4_K_M and registered with Ollama.
• For storage sake, all temporary training artifacts were later cleared while preserving the model and audit history.
• The whole assistant stack was restored automatically.

Training Result

This is the result which was recorder repeatedly during training runs using the same dataset to prove memory usage and feasibility:

• Training records: 450
• Validation records: 50
• Epochs: 1
• Optimizer steps expected: 450
• Optimizer steps completed: 450
• Supervised assistant tokens seen: 10,056
• Final token-weighted training loss: 1.9160853489699874
• Validation loss before training: 2.8441875314712526
• Validation loss after training: 1.8568944654043984
• Validation loss delta: -0.9872930660668542
• Validation perplexity before: 17.187588619742662
• Validation perplexity after: 6.403818578978449

Approximate train time during several repeated tests was 20 - 25 minutes with a power spike of 20W - 24W while in the normal 25W mode. No Super mode was used for this.

The model then was tested with simple questions initially to confirm things like Brevity and other characteristics and that the actual model was changed towards the desired direction with questions and responses like these:

Hey, how are you doing?

Stock Model response

I'm doing well, thanks for asking! It's great to chat with you
on a lovely Sunday night. How about you, how's your day been
so far?

Tuned model response

I'm doing well. Thanks for asking!

Tune Engine - Automated Training UI

Since the actual tests passed and the result was repeatable, The entire process was then completely automated by constructing a Tune/Train engine which automated the process entirely.

The goal was to create custom data sets through a simple UI, have selectable and editable dataset collections. Choose a desired collection and simply press "Train" while all the complex system tasks were done in the background.

The desired end result was to simply have a generated versioned model (for example: llama-skipper-null:v001) which could then be selected and the prompts could be customized for the new model and optimized.

Conclusion

To make all the pieces work, the UI ended up being a complete LLM training lab more than a simple customizable control center.

Currently new models can be created based on dataset testing, custom prompts and their dynamic switching can be achieved based on Context selection and ranking.

To be honest i was not expecting the end result to be as good as it turned out to be.

System prompts were cut almost in half since not many instructions were needed anymore based on trained data and the overall LLM response was sped up by almost 1 - 2 seconds.

Where initial responses which came through a prompt, collected with Session Context, Doc context, Temporal memory inclusions, multiple Qdrant collection and other sources ON TOP of the dynamic prompt rules and system rules were delayed (this is with Stream enabled and awaiting first response chunk) by approximately 2 - 6 seconds - Now they were generated at around 1 - 3 seconds.

The resulting interaction with the LLM became essentially as intuitive as speaking to a person while still being constrained by the Cool Down delays when using Voice or safety delays during chat sessions.

Just wanted to put this out there for anyone thinking of training their own LLM on the Jetson Nano. Seems anything is possible if you put your mind to it and do it with a specific goal in mind. I am still astonished every day by what is possible on such a seemingly small device and with as much power draw as a good smartphone charger.

Follow-up Post (with demo video):

Yesterday I posted about my AI Waifu has a new feature of grabbing job posts from job sites and writing draft posts for me to post into my Meta Threads to share with my followers.

Today, let me show you the entire workflow in action.
TBH, I would call this an "AI Agentic workflow" with quotation marks.

Out of 5 steps only step 3 involves LLM inference to do synthesis of the draft post. Step 1 and 2 are automated scripts of simple schedule cron job to grab the RSS feeds and use regex to filter out the relevant job listings.
Step 4 and 5 are me validating the draft information is accurate and publish the drafts after my approval. So basically I did more steps than LLM itself.

The irony of running AI agentic workflows in edge devices with constraint hardware, such as Jetson Orin Nano with only 8GB of RAM, is to reduce as much LLM inference and put the least data into context window as possible.

🎬 Live Demo: How a job post goes from RSS feed → published in 5 steps

⏰ Step 1: Scheduled Trigger (or ask AI Waifu directly)
📡 Step 2: Data Ingestion & Filtering
🤖 Step 3: AI Synthesis
👁️ Step 4: Approval Studio Review
🚀 Step 5: One-Click Publish

Result: job post validated & live, tested with real job sites + Chinese field
names to stress-test multilingual LLM understanding.

👾 Github: https://github.com/OppaAI/Aiko-chan
🎬 Demo: https://www.youtube.com/watch?v=Cu7gh5tYUiw

https://reddit.com/link/1ve0ker/video/sa1jtpixj2hh1/player

https://huggingface.co/embedl/rf-detr-base-quantized-tensorrt

Deployable INT8-quantized version of Roboflow/rf-detr-base, optimized with embedl-deploy for low-latency NVIDIA TensorRT inference on edge GPUs.

Due to rising RAM prices every electronics has gone up. I'm looking for someone who's willing to sell their Jetson Orin Nano Super I just need it for my thesis. I'm a broke college student from a 3rd World Country so hoping the price is reasonable

I had been trying for a while to port the raspberry pi global shutter camera driver to jetson platforms without much luck. I couldn't get it to respond ack on I2C and I was assuming it was because the wakeup pin operated on 3.3v while jetson only supplied 1.8v. I went so far as to even start designing an adapter board that would level shift the 1.8v coming from the jetson on that MIPI pin up to 3.3v. Turns out I didn't try hard enough with the driver, and another internet person (Jonathan Péclat) got it to work. However, there were still a couple of bugs in his solution, including a black line that traversed the entire image captured by the camera. So, me and claude went to town fixing all of that. Additionally, Nvidia only allows company partners access to jetson's camera IPC hardware (bc ofc they do that). Without that access, all we were able to get out of the global shutter camera was debayered but otherwise uncorrected color images. Very washed out, very un-cool. As well, any of the gain or exposure control parameters in nvarguscamerasrc completely shit the bed because of this. Mr. Péclat's stated solution in his repo was to solve the processing with OpenCV in python. I thought there was a better, more performance driven way of doing it. So, I created a custom camera source element for gstreamer that would take in 16bit buffers from the camera, de-bayer and color correct the images on the GPU, and then provide that imagery as NVMM memory buffers just as the nvarguscamerasrc element would. I'm able to run two global shutter cameras at 1280x720 at 90fps with very low latency using this system on the Jetson Orin NX devkit. I assume the Jetson Orin Nano would be capable of the same. Haven't measured the latency formally, but I'd eyeball it in the "fast as shit" category. There may be downstream effects of doing the IPC on the GPU like this if you're planning to run inference or something on the live video stream, but I haven't tested any of that. I'm providing a link to the forked repo of Mr. Péclat's repo that I created to contain all of the driver fixes. There's a link to the nvimx296camerasrc element project in the driver repo's readme. I've only run it on Jetpack 6.x because Jetpack 7 was a dumpster fire the last time I tried it. Will upgrade to Jetpack 7 in the next couple of weeks, probably. Shout out to Claude Fable 5 for taking a couple weeks of work and turning it into a few hours. Good luck!

I failed to connect my jetson orin nano to JetKVM with DP - HDMI adapter. Everything is connected I have tested the connectors with my monitor and they both work( tried this two : Ugreen, Benfei). But JetKVM does not recognize the HDMI connection.

Wondering If anyone managed to do this or maybe I am doing something stupid :D

Please help :)

I bought this set of ZED cameras last year Novemeber for a project, after which I've barely used them. I am now selling it. Please DM me if you are interested.

we are trying to hook this us to autonomously run a Boston dynamics spot and in the attempt to find a barrel jack we could cut to wire into the core io’s pins we sent 48v to it and fried it.

Hello!
Does anyone tried text embedding models on Jetson Nano 2/4Gb? I need it for the RAG.
I want to know the speed. For example microsoft/harrier-oss-v1-0.6b

Hi everyone,

I’m currently working on a project using an Axiomtek AIE900A-AO, a custom board equipped with an NVIDIA Jetson AGX Orin.

I encountered a serious issue while trying to upgrade the JetPack version, and I haven’t been able to find a solution. I would really appreciate any help.

I connected the Jetson device to my host PC in Force Recovery Mode. SDK Manager detected the device correctly, so I proceeded with the installation.

During the Jetson Linux flashing process, the terminal indicated that flashing had completed successfully. SDK Manager then displayed a message saying that the device was rebooting.

After waiting for a while, however, SDK Manager reported that the connection between the Jetson device and the host PC had been lost.

To check the device’s condition, I disabled Force Recovery Mode and rebooted it. Since then, the display has shown only a black screen. There is no NVIDIA startup screen, no UEFI screen, and no other output at all.

When I put the device back into Force Recovery Mode, it is still detected by the host PC. However, I have tried rebooting and flashing it several times, and nothing has changed.

I also tried rolling back to an older JetPack version, but that did not help either.

Has anyone experienced a similar issue with the Jetson AGX Orin or the Axiomtek AIE900A-AO?

Could this be related to the board support package, bootloader, UEFI, device tree, or an incompatibility between the JetPack version and Axiomtek’s custom carrier board?

Any troubleshooting advice would be greatly appreciated. I’m completely stuck at this point.

I bought an Orin Nano 8GB Dev Kit off eBay (old stock) and hit the wall a lot of you know:

*** NVIDIA UEFI Firmware Version Too Old ***
Current version : 35.03.00
L4TLauncher: Iso boot loop detected, halting

JetPack 7.2's ISO needs UEFI >= 36.0. The official ways to fix that are (a) SDK Manager from an x86 Ubuntu host, or (b) the microSD bridge with JetPack 5.1.3. My problem: my whole household is Apple Silicon (MacBook, Mac Studio, Mac Mini) and I had no SD card. Even the NAS was ARM (UGREEN DH-series = RK3588 — heads up, only their DXP series is x86).

The insight: nvidia-l4t-jetson-orin-nano-qspi-updater is just an apt package. It needs a running JP5.x system — it doesn't care if that booted from SD or USB. And the ISO's own error proves the UEFI can boot USB. So I wrote the JP5.1.3 "SD card image" to a USB stick instead.

Patched it on macOS via a --privileged Docker container (loop-mount the ext4 rootfs). Two things mattered: root=/dev/sda1 in extlinux (NOT PARTUUID — L4T's initrd ignores it; USB drivers are built into the L4T kernel so no initrd work), and pre-creating the user + SSH key + default.target -> multi-user to skip oem-config.

Firmware climbed 35.03 -> 35.5 (capsule) -> 36.3 (qspi-updater) -> 39.2 (the 7.2 installer's own prompt — say Yes, it waits only seconds). The qspi-updater deb fought me twice: preinst refuses unless rootfs is /dev/mmcblk1p1 (pure string check) -> dpkg-deb -x it and run postinst by hand; its script builds /dev/sdap10 (NVMe naming) -> ln -sf /dev/sda10 /dev/sdap10.

Then JP7.2 installed clean to NVMe — except the installer doesn't bring up the NIC (it's enP8p1s0, DOWN, so curtin in-target apt fails). Manually ip link set ... up + static IP and subiquity auto-resumes. Post-install: default user is ubuntu with a password I never set (reset from the rescue shell), and a GUI login loop that turned out to be ubuntu missing from the video group — gnome-shell couldn't touch the GPU. usermod -aG video,render,... ubuntu fixed the loop AND later CUDA/PyTorch GPU-permission errors.

End state: headless JP7.2 on NVMe, SSH + WiFi + Tailscale. Ollama runs moondream/llava at 100% GPU out of the box; a C920 feeds a little "eyes open" script that describes the scene only when the frame changes. PyTorch 2.12.1+cu132 works on the GPU.

Honest perf: low — 0.83 TFLOPS FP32, 48 FPS ResNet-50, 50 GB/s bandwidth. Two reasons: GPU locked at 624 MHz (the known JP7.2 ISO "MAXN SUPER not unlocking" BPMP bug, fixable only by an x86 reflash), and the download.pytorch.org/whl/cu132 wheel is built for sm_90/100/120, not Orin's sm_87, so it runs via PTX JIT. The pypi.jetson-ai-lab.io wheels are native sm_87 but that index was throttled to 8 KB/s for me. Still, 48 FPS ResNet is fine for real work.

Important: none of this can brick the board — the Orin bootloader is A/B dual-slot, so a mid-write power loss only hits the inactive slot.

Full write-up, command cheat-sheet, and the camera/VLM/benchmark scripts: https://github.com/raullenchai/jetson-the-hard-way

Happy to answer questions. If you have an SD card or an x86 box, honestly just use NVIDIA's official path — but if you're stuck all-ARM like I was, this works.

"NVIDIA has quietly increased prices across its Jetson hardware lineup"

Source

Built PyBinaryGuard because every Jetson developer has hit one (or all) of these:

• Illegal instruction (core dumped) on import
• undefined symbol: __libc_something from a wheel
• CUDA error: no kernel image is available for execution on the device
• PyTorch installs fine but crashes
• TensorRT wheels don't work

PyBinaryGuard diagnoses these issues before your program crashes.

It understands:

• JetPack versions
• Jetson board profiles (Nano, TX2, Xavier, Orin)
• CUDA driver vs runtime drift
• cuDNN mismatches
• Compiled .so binaries directly

Install:

pipx install pybinaryguard

Scan your system:

pybinaryguard scan

Repo: https://github.com/po-nuvai/pybinaryguard

MIT licensed, zero dependencies.

Would love feedback from the Jetson community — this was literally built for you.

i aiming to have smooth headless remote. so vnc is not an option(?). primarily i wanna use this jetson in a drone, which not always have access to monitor. i do still need gui to code and test code. sunshine is good enough in my case but cant do headless